Can Australian users agree on using a single frequency plan?


(Adam Jp) #1

Or… Australia TTN Users why not just use AU915?


TTN home page feature request: can map show which frequency plan is used?
Issues with Things Uno OTAA Connection
#2

I agree that this is a rather unfortunate situation we find ourselves in down under. My concern is that this will cause a lot of wasted efforts in Australia.

Just because the two AS923 frequency plans happen to within the allowed frequency band doesn’t mean it’s a good idea to spread resources between frequency plans. For the development of an open community network this does seem detrimental.

It would be good if there would be some more communication & co-ordination between the AU communities as far as the public TTN network is concerned.


(Tuftec) #3

My understanding that the reason the situation has emerged in the first place is due to frustrations with OTAA experiences with single and 8 channel gateways. The Aus plan provides for 64 + 8 channels. So a node needs to potentially attempt to connect on all of these when looking for a gateway. The as923-1 and as923-2 plans each only support 8 or so channels with 2 being common between each plan . A node operating on these plans only nedds to communicate on 2 chanbels to effect registration on any gateway. All plans have their advantages and disadvantages.
Anyway, that is the cureent situation. Have the details available on the TTN map would make life easier.


(Heath Raftery) #4

I’d be keen to participate in a Community Initiators get-together (online) so we can get on the same page. This is causing pain right now and we should at least have a common understanding, if not a solution straight away.


(Tuftec) #5

Sounds like a good idea.
We should also give some consideration for other technologies, like Sigfox. I have heard of some interoperability issues with some LoRa Sigfox installations.

We probably should base any decision around node capabilities. What are end users most likely to be buying? If the majority of equipment is sourced out of Asia then maybe the AS923 plans are not a bad choice. These plans use a limited amount of bandwidth from the available Australian spectrum. Probably good for a public network as it leaves other areas of the spectrum available for private network use. The AS923-925 plan would be best as it stays clear of Sigfox.
There is also a need to investigate the ACMA regulatory requirements a bit more. I read an article a while ago that implied that some of the available lora band plans might not strictly comply with the Australian rules.
I think NNN Co use AS923-925. It would be nice to seperate the private networks from the public ones.
The original proposed AU915, sub band 2, although having device registration complexities, is relatively clear of other networks operation in the 915 ISM band.

Who else should be involved in this discussion?


(Gna) #6

I would certainly be keen to participate in any discussion on this subject.

I have kicked the can around the park pretty heavily over the last two months trying to get a stable OTAA result and seem to have it working fine now, although I can see opportunities to improve things.

There are issues with ADR though that are unresolved in the LoRaWAN client stack - I have implemented a fix for this and it is working well.

I did muck with AS923 and it worked better “out of the box” for OTAA - but this does not mean it is the right way to go forward. I am of the opinion that AU915 is the right plan. Happy to go into more details in this or a new thread.

Andrew


#7

The official ACMA endorsed channel plan is AU915 (ibid for NZ) and my personal belief is that it is the one we should all try to use. It has been suggested that one reason why AS923 was picked up, was because some vendors did not have support for AU915 on their chips. Using AS923 enabled them to get to the market without worrying about adding suport for AU915 and made inventory management easier. I have even read web sites which claim it to be superior, which is nonsense - the only advantage it has is in being able to run a 2 channel Gateway. But as Gateways have come down in price so quickly, there is no real sense in doing this. But now it is established (and in use with some big players) we have to deal with it. There are plenty of modules & Gateways that support both.
Unfortunately what the mixed use of AU915 and AS923 has done has reduce the level of inter-operability and hence choice available to users - especially for those buying off the shelf nodes from commercial suppliers.
If building your own nodes or Gateways, always try to use AU915. But if you have to connect to an existing network you may get stuck on AS923.


#8

AU915 was a fine choice. Just an evolution of NA915 but offset to avoid the Australian cellular bands. But it meant that devices needed to be made specifically for the AU economy, and the lack of scale in the early days meant that Australia was disadvantaged. Then along came AS923 and the promise of a much larger interoperable territory across Asia, so seemed like a nice economic choice to align on AS923.

Since then, Latin America has normalised on AU915 channel plan, so now AU915 is also a good economic choice with sufficient scale.

I would promote AU915


(Joey) #9

Hey JDP long time no speak… It’s me from down under… I used to call you regularly in your old job :slight_smile:

From an Australian RF regulatory point of view the 915-928MHz is defined in the ACMA short range devices regualtions , which calls up technical standard AS/NZS4268: FEB2017.

My interpretation of AS/NZS4268 for the 915-928 MHz ISM band is the following for digital modulation transmitters such as LoRa.

    Tx power  up to 1watt EIRP provided (psd <25mW/3kHz)

     Any modulation scheme  and  any number of channels  can be used, provide they meet  AS/NZS4268 
     tech requirements (test method  calls a up  FCC 15.127).

Hence from an RF regulatory point of view both AU915 and AS923 can be used. IE the LoRaWAN AU915 and AS923 channelization / protocol “fit” with within the ACMA governments RF regulation framework.

AU915
Has the ability to use 64+8 UPLINK channels… but it is highly recommend to turn off all channels except those same channels the gateway has… In this way both UPLINK and DOWNLINK channels are well defined and a much simpler Join protocol than AS923 .

History - Australia ISM 915 - 928MHz was derived from US FCC 15.247 and AU915 is basically the US LoRaWAN version and shifting of the UPLINK Channels above 915MHz (no change to the downlinks).

There are pros and cons for either AU915 and AS923, but large networks should be consistent one or the other.


(Joey) #10

Now which channels… that’s up to the gateway and network operator


(Gna) #11

I am not convinced about devices disabling channels not used by the gateway.

What happens now (with all channels enabled) is the device tries random channels across the full set of 72 until it gets a JoinACK from the network. This is very much hit and miss and leads to a variable delay to completing the OTAA procedure. Not very efficient and time consuming.

Once the join has been completed however, the network disables the unwanted channels - or should be doing so. (There is a problem here that needs to be resolved: https://github.com/Lora-net/LoRaMac-node/issues/533)

Disabling the unused channels (where known) is a band-aid fix.

Yes, it means that OTAA joins happen much more quickly, but it also means that you are locking in the network’s channel plan, making it impossible for networks to either change the plan or to expand into additional sub-bands without also reprogramming every device already deployed in the field.

I see this as being a really bad idea.

If the device’s OTAA process was amended such that the selection of channel for the join attempt wasn’t totally random, the join delay from trying to find the network in the first place could have a definable upper limit.

The OTAA join logic should first select a sub-band in a way that does not repeat (e.g. create a randomly shuffled listed of sub-bands) and then can select a random channel within the sub band for the join attempt. This will minimise the OTAA join delay to maximum 8 attempts with an mean of 4 (ignoring joins over the 500kHz channels 64-71).


(Gna) #12

The other issue with AS923, is that it mandates two join channels (923.2, 923.4MHz) that gateways must listen on. Because of how the gateways I have used (Multitech, Laird, MatchX) have been designed, this would lock one of the radios to a band covering these frequencies while the second radio could be programmed for some other sub-band in the 915-928MHz range.

You still end up with half the traffic for all the networks being pumped through a single 1MHz spectrum around the mandated join channels. This doesn’t seem ideal.


(Joey) #13

AU915 :With all channels enabled on the module uplink, there is a very high probability of uplink transmissions the gateway does not have channels for! This has been reported on the TTN forum many times.


(Gna) #14

Yup - just until the network gateway specifies the supported channels.