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.
There seem to be a fair-few Meshed gateways with only AS923 - some of them have prime coverage in key areas around Sydney, Newcastle and Lake Mac. Are there any plans to assist with the AU915 cutover for those devices?
@CoreElectronics It depends on the end-customer. Some gateways are used primarily for internal projects (although on the public network). They are unlikely to start supporting AU915. Other gateways that are primarily for the purpose of providing coverage to the community will already support AU915.
Lake Mac gateways (the ones provided by Meshed) all support AU915 and AS923
We don’t have any customers/gateways in Newcastle. The nearby gateways owned by DPI are single-band gateways for a private project on a private network, but they are dual-homed so that they provide benefit to the community as well.
Many Sydney gateways support AU915 - the ones in the West for instance, but some of the older ones, nearer CBD do not. But there are a lot of non-Meshed community gateways in Sydney so both band plans will likely thrive.
Thanks for the conversations @Maj. It is hard to read in-between-the-lines of your replies from a TTN community interests perspective, though it is understandable that Meshed has commercial interests with AS923 given the Meshed AS923 nodes/devices deployed around the country. Quite the predicament.
@TonySmith raised some interesting points. Though it does seem the deeper you dive into the mechanics of LoRaWAN, a single frequency plan offers more benefit for community interests. From the initial discovery that TTN exists, through to device deployment. Not forgetting the more-human aspects such as education. The single frequency plan model has been well proven elsewhere around the world.
More bandwidth is an interesting coexistence opportunity. But is it worth scaling a deployment model given the challenges of AU915+AS1+AS2 thus far?
If AU915 becomes the standard, as indicated by the removal of AS923 on the Australian TTN page, then we will certainly do our part to promote AU915 and the switchover. Will be following this topic with genuine interest, along with developments on the Australian TTN page.
If it stays as-is, then so be it… a good conversation either way.
We’ll have our work cut out for us in this region!
The commercial undertones of Meshed are strong, though it just goes to show the diversity that TTN attracts. Perhaps the best community interests move they made was listening to the early feedback surrounding AS923/AU915 and making the switch to dual plan gateways.
It will be interesting to see how Meshed / @Maj approach legacy AS923-only gateways in high-value locations in the months to come given the removal of support on the Australian TTN page.
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.
