Relation between Sync Word, Private Network and End-Nodes


#1

I’m building a private network with the loraserver, and I understand that for private networks I need to set this information on my end-node. So, to do that I set this information in a #define and initialize the protocol stack with it.

The problem is that when I set the public network to false my node can’t be able to join, but with the public network the node works just fine. I was looking for the reason for that but the only information that I found about this is that for each of them, public and private networks, there is a sync word: 0x34 to public, 0x12 to private.

I also found this interesting article about LoRa and on page 4 the author says:

but that was not pretty clear to me.

My question is: What is the impact of this change in terms of the management of the network? Why the node can’t join when I set the public network to false?


#2

I think the reason why your nodes can’t join the network / why the gateways don’t receive your node data is that you need to configure the private sync word for each node too. How to do this depends on your node. An example for the Microchip RN2483:

image


#3

Thanks for the answer @brocaar.

I do not think that this is the problem because this sync word is already configured in my end-node (i believe): In my file LoRaMac.c I have this function SetPublicNetwork

As I said, in a #define I set the public network to false or true, depending on the value, the syncword is set to the radio. The value for LORA_MAC_PRIVATE_SYNCWORD = 0x12 and LORA_MAC_PUBLIC_SYNCWORD 0x34.

I looked at the gateway and the loraserver to find any configurations about this syncword but I do not got anything. What i don’t know is if this syncword is already configured on my gateway or loraserver.


#4

Sorry, I might have read your question too fast. On the gateway you configure this in the packet-forwarder settings. See:


#5

I’ve tried to help with this question and find out that there is one more line in global_conf.json that might should be changed. There is a part of global_conf.json:
“gateway_conf”: {
“forward_crc_disabled”: false,
“forward_crc_error”: false,
“forward_crc_valid”: true,
“gateway_ID”: “”,
“keepalive_interval”: 12,
“push_timeout_ms”: 120,
“serv_port_down”: 1780,
“serv_port_up”: 1780,
“server_address”: “us01-iot.semtech.com”,
“stat_interval”: 20,
“synch_word”: 52
}
Here you can see parameter “sync_word”:52. Which means that you’re using public network(52 in dec = 0x34 in hex). To use private network this parameter should be set to 18(in hex - 0x12).


#6

Hi guys, thanks for answer.

For both tips i couldn’t find a place to put this informations (there is not a “gateway_conf”, for example), i’m using a gateway Laird Sentrius RG1xx LoRa, my configuration file is like this:

