Regional Parameters

Hi All,

Am a bit confused regarding the Regional Parameters in the Device profile. It states that it can be set to A or B, but what does A or B mean?

I have devices with loraWAN 1.0.2 MAC version and no idea what to set the Regional Parameters to. The Device is an 868Mhz freq.

I have read the LoRaWAN specification and it states the following:

This seems confusioning as the table suggests any LoRaWAN 1.0.2 devices should be B.

Is this correct?


1 Like

The Regional Parameters are region specific values which are defined outside the LoRaWAN specification. Examples are the defined channels, max payload sizes, data-rate to spreadingfactor/bandwidth mapping, tx power mappings etc… These might be updated over time independent of the LoRaWAN MAC version.

You will find these specifications at:

1 Like

Hi Brocaar,
Thanks for the link.

I have read through the spec somewhat, but can’t make the link to A or B on the GUI.

Can you point me in the direction of GUI docs that explained these options and other options on the page.

Sorry for any inconvenience.


You can configure this in the Device Profile.

But what does ‘A’ mean and what does ‘B’ mean? I cannot find any reference to these either.

They are part of the version number. For example:

1.0.2 revision B


I’d also like to get this straight. Is the following correct?

Each LoRaWAN version attempts to make it possible to adhere to the latest Regional Parameters, which are set by law in their respective regions. These Regional Parameters are described in documents released by the LoRa Alliance, which have names like, for example, v1.02rB, which in this case would indicate that in order to adhere to the Regional Parameters described in that document, you must (?) use LoRaWAN v1.02 and use your devices according to the Regional Parameters in that revision of the specification, in this case B.

So it is the responsibility of the End-node user to use the devices in adherence to the Regional Parameters, which involves stuff like not exceeding payload size, duty cycles, etc.

If this is correct, then why do we need to specify the revision in the Device profile? Does the Application Server have some mechanism to help enforce adherence to the Regional Parameters?

The device profile configures operation according not just to regional parameters, but to the LoRaWAN spec. The network server operates different depending on version. 1.0.3 vs 1.1 significantly, 1.0.2 vs 1.0.3 subtly (potentially), etc.

This is also driving me little nuts.

So far, on CS, we have: (as of this date)

  • LoRaWAN MAC version (1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.1.0)
  • Regional parameters

The issue I run into is selecting the revisions when , for example, setting up for a devices running LoRaWAN MAC version 1.0.3. In this case, I can choose regional parameter revisions of A, B, RP002-1.0.0, RP002-1.0.1, and RP002-1.0.2.

I would have assumed that the regional parameter version are denoted by the first part of the filter (A, B, RP002). Any additional identification (e.g. ‘[whatever]-1.0.0’) is intended to target a specific LoRaWAN MAC version. In my case, I would therefore avoid using RP002-1.0.0 through to RP002-1.0.2, assuming there was some sort of filtering missing in this selection menu. In otherwords, I would, only use A, B [1] or RP002-1.0.3 (assuming this “RP” became available), for my device using LoRaWAN MAC 1.0.3.

Apologies if I’m being obtuse. This can get very unclear when also trying to work with device manufacturer docs, which can often use vauge or incorrect documents names and identifiers. Too many degrees of freedom here! I think some blame also lies with the LoRaWAN Alliance but, alas, this is where we come for all the answers.

I’m sure it makes sense once you get it.

[1] Is there even a revision B for LoRaWAN 1.0.3 regional parameters??

1 Like


According to the chirpstack lorawan repo

which contains band-related settings, you can see in those structs, for example in the 868 band, that the regional parameters define the maximum payload lengths (mac and app data). That is what the RP is about there.

The only places where I can see that the regional parameters plays a role is in downlink code (fuota, multicase, unicast) which makes sense.

Also the function GetMaxPayloadSizeForDataRateIndex (see lorawan repo again) will use the ‘lastest’ settings ( a constant) as default if the given regional parameters depending on the MAC Version you choose.

In the example of US902 band source file you can see that the MAC version already pre-selects the regional parameter revision for each distinctly defined mac version because they only contain one setting which the ‘latest’ setting which means whatever RP you choose it does not matter because it defaults back to the ‘latest’ (in case of the us band), it does only matter if you choose a mac version which is not in that list, thus falling back to ‘latest’ setting, so the rule is, the MAC version your device implements will determine the regional parameters for you.

To find out for your device and band which RP has which setting just have a look into the lorawan repo.

I am not sure if the current implementation was always like this, you would need to go back the file history to find out. I can remember back to 2018 that there were interesting behaviors to observe in regard to the chosen RP, and that it might have been related to TXPoint for the ADR algorithm back then, so I guess something must have changed.