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!
All in agreement here, with the following caveats:
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.
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!
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.
“But if you have an exceptional use case, go ahead and add a AS923 gateway. You’re welcome to”?.
If the other recommendations are effective, this will be implicit by inertia, I would hope.
General use public gateways yes. Gateways for legacy or exceptional use cases ought to be welcome, I think.
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?
“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.
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.
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:
“No doubt about it - give me one of the sensors and I’ll make sure the network will support them all”.
“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.
Great conversation! That really depends on your viewpoint. And that is I guess what we have to be clear about. Do we want to create a patchwork where everything goes and no-one is able to do any cross-regional use-cases (and it most likely becomes (is) pretty unsupportable)? Or do we want to ensure some consistency which will allow larger use-cases? We are hoping to do work with some environmental use cases around different regions. The gear would support both bands so no problem there. You are in an area with an Asian band gateway. You set your device to that band. Then all of a sudden other gateways pop up and they are on the Australian band. It’s a mess!
I am trying to look at this from the perspective of what would benefit the TTN community overall. Which will probably mean that some tinkerer won’t be able to everything they might want. But there’s nothing to stop them from running a local network server for a localised use case or an NS cluster that does support that band. But for every such tinkerer, there is another that will just throw their hands in the air and say LoRaWAN is too hard with all these choices that shouldn’t be necessary. And I don’t think consistency in the network and some learning from past mistakes will hinder peoples imagination. To the contrary - you would think it would enable them to think larger (if they want to).
“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?”
Don’t get me started on that one! You lost me at Alibaba We have all been there. My advice for the “enthusiastic community member” after being involved with TTN since 2016 would be is to cut your losses now and run. Fast! And to me, that is also a key value of the TTN community. People have made mistakes and have been able to learn from them so others don’t have to make them.
Thanks for your input! This is really a valuable conversation that we should have had a lot earlier…
Great discussion :). I think this is all heading in the right direction, but I’ll throw in some comments along the way…
We (Meshed) have deployed hundreds of AU915 gateways for our customers over the past few years. They happen to also be AS923 gateways. I realise this is both a benefit and a curse. A few years ago (2017ish) there really was not much choice. AS923 device types significantly outnumbered AU915 devices. When a customer wanted a bunch of parking sensors, the choices were either deploy AS923 devices or go talk to SigFox.
I don’t see a problem with deploying dual band gateways for community use. Encourage the use of AU915 gateways and devices, discourage the use of AS923-only gateways. That way the community can count on AU915 being available, and as a bonus in some areas AS923 too.
As someone pointed out above, sometimes there is a valid reason to deploy AS923. There are still some device manufacturers that are using LoRaWAN stacks where the band plan is not user definable (hopefully less each day!). They will typically start shipping a product configured for a band plan that will get the most units out the door. That’s normally EU868 first, but often it’s AS923 second. As long as we keep installing dual-band gateways (AU915 and AS923), the community gets the benefit of this deployment as well. If I were to accept some of the more “hard line” ideals I see here, then this deployment wouldn’t go ahead and the community wouldn’t benefit from the rollout of those AU915 gateways.
Personally I feel that the more pressing issue at the moment is how is the community going to manage the migration from V2 to V3 without everyone’s sensors going offline, or without having to go reboot every one, but I guess that’s off-topic
Looking forward to tonight’s call! We are going somewhere in the right direction
I don’t see a problem with deploying dual band gateways for community use.
Agreed - dual-band is not the issue. The problem is AS923 only gateways and nodes!
There are still some device manufacturers that are using LoRaWAN stacks where the band plan is not user definable (hopefully less each day!).
I don’t think that is a valid problem any longer. If that is an issue it’s generally due to the manufacturer using old modules (ie. Microchip 2903’s).
And in any case, this would be the tail wagging the dog. I can’t see any other network that will change their frequency band just because some device maker is too lazy to support multiple bands.
Chat this evening. And yes - the migration is the big one after we have some clarity of direction on the frequency band.
Thanks, everyone for a very productive meeting call last night! Special thanks to our international guests @johan, @jpmeijers & @Jeff-UK for the early shift.
To try to summarise the main outcome of the call:
The general agreement was to go forward with using the current TTN recommendation of AU915 FSB2 to be the only recommendation for new gateways.
For special use-cases only (such as dual-head gateways running 2 different forwarders), unavoidable localised exceptions and to assist the migration of current gateways on the Asian frequency band, AS923 will still be used on the V3 Community Cluster. However, the use of AS923 only gateways should be actively discouraged going forward as not to further fragment the public network and current AS923 single band gateway owners encouraged to move to the AU915 FSB2 as soon as feasible.
I hope I got this one right - please let me know if I have misinterpreted. The meeting recording and transcript will be made available to participants anyway as per previous meeting. My apologies on starting the recording too late and not getting most of Johan’s status report (the next meeting call will record automatically).
Please see the topic on V3 Migration for the invite to the next community call!
Does TTI/TTN require Carrier Licensing in Australia?
"A carrier licence must be held by the owner of a network unit (cable or wireless facility) which is used to supply carriage services, for example telephone or internet, to the public unless there is a nominated carrier declaration in force in relation to the unit. That is, the owner of the network unit arranges for a carrier to accept carrier-related responsibilities and become the ‘nominated carrier’ in relation to the unit (Division 4 of Part 3 of the Act).
“The owner(s) of a network unit(s) must not allow use of their network units to provide services to the public unless they hold a carrier licence, or a nominated carrier declaration is in force over the network units or an exemption applies”
This is not my area of expertise - so please do not take this as advice in any form! But when starting the TTN community in ADL 2016 the advice we received was something along the following lines. The Public TTN Network falls within the meaning of ‘exempt network’ under subsection 34 (3) of the Telecommunications Act 1997, the owner of the exempt network is not required to hold a carrier license. An exempt network includes a wireless network that is used for the sole purpose of supplying carriage services on a non-commercial basis.
Thanks for the reply. I understand this may be off-topic but i posted due to the strong Australian following.
I think carrier licensing has implications for some of us, especially those who host gateways on commercial radio sites for the exclusive use of extending the TTN/TTI network reach (rather than to support a local use case on a single “distinct place”)
My understanding is that the “loophole” of subsection 34(3) was to deal with public wifi hotspots
"The new Determination is intended to continue to allow businesses like cafés, hotels and airport lounges to provide wireless local area networks (‘WiFi hotspots’) to customers within their premises on a paid or incidental basis without first obtaining a carrier licence "
The exempted wireless network unit test outlined in the Section is
A Wireless Network Unit is to be exempt where it satisfies both paragraph (a) and (b).
A Wireless Network Unit satisfies paragraph (a) where the unit is used to supply a carriage service to users where the users are not in a distinct place from the Wireless Network Unit.
A distinct place is defined in section 36 of the Act. Places are essentially distinct unless they are:
· in the same property (i.e. situated on a property subject to a single freehold or leasehold title);
· contiguous properties and the same person is the principal user of those properties; or
· the same eligible Territory (i.e. the Territory of Christmas Island and the Territory of Cocos (Keeling) Islands or any prescribed external Territory, as defined in section 7 of the Act).
A Wireless Network Unit satisfies paragraph (b) where a carrier licence or nominated carrier declaration would not be required for a fixed line network supplying a carriage service under the same circumstances as referred to in paragraph (a) (i.e. supplying a carriage service to users that are not in a distinct place from the fixed line network)."
This suggests no commercial use as much as only for non-c … and lots of companies & people use TTN for paid services so interesting to see where that leaves the network. Note as an open network TTN would have no way of stopping such use… and indeed it would be against the global TTN Manifesto! Probably best person to comment @maj given Meshed AU is run as both commercial operation and local TTN host, though this may have interesting implications for TTN V3 cluster/new instantiation AU1 @johan? Can you guys help clarify legal position.
The WiFi Hotspot model as in above seems most appropriate?
As that appears to allow ad hoc & paid services without license.
The Meshed gateways in this region (Newcastle / Lake Mac) installed by @Maj were configured as AS923. A topic of interest at the time, and somewhere in the middle AU915 support was added to Meshed gateways.
Even though those gateways have dual region support, Meshed gateways continued to broadcast on the TTN V2 API with AS923 config. Why they didn’t make AU915 the primary network and AS923 the secondary has been a mystery for everyone on the outside looking in. AS923 quickly ensued as the normal.
As maker educators in the region, we field hundreds of inquiries regarding TTN / LoRaWAN - confusion over frequency is hands-down the most common. It is great to see the Australia TTN page has finally dropped all mention of AS923 - count us in for the cutover!
Dual band gateways will show as both AU915 and AS923. However the one you point to above is a single band gateway on AS923. This gateway was installed before we started installing dual band gateways in 2018.
The carrier licensing thing is a can of worms. This legislation was written long before something like LoRaWAN existed and doesn’t really cope with free public networks well. We (Meshed) had a discussion with ACMA about this in 2016, since we were in the process to building a business around TTN/TTI.
The exemption that @leogaggl mentions above seems to be what is widely viewed as acceptable, but there doesn’t seem to be a black and white definition.
We have all been there. My advice for the “enthusiastic community member” after being involved with TTN since 2016 would be is to cut your losses now and run. Fast! And to me, that is also a key value of the TTN community. People have made mistakes and have been able to learn from them so others don’t have to make them.