{
  "data": {
        "name": "Sentrius configuration Thu Oct 05 2017 14:07:52 GMT-0300 (BRT)",
        "country_code": "US",
        "url": "",
        "icon": ""
  },
  "lora": {
        "logging_level": "debug",
        "gateway_mode": "forwarder",
        "country_code": "US",
        "connected": true
  },
  "forwarder": {
        "gateway_ID": "C0EE000000000000",
        "server_address": "172.20.9.1",
        "serv_port_up": 1700,
        "serv_port_down": 1700,
        "keepalive_interval": 10,
        "stat_interval": 30,
        "push_timeout_ms": 100,
        "forward_crc_valid": true,
        "forward_crc_error": true,
        "forward_crc_disabled": false
  },
  "lorawan_public": false,
  "synch_word": 18,
  "radios": {
        "radio_0": {
              "freq": 902700000
        },
        "radio_1": {
              "freq": 903500000
        },
        "chan_multiSF_0": {
              "enable": true,
              "radio": 0,
              "if": -400000
        },
        "chan_multiSF_1": {
              "enable": true,
              "radio": 0,
              "if": -200000
        },
        "chan_multiSF_2": {
              "enable": true,
              "radio": 0,
              "if": 0
        },
        "chan_multiSF_3": {
              "enable": true,
              "radio": 0,
              "if": 200000
        },
        "chan_multiSF_4": {
              "enable": true,
              "radio": 1,
              "if": -400000
        },
        "chan_multiSF_5": {
              "enable": true,
              "radio": 1,
              "if": -200000
        },
        "chan_multiSF_6": {
              "enable": true,
              "radio": 1,
              "if": 0
        },
        "chan_multiSF_7": {
              "enable": true,
              "radio": 1,
              "if": 200000
        },
        "chan_Lora_std": {
              "enable": true,
              "radio": 1,
              "if": 300000,
              "bandwidth": 500000,
              "spread_factor": 8
        },
        "chan_FSK": {
              "enable": false,
              "bandwidth": 500000,
              "datarate": 0
        }
  }

So, I put both info “lorawan_public”: false and “synch_word”: 18 like is shown above, but I think this is not working properly, when I download the file to see what is the current configuration of the gateway, lorawan_public and synch_word is not there. Any of you already used this gateway?


#7

Never had deal with that gateway, but maybe clue will be in log file?(location of this file I don’t know, but try to google)


#8

EDIT:
I’ve noticed that you put this parameters not in some block. These parameters should be in the block where they’re expected. Let me explain, so you better understand(I just don’t know if I explained good:upside_down_face:)
Here WILL BE AN ASSUMTION:
I was googling to try find out where this parameters should be written(like .json config file example for your gateway). In the User Guide it says only simple things, like you can save, load from and so on.

But let’s try to compare multitech and Sentrius gateway config file. To avoid long explanation, I’ll just put my ASSUMTION, how your config should look like:

{
  "data": {
        "name": "Sentrius configuration Thu Oct 05 2017 14:07:52 GMT-0300 (BRT)",
        "country_code": "US",
        "url": "",
        "icon": ""
  },
  "lora": {
        "logging_level": "debug",
        "gateway_mode": "forwarder",
        "country_code": "US",
        "connected": true
  },
  "forwarder": {
        "gateway_ID": "C0EE000000000000",
        "server_address": "172.20.9.1",
        "serv_port_up": 1700,
        "serv_port_down": 1700,
        "keepalive_interval": 10,
        "stat_interval": 30,
        "push_timeout_ms": 100,
        "forward_crc_valid": true,
        "forward_crc_error": true,
        "forward_crc_disabled": false
        "synch_word": 18,
  },            
  "radios": {
        "lorawan_public": false,
        "radio_0": {
              "freq": 902700000
        },
        "radio_1": {
              "freq": 903500000
        },
        "chan_multiSF_0": {
              "enable": true,
              "radio": 0,
              "if": -400000
        },
        "chan_multiSF_1": {
              "enable": true,
              "radio": 0,
              "if": -200000
        },
        "chan_multiSF_2": {
              "enable": true,
              "radio": 0,
              "if": 0
        },
        "chan_multiSF_3": {
              "enable": true,
              "radio": 0,
              "if": 200000
        },
        "chan_multiSF_4": {
              "enable": true,
              "radio": 1,
              "if": -400000
        },
        "chan_multiSF_5": {
              "enable": true,
              "radio": 1,
              "if": -200000
        },
        "chan_multiSF_6": {
              "enable": true,
              "radio": 1,
              "if": 0
        },
        "chan_multiSF_7": {
              "enable": true,
              "radio": 1,
              "if": 200000
        },
        "chan_Lora_std": {
              "enable": true,
              "radio": 1,
              "if": 300000,
              "bandwidth": 500000,
              "spread_factor": 8
        },
        "chan_FSK": {
              "enable": false,
              "bandwidth": 500000,
              "datarate": 0
        }
  }

“lorawan_public”: false, —> In “radios” block,
“synch_word”: 18, —> In the “forwarder” block

Try it, and I’m looking forward to hear if it helped.


#9

Well, I tried to do these things @Oleg_Somov , but unfortunately, still does not work. That is really odd, I think somehow the gateway is filtering all configuration keys that was not there by default. I also tried to put the syncword inside the “radios” since this is a radio configuration, but yet without success. An important detail is that when I put the synch_word inside the forwarder, the gateway doesn’t even let me update the config, an error arises just when I press “Apply”.


If I remove the synch_word, the gateway seems to update (At least the update message appears), but as I said when I download the file with the current configuration, these keys are not there.


#10

UPDATE

I left the location of the key lorawan_public inside of the “radios” block and removed the synch_word key, now is like this:

 "radios": {
        "lorawan_public": false,
        "radio_0": {
              "freq": 902700000
        },
        "radio_1": {
              "freq": 903500000
        },
        "chan_multiSF_0": {
              "enable": true,
              "radio": 0,
              "if": -400000
        },
        "chan_multiSF_1": {
              "enable": true,
              "radio": 0,
              "if": -200000
        }, 
        ...

The node could join the network but the behavior is really odd. For tests, my node’s firmware is sending a packet every 20 seconds, when I was using the lorawan_public = true, the packets were successfully sent without any trouble, but when I set to false I can’t see the packets that supposedly were sent (because they were not). I just see the packets arriving just after 1 or 2 seconds.

So, the question on top of my head remains

I mean, what are the implications of this syncword in terms of how the node will send the packets? Because seems to me that the node is more “controlled” or limited to send something.


#11

@alexbatista To answer your question I asked experienced person I know.

So for you to understand all this “sync_words”. You can find a lot of LoRa module specification for example:
SEMTECH SX1276
image
MULTITECH RN2483/RN2903
image

Also you can find some definition in LoRa Alliance Specification:

So what does it all mean? First, you need to distinguish concept/idea of LoRa and LoRaWAN. You can go to LoRa Alliance Web site and read more about it, but shortly, here is a picture from LoRa Alliance Overview
image

LoRa - just modulation type - PHY layer(Physical layer). On picture - in red frame.
LoRaWAN it’s MAC Layer(Media Access Control) layer. On picture - in green frame.

LoRAWAN defines all standards, protocols and network architecture. Again, if you want to go deep, go to LoRa Alliance.

And finally about sync_word. sync_word=“0x34” means, that device using LoRaWAN specification and should follow it(OTAA, ABP, encryption, authentication, CRC and so on.)

When you’re using sync_word=“0x12” you literally use private network based on LoRa modulation (private means not “encrypted” or “only for you”). Private means that your protocol, headers, architecture, etc. ARE implemented by you. You might not use Gateway or NS, instead you can make everything point to point, or mesh network. Also you can create your own header format, payload format. So everything is possible at this point.

Since the LoRa Server use and follow LoRaWAN specification, I have no idea how it COULD behave in case of using “private network”.

A lot of people, organizations work on the LoRaWAN specification to make it easy,secure and reliable. And it’s a standard, which makes it easy to implement in your devices.

If there is more questions or something unclear, I’m happy to answer.

Best regards,
Oleg Somov


LoRa communication between nodes
#12

Now I’m really confused. What you just said, somehow makes sense, but let me tell you why this syncword question arisen:

First of all, I think that the main question that comes before this syncword questions is: What is the difference between public and private network? For this question, is really hard to find a trusted answer because in every place that I search I got a completely different answer, for example:

In this topic from laird support, they try to explain the difference between these two networks:

  • A private LoRaWAN network is usually made up of a single application with network infrastructure provided by a single organization.
  • A public LoRaWAN network will support multiple applications from multiple organizations.

This is more a conceptual definition rather than technical, and that is ok. The problem begins when a put the following two pieces of information side by side:

The first one, I got in the same discussion on TTN:
Johan says:

There’s not really a functional difference between private and public networks. For roaming, you’ll need a NetID. A NetID allocation requires Contributor membership with the LoRa Alliance.

The second one is on multitech “documentation” where they say explicitly that there is a functional difference between private e public networks:

Screenshot from 2017-10-06 23-29-54

Why is this discussion important? Because since I’m using this loraServer project and I’m building my own LoRaWAN network (that means, I’ll not use TTN or any other service like what they provide, I’m using my own gateways, end-nodes, and applications) I’m assuming that I have to use a private network syncword for my case.
See, my interest is to build a LoraWAN network, the concept in my mind was that both private and public networks are LoRaWAN compliant, but considering your explanation, only the public really is, right?

Since I started to work on my current project, I was assuming that public networks were only that provided by companies like TTN, LORIOT and others, that is, services where anyone could register them nodes. To me seems logical to pay for a license to the LoRa Alliance if you build a public network (considering public network on this terms) and for private network all completely free, but both LoRaWAN compliant.

So, to resume, can I use a public syncword for my use case? Without having to pay any licenses?

Thanks for you support @Oleg_Somov, I really appreciate that

Best Regards


#13

Yeah, @alexbatista, I understand your confusing. I’ll answer in order of your post and mark every point.

1. If we’re talking NOT about the sync_word, just forget about it for now, I think private and public it’s just overall meaning. About the definition you’ve provided from Laird. There is no word about the sync_word.
All you need to notice here is LoRaWAN(remember to differ LoRa network and LoRaWAN network).

Public LoRaWAN and Private LoRaWAN in this case still LoRaWAN(not a LoRa network) compliant networks and they represent next division(in examples):

Public LoRaWAN network could be any company that provides you resources to use LoRaWAN network just having nodes. You don’t need to run your own NS and AS, all you need is to have nodes, that will be connected to the Public LoRaWAN network, for example - Actility.

Private LoRaWAN network means that you will be using your own NS and AS, provide all connectivity and do whatever you want. For example - The LoRa server project. It’s open-source project which means you can use it freely without any restrictions and pay, but you should have your own gateways, nodes, AS and NS.

Think about it like you would think about Cloud. Public Cloud would be - Microsoft Azure, Google Drive etc. When the Private Cloud is something that you need to create by your own.

**2.**Discussion on TTN and Multitech documentation.

These two definitions/explanations is TOTALLY DIFFERENT

To understand discussion on TTN use first clause of this post. This discussion about NetID in private and public LoRaWAN networks. And when you’re think about it, you can understand that when you’re using YOUR OWN(understand private) LoRaWAN network, you can assign any NetID for your network, and then configure the gateways to use this identifier. That will be helpful to divide different network instances, but it’s another discussion.

We can make an conclusion: YES, in this case, when private and public means just “Who is owner of network” there is no functional difference, because BOTH IS COMPLIANT to LoRaWAN specification.

**3. ** Second piece of information you’ve provided about Multitech documentation:

Here we can refer to my previous post about sync_word.

First of all here sync word means that if you use sync_word=0x34 - you should be compliant with LoRaWAN specification and follow LoRaWAN network infrastructure(I decided to put here a picture, because it’s long to explain):

Here you can see divided functionalities.

When you’re configuring your gateway to use sync_sord=“0x12” you’re using private LoRa network(notice LoRa not LoRaWAN), which means that you can use different infrastructure, different packet header, your own functionalities and so on. In case of Multitech gateways, to understand their private mode refer to the link you’ve provided:

In MultiTech’s private LoRaWAN network, the MultiConnect Conduit (with LoRa mCard) functions as both the gateway and the central network server.

So with sync_word=“0x12” it will be Multitech’s type of LoRaWAN network. It’s not gonna follow LoRaWAN spec. And now I can say, that is the reason why you see your messages every 1-2 sec, instead 20 sec.

4.

Yes, (refer to first clause of this post) , in case if you understand private as your own LoRaWAN network(LoRaWAN compliant network with your own gateways, NS,AS and so on) and public as all the connectivity will be provided by some company(let’s say TTN, you’re only need to have nodes, as you said in your post “I was assuming that public networks were only that provided by companies like TTN, LORIOT and others, that is, services where anyone could register them nodes.”).

5. To answer your last question:

YES, you can, without any pay, because using sync_word=“0x34” means that you WILL BE compliant and follow LoRaWAN specification.

I’m happy to answer your question, because it’s a food for my brain.

If you have any question, or something was unclear - you’re welcome to ask.

Best regards,
Oleg Somov


[AU915-928] OTAA fails, join-accept not received by mDot
#14

I think that your answer is really good enough. You helped me a lot. Thank you @Oleg_Somov :smiley:


#15

You’re very welcome, @alexbatista! If you’ll have more questions - do not hesitate, I’m trying to check this forum every day :grinning:


#16

Actually, when LoRa modulation is used, the sync word value doesn’t really matter.
For instance, SX1272/1276 are unable to filter the incoming packets by sync word value, and so on.


#17

Hello,

I gathered some facts from datasheets and source about this topic and hope to supply a bit more clarification of what is done with the sync word behind the scenes without adding confusion.

sync word / synch word are the same. It is just not used consistently.

LoRaWAN Specification:
According to the lorawan regional parameters the synch word (not sync word. it’s synch word) states use of LoRa modulation. No mentioning of 0x12. It is always 0x43 for LoRa but they mention it SHOULD be used, so not essentially required. Also I could not find any explanations there.
See lorawan_regional_parameters_v1.1rB-final.pdf, page 15 section 2.2.1 EU863-870 Preamble Format.
Also I noticed the synch word is not defined for all countries, e.g. Australia.

Semtech Packet Forwarder Source:

There is no mentioning of a “sync_word” key/value (also no synch_word) in the semtech packet forwarder configuration but there is a sync_word variable which is only used for GFSK modulation.

But there is a lorawan_public key/value and it has the following comment:
Enable ONLY for public networks using the LoRa MAC protocol

And in the code it does write the numbers of 0x34 (if lorawan_public == true ) or 0x12 (false) into the registers using SPI.

Note the SX1301 (concentrator chip on gateways) registers are not explained in the data sheet. You are referred to the github repository instead.

SX1272 / SX1276:

and

The data sheets say this about sync:

4.2.11.1. Sync Word Recognition
Sync word recognition (also called Pattern recognition) is activated by setting SyncOn in RegSyncConfig. The bit synchronizer must also be activated in Continuous mode (automatically done in Packet mode).

The block behaves like a shift register as it continuously compares the incoming data with its internally programmed Sync word and sets SyncAddressMatch when a match is detected. This is illustrated in Figure 29 below


During the comparison of the demodulated data, the first bit received is compared with bit 7 (MSB) of
RegSyncValue1 and the last bit received is compared with bit 0 (LSB) of the last byte whose address is determined by the length of the Sync word. When the programmed Sync word is detected the user can assume that this incoming packet is for the node and can be processed accordingly.

4.2.14.2
Variable Length Packet Format

Variable length packet format is selected when bit PacketFormat is set to 1.

This mode is useful in applications where the length of the packet is not known in advance and can vary over time. It is then necessary for the transmitter to send the length information together with each packet in order or the receiver to operate properly.

In this mode the length of the payload, indicated by the length byte, is given by the first byte of the FIFO and is limited to 255 bytes. Note that the length byte itself is not included in its calculation. In this mode the payload must contain at least 2 bytes i.e. length + address or message byte.

An illustration of a variable length packet is shown below. It contains the following fields:

4.2.14.3. Tx Processing

In Tx mode the packet handler dynamically builds the packet by performing the following operations on the payload available in the FIFO:

  • Add a programmable number of preamble bytes.
  • Add a programmable Sync word.
  • Optionally calculating CRC over complete payload field (optional length byte + optional address byte + message) and appending the 2 bytes checksum.
  • Optional DC-free encoding of the data (Manchester or whitening).

4.2.14.4. Rx Processing
In Rx mode the packet handler extracts the user payload to the FIFO by performing the following operations:

  • Receiving the preamble and stripping it off.
  • Detecting the Sync word and stripping it off.
  • Optional DC-free decoding of data.
  • Optionally checking the address byte.
  • Optionally checking CRC and reflecting the result on CrcOk.

In variable length mode the first byte received after the sync word is interpreted as the length of the received packet.

4.2.14.6. Packet Filtering
The SX1272/73 packet handler offers several mechanisms for packet filtering, ensuring that only useful packets are made available to the uC, significantly reducing system power consumption and software complexity.

Sync Word Based

Sync word filtering/recognition is used for identifying the start of the payload and also for network identification. As previously described, the Sync word recognition block is configured (size, value) in RegSyncConfig and RegSyncValue(i) registers. This information is used both for appending Sync word in Tx and filtering packets in Rx.Every received packet which does not start with this locally configured Sync word is automatically discarded and no interrupt is generated. When the Sync word is detected payload reception automatically starts and SyncAddressMatch is asserted.

Note

Sync Word values containing 0x00 are forbidden.

Address Based

Address filtering can be enabled via the AddressFiltering bits. It adds another level of filtering above Sync word (i.e. Sync must match first) and is typically useful in a multi-node networks where a network ID is shared between all nodes (Sync word) and each node has its own ID (address).

Register description mentions this:

Timing diagrams show some important info about the sync word:

Next: Recommended SX1272 Settings for EU868 LoRaWAN Network Operation

Semtech Forum

Comment by Semtech employee:

http://semtech.force.com/lora/LC_Answers_Questions?id=90644000000PlqNAAS

Gregory (Semtech Corporation)
Hi All,
We have used the term sync word as we could not[SIC] find a better name but it is not a sync word as such. This register is just a way to differentiate two LoRa signals which do not interfere with one another. Here, not all values are permitted if you want to be able to differentiate signals with different “sync word”.

How sync word change looks on the scope:

https://revspace.nl/DecodingLora

Personal Conclusion

For me it boils down to a bad choice of variable name ‘lorawan_public’ and ambiguous interpretations by different people even within Semtech Corporation.

The default value mentioned everywhere depends on the level of abstraction, e.g. Semtech chip has Default 0x12 but end device radio modules will most likely set to 0x34 as ‘their default’.

If you want to use your end device with different gateways (and subsequently networks) all participants, end device and each gateway operator will need to stick to the mentioned 0x34 or devices wont be able to communicate due to sync word mismatch. So my advice is to stick with this value if you want to compatibility.

Also from the docs above:

The SX1272/73 packet handler offers several mechanisms for packet filtering, ensuring that only useful packets are made available to the uC, significantly reducing system power consumption and software complexity. Sync word filtering/recognition is used for identifying the start of the payload and also for network identification.

This is a mentioned in the data sheet and not the lorawan specification but still the mentioning of ‘network’ even if only understood in a broader sense does relate a bit to the lorawan network term. But setting the sync word other that 0x34 will shut off access to lorawan networks while only allowing matching sync word networks.

So if you choose a sync word different you lose compatibility of end devices to other networks but if thats what you want, this should be done in order to achieve less iC activity or better battery runtime depending on configuration.

What else happens inside undocumented firmware as side effects of setting the sync word I don’t know.

I also read that using a different sync word other than 0x34 means not being 100.0000% compliant to the lorawan spec even if all participants would be compliant in all other aspects of the specification.

I am not a lawyer but maybe someone could find out if it is legit to run a public lorawan network without using 0x34 even if that would not make a lot of sense to do so.


#18

Is it possible to use any other Synch Word value than 0x12/0x34 for private custom LoRa protocol ? (not LoraWAN)


#19

Thanks for this explanation. I’m reading a lot of docs looking for a definition and how to use the sync word, but no luck yet.
I ran a few tests here, changing the sync word on the end devices and gateways but the results are quite odd.

I was expecting, some kind of filtering, based on this:

@Oleg_Somov, do you have any further information on how to achieve this?
Thanks.


#20

If you can control the sync word in every device completely I suppose that could work.