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

[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