Should private LoRaWAN networks use a different sync word?

So far I thought that public LoRaWAN networks (maybe including commercial shared networks such as TTI) need to use sync word 0x34 (or 0x3444 for SX126x 16 bits). And private LoRaWAN networks require 0x12 (or 0x1424 16 bits). Even @htdvisser mentioned that, though long ago:

Also, I see configurations in some LoRaWAN libraries, to change it.

However, maybe my understanding was just wrong, as in another topic @LoRaTracker mentioned a distinction between LoRaWAN and non-LoRaWAN:

And that might be right. From the 1.0.2b Regional Parameters:

2.1.1 EU863-870 Preamble Format

The following synchronization words should be used:

Modulation Sync word Preamble length
LORA 0x34 8 symbols
GFSK 0xC194C1 5 bytes

Same for other versions, same for all other regions, and no mention about public/private (there) at all.

If LoRaWAN is indeed always 0x34 (or 0x3444 16 bits), then off-the-shelf sensors that are shipped with just an OTAA DevEUI, AppEUI and AppKey will work on both public and private LoRaWAN networks. Nice.

So: should private LoRaWAN networks use a different sync word?

This, obviously, isn’t correct. A officially assigned NetID isn’t required for a private network. But 0 and 1, typycally used for private networks, surely are NetIDs too.

There’s no offically published document saying this (SX127x datasheets don’t count, they actually say/know nothing about LoRaWAN). And, as you already said, Reg. Params. doc clearly states that 0x34 should be used for LoRaWAN.

1 Like

Another confusing thing: if 0x12 (or 0x1424 16 bits) would be non-LoRaWAN, then there would be basically only two sync words in LoRa: LoRaWAN and non-LoRaWAN? That’s probably not the case, so why (or by whom) was this 0x12 defined… :slight_smile:

I don’t know if 0x12 and 0x34 are the only allowed values, but you surely cannot use whatever value you want to use for sync word. Someone from Semtech was trying to explain these matters at their Salesforce community site some years ago, but that site was redesigned since that (and a lot of valuable info was lost), not sure if it still possible to finf that discussion.

1 Like

Semtech have never, as far as I am aware released full information of how syncwords work or which ones are compatible between SX127X systems (16 bit sync words) and SX126X systems (32 bit syncwords).

I have also not seen an reasonable explanation as to why some constructs of syncwords loose you sensitivity on the receive side.

However following an issue raised on the Semtech Knowledge base;

It seems that Semtech might be about to reveal what is known about syncwords.

1 Like

Should TTN be encouraging the setup of Private networks in the first place ?

Funny you asked; I started to look for the official documentation as I wanted to make clear that non-programmable off-the-shelf devices are not usable on private networks, as they have the sync word fixed to the public 0x34.

To be clear, I very much endorse an open, shared, public network: Why do you need TTN?

I note the comment in that about setting up a private network, but presumably thats to do with setting up a private backend.

If a user sets up a Gateway and nodes with a different syncword, and uses the (free) TTN backend, are they OK with that ?

One issue with different syncwords is that you may not even know the nodes\gateways are there, so its possible a ‘rogue’ network local to you could be consuming\blocking channels and you wont see them …

In the 3 years since I wrote that message I haven’t heard of any network actually using a different sync word.

@LoRaTracker’s explanation seems reasonable, but the fact that the sync words are specified separately for each band in the LoRaWAN Regional Parameters specification suggests that there could be future bands that use different sync words.

Let’s keep an eye on that thread then.

I would say no. All LoRaWAN networks need to be compliant with the LoRaWAN Regional Parameters specification, and use the sync word defined for the band.

1 Like

2.4 GHz, for instance. And it seems that there will be additional different PHY level(s) for 868/915 MHz.

2.4Ghz LoRa does not have a configuarable syncword, according to the datasheet.

SyncWords for GFSK and FLRC modes are supported.

Yeah, but what is the hardcoded value of sync word? 0x12? 0x34? :slight_smile:

Since the datasheet does not mention a syncword for LoRa, then even if you assume there is a secret one there and it is hardcoded, its possible value is of no real relavence.

The SyncWord is always configurable. It is here to separate networks and avoid spending time demodulating frame which belongs to another network, so if you are on a completely different band you can re-use a syncword without worry.
As soon as you are on a private network you can use whatever valid SyncWord you want as long as it is different from the public one. I think the value 0x12 for private network was just defined to give people one valid value which was tested and characterized. But if you set up multiple private network in the same geographic area you will need to use different sync word and if you respect some rules it will work properly.

As for the rules:

  • Each nibble of the SX127x SyncWord must be strictly below 8 to be compatible with SX126x
  • Each nibble of the SX127x SynchWord must be different from each other and from 0 or you might experience a slight loss of sensitivity
  • Translation from SX127x to SX126x : 0xYZ -> 0xY4Z4 : if you do not set the two 4 you might lose sensitivity
    There is more to it, but this should be enough to setup your networks and hopefully the official response will be more complete.

We actually were talking about LoRaWAN and hypothetical changes to Regional Settings doc, not about P2P and the only currently available end node chip’s datasheet.

I just ran into a LoRa (not LoRaWAN) FAQ-item from Semtech, emphasis mine:

How does LoRa behave when there is coexistence of private and public networks at given location?

When it comes to the access point side (gateways), the use of the “private” sync word versus “public” sync word is useful to ensure that the gateways don’t report a vast majority of the incoming traffic using a different setting.

So again, this doesn’t sound like a mandatory thing.

That would be extremely bad.

The reason is that sync word detection is “leaky” - try configuring the wrong one, and you’ll see that sometimes packets get through anyway.

If a packet is picked up by a gateway configured with the wrong sync word, and reported in as stronger than any copy of that packet received by one with the right sync word, then the “accidental” availability of that gateway could walk an ADR algorithm into assuming that gateway is a regulator contributor to the network, or get it elected to send a reply.

But since wrong syncword packets only get through a fraction of the time, this would be highly misleading, either causing missed downlinks or causing ADR to adjust for a nearby gateway that picks up the node’s signal loudly when it detects it at all, but usually misses it.

If you’re going to connect a gateway to TTN, definitely use the proper sync word.

Messing that up is far more severe than the “extraneous” (and decoder-rejected) traffic that would occur from sharing a synchword between a private and a public network.

It’s effectively the difference between a “spoofing” denial of service and a (very gentle) “flooding” one.

1 Like