Or… Australia TTN Users why not just use AU915?
4 Likes
I agree that this is a rather unfortunate situation we find ourselves in down under. My concern is that this will cause a lot of wasted efforts in Australia.
Just because the two AS923 frequency plans happen to within the allowed frequency band doesn’t mean it’s a good idea to spread resources between frequency plans. For the development of an open community network this does seem detrimental.
It would be good if there would be some more communication & co-ordination between the AU communities as far as the public TTN network is concerned.
2 Likes
My understanding that the reason the situation has emerged in the first place is due to frustrations with OTAA experiences with single and 8 channel gateways. The Aus plan provides for 64 + 8 channels. So a node needs to potentially attempt to connect on all of these when looking for a gateway. The as923-1 and as923-2 plans each only support 8 or so channels with 2 being common between each plan . A node operating on these plans only nedds to communicate on 2 chanbels to effect registration on any gateway. All plans have their advantages and disadvantages.
Anyway, that is the cureent situation. Have the details available on the TTN map would make life easier.
I’d be keen to participate in a Community Initiators get-together (online) so we can get on the same page. This is causing pain right now and we should at least have a common understanding, if not a solution straight away.
Sounds like a good idea.
We should also give some consideration for other technologies, like Sigfox. I have heard of some interoperability issues with some LoRa Sigfox installations.
We probably should base any decision around node capabilities. What are end users most likely to be buying? If the majority of equipment is sourced out of Asia then maybe the AS923 plans are not a bad choice. These plans use a limited amount of bandwidth from the available Australian spectrum. Probably good for a public network as it leaves other areas of the spectrum available for private network use. The AS923-925 plan would be best as it stays clear of Sigfox.
There is also a need to investigate the ACMA regulatory requirements a bit more. I read an article a while ago that implied that some of the available lora band plans might not strictly comply with the Australian rules.
I think NNN Co use AS923-925. It would be nice to seperate the private networks from the public ones.
The original proposed AU915, sub band 2, although having device registration complexities, is relatively clear of other networks operation in the 915 ISM band.
Who else should be involved in this discussion?
I would certainly be keen to participate in any discussion on this subject.
I have kicked the can around the park pretty heavily over the last two months trying to get a stable OTAA result and seem to have it working fine now, although I can see opportunities to improve things.
There are issues with ADR though that are unresolved in the LoRaWAN client stack - I have implemented a fix for this and it is working well.
I did muck with AS923 and it worked better “out of the box” for OTAA - but this does not mean it is the right way to go forward. I am of the opinion that AU915 is the right plan. Happy to go into more details in this or a new thread.
Andrew
The official ACMA endorsed channel plan is AU915 (ibid for NZ) and my personal belief is that it is the one we should all try to use. It has been suggested that one reason why AS923 was picked up, was because some vendors did not have support for AU915 on their chips. Using AS923 enabled them to get to the market without worrying about adding suport for AU915 and made inventory management easier. I have even read web sites which claim it to be superior, which is nonsense - the only advantage it has is in being able to run a 2 channel Gateway. But as Gateways have come down in price so quickly, there is no real sense in doing this. But now it is established (and in use with some big players) we have to deal with it. There are plenty of modules & Gateways that support both.
Unfortunately what the mixed use of AU915 and AS923 has done has reduce the level of inter-operability and hence choice available to users - especially for those buying off the shelf nodes from commercial suppliers.
If building your own nodes or Gateways, always try to use AU915. But if you have to connect to an existing network you may get stuck on AS923.
AU915 was a fine choice. Just an evolution of NA915 but offset to avoid the Australian cellular bands. But it meant that devices needed to be made specifically for the AU economy, and the lack of scale in the early days meant that Australia was disadvantaged. Then along came AS923 and the promise of a much larger interoperable territory across Asia, so seemed like a nice economic choice to align on AS923.
Since then, Latin America has normalised on AU915 channel plan, so now AU915 is also a good economic choice with sufficient scale.
I would promote AU915
1 Like
Hey JDP long time no speak… It’s me from down under… I used to call you regularly in your old job 
From an Australian RF regulatory point of view the 915-928MHz is defined in the ACMA short range devices regualtions , which calls up technical standard AS/NZS4268: FEB2017.
My interpretation of AS/NZS4268 for the 915-928 MHz ISM band is the following for digital modulation transmitters such as LoRa.
Tx power up to 1watt EIRP provided (psd <25mW/3kHz)
Any modulation scheme and any number of channels can be used, provide they meet AS/NZS4268
tech requirements (test method calls a up FCC 15.127).
Hence from an RF regulatory point of view both AU915 and AS923 can be used. IE the LoRaWAN AU915 and AS923 channelization / protocol “fit” with within the ACMA governments RF regulation framework.
AU915
Has the ability to use 64+8 UPLINK channels… but it is highly recommend to turn off all channels except those same channels the gateway has… In this way both UPLINK and DOWNLINK channels are well defined and a much simpler Join protocol than AS923 .
History - Australia ISM 915 - 928MHz was derived from US FCC 15.247 and AU915 is basically the US LoRaWAN version and shifting of the UPLINK Channels above 915MHz (no change to the downlinks).
There are pros and cons for either AU915 and AS923, but large networks should be consistent one or the other.
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