Sub-band handling for LoRaWAN EU868 Band

[cameronkordy (jabroni)]

Is anyone here familiar with the LoRaWAN on TTN and the EU868 band? I am trying to figure out how to modify the sub-band it operates on. By default, it appears that the JOIN_REQUEST message returns a value which sets the 3 default frequencies (868.1, 868.3, 868.5) and the remaining 5 (867.1, 867.3, 867.5, 867.7, 867.9). To modify the sub-band in other regions, i have written a function that sets the ChannelsMask field depending what value is passed by the user. This works becuase Nvm.RegionGroup2.Channels array is set with all operating frequencies, but the EU band just seems to operate on the 8 frequencies I listed before.

I feel like I’ve gone down the rabbit hole and travelled further away from the solution I need. Does anyone know how sub-band setting for this region actually works? Been banging my head against my desk for the past 2 days on this so any guidance will be much appreciated

[kersing (Jac Kersing)]

Are you familiar with the LoRaWAN regional specifications and LoRaWAN specification documentation? Those describe the mechanism and standard frequencies/spectrum for regions.

It would help is you tell us what you are trying to achieve (and why). You current question leaves a lot to guess and our crystal ball has worn out years ago. (Are you changing things server side? On the end device? Why?)

[Jeff-UK]

From your own description all is as it should be! TTN uses 8 channels in EU and no other sub band options unlike say AU or US where there are more channels available (up to 64?) and therefore a mechanism to select a sub band -even then there are specific bands that are relied on for TTN use. So, as I see Jac has asked, what are you looking to achieve? If you change EU channels it won’t be on TTN community network….

[descartes (Nick McCloud)]

@cameronkordy

Does anyone know how sub-band setting for this region actually works?

Yes. Many do. TL; DR:

There is no sub-banding. So in a rather meta-way that pleases my forum name, it neither exists as there aren’t any and exists as a single entity.

I may be wrong (not unusual) but I liked my answer too much not to post.

Any further discussion will have to involve answers to the questions above. Particularly as all the alterations that you’ve made to the LMn code base will largely be countermanded by the LNS with the settings on an OTAA join - unless you are trying to speed up the join by restricting the frequencies initially used.

[KrishnaIyerEaswaran2 (Krishna Iyer)]

@cameronkordy

Does anyone know how sub-band setting for this region actually works?

My first question is why do you need to work with a different set of frequencies?

Background

The EU868 band does not technically have a concept of a sub-band. The three default frequencies (868.1, 868.3, 868.5) are mandatory and operators have a choice to define the other 5 channels.

Operators are allowed by the LW Spec to choose any frequency range in 863 - 870 MHz (IIRC) as long as the spacing between channels is at least 200 MHz for interference reasons.

TTN community network historically uses 867.1, 867.3, 867.5, 867.7, 867.9 and hence that’s the default option that is available for selection.

I’m not exactly sure of why we stick to these frequencies as this was before my time. But afaik this is historical based on performance and gateway availability.

Choosing custom frequencies

As mentioned earlier, the spec allows us to customise the 5 non-default channels. For the sake of manageability and potential debugging, we do not allow users to inject custom frequency plans in The Things Stack Community Edition.

However, you can run the open source version of The Things Stack and customize the frequencies by forking GitHub - TheThingsNetwork/lorawan-frequency-plans: LoRaWAN Frequency Plans for The Things Stack and adding your custom channels.

If you run some tests and show us some data that your sub-band is helpful to the community, you can submit a pull request to GitHub - TheThingsNetwork/lorawan-frequency-plans: LoRaWAN Frequency Plans for The Things Stack to list the plan as one of the options.

Side Note

Btw, quick side note; we group these in sets of 8 because we assume that all gateways have a minimum of 8 channels on which they transmit/listen.

[cameronkordy (jabroni)]

@KrishnaIyerEaswaran2

My first question is why do you need to work with a different set of frequencies?

A client has requested for the ability to operate on different sub-bands within their region for multiple different regions. I should note that the customers our client sells to may not always be on TTN and could instead use some other stack.

Thank you for your explanation. I figured for this band it would be harder to modify than the others because the TTN stack is pre-configured to use the 5 pre-defined channels which are sent during the join request field.

I’m not entirely sure how to use the YAML files in repo you provided. Are they meant to interface with the .c files, or are they gateway configuration files?

I’ve just had a thought however - if a customer in the EU region wants to change the band they operate on, then isn’t this something they can modify in their gateway configuration?

[cameronkordy (jabroni)]

Hi Jac,

Yes I have read through the Region Parameter documentation (still trying to wrap my head around it as the documentation is not really newbie friendly), but from my understanding the EU band operates on 3 MUST HAVE frequencies, and 5 optional frequencies. The optional ones are set by TTN (867.1, 867.3, 867.5, 867.7, 867.9).

