[OpenThread] Multiple Intances

[Thierry Hischier]

Hello community

I have a question regarding openthreads multiple instances.

I started playing around with the different example applications from silicon labs (ot-cli-ftd, sleepy-demo) and have now started on testing some of the features as a proof of concept. I need to do some testing in order to evaluate if OpenThread could be a solution for our product...

What I need to test is the following scenario:

In the above example, I have three different local networks and a global network. The idea is that all my local networks contain a router (which is the leader for its own local network) and some child devices (this could be sensors or other devices that needs to forward data). In addition, the three local networks should also be connected over a global network with each other. In the global network is one of the router of the different local networks the leader. From my understanding of Openthread, the global network should work, even if one of the local networks loose the connection and creates a partition of the global network and as soon as the partitioned network finds the global network again, it should automatically connects to it.
 

I saw inside the cli demo app that there was a configuration in order to use multiple instances (OPENTHREAD_CONFIG_MULTIPLE_INSTANCE_ENABLE). Now I'm wondering how this work. Is it really possible to create for example two OT instances and run two OpenThread network simultanously? If so, does that means that one OT instance contains the local network with which the different child devices can connect and send data to it and the second OT instance would be used for the connection to the global OpenThread network?

Thanks in advance!

[Jonathan Hui]

Great to hear that you are considering OpenThread for your product.

Do you really want/need to manage multiple Thread networks? From your use case description, it seems that a single Thread network might address your use case.

1. Thread devices may either be router-capable or end-device only. This should address your "local" communication needs, where end devices connect directly to routers.
2. Thread routers automatically form a mesh based on real-time connectivity. They implement a dynamic routing protocol to continuously optimize routes over the mesh topology.
3. Thread routers are all capable of forming their own Thread partitions. If two or more groups of Thread routers become disconnected, each group will form their own partition. Conversely, when two or more groups of Thread routers become connected again, they will merge into a single Thread partition. This should address your "global" communication needs.

Regarding OpenThread's "multiple instance" feature, this allows you to run multiple separate Thread networks simultaneously. Note that the multiple instances do not share any information or state. As a result, any routing/forwarding that you want to enable between the different Thread networks must be done separately and is effectively the same as general IPv6 routing/forward between different IPv6 network interfaces.

The multiple instance feature is most useful on constrained devices that do not offer an MMU. On Linux, for example, you can simply run multiple OpenThread processes simultaneously, where each process supports a single Thread instance.

Hope that helps.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ab4aa331-b230-40e4-8586-b2c17269e255o%40googlegroups.com.

[Thierry Hischier]

Hello Jonathan and thank you for your prompt reply!

Considering of your explanation, it seems that a single Thread network could be enough for the current use case. I will also look into that solution. But the final decision will be made from our System Architecture engineers and they want two networks running simultaneously. Maybe they have other features already in mind that I'm not aware of and therefore requires a second Thread network...

Regarding your explanation of the multiple instance features, does this mean that none of the two networks are building a mesh network automatically and I need to create the mesh behaviour on my own or does it mean that it needs some additional work if I want to send data from my local network to the global network?

A few questions regarding the two possibilities:

I tried going forward with the multiple instance project, but couldn't really find much information on how to do it. Is there some kind of examples about creating/using multiple instances?

I just found the code from the ot-cli-ftd demo application where you can choose with the OPENTHREAD_CONFIG_MULTIPLE_INSTANCE_ENABLE flag if a single instance is used or not. I enabled this flag and modified the code in order to create two OpenThread instances. I also have a function which set the dataset with hardcoded information for each OT instance. This will help when I want to connect the other thread devices with it. Unfortunately when I scan for OpenThread networks with a silabs dev-kit, I get always only one network running. Please find attached my code. It was my first attempt to do something with OT, so it is quite possible that it is far from correct or pretty...

Regarding the solution with only one instance:

- I assume that I'm only creating one OT network which will act as the "global" network?

- How can I connect the end-device with the correct router-capable device?

Thanks!

/thierry

[Jonathan Hui]

As you discovered, the ot-cli-ftd example app has an example of using the multiple instance API. However, the example app only initializes and starts a single instance (see the single call to `otInstanceInit()`). To support multiple instances, you will need to manage each instance separately. For example, if you want to run two instances, you'll need to have two calls to `otInstanceInit()`, two calls to `otTaskletsProcess()`, etc. Also note that when running multiple instances simultaneously, you'll also need to have multiple 802.15.4 radios (one for each instance).

As a reminder, if you are running a Linux host, you can simply run multiple OpenThread processes and avoid the need to deal with the multiple instance API.

--

Jonathan Hui

On Sun, Jun 7, 2020 at 9:35 AM Thierry Hischier <thierry....@gmail.com> wrote:

Hello Jonathan and thank you for your prompt reply!

Considering of your explanation, it seems that a single Thread network could be enough for the current use case. I will also look into that solution. But the final decision will be made from our System Architecture engineers and they want two networks running simultaneously. Maybe they have other features already in mind that I'm not aware of and therefore requires a second Thread network...

I tried going forward with the multiple instance project, but couldn't really find much information on how to do it. Is there some kind of examples about creating/using multiple instances?

I just found the code from the ot-cli-ftd demo application where you can choose with the OPENTHREAD_CONFIG_MULTIPLE_INSTANCE_ENABLE flag if a single instance is used or not. I enabled this flag and modified the code in order to create two OpenThread instances. I also have a function which set the dataset with hardcoded information. This will help when I want to connect the other thread devices with it. Unfortunately when I scan for OpenThread networks with a silabs dev-kit, I get always only one network running. Please find attached my code. It was my first attempt to do something with OT, so it is quite possible that it is far from correct or pretty...

Thanks!

/thierry

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/cde218bf-ace8-4f44-945f-5963218ba797o%40googlegroups.com.

[Thierry Hischier]

Hello

Ok, at least this means that I was almost 100% correct with what I did (creating two instances, setup 2 networks, 2 calls to otTaskletsProcess() etc...

I can't run the example on a Linux host, because I need to check that the multiple instance feature is running on our own hardware...

You wrote that I need multiple 802.15.4 radios (one for each instance to run it simultaneously). This makes absolutely sense, but our SoC has only one Radio front end.... But is it possible to share the same radio for both instance? Something like a time based sharing where I give the radio in a pseudo parallel manner to both instances? Do I loose connection with instance 1 when the radio is used for instance 2 and vice versa?

If I loose the connection, I have no other possibility to start with your proposition in your first answer. Sorry for the following question, maybe this is an obvious one, but I'm really new with OpenThread...

Let's say I will implement my solution with what you wrote:

1. Thread devices may either be router-capable or end-device only. This should address your "local" communication needs, where end devices connect directly to routers.
2. Thread routers automatically form a mesh based on real-time connectivity. They implement a dynamic routing protocol to continuously optimize routes over the mesh topology.
3. Thread routers are all capable of forming their own Thread partitions. If two or more groups of Thread routers become disconnected, each group will form their own partition. Conversely, when two or more groups of Thread routers become connected again, they will merge into a single Thread partition. This should address your "global" communication needs.

If we take my example as a starting point.

I have my first local network where I have one device, acting as a router (I assume this device will work like a FTD device). My first local network also contains 3 sensors (which will act as end device). What should I use as a starting point for the implementation? Can I use also an FTD and I can set the deivce in a state where it is working only as an end device (without router features)?

Regarding the direct connection between the router and the end devices. How can I assure that those 3 sensors connect with the router device from local network 1? Is it possible that they connect with the router from my second local network if they are close together? This is a requirement that is really important because the "local networks" must work as a unity, this means my 3 sensors from local network 1 must be connected to this local network and not with another one!

Thanks for your assistance!

/thierry

Am Montag, 8. Juni 2020 20:01:32 UTC+2 schrieb Jonathan Hui:

As you discovered, the ot-cli-ftd example app has an example of using the multiple instance API. However, the example app only initializes and starts a single instance (see the single call to `otInstanceInit()`). To support multiple instances, you will need to manage each instance separately. For example, if you want to run two instances, you'll need to have two calls to `otInstanceInit()`, two calls to `otTaskletsProcess()`, etc. Also note that when running multiple instances simultaneously, you'll also need to have multiple 802.15.4 radios (one for each instance).

As a reminder, if you are running a Linux host, you can simply run multiple OpenThread processes and avoid the need to deal with the multiple instance API.

--

Jonathan Hui

On Sun, Jun 7, 2020 at 9:35 AM Thierry Hischier <thierry...@gmail.com> wrote:

Hello Jonathan and thank you for your prompt reply!

Considering of your explanation, it seems that a single Thread network could be enough for the current use case. I will also look into that solution. But the final decision will be made from our System Architecture engineers and they want two networks running simultaneously. Maybe they have other features already in mind that I'm not aware of and therefore requires a second Thread network...

I tried going forward with the multiple instance project, but couldn't really find much information on how to do it. Is there some kind of examples about creating/using multiple instances?

I just found the code from the ot-cli-ftd demo application where you can choose with the OPENTHREAD_CONFIG_MULTIPLE_INSTANCE_ENABLE flag if a single instance is used or not. I enabled this flag and modified the code in order to create two OpenThread instances. I also have a function which set the dataset with hardcoded information. This will help when I want to connect the other thread devices with it. Unfortunately when I scan for OpenThread networks with a silabs dev-kit, I get always only one network running. Please find attached my code. It was my first attempt to do something with OT, so it is quite possible that it is far from correct or pretty...

Thanks!

/thierry

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openthre...@googlegroups.com.

[Robert Cragie]

Thierry,

It sounds to me like your System Architecture engineers may need to fully understand the features of Thread to see how it fits to your requirements. Guessing at why they want certain features doesn't seem like a good starting place for development.

From your original email, as Jonathan explains, it would seem that a single Thread network would meet the requirements. I am struggling to see why you would want to time-division multiplex two instances of a Thread stack on a single radio, where you will lose context for each stack periodically. This is generally problematic for routers, which require the radio to be receiving all the time on behalf of the Thread network they represent. Allocating even a small portion of that time to another network can be problematic, although if that is to appear as a sleepy end device on another network, that could work. However, I don't think that scenario fits into what you originally described.

Robert

On Tue, 9 Jun 2020, 06:44 Thierry Hischier, <thierry....@gmail.com> wrote:

Hello

Ok, at least this means that I was almost 100% correct with what I did (creating two instances, setup 2 networks, 2 calls to otTaskletsProcess() etc...

I can't run the example on a Linux host, because I need to check that the multiple instance feature is running on our own hardware...

You wrote that I need multiple 802.15.4 radios (one for each instance to run it simultaneously). This makes absolutely sense, but our SoC has only one Radio front end.... But is it possible to share the same radio for both instance? Something like a time based sharing where I give the radio in a pseudo parallel manner to both instances? Do I loose connection with instance 1 when the radio is used for instance 2 and vice versa?

/thierry

Am Montag, 8. Juni 2020 20:01:32 UTC+2 schrieb Jonathan Hui:

As you discovered, the ot-cli-ftd example app has an example of using the multiple instance API. However, the example app only initializes and starts a single instance (see the single call to `otInstanceInit()`). To support multiple instances, you will need to manage each instance separately. For example, if you want to run two instances, you'll need to have two calls to `otInstanceInit()`, two calls to `otTaskletsProcess()`, etc. Also note that when running multiple instances simultaneously, you'll also need to have multiple 802.15.4 radios (one for each instance).

As a reminder, if you are running a Linux host, you can simply run multiple OpenThread processes and avoid the need to deal with the multiple instance API.

--

Jonathan Hui

On Sun, Jun 7, 2020 at 9:35 AM Thierry Hischier <thierry...@gmail.com> wrote:

Hello Jonathan and thank you for your prompt reply!

Considering of your explanation, it seems that a single Thread network could be enough for the current use case. I will also look into that solution. But the final decision will be made from our System Architecture engineers and they want two networks running simultaneously. Maybe they have other features already in mind that I'm not aware of and therefore requires a second Thread network...

I tried going forward with the multiple instance project, but couldn't really find much information on how to do it. Is there some kind of examples about creating/using multiple instances?

I just found the code from the ot-cli-ftd demo application where you can choose with the OPENTHREAD_CONFIG_MULTIPLE_INSTANCE_ENABLE flag if a single instance is used or not. I enabled this flag and modified the code in order to create two OpenThread instances. I also have a function which set the dataset with hardcoded information. This will help when I want to connect the other thread devices with it. Unfortunately when I scan for OpenThread networks with a silabs dev-kit, I get always only one network running. Please find attached my code. It was my first attempt to do something with OT, so it is quite possible that it is far from correct or pretty...

Thanks!

/thierry

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/cde218bf-ace8-4f44-945f-5963218ba797o%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/8599ed4e-675f-4472-90e9-07634bca4890o%40googlegroups.com.

[Thierry Hischier]

Hello Robert

Maybe my explanation was not 100% understandable...

We have a working solution where we only have the local network feature (I know it is not the best term to explain it, but I can't give all related information on an open discussion group...)

The working solution has several Open Thread devices which builds a network (let's say this is my local network 1). There can be several of those local networks, even close to each other. Each network has a master which handles all related information from "sensors" and they must be able to interact in both direction. It is important that all sensors are connected with its proper master. This is in the current situation not a problem because the master and its sensor build its own OT network.

The next step, and this is where I need to do some tests, is where all masters are also connected to each other because they need to broadcast some information to all available routers inside the "global" network. We saw that it could be possible to use multiple instances, but weren't aware that they need its own radio. We also saw that Nordic for example can run BLE besides OT and I don't think that they have two radios. So they need to do something similar what I have in mind (with time sharing of the radio) but as you wrote, there could be a risk that they loose data because the RX of instance 1 is not always on...

Behind the idea to have a second network which we wanted to use for the global network on another OT instance was also that a huge part of the current running system could be reused. But as I say, maybe the proposition from Jonathan covers all specs from our side and I need to start from sketch for the new development...

What we need are the following requirements:
Each system contains a master (I assume this will be the router) and n sensors (which will act as end devices) and those devices must be connected directly (Master and sensors must be able to send and receive information at all time)

Several systems can be close and we need to assure that the sensor are connected to its master and only to its master.

The different systems needs a way to communicate to each other over a mesh network to forward information

Hope this makes more sense...

/thierry

Am Dienstag, 9. Juni 2020 08:30:33 UTC+2 schrieb Robert Cragie:

Thierry,

It sounds to me like your System Architecture engineers may need to fully understand the features of Thread to see how it fits to your requirements. Guessing at why they want certain features doesn't seem like a good starting place for development.

From your original email, as Jonathan explains, it would seem that a single Thread network would meet the requirements. I am struggling to see why you would want to time-division multiplex two instances of a Thread stack on a single radio, where you will lose context for each stack periodically. This is generally problematic for routers, which require the radio to be receiving all the time on behalf of the Thread network they represent. Allocating even a small portion of that time to another network can be problematic, although if that is to appear as a sleepy end device on another network, that could work. However, I don't think that scenario fits into what you originally described.

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/8599ed4e-675f-4472-90e9-07634bca4890o%40googlegroups.com.

[Robert Cragie]

Hi Thierry,

I completely understand that you cannot give all details of a project in an open forum. It is clearer now what your requirements are, thank you for the clarification. Some comments and questions from your explanation: I'm not expecting answers, it's more about things to consider.

• Do the distinct Local Networks/Systems need to be entirely independent from an 802.15.4 perspective, i.e. do they need to use a separate PAN ID and/or channel? If not, then a single Thread Network will likely meet your requirements,
• From your requirements, it's not clear whether the relationships you specify are application layer requirements from the perspective of binding sensors and masters or network topology relationships between nodes. Whilst not always the case, normally the network layer topology is kept independent from application layer bindings/groups between devices. In a mesh network, this is particularly important as it allows much more flexibility in providing network connectivity between two nodes with an application layer binding. You say they need to be in "direct connection" - is this specifically a layer 2 single hop radio connection between a sensor and its Master or do you mean there needs to be a specific application layer binding between a sensor and its Master? Similarly, you say "sensor is connected to its master and only to its master.". Again, is this a single radio hop layer 2 connection, or is it more from an application layer binding perspective?
• A Thread Router can be a highly capable device and perform sensor processing at the application layer. If a Thread Router has at least one other network interface it is generally considered to be a Border Router. How you describe the Master suggests that it could be a Border Router. Assuming the Master is a Border Router, then does the second network interface have to be a Thread network interface? If it is a more conventional Border Router in the Thread sense, i.e. with a non-802.15.4 secondary network interface, then OpenThread solutions are already there.
• It is always possible to TDM a single radio interface and certainly in a single 802.15.4/Bluetooth LE radio (like the Nordic), the Bluetooth LE activity will interrupt the 802.15.4 activity, which is likely to be receive if it's a Router. The same concept applies to multiple stack instances sharing a 802.15.4 radio. The device properties are important here; if both stacks represent Routers, then this is unlikely to work as you would typically have to allocate 50% to each stack, unless there is some other higher level control that can optimise this. However it is done, it is likely that the Router will be effectively "deaf" for a significant part of its activity, which is inconsistent with the requirements for a Thread Router as currently specified.

In summary, I believe a single Thread network would meet your requirements as you have written them but if there are specific reasons to separate the networks, then I would suggest multiple Thread networks connected through Border Routers and then assess how those Border Routers communicate through their second network interfaces and what the best solution for the second network is, i.e. it may not be another Thread network.

Robert

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/edda07a1-9888-4e17-b436-b1b5494cf0cdo%40googlegroups.com.

[Thierry Hischier]

Hello Robert

I will clarify your open questions with my colleague who has a better overview of the product since I started working 4 months ago at my new company (and 2 weeks ago on Open Thread).

I'll get back to you tomorrow with answers to your questions. Hopefully you can then point me into the correct direction for my project.

/thierry

Am Dienstag, 9. Juni 2020 12:42:33 UTC+2 schrieb Robert Cragie:

Hi Thierry,

I completely understand that you cannot give all details of a project in an open forum. It is clearer now what your requirements are, thank you for the clarification. Some comments and questions from your explanation: I'm not expecting answers, it's more about things to consider.

• Do the distinct Local Networks/Systems need to be entirely independent from an 802.15.4 perspective, i.e. do they need to use a separate PAN ID and/or channel? If not, then a single Thread Network will likely meet your requirements,
• From your requirements, it's not clear whether the relationships you specify are application layer requirements from the perspective of binding sensors and masters or network topology relationships between nodes. Whilst not always the case, normally the network layer topology is kept independent from application layer bindings/groups between devices. In a mesh network, this is particularly important as it allows much more flexibility in providing network connectivity between two nodes with an application layer binding. You say they need to be in "direct connection" - is this specifically a layer 2 single hop radio connection between a sensor and its Master or do you mean there needs to be a specific application layer binding between a sensor and its Master? Similarly, you say "sensor is connected to its master and only to its master.". Again, is this a single radio hop layer 2 connection, or is it more from an application layer binding perspective?
• A Thread Router can be a highly capable device and perform sensor processing at the application layer. If a Thread Router has at least one other network interface it is generally considered to be a Border Router. How you describe the Master suggests that it could be a Border Router. Assuming the Master is a Border Router, then does the second network interface have to be a Thread network interface? If it is a more conventional Border Router in the Thread sense, i.e. with a non-802.15.4 secondary network interface, then OpenThread solutions are already there.
• It is always possible to TDM a single radio interface and certainly in a single 802.15.4/Bluetooth LE radio (like the Nordic), the Bluetooth LE activity will interrupt the 802.15.4 activity, which is likely to be receive if it's a Router. The same concept applies to multiple stack instances sharing a 802.15.4 radio. The device properties are important here; if both stacks represent Routers, then this is unlikely to work as you would typically have to allocate 50% to each stack, unless there is some other higher level control that can optimise this. However it is done, it is likely that the Router will be effectively "deaf" for a significant part of its activity, which is inconsistent with the requirements for a Thread Router as currently specified.

In summary, I believe a single Thread network would meet your requirements as you have written them but if there are specific reasons to separate the networks, then I would suggest multiple Thread networks connected through Border Routers and then assess how those Border Routers communicate through their second network interfaces and what the best solution for the second network is, i.e. it may not be another Thread network.

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/edda07a1-9888-4e17-b436-b1b5494cf0cdo%40googlegroups.com.

[Thierry Hischier]

Hello Robert

Please find below some answers to your comments...

• Do the distinct Local Networks/Systems need to be entirely independent from an 802.15.4 perspective, i.e. do they need to use a separate PAN ID and/or channel? If not, then a single Thread Network will likely meet your requirements,

Maybe my understanding of OT is still not accurate enough, but as much as I understand OT, the idea is that devices can connect to another router inside an OT network if the current associate router disconnects. This is exactly what we can't have in our system. If you have a look at the following picture, hopefully you see what our system needs to achieve...

As you can see, we have three systems in our environment. Each of the system contains a master (which will act as the router) and 2 sensors (probably end devices). It is important that sensor 1.1 and sensor 1.2 are connected with master 1, sensor 2.1 and 2.2 with master 2 and so on. If master 1 is no longer available, sensor 1.1 and sensor 1.2 shouldn't connect to another router (master 2 or master 3). Because of this, we thought that the best idea is to create an OT network for each system. In this case, as soon as the master is no longer available, the two sensor will not connect to another router because they are not in the same OT network. They can have the same channel, but must be in a separate network with its own PAN ID... 

If we have only one OT network, how can we assure that sensor 1.1 and 1.2 are childs from master 1 and doesn't connect to another master?

• From your requirements, it's not clear whether the relationships you specify are application layer requirements from the perspective of binding sensors and masters or network topology relationships between nodes. Whilst not always the case, normally the network layer topology is kept independent from application layer bindings/groups between devices. In a mesh network, this is particularly important as it allows much more flexibility in providing network connectivity between two nodes with an application layer binding. You say they need to be in "direct connection" - is this specifically a layer 2 single hop radio connection between a sensor and its Master or do you mean there needs to be a specific application layer binding between a sensor and its Master? Similarly, you say "sensor is connected to its master and only to its master.". Again, is this a single radio hop layer 2 connection, or is it more from an application layer binding perspective?

The relationships between sensors and its master should be a network topology relationship between nodes. The idea is that the relationship between a master and its sensors is handled by OT and not inside our application. If a sensor is connected to the master, it must be the correct one and we don't need to worry that another sensor will connect to the wrong master. Again, we thought that the easiest way to achieve this is via a local network with its own PAN ID in order to connect the correct sensors with the master. Also, if we loose the master, the connected sensors don't connect to another router. All of this should be handled directly by OT via its own local network.

• A Thread Router can be a highly capable device and perform sensor processing at the application layer. If a Thread Router has at least one other network interface it is generally considered to be a Border Router. How you describe the Master suggests that it could be a Border Router. Assuming the Master is a Border Router, then does the second network interface have to be a Thread network interface? If it is a more conventional Border Router in the Thread sense, i.e. with a non-802.15.4 secondary network interface, then OpenThread solutions are already there.

The second network should be OT. Hence we cannot use the router as a border router.

• It is always possible to TDM a single radio interface and certainly in a single 802.15.4/Bluetooth LE radio (like the Nordic), the Bluetooth LE activity will interrupt the 802.15.4 activity, which is likely to be receive if it's a Router. The same concept applies to multiple stack instances sharing a 802.15.4 radio. The device properties are important here; if both stacks represent Routers, then this is unlikely to work as you would typically have to allocate 50% to each stack, unless there is some other higher level control that can optimise this. However it is done, it is likely that the Router will be effectively "deaf" for a significant part of its activity, which is inconsistent with the requirements for a Thread Router as currently specified.

We discussed the TDM approach internally and agree that this is nothing that we should consider. We can't use the system if the router can miss information on one of the two networks.

/thierry

Am Dienstag, 9. Juni 2020 12:42:33 UTC+2 schrieb Robert Cragie:

Hi Thierry,

I completely understand that you cannot give all details of a project in an open forum. It is clearer now what your requirements are, thank you for the clarification. Some comments and questions from your explanation: I'm not expecting answers, it's more about things to consider.

• Do the distinct Local Networks/Systems need to be entirely independent from an 802.15.4 perspective, i.e. do they need to use a separate PAN ID and/or channel? If not, then a single Thread Network will likely meet your requirements,
• From your requirements, it's not clear whether the relationships you specify are application layer requirements from the perspective of binding sensors and masters or network topology relationships between nodes. Whilst not always the case, normally the network layer topology is kept independent from application layer bindings/groups between devices. In a mesh network, this is particularly important as it allows much more flexibility in providing network connectivity between two nodes with an application layer binding. You say they need to be in "direct connection" - is this specifically a layer 2 single hop radio connection between a sensor and its Master or do you mean there needs to be a specific application layer binding between a sensor and its Master? Similarly, you say "sensor is connected to its master and only to its master.". Again, is this a single radio hop layer 2 connection, or is it more from an application layer binding perspective?
• A Thread Router can be a highly capable device and perform sensor processing at the application layer. If a Thread Router has at least one other network interface it is generally considered to be a Border Router. How you describe the Master suggests that it could be a Border Router. Assuming the Master is a Border Router, then does the second network interface have to be a Thread network interface? If it is a more conventional Border Router in the Thread sense, i.e. with a non-802.15.4 secondary network interface, then OpenThread solutions are already there.
• It is always possible to TDM a single radio interface and certainly in a single 802.15.4/Bluetooth LE radio (like the Nordic), the Bluetooth LE activity will interrupt the 802.15.4 activity, which is likely to be receive if it's a Router. The same concept applies to multiple stack instances sharing a 802.15.4 radio. The device properties are important here; if both stacks represent Routers, then this is unlikely to work as you would typically have to allocate 50% to each stack, unless there is some other higher level control that can optimise this. However it is done, it is likely that the Router will be effectively "deaf" for a significant part of its activity, which is inconsistent with the requirements for a Thread Router as currently specified.

In summary, I believe a single Thread network would meet your requirements as you have written them but if there are specific reasons to separate the networks, then I would suggest multiple Thread networks connected through Border Routers and then assess how those Border Routers communicate through their second network interfaces and what the best solution for the second network is, i.e. it may not be another Thread network.

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/edda07a1-9888-4e17-b436-b1b5494cf0cdo%40googlegroups.com.

Am Dienstag, 9. Juni 2020 12:42:33 UTC+2 schrieb Robert Cragie:

Hi Thierry,

I completely understand that you cannot give all details of a project in an open forum. It is clearer now what your requirements are, thank you for the clarification. Some comments and questions from your explanation: I'm not expecting answers, it's more about things to consider.

• Do the distinct Local Networks/Systems need to be entirely independent from an 802.15.4 perspective, i.e. do they need to use a separate PAN ID and/or channel? If not, then a single Thread Network will likely meet your requirements,
• From your requirements, it's not clear whether the relationships you specify are application layer requirements from the perspective of binding sensors and masters or network topology relationships between nodes. Whilst not always the case, normally the network layer topology is kept independent from application layer bindings/groups between devices. In a mesh network, this is particularly important as it allows much more flexibility in providing network connectivity between two nodes with an application layer binding. You say they need to be in "direct connection" - is this specifically a layer 2 single hop radio connection between a sensor and its Master or do you mean there needs to be a specific application layer binding between a sensor and its Master? Similarly, you say "sensor is connected to its master and only to its master.". Again, is this a single radio hop layer 2 connection, or is it more from an application layer binding perspective?
• A Thread Router can be a highly capable device and perform sensor processing at the application layer. If a Thread Router has at least one other network interface it is generally considered to be a Border Router. How you describe the Master suggests that it could be a Border Router. Assuming the Master is a Border Router, then does the second network interface have to be a Thread network interface? If it is a more conventional Border Router in the Thread sense, i.e. with a non-802.15.4 secondary network interface, then OpenThread solutions are already there.
• It is always possible to TDM a single radio interface and certainly in a single 802.15.4/Bluetooth LE radio (like the Nordic), the Bluetooth LE activity will interrupt the 802.15.4 activity, which is likely to be receive if it's a Router. The same concept applies to multiple stack instances sharing a 802.15.4 radio. The device properties are important here; if both stacks represent Routers, then this is unlikely to work as you would typically have to allocate 50% to each stack, unless there is some other higher level control that can optimise this. However it is done, it is likely that the Router will be effectively "deaf" for a significant part of its activity, which is inconsistent with the requirements for a Thread Router as currently specified.

In summary, I believe a single Thread network would meet your requirements as you have written them but if there are specific reasons to separate the networks, then I would suggest multiple Thread networks connected through Border Routers and then assess how those Border Routers communicate through their second network interfaces and what the best solution for the second network is, i.e. it may not be another Thread network.

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/edda07a1-9888-4e17-b436-b1b5494cf0cdo%40googlegroups.com.

[Robert Cragie]

Hi Thierry,

Thanks for your detailed explanation. It does seem unusual to impose strict layer 2 connectivity constraints as you explain but I accept there may be deliberate reasons for doing this.

Basically, it doesn't look like OpenThread is going to work out-of-the-box for your requirements. It may be possible to use OpenThread but the routers will be a somewhat custom design, effectively running dual OpenThread stacks. Practically, you would need two radios on each router but it may be possible to TDM a single radio if the sensors report infrequently and they could have some sort of periodicity. Anything like this would require customisation of OpenThread.

If you can accept some latency from the sensor communication, you might be better off using 802.15.4 in beacon-enabled mode. The sensors would be RFDs, the routers would be coordinator FFDs, with the first router effectively being the PAN coordinator. Address allocation and whitelists would be sufficient to provide the isolation you need. This would be much simpler than using Thread overall, as none of the resilience and robustness processing that Thread provides would actually be necessary. However, there is a practical issue of finding such an implementation off-the-shelf. It's likely the silicon vendors may have some examples with their example code that is usually freely available from their websites and this could be used as a starting point. Would you need the other features that come with OpenThread, e.g. 6LoWPAN, UDP, CoAP etc.? In other words, do the sensors need to be first-class IPv6 devices, or do they just need to be able to send some data in a MAC frame (bearing in mind they are always one hop from their router)?

Robert

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/4a85e11e-d0fc-4b0d-9b64-a9106f256c7ao%40googlegroups.com.

[Jonathan Hui]

One option to arbitrarily restrict communication in a Thread network is to utilize OpenThread's `macfilter` feature.

• Build Configuration: src/core/config/mac.h
  
• CLI: macfilter command

With macfilter, you can whitelist IEEE 802.15.4 extended addresses and only accept frames sourced from the whitelsted extended addresses.

This would allow you to maintain a single Thread network, where the "masters" are all Thread routers and the sensors are restricted to communicating with a single Thread router.

Would that work for you?

--

Jonathan Hui

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/4a85e11e-d0fc-4b0d-9b64-a9106f256c7ao%40googlegroups.com.