Future Strategies for AU915 and AS923 in Australia

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.

AS923 1and2

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.
3 Likes

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.

1 Like

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.

NNNCo is definitely on AS923 and would have the largest non-TTN LoRaWAN footprint in Australia AFAIK.

1 Like

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.

3 Likes

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.

2 Likes

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

6 Likes

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!

KISS is the best!

4 Likes

Great write up, thank you.

All in agreement here, with the following caveats:

  1. Yes, but remember it is (or should be!) the gateway that dictates AS1 or AS2 selection. The node join requests on the common channel and is told which option to use in the join accept. I guess there’s always going to be (non-compliant) nodes that stubbornly use one or the other, but changing this option would be largely a gateway side re-config rather than node side re-config.
  2. Do nothing is always the preferred option, and in this case it happens to also be the technically superior option. Cast technical baggage when you can. Win-win!
  3. Could be stated more earnestly, I think. Continuity, principle of least surprise, not fixing stuff that works are all important principles when you’re trying to win the trust of early adopters and build momentum in the community. There’s legacy nodes out there and it’s unlikely to be the fault of the deployer. Let’s not needlessly punish them. Leaving in a generous grace period for existing AS923 nodes also leaves the door open for current users of other LoRaWAN networks that happen to have picked AS923 to have an easy switch experience, and easy on-boarding for the endless nodes sourced from Asia. As stated, with fewer and fewer radios that don’t provide a simple software switch, configuring a node for AS915 will naturally become less and less of an issue. Doesn’t hurt to give it time though.
  4. “But if you have an exceptional use case, go ahead and add a AS923 gateway. You’re welcome to”?.
  5. If the other recommendations are effective, this will be implicit by inertia, I would hope.
  6. General use public gateways yes. Gateways for legacy or exceptional use cases ought to be welcome, I think.
  7. Aye. Is it fair to think that a second head gateway is not particularly more challenging than supporting two channel plans that happen to have overlapping frequencies? The latter, while cute, seems a potential source of confusion. Coincidentally, it’s a handy quirk when on-boarding new devices with suspect config, that misconfigured nodes may happen to occasionally be heard through channel overlap, but it’s just a quirk, right?
1 Like

Hey Heath,

“But if you have an exceptional use case, go ahead and add a AS923 gateway. You’re welcome to”?.

I am trying to understand this and come up with an example in which this would be useful? I am really struggling with it. If it’s a great use-case you would want to design your device so the frequency plan is just a firmware setting. If you’re targeting Asian markets you can test it on an AS923 gateway. But f your intent is to run it locally on the public TTN network AS923 makes no sense going forward. All it means your device would not be portable for no actual technical gain or making anything in the process easier. And on top of it, your gateway is useless for anyone around you.
Am I missing something obvious here?

There’s legacy nodes out there and it’s unlikely to be the fault of the deployer. Let’s not needlessly punish them. Leaving in a generous grace period for existing AS923 nodes also leaves the door open for current users of other LoRaWAN networks

I don’t think anybody is talking about punishment and there is plenty of options to support an AS923 transition. But without clear guidance for new users and a defined grace period, we’re just perpetuating the current situation. And that can’t be in anybody’s interest. It has been the cause of instability and confusion for people trying to deploy devices in different Australian regions. From a public network perspective as @WaynePeacock said people just want to deploy devices (and don’t want to worry about what frequency plan the gateway near you has).

I haven’t seen any disagreement that AU915 is the way forward. Then why perpetuate the pain? All it does is stopping TTN public from reaching a consistent continent-wide community network.

Hi Health, thanks for the contribution

I agree if someone who is experienced in Lora/LoraWan and/or has a background in RF design/ analysis determines that a particular location would benefit from AS923 then I agree it can be used.

However, the focus of this discussion is the public community TTN network which as it grows will be joined by people with little or no knowledge and experience in RF nor Lora/LoraWan. Here I see we have the opportunity to make some recommendations for the future development of the community network. In this case people with knowledge and experience can share and guide others so they get it right the first time.

Clearly the network and its configuration is a key part of this.

As an example, I would strongly suggest we as a community actively discourage the installation of AS923 Only gateways on the TTN community network. An AU915 gateway with a second head on AS923, well I would not do it, but equally I would not actively discourage this.

Anyway, just some thoughts.

I have a Dragino LPS8 Indoor Gateway configured for ASIA 920-923MHz on the V2 stack.

Now that the Australian V3 handler is released should I change the gateway to AU915 and change my device program to also use AU915?

Yeah, I’m not particularly impassioned about it so am not going to provide much counter-argument anyway, except to say that in engineering we usually start with the assumption that our imagination is limited rather than conclude with it. Empathy is hard. For example you seem to be imaging your “customer” as device designer. I can imagine a “customer” being an enthusiastic community member drumming up support to establish a vibrant local TTN community. She gets an audience with the local council or local land services who say “this thing you’re doing for the community is interesting, we’re thinking of supporting it. We already gave a bunch of stakeholders a trial of 100 water level sensors we found on Alibaba. Could your network work for them?”

The conversation could go two ways:

  1. “No doubt about it - give me one of the sensors and I’ll make sure the network will support them all”.
  2. “It depends. They might all have to be re-configured for AU915.”, “91-what? Hmm, this is getting complicated.”

It’s about making the on-ramp super slick. Once they’re on the highway, changing lanes is easy.

But the point about discouraging AS923-only gateways is well made, and ought to be the more important consideration.