Multiprotocol Wireless Technology

Switched Multiprotocol involves having two separate possible modes running on one chip. Each mode from a protocol and stack point of view is separate from each other. To swap protocols, you have two options: 1) Bootload the firmware image you want that contains the other protocol stack, do the communicating, and then bootload back to the other image, or 2) Have one image that has two modes to completely enable or disable each protocol.

One example of this is a connected home device (like a door or window sensor) that only needs Bluetooth to be commissioned to join the network, and then will communicate via Zigbee for a vast majority of its life. To do this, you will ship the part with Bluetooth software programmed or enabled, interact with the user/installer via a phone, and then disable Bluetooth, enable Zigbee and join the Zigbee network. Then, typically the only way to go back to Bluetooth is via a user interrupt, like a button, or to reach out to the node via Zigbee to tell it to swap back to Bluetooth because the device cannot simultaneously remain on the mesh network and hold on to its Bluetooth connection. The time between swapping is very long – in the hundreds of milliseconds for Bluetooth and even longer for Bluetooth mesh.

Dynamic Multiprotocol is more fluid and flexible in its ability to swap and can more quickly hop between the two protocols. With dynamic multiprotocol, you do not shutdown or de-initialize the entire protocol stack; instead, you simply keep both running but swap who is using the physical radio, drastically reducing the time to switch. You are sharing the lowest level dependencies between the two protocols, which is typically the radio (this is represented as the bottom brick in the wall in the image below). By being able to swap faster, it allows Bluetooth Low Energy (BLE) connections to remain active, and at the same time remain on the Zigbee/Thread network, by ensuring you remain in the timing windows for each of the protocols as not to drop connection or be removed from the network. This allows the node to respond to either a command via Zigbee/Thread or Bluetooth, which means a user on the phone can control the node and the main network.

A good example of a dynamic multiprotocol application is a door lock where you want the user to be able to lock/unlock to door via Bluetooth on their phone, as well as use sensors, time schedule, or cloud command via Zigbee.