In fact there are two versions of AS923 and the one in use is dependent on the available frequencies in each Asian country. AS923 is defined to have two mandated channels they being 923.2 and 923.4 and the other channels are in steps of 200kHz.
In Australia, by far the most dominate version of AS923 in operation is AS920-923.
An import aspect of AS923 is the node transmits on one of the eight channels and the gateway responds on the same channel. There is no separation between the two frequencies. If it fails then the second transmit window (RX2) is always on 923.2. As a result the traffic levels on 923.2 are much higher than other channels
So what difference does it make if AU915 uplink and downlink are on different channels and AS923 are on the same?
Answer: Network Capacity
Many LoraWan networks are built for Coverage but in time as more and more nodes are connected they will need to be design for Capacity. Cellular mobile networks started out this way in the 1970s and 80 but today a cellular network is designed on the basis of Capacity.
Now I hear you say, that’s not a current problem with LoraWan or TTN, it won’t affect my gateway for many years. While we tend to think of Capacity being related to a city’s population density and the number of temperature sensors, water meters it is already a real issue in localised areas. At the TTN Conference 2021 a presentation on the use of TTN on a New Zealand dairy farm highlighted the radio congestion problem due to the large number of cows (nodes) located in such a small area.
So the take-away message: The strategic decisions we make about the use of AS915 and AS923 are important right now, not something that won’t be seen for years.
Take an example of a dairy farm with say 500 cows and 4 gateways located around the perimeter of the farm. The gateways provide good overlapping coverage, they are somewhat elevated and as a result the reliability of node-to-gateway transmissions is very high.
Now, when the network server sends a downlink message one gateway will transmit.
In an AU915 system one gateway transmits and its receivers are disabled. The other gateways are still receiving traffic and since the first gateway transmits on a different channel to the node to gateway uplinks, the other three gateways continue to receive traffic from the nodes. More importantly, all 8 LoraWan channels are in full operation.
Compare this to a AS923 system (or EU868) where the gateway responds on one of the eight channels. In this scenario, when the channel the gateway responds and sends a downlink packet, that channel is now unusable on the other gateways. Their receivers on that channel are dominated by the signal from the transmitting gateway.
So in comparison, a dual frequency system as implemented in AU915 provides more capacity than a single frequency system as found in AS923. This results in higher probability of a packet sent by a node reaching your application.
Excellent write up and summary in the above 3 posts Tony, clear for many outside your region who don’t have to live and breath the issues this raises. I was always of the the opinion that AU915 was better from network perspective due both to the capacity issues you highlight (none overlapping channels) but also even a small reduction in frequency from AS923 can help extend range due to improved free space loss… I know it’s a small change and at the margins but in a large territory like Oz and with potentially millions of sheep if not cows vs people or utility meters in a given area, every little helps right! Though I guess the changes in availability and cost of the nodes has driven local decisions to use AS923… So
Absolutely envious yes!
I would be cautious on one point however:
I would certainly not make a comparison there…S/DCPF’s are clearly what others have described as an abomination wrt LoRaWAN, and disruptive to network operation and others use of the network and can never be LoRAWAN compliant, so should not be connected to TTN and where already deployed for early historic reasons should really be removed and replaced by a low cost complaint 8 channel GW. Both full AU915 & AU/AS923 GW’s, however, are compliant and legit to use so absolutely no issue there and indeed another point of envy is the fact you can deploy dual head unit or co-locate one of each further improving capacity where needed
And finally your example with the cow hurd and 4 gw’s gets the message across although in reality, and as ever, the situation vs theory is a bit more nuanced.
If we assume your GW’s are N, S, E & W, then for all in close proximity to the Tx’ing GW (say N) what you say is broadly true, However assuming the GW’s are at a reasonable distance (as likely in that scenario) then a cow near S GW is likely to still be heard (trying to avoid pun!), due to classic near/far behaviour of transmitters and relative received power. LoRa is a very resilient modulation, and whilst much is made and written of the pseudo orthogonality of one SF relative to another on the same channel and hence ability to decode them, even a signal in same channel and on same SF can still be resolved (more so than classic legacy modulations like FSK where destructive interference means both signals often lost) provided there is some headroom between the signals - the remote tx signal simply contribution to raising the local (to node or other GW) noise floor…and as we know LoRa good for pulling signals out of noise In addition GW’s are somewhat able to discriminate node vs GW transmission (which is why GW’s don’t react to other GW’s nearby/in range) - upchrip vs down chirp & all that Even a cow near say E or W - roughly equidistant from N & S is still likely to be received and discriminated by E and potentially S if coverage range overlap is good enough (all this SF & node Tx power/device antenna efficient dependant of course).
Even so I generally agree with the direction of your thinking…
Thanks @Jeff-UK , Yes I agree with your caution about the dairy farm scenario. Sorry about the rambling.
The point I was trying to explain, is that to date the gateways are reasonably sparce but going forward as there are more and more nodes installed the number of gateways will increase and the network will be based on Capacity not Coverage.
So, we can expect to see a difference between systems that use two frequencies (AU915) and less capacity in a system that uses the same frequency for uplink and downlink (AS923).
The second point, this experience is starting to be seen today, it’s not something that will occur in 5-10 years time.
Regarding the single channel gateway example. I was saying circumstances change with time. What can be a “good idea” at one point in time of a network’s deployment can be the opposite some time later. So from this learning we need to review the way we work in Australia by considering the future LoraWan technology developments.
Given we have systems with both AU915 and AS923 operating in Australia the question is, how do we best support these going forward? What is the best system configuration?
Returning to the frequency diagram you can see the following point
The most dominant form of AS923 in Australia is AS_920_923 which is at the bottom of the diagram
TTN AU915 is in FSB2 and its downlinks are transmitted on 923.9MHz which does not overlap with AS_920_923
AS_920_923 also does not overlap with systems running in FSB3, FSB4 or higher. Remember we share the band with other LoraWan systems, other IoT systems and general industrial systems that have nothing to do with Lora.
You will also see AS_923_925 aligns with FSB6 and so there is a proposal to move TTN from FSB2 to FSB6 and then every gateway can receive AU915 as well as AS923.
So what are the benefits and issues.
Every gateway will be able to receive AU915 and AS923 nodes. Nice!
Systems using AU915 loose the benefit of two frequency (duplex) operation as gateways when sending downlinks to AS923 nodes they will transmit on the same channel as the node → gateway uplink. (Refer above to see that difference between single frequency and dual frequency operation)
All the existing AS923 nodes which are in the AS_920_923 band will need reprogramming and move them to AS_923_925. I assume this will be the vast majority of these nodes as there are 293 gateways on AS_920_923 and only 30 on AS_923_925. If this is the case, why not reprogram them to work on AU915 FSB2?
This will also mean we need to move all existing AU915 systems from FSB2 to FSB6.
By being located in FSB6 we also have additional background noise from the downlink channels transmitted by LoraWan systems commissioned on FSB1, 2 and 3.
These may not be TTN systems but other commercial systems, which by the way are likely to be heavily loaded. eg meter reading etc. Just because they don’t appear on the TTN map does not mean they don’t exist. (I have one myself)
From this I have concluded
Leave AS923 where it’s currently located as it will receive less interference and work better than moving it to AS-923_925
Leave AU915 where it is in FSB2
Continue to support existing AS923 systems - ie don’t remove existing gateways
The Australian TTN community promotes all new nodes should be installed on AU915
If a AS923 node is replaced (failure) then commission its replacement on AU915.
Gateways that are solely on AS923 are not a good idea.
All Gateways should be on AU915 and if a second head is installed it can be on AS923.
Hi Again Tony - I meant to ask earlier and been prompted by your latest…do you know where the commercial operators and other networks (public or private) sit in Au?
Thinking nnnCo, Senet/SimplyCity, GeoWan, Goanna (dont they use nnnCo?), Ventia/Orbiwise, Proximvo, et al.?
That may influence yur own seletion of FSB’s etc. if keen to avoid other network traffic and optimise future capacity
From the work I have done with GoannaAG (and I assume NNNCo), they use AS920_923 but can move their gear across to AU915 in the few tests they have done on our gateways.
No i don;t know where they are. Hope someone can share this.
Given that, my recommendation would be to use FSB2,3,4 or 5 as a first priority.
A lower priority would be FSB6, 7 and 8 due to gateway downlink transmissions
FSB1 is also a lower priority as its adjacent to a national 4G mobile network and adjacent channel interference will mean problems if there nearby cell towers.
Reading all the above post and summarising them - there is no valid reason (neither technical nor operational) to change the current TTN Australia recommendation using FSB2 (https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html) as the default setting moving forward with the V3 AU915 community cluster. And as gateway channel capacity increases expand into 3-5 avoiding the issues Tony highlighted with FSB6-8.
For existing AS923 gateways that want to continue on the Asian frequency plan, there is an AS Cluster available.
That’s not correct Leo. The V3 TTN AU Cluster will support all band plans. It makes sense to use your closest cluster regardless of band plan, otherwise your traffic needs to leave Australia then come back again.
@TonySmith
Thanks for the comprehensive posts. You could always ask the commercial operators what band plans they operate (or intend to operate), with this discussion in mind.
My observations have been (although I may be way out of date):
NNNco: AS923
Ventia: AS923
GeoWAN: AU915 FSB1
We (Meshed), nearly always deploy dual-band gateways running AS923 AS1 and AU915 FSB2. Most of the devices we provide to our customers are AS923.
Logistically, I don’t think it would be worth attempting to change frequencies in-use; overcoming the inertia of legacy documentation/tutorials would lead to a lot of confusion. I also suspect that not everyone would update; visiting all of the nodes to either restart them (AS923) or reprogram them (AU915) would be a lot of work (commercial/council users, much as they’re unlikely to be the priority here, would not appreciate those costs).
For capacity, both networks support additional channels post-join (up to 15 total for AS923, and 64 total for AU915); deploying additional gateways (in localised areas) for static assets would alleviate congestion, though would require technical support from the v3 stack (I’m not sure it has per-device frequency management capability – some other servers do). As long as the AU915 devices implement the frequency sub-band as a default channel mask which can be altered post-join it’d be fine; I’d consider it an implementation flaw if changing the mask isn’t supported, as v1.1 can provide a mask on-join.
I’m assuming the reduced cost of the Semtech radios (SX1302 and later) will result in more multi-concentrator gateways becoming available on the market at more affordable prices; that may not be true for a while.
Whilst the discussion about frequencies is ongoing:
I’m interested in addressing the power spectral density issues of FSK modulation with AS923. Legally AS923 devices and gateways should be configured with a maximum EIRP of around 16 dBm if the FSK channel is enabled (down from ~24 on devices with 22 dBm SX1262 radios and a 2 dBi antenna); other networks get around this by disabling the FSK channel. I expect there are many devices out there which violate this if they’re close enough to be using the FSK channel. For maximum range, at the cost of short-range capacity, it’d be worth considering disabling the FSK channel.
I’m also interested in addressing downlink capacity on gateways – specifically limiting the maximum number of downlinks a device can request in a period of time (to prevent an effective denial-of-service, which is a concern because most gateways are half-duplex); can the v3 stack can support this? If so, what should the limit be?
Hi Andrew,
Sure - the network servers will support different band plans. But that doesn’t mean it is a good idea at all to run more than one band as the default. The whole point of the TTN public network (and it’s disruptive nature) is to support a consistent regional network which allows roaming use cases and ensures consistency. Anything else means the community shoots itself in the foot.
I think it’s fairly clear that the argument for AS923 (which was apparently the availability of devices at the time) has gone away. For those that want to run legacy gateways on the Asian frequency band in Australia, there is plenty of options and they can continue. But I think it is absolutely critical to settle on a single default frequency band going forward. It should be made clear that any new public gateways and upgrades should be using a common AU915 frequency plan.
I can’t see any other network that has chosen to split itself across multiple frequency bands. And I think there is a clear reason for that. It pollutes the network and prevents the network effect of a large consistent regional network.
And just to make clear. I am talking about V3 going forward. As @brulath mentioned we can not easily change legacy gateways. But this discussion is about the future and a very limited opportunity (the V3 migration) to learn from the past and correct some mistakes.
That’s a different discussion. I’m not making a case for using AS923 in Australia, I’m saying that if you do run AS923 and your gateway is in Australia, it makes sense to use the Australian cluster. ie. Choose your cluster based on geography, not frequency.
There’s no benefit to anyone by connecting an Australian AS923 gateway to an Asian cluster, and there’s no determent to anyone by connecting an Australian AS923 gateway to the Australian cluster. In either case, those gateways just don’t participate in the AU915 network.
Agreed. But that is the discussion we have to have. AS923 really should not come into the discussion looking forward to V3. It’s a legacy that we have to live with for a while (as far as the public community network is concerned).
As for connecting AS923 gateways to V3 cluster, it is technically possible, but it should be highly discouraged (if not prevented after some sunset phase). All this would do is perpetuate the disaster we have now and prevent the public network from reaching its potential across the country. There’s nothing stopping people to use AS923 in Australia. If you don’t want to use the AS Cluster you can run an AS923 network server.
The opportunity for a spring clean in this migration will not come again (or not for a long time). What’s required is a clear path to a consistent and stable public network as far as I am concerned.
I fully support the concept of standardising on AU915 for TTN in Australia.
The situation with AS923 being in use here at all is an unfortunate accident of history and down to one supplier not having their AU915 product available - this was a firmware rather than hardware issue (and goes back to a time when there were no LoRa WAN stacks on chip and the LMIC library ruled; where AU channel plans were crafted by hand from US plans and Jac was already a god!).
We have to be careful here not to allow decisions for TTN to be directed by the decisions the commercial operators have taken. After all those decisions were made for commercial gain not for the good of the community. I say this as someone who has a commerical interest in LoRaWAN as well as a private interest. My commercial interest has driven a switch to the use of closed private networks rather than public networks. That reflects the differing needs of our use case: 15 minute logging, long data packets and lots of sensor tags which means we fall way outside the “fair use” limits.
The use of AS923 byy NNN Co etc is not a reason to adopt AS923 - their target market is completely different to the market for which TTN is intended. What shaped their decision at the time was the need to get to market as quickly as possible. AS923 fitted with the ACMA’s spectrum plan and was legal although not preferred. I believe that AS923 should be looked at as a “Legacy” product and allowed to fade away.
If LoRa WAN realises its potential, the number of nodes and gateways deployed to date will seem trivial. So making decisions based on the history rather than the future is a bad choice. Instead we must ensure we look ahead and try to make life easier for the new entrants. To avoid confusion promoting the use of AU915 is essential.
Those Gateways which I am involved with which are on TTN and running on AS923 will be switched to AU915 during the next maintenance rounds - when the Nodes will also be re-configured. And I would have to question what future there really is for devices which do not readily allow switching between channel plans.
So onwards and upwards with AU915 and consign AS923 to the annals of history
I will copy Petertoome’s line, I also fully support the concept of standardising on AU915 for TTN in Australia.
Very nice write up Tony Smith!
I run a gateway on AU915 and all my devices are on AU915. I don’t really see a case for AS923 as we just run the issues of incompatible nodes (AS923) in AU915 single band areas. I think it’s clear we have much better coverage on AU915 at this time.
I do agree AS923 can stay moving forward, but all new node should really only support AU915. New gateways can then be AU915 only. Then in 10 years or so, AS923 will be a distant memory. People then have the choice to reprogram nodes to AU915 overtime or leave them until they died or are no longer supported in Australia. Makes sense to me.
I guess the big bonus will be for the non-technical users. “I just want to buy a sensor that works”. The supplier no longer has to ask AU915 or AS923? The end user goes, “What is the difference? Which one do I need?” and the questions go back and forth! Also the supply chain now only has to stock one frequency per node in/for Australia.
I have a few of the Victron Energy Monitors for solar systems pre configured for TNN. Nodes like these are just so easy to use. Buy, scan barcode and works if in coverage. Support requests would be reduced. “Are you covered by AU915 or AS923?” How do I tell… and it goes on!
