Hi guys,
I’m looking at the LinkADRReq byte content, and am wondering the following:
The channel mask has 16 bits for 16 channels. In the Regional Parameter document (v1.1ra) I however do not see 16 channels (EU863-870). The only thing I can find is 8 channels from the TTN documents - the three default ones and five extra ones (867-ish).
What should I do with these 2 bytes? Are they actually ever used?
Cheers!
There are other LoRaWAN providers using gateways with 16 channels. As those are more expensive they are uncommon. (A certain commercial commercial provider in NL does)
To have a LoRaWAN compliant implementation you will need to process the additional information.
Are you implementing your own LoRaWAN stack?
have only seen these channel published even lorawan_regional_parameters_v1.0.3reva talks about all 16 have not seen them explicitly in the doc
| 868 MHz Frequency Band Channels | |
|---|---|
| 125 kHz Uplink Channels | 125 kHz Uplink Frequency |
| 0 | 868.1 |
| 1 | 868.3 |
| 2 | 868.5 |
| 3 | 867.1 |
| 4 | 867.3 |
| 5 | 867.5 |
| 6 | 867.7 |
| 7 | 867.9 |
| 8 | 868.8 |
| 125 kHz Downlink Channels | 125 kHz Downlink Frequency (MHz) |
| 0 | 868.1 |
| 1 | 868.3 |
| 2 | 868.5 |
| 3 | 867.1 |
| 4 | 867.3 |
| 5 | 867.5 |
| 6 | 867.7 |
| 7 | 867.9 |
| 8 | 868.8 |
| 9 | 869.525 |
@kersing yes I am working on a LoRaWAN stack. Therefore I need to know how to implement LinkADRReq. I’ve only seen those channels mentioned by @Piet_Pillay
If you know which channels numbers 9-16 would be, please share!
more confusing i believe this is the specification but 125khz bandwidth is not mentioned
especially refer to page 21 on
EN 300 220-2
what lns are you using
It’s just an end device talking to TTN… 
Why do you need to know the channel numbers? The ADR command will provide the required information.
The regional specifications only list the 3 required channels for EU868, the other channels are chosen by the network provider and provided to the device when joining. I don’t know where @Piet_Pillay quotes the table from but I haven’t seen it in the regional parameter specification.
The Mac command has 2 bytes ChMask which indicates for 16 channels whether or not they should be used by specifying 0 or 1. But then there must be some ordering and frequency related to index 0…15.
Would those then by your logic mean the 3 default ones + 5 from Join Accept CFlist, and 9…16 not in use?
calculator
Abstract yourself away from the TTN implementation.
A private setup can set the channels as they see fit within legal constraints - this may be three, it may be 8, it may be 16.
Holding 16 channels in memory / NVM would be somewhat of an edge case so I’d concentrate on the first 8 for now as there’s plenty to do in that stack.
Does the bitmap for TTN turn on any of channel 8-15?
Any channels not present in the join request can be set by the LNS using MAC commands ‘creation/modification of a channel’ (spec 1.0.3 chapter 5.6 or spec 1.1 chapter 5.7) That request specifically contains the index to be used.
Channels not yet defined should be set to not be used of course,
how then
where do you declare these
Initially a node should start with only the first 3 channels enabled. Channel mask set to disable everything else. Once channels are added the LNS will update the channel mask to allow usage of the new channels.
if they are not define how do they deliver a service providing support for all 16 channels as your lns needs to know what the cannel parameters is
TTN apparently uses just about 8 channels - and most gateways apparently will only listen to those channels. Then there are more expensive gateways that can listen to 16 channels simultaneously, but they are probably OEM only and the specs aren’t really out on the streets. And/or the OEM uses some way or another to tell the gateway to which frequencies it has to listen.
That’s a bit of a guess but not completely relevant for open source-ish end devices talking to open source-ish LNS
i understand as per specification your node only need to know the 3 channels
this spech are essentially non valid are normally supersede by the new one
then they are ‘not compliant’ to the specification as they are doing their on thing
The band is free for everyone - also free for a company to do their own thing. As long as the company’s users adhere to the company’s standard, they don’t need to be compliant. So a provider can choose to use something that’s incompatible with the open standard but if they make money, who cares?
Anyway, this is mostly all a guess and I will try to adhere to the specification. For which Jac has provided me with the necessary details to make it work!
Each provider defines (apart from the 3 required channels) their own frequency plan. The LNS of the provider knows these channels and will push them to any device joining the network using MAC commands. A device in EU868 must be able to handle 16 frequencies as per specification.
The Lora Alliance does not define the frequency plan, the provider has to do that within the bounds of the regional parameter specification (upper and lower frequencies and mandatory channels) and the local regulations.
If this doesn’t answer your question then please state the question more clearly.
At that point they’re not operating a LoRaWAN network. LoRaWAN networks comply with the standard. However as mentioned above, only part of the frequency plan for EU868 is part of the standard. The remainder can be chosen by the operator.
And no, that isn’t guesswork on my part but 8 years of assimilating knowledge 
1 Like