Future Strategies for AU915 and AS923 in Australia

Countries Australia
1

Australia operates in the 915MHz ISM band and is somewhat unique in that both AU915 and AS923 are both allowed to operate.

With TTN about to launch the V3 server in Australian it’s an opportune time for the TTN Australian community to review how both systems can best co-exist going forward.

The launch of the V3 server is a Break-Point where we have an unique opportunity to:

  1. learn from history,
  2. review what has changed since the first introduction of LoraWan, and
  3. look forward at the next round of standards developments.

The later is one of the most important as we have the opportunity to ensure both AU915 and AS923 can co-exist and not restrict the deployment of the upcoming innovations.

The Australian 915MHz ISM band is divided into 64 channels. The number of channels are less than US915 where downlink channels are separate from uplink. In Australia, the gateway downlink channels overlapping the top three blocks of 8 channels (FSB6, 7 and 8). The challenge is to evaluate how AU915 and AS923 can co-exist and understand the impact of one on the other. (I’ve done this professionally looking at how cordless phone systems using different technologies can coexist, as an example, how does DECT perform when other cordless systems are in the same vicinity and then vice-versa).

In Australia we were fortunate as Meshed took a lead role and with TTN established a server in the region. They also recognised the limited supply of AU915 nodes and (at the time) the more available AS923 nodes. To provide access via AS923 Meshed installed dual head gateways, one on AU915 and the second on AS923. They are still in operation today. There are a small number of which are AS923 only.

Coming back to the points 1 and 2 above, about learning from history and the changes that have taken place since LoraWan was first rolled out in Australia. The equivalent topic would be the single channel gateway. When first released, it was one of few ways to get into LoraWan with a low cost gateway. Since there are many more gateway suppliers, there are low cost 8 channel gateway and there is significantly more open-source information to support DIY systems. As a result the single channel gateways are now actively discouraged as on-balance they do more “harm” to the network than good. So similarly, we need to understand the coexistence of AU915 and AS923 was important in the early days of LoraWan in Australia but we have the opportunity to reconsider how they can both be best used for the overall benefit of the Australian LoraWan and TTN community.

The limited supply of AU915 nodes no longer exists and the firmware is sorted. There is an installed base of AS923 nodes which need to be supported going forward. Maybe others can comment on the number or the proportion of nodes running on AS923 but there must be a reasonable number. So there is a strong case to continue supporting these existing systems.

Right now there are 1019 gateway in Australia

  • 653 are on AU915
  • 293 on AS_920-923
  • 30 on AS_923-925
  • 43 on US915 or EU868

So what is coming in the next 12+ months? (refer Semtech presentation TTN 2021 Conference)

  1. Frequency Hopping Spread Spectrum (as compared to the current Chirp Spread Spectrum),
  2. Repeater operation and
  3. Node to node transmissions within a LoraWan umbrella.

In my next post I will explain the Australian LoraWan channel allocation and compare the operation of AU915 and AS923.

8 Likes
2

The Australian regulator has allocated the band of frequencies from 915.1 - 927.9 for used as an ISM band. This band of frequencies is used by a range of systems including Drones, industrial equipment as well as a number of IoT type systems. To allow for interworking with Lora the Lora Alliance defined a series of 64 channels, each 200kHz wide with the first centred on 915.2MHz and the 64th centred on 927.8 MHz.

For LoraWan they went further and defined the “downlink” radio channels for a Gateway to communicate with a Node. For “uplink” from the Node to Gateway they divided the 64 channels into 8 blocks of 8 channels to match the design of the Semtech radio modules found in Gateways. These blocks (of 8 channels each) are now called FSB1 to FSB8.

For AU915 the uplink and downlink channels are

AU915-1

Being a bit small and making it easier to read, I’ve broken the image into sections

Bottom End of the ISM band
AU915-bottomend

Middle Section
AU915-middle

Top End of the band
AU915-topend

The channels in light or dark blue are the uplink channels from the Node to the Gate
The light orange blocks are the downlink channels from the Gateway to the Node.

TTN in Au915 is located in FSB2 which means the Nodes transmit on all 8 channels from 916,8 MHz to 918.2 MHz. The gateway responds further up the band on 923.9 MHz

An important thing to realise is the uplink and downlink channels are different, they don’t overlap and are sufficiently separated not to interfere with each other. This is an important aspect for the operation of TTN which I’d ask you to remember as we will come back to later…

When we get to describe both versions of AS923 you will see the Node and Gateway communicate back and forward on the same channel. So there is a quite a distinct difference between the underlying operation and performance of AU915 and AS923. The same occurs in Europe on EU868 where I would bet they envy both the number of channels we have and the separation of uplink from downlink frequencies.

3 Likes
3

AS923 is allocated as per the diagram below.

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

AS923 1and2

2 Likes
4

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.

3 Likes
5

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! :slight_smile:

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 :wink:

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 :slight_smile: 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 :wink: 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…:wink:

3 Likes
6

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.

7

Agree with all your points…and one thing I dont envy is you guys having to tackle the LoRaWAN AU equivalent of the judgement of Solomon you now face :wink:

8

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
9

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

10

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.

11

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
13

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.

14

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

1 Like
15

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.

16

@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.

18

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?

19

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
20

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.

22

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
23

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