@kersing

It would help is you tell us what you are trying to achieve (and why). You current question leaves a lot to guess and our crystal ball has worn out years ago. (Are you changing things server side? On the end device? Why?)

I have a device that is used in multiple different regions around the world. Previously, these devices would use their default bands. I am not changing anything server side - this is handled by the customers, and instead I am modifying the LoRaWAN code to handle a sub-band value. For the AU915 band for example, what happens is that the user supplies a sub-band value (1-9), then depending what is passed through, the channelMask array is modified (using something like RegionNvmGroup2->ChannelsMask[0] = 0x00FF;). I was hoping to replicate this through all bands, but this proved to be a little more complex as I learnt more and more about each region.

[Jeff-UK]

@cameronkordy

I should note that the customers our client sells to may not always be on TTN and could instead use some other stack.

This is the TTN Forum, for the TTN Community funded & paid for by TTI and run by the Forum volunteers for the benefit of the Community. What you are looking to do is outside the scope of this and perhaps better addressed on a more generic LoRaWAN forum or that for the alternate stack/LNS operator you may be targetting. It may be that some of what you would want to look at could he handled with a private or OS instance of TTS, so perhaps approach TTI team as a commercial client, though still wouldnt help you much if ‘some other stack’ is not TTS based, especially if you are doing this commercially;

@cameronkordy

A client has requested for the ability

Note TTS - in both is CE and Enterprise versions already supports a number of sub-bands and alternate channel plans where approriate for each region, which may be enoug for you. If not already done so look at the options available to you when registering a GW:

[kersing (Jac Kersing)]

@cameronkordy

this proved to be a little more complex as I learnt more and more about each region.

Yep, it’s complex. EU868 does not have subbands like US915 or AU915 so that mechanism doesn’t work. However the good news is that for OTAA on EU868 you do not have to do anything at the end device. The network server will provide the device with the 5 additional frequencies used when it joins using one of the mandatory frequencies.

The customers need to make sure their network server and gateway configurations match. If the network server instructs the device to use 867.1MHz as one of the frequencies the gateway needs to be configured to listen for transmissions on that frequency.

Looking at your questions it seems you are implementing the device stack from scratch which is a lot of work and hard to get right. The existing reference implementations like LoRaMAC-node handle all this for you, you just need to use the right defines.

[descartes (Nick McCloud)]

@cameronkordy

A client has requested for the ability to operate on different sub-bands within their region for multiple different regions

So, same as everyone else selling kit then. Seems your first outing with LMn isn’t just implementing it but making fundamental changes to its core - which is going to bring in to question all levels of certification queries.

@cameronkordy

I should note that the customers our client sells to may not always be on TTN and could instead use some other stack.

Leaving aside for a second what @Jeff-UK highlights above, this still doesn’t matter, because the 3 join frequencies are set and the other five will be set with the join accept - so there is still no work for you to do on this.

@cameronkordy

because the TTN stack is pre-configured to use the 5 pre-defined channels which are sent during the join request field.

This makes it sound bad when it is just the choice of TTI, just like all the other EU based providers would make a choice of their five channels. If you run your own setup, you can choose your own five channels, this does not make you a bad person.

@cameronkordy

if a customer in the EU region wants to change the band they operate on, then isn’t this something they can modify in their gateway configuration

The band or the channels? The band would run in to legal issues. The channels, sure, but you must know this by looking at your global_conf.json?

@cameronkordy

still trying to wrap my head around it as the documentation is not really newbie friendly

It’s not designed for newbies. It can’t be formatted for newbies. It’s a formal spec that has been accepted as an international standard. This is normal. What’s not normal is trying to do what you are doing without making enquiries on somewhere like here before you started messing with some of the most complex code that just has to keep working day-in, day-out for years.

I would also suggest that perhaps your client is coming up with ideas & problems due to a lack of understanding of the details & consequences. Between you both, you run the risk of deploying kit to end users and then finding an issues that totally borks the whole system that can only be resolved by retrieving the devices for a firmware update - assuming it is possible to figure out which moving part is causing the problem.

I’ve experienced this situation a couple of times and it has taken days of testing to identify the issues at hand. In one instance it wasn’t my code that caused it, it was a clash between the LMn version and the LNS and the specifications - the LNS was updated to take account of new specification details but it relied on a new version of LMn than the core vendor (ST) had not yet made available.

At the very very worst, LMn comes with the bands all setup, it just takes a bit longer in some regions to join as it uses channels that aren’t in use, but it will get there in the end. The simplest alternative is to change the channel masks in the code to suit the region & LNS.

By your own admission you are just starting out which is hard enough with LoRaWAN. Once you’ve shipped a few devices to EU, US & AU and gone the hard coded channel plans route, then you could look to feed the channel plan changes in programatically.

But mostly, thank you for creating such a perfect case study!