Now which channels… that’s up to the gateway and network operator
I am not convinced about devices disabling channels not used by the gateway.
What happens now (with all channels enabled) is the device tries random channels across the full set of 72 until it gets a JoinACK from the network. This is very much hit and miss and leads to a variable delay to completing the OTAA procedure. Not very efficient and time consuming.
Once the join has been completed however, the network disables the unwanted channels - or should be doing so. (There is a problem here that needs to be resolved: https://github.com/Lora-net/LoRaMac-node/issues/533)
Disabling the unused channels (where known) is a band-aid fix.
Yes, it means that OTAA joins happen much more quickly, but it also means that you are locking in the network’s channel plan, making it impossible for networks to either change the plan or to expand into additional sub-bands without also reprogramming every device already deployed in the field.
I see this as being a really bad idea.
If the device’s OTAA process was amended such that the selection of channel for the join attempt wasn’t totally random, the join delay from trying to find the network in the first place could have a definable upper limit.
The OTAA join logic should first select a sub-band in a way that does not repeat (e.g. create a randomly shuffled listed of sub-bands) and then can select a random channel within the sub band for the join attempt. This will minimise the OTAA join delay to maximum 8 attempts with an mean of 4 (ignoring joins over the 500kHz channels 64-71).
The other issue with AS923, is that it mandates two join channels (923.2, 923.4MHz) that gateways must listen on. Because of how the gateways I have used (Multitech, Laird, MatchX) have been designed, this would lock one of the radios to a band covering these frequencies while the second radio could be programmed for some other sub-band in the 915-928MHz range.
You still end up with half the traffic for all the networks being pumped through a single 1MHz spectrum around the mandated join channels. This doesn’t seem ideal.
AU915 :With all channels enabled on the module uplink, there is a very high probability of uplink transmissions the gateway does not have channels for! This has been reported on the TTN forum many times.
Yup - just until the network gateway specifies the supported channels.
I’m looking at installing a couple of gateways, and rapidly getting to a point where we need to lock in the frequency range that we want to use. Multiple organisations that we’ve spoken to are recommending AS923 (which is where we are leaning) for new installs, however there are existing gateways around using AU915.
So agree that it would be good if we could generally agree on which frequencies the community is encouraging use of.
Even within AS923 there are the two options, is there a general preference for one over the other?
I was initially a fan of AS923, based primarily on my bad experience trying to get node devices (Asian sourced) out of the box, up and going with 8 channel gateways. The lengthy join delay caused some very early frustrations.
I have now set up a few gateways using AU915 (sub band 2) to work with TTN. Once you get the hang of configuring gateways and nodes properly (does require selecting the right node devices in some cases) it is not too problematic. Admittedly, this does require disabling the unused channels in the node devices (not always that straightforward) to improve the join experience.
I would now support the use of AU915. Longer term I think this offers more expansion capability. Particularly as gateways with support for more than 8+2 channels become readily available.
With relatively low levels of network traffic currently, I do not think 8 channel gateways will be an issue for some time however.
For TTN (community gateway applications), we should probably stick with AU915 sub band 2 as originally proposed.
AS923 can be utilised by LoRaWAN commercial operators as well as the other AU915 sub bands as currently appears to be happening anyway.
So, vote +1 for AU915.
Peter.
Being part of TTN Adelaide with @leogaggl, we have discussed this a fair bit.
I had a discussion on Slack and considering that AS923 has numerous limitations compared to AU915, the only reason it is being used in Australia is because it provides access to Asian nodes and a greater market of 600 million people. This is in addition to the connectivity issues others have previously described with AU915.
Here are a few stats to compare:
AU915
- 8 bands of 8 channels, being 64 total
- 30 dBM EIRP
AS923
- 16 channels total
- 16 dBM EIRP
AS923 did previously have the advantage of sending CF-lists on join, however since LoRaWAN 1.1, AU915 does the same.
Agreed. Our community (Albury-Wodonga) is 100% AU915.
TTN Adelaide user here too. Looks like we have agreed on AU915! It makes so much sense to stick with one frequency plan only. It’s hard enough debugging some of the devices now, let alone having gateways on AS923 only and thinking it should work and it must be a signal or range issue.
As a early adopter I have commercial devices locked to AU915. Changing to AS923 would mean buying or swapping over the hardware as the manufacturer does not allow for firmware updates on the devices. Therefore I will always be running AU915 locally.
From Lachlan’s post, we have higher power levels that can help (1W vs 40mW on AS923). The only benefit of AS923 was the Join-accept CFList, but as this is now it LoRAWAN 1.1 it’s a no brainer to say with AU915. I will have to start playing with LoRaWAN 1.1!!
1 Like
Toowoomba and any future gateways I setup will stay on AU915 - I still haven’t seen a proliferation of devices outside of EU and US as yet.
For rural situations we need as much power as we can get for maximum distance
1 Like
Perhaps we should take this offline however I would have thought Toowoomba, with access to all those surrounding peaks, would have been easy to cover with a few strategically places gateways on peaks. In such a scenario I would not have expected power to be an issue assuming the aerials are high enough above the ground to cover line-of-sight limitations.
Actually yes Toowoomba is ok, we now have about 4-5 gateways in a small city.
I also have gateways in Goondiwindi, St George, Dalby, Muckadilla (outside Roma), Felton and just north of Toowoomba where the range will be determine how many users (farmers) we can include in demonstration trials.
cheers
Paul
OK, I’m new to LoRaWan but can anybody tell me if there is a list of frequencies used by communities in Australia? More importantly, if I am buying gear, what device frequency should get?
1 Like
https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html tells you what the above plans are.
In general you will need to buy stuff marked 915mhz, some chips have a broad spectrum across 868/915.
Stay away from the 433mhz stuff for LoRaWAN in Australia
Cheers
Paul
1 Like
It seems TTN is limited in channels by itself, better to read LoRa Alliance document [https://lora-alliance.org/sites/default/files/2018-04/lorawantm_regional_parameters_v1.1rb_-_final.pdf](LoRaWAN™ Regional Parameters v1.1rB)
I’m a little late to this party (only just saw the topic).
Some of you have heard this from me before…
The TTN community in Australia has been running AU915 since before it was a released standard. It was the first LORaWAN band plan released for Australia and at the time was the only band plan available. At the time I recall there were 2 gateways. One in Perth and one in Sydney. (we’ve come a long way!)
Since then the AS923 band plan was created, primarily for a bunch of Asian countries and also New Zealand.
Both AS923 and AU915 can be used in Australia and there are slightly different pros and cons for each.
One of the big attractions for AS923 is the ever increasing amount of ready-made devices coming out of Asia. Some of these vendors support both band plans, but many are just AS923. The market for AS923 is large, whereas our sparsely populated island paradise is but a mere 20-something million people.
I think we’re now at the point where the variety of AS923 devices is at least on par with AU915, but growing at a faster rate. All LoRaWAN module manufacturers have had AS923 support since 2017 (except for Microchip who were about a year behind everyone else)
An attraction of AU915 is that it already has wide community adoption and the possibility of using all 64 channels, compared with 16 in AS923. (currently TTN only uses 8 for either band-plan)
The reality is that market forces will prevail and customer demand will drive what happens. Australia will continue to have both band plans for the foreseeable future, and TTN and Meshed will continue to support both.
To that end, Meshed has started implementing dual-band gateways on the public TTN network. Both AU915 and AS923. You will see them popping up on the map (they look like 2 gateways at the same location) and we are encouraging growth of both band plans in Australia.
It would be nice to have just one band-plan, but both exist today and will do well into the future. If you are pondering which band-plan to implement in your gateway, my suggestion is:
- If you are mostly interested in LoRaWAN for yourself, go with what the remainder of your community already has. Sydney (and soon Adelaide) will have pretty good coverage of both band plans.
- If you are mostly interested in producing devices, make sure your device supports both and configure your gateway for either.
- If you are mostly interested in setting up gateways for other people/organisations, be flexible, understand their requirements, understand surrounding band-plans.
Things which may help in the future:
- Some South American counties have adopted AU915, which strengthens its appeal/community
- New LoRaWAN standards (such as inclusion of CFList on AU915) help to improve flexibility and inter-operability between standards. Both band plans will probably continue evolving.
- TTN v3, which has the potential to assign channels to devices on an individual device basis - details TBD
Some things which may hinder in the future:
- Devices that have been hard-coded to particular frequencies
- Devices running older versions of the LoRaWAN stack - ie 1.0.1
- Devices using ABP
This is all just my (incomplete) opinion. I recognise this is a topic that some of us are passionate about and many of you have other opinions. Let’s discuss. Someone suggested an offline forum and I think that’s a good idea too.
Maj
2 Likes
Hi Andrew,
It appears I’m walking a path you once trod. Have your thoughts on this changed over the past year, and would you happen to have a copy of a TTN compliant AU915 matchx config file I could look at?
cheers,
Daniel
Not at the moment - my MatchX is supporting a private dev network right now.
If I recall I got a config file from MatchX themselves. The only thing I needed to do was turn off the “listen before talk” feature which was just blocking the gateway from transmitting. Bizarre as I am operating out in the sticks where the band is really quiet.
If you send me your current config file, I should be able to tell you what needs tweaking.