How to use Zigbee and Thread for multi-protocol.

[OYAMA YUKIO]

Hello,

At the following URL,

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multiprotocol_support.html

In "The Thread and Zigbee protocols support running another protocol in parallel.", does "another protocol" refer to BLE?

So, as with the following question.

 Concuurent Multiprotocol Communication (BLE ,Zigbee,Thread) 

Is Zigbee+Thread still not possible today, and only Zigbee+BLE or Thread+BLE combinations can be run simultaneously?

Is it possible to combine two protocols into one firmware unless Zigbee and Thread are running at the same time?

It is a solution to switch between Zigbee and Thread by giving some kind of trigger. (At least, that trigger is not the incoming signal of the respective protocol.)

And can the protocol switching be done within the application? Or do I have to start from boot when making that switch?

Best Regards,

Yukio Oyama

[AHaug]

Hi again,

In "The Thread and Zigbee protocols support running another protocol in parallel.", does "another protocol" refer to BLE?

Yes, this is correct

Is Zigbee+Thread still not possible today, and only Zigbee+BLE or Thread+BLE combinations can be run simultaneously?

It is ZigBee + BLE or Thread + BLE, not (ZigBee + Thread + BLE), so yes the same as mentioned in the older case you linked.

Is it possible to combine two protocols into one firmware unless Zigbee and Thread are running at the same time?

Yes, it should be possible, but if you are aiming to do so yourself it might be more complicated than simply using the Multi Protocol Support Library already created by us (and which we really recommend you use). It could be a solution to timeslice the use of the radio yourselves, but we do not have any existing samples that illustrates how to do this other than the MPSL

And can the protocol switching be done within the application? Or do I have to start from boot when making that switch?

I think it should be possible to do so within the application if you implement the proper timeslicing algorithms. I believe the main hurdle here is going to be the protocols competing for the use of the radio

Kind regards,
Andreas

[OYAMA YUKIO]

Hello, Andreas-san,

Thanks for your answer.

The meaning of the question

"And can the protocol switching be done within the application? Or do I have to start from boot when making that switch?"

is not intended to be so complex that it can be time-sliced to make it appear as if it is running at the same time.

For example, if what I want to do is a simple operation like switching between Zigbee and Thread every minute, can I simply switch between Zigbee and Thread within one application?
Or do I have to go back to reboot to switch between the respective protocols?

Best Regards,

Yukio Oyama

[AHaug]

Hi,

I will have to verify this with a colleague of mine working in the ZigBee developer team when they return from vacation (start of August), but in the meanwhile I believe this should be a sufficient reply:

OYAMA YUKIO said:

For example, if what I want to do is a simple operation like switching between Zigbee and Thread every minute, can I simply switch between Zigbee and Thread within one application?

Normally you can not swap between protocols without any multi protocol support since the chip only has one radio. For 802.15.4 (ZigBee and Thread) and Bluetooth LE you will have to swap which of the protocols that has access to the radio at a given time. Even though both Thread and ZigBee uses the 802.15.4 driver and the 802.15.4 driver supports swapping, I am not 100% sure that this still is possible to do, so I will ask my colleague when they return about this.

If it is possible, you will most likely have to disable ZigBee and then enable Thread (and the other way around when going back) within the application. This might in theory work, but I don't believe this is a good solution. This will cause that the device disappears from either the Thread or ZigBee network for a indefinete time. Even though it will return, other devices in the Thread or ZigBee network will consider the device as "gone from the network" unless you swap back again quick enough. In addition you will have to start up and initialize the ZigBee/Thread network every time to rejoin the network. 

If you want the user to choose if this is either a Thread or ZigBee device at startup it should work fine, but not if you want to swap every minute due to how it interacts with keep alive procedures and similar.

I hope this clarifies your question a bit, and I will return with a verification with regards to this within early next week. In the meanwhile, please let me know if you have any additional question regarding this topic!

Kind regards,
Andreas

[OYAMA YUKIO]

Hello Andreas-san,

Your response clarifies what I need to understand. Thank you.

1, Can two protocols be dynamically swapped for one radio?
Your answer will mention the possibility, but it will become clear when your colleague in charge returns.

2, After changing protocols and disappearing from the network, when it reverts back to the original protocol, can it be restored with its previous state intact?

2-1, Network-side issues (this is not a question for you).

Does the network have a period of time in which it allows devices to disappear and reappear like ghosts?

2-2, Device issues (this is a question for you)

Can the device be resurrected with its previous settings retained when it reverts back to the original network? 

This may bother you as I don't know what to keep as a setting myself

3, When the network refuses to reinstate the device (this is a question for you)

Can the device run its protocols from initialization?

Probably, It can initialize and join the network without having to redo the boot, as the device may still lose the network in normal operation. Is this correct?

Best Regards,

Yukio Oyama

[AHaug]

Hi and thank you for your patience.

I've heard back with the MPLS, ZigBee and Radio driver teams after the vacation period and they say that ZigBee + Thread multiprotocol combo is not supported in NCS . This would require two instances of a radio driver to be present, which we do not have any solutions for at this point in time.

Apologies for the long response time, and I hope this answers your question

Kind regards,
Andreas

[OYAMA YUKIO]

Hi Andreas-san,

Thanks for remembering to follow up.

Does the answer from the driver team mean that Zigbee and Thread cannot be changed dynamically?

Before Zigbee and Thread networking issues, nRF52840 cannot switch between Zigbee and Thread within one application?

Can it switch back to boot?

Best Regards,

Yukio Oyama

[AHaug]

Hi,

Apologies for the delay in answer. I've been out of office this week.

Yes, currently we do not support dynamically change between ZigBee and Thread in the same application.

If the device has sufficient memory to store both stacks, you can switch between the protocols during boot and selecting if the device should be a Tread device or a ZigBee device at boot. You can do it like it is done for the Sleepy End device in the light switch, i.e if you hold a button while you boot it up, you choose ZigBee, while holding another button selects Thread. Then you can initialize the protocol and start a thread for the protocoll chosen.

Note that the same issues with regards to leaving the network will be present if you intend to design a protocol switching algorithm that includes rebooting, i.e going from Z -> T -> Z will still cause issues with the device leaving and rejoining the network

Kind regards,
Andreas

[OYAMA YUKIO]

Hi Andreas-san,

I understood that it is not possible to dynamically switch between Zigbee and Thread within one application. That fact affects our plans in no small way.

However, there is a slight hope that we can switch by starting over from the boot.

Now that I know what kind of system would allow me to switch between the two protocols, I close the case.

I appreciate your support, thank you.

Best Regards,

Yukio Oyama