Hi, and welcome to this session on the Dynamic Multi-protocol Manager. What is it? How does it work? And how can it be used?

In this session, we will cover the fundamentals of using the Dynamic Multi-protocol Manager, a software module that allows for multiple radio protocol stacks to coexist and operate concurrently on a single CC13X2 or CC26X2 device. The Dynamic Multi-protocol Manager empowers the applications to reap the benefits from multiple wireless protocols on one single MCU.

This could, for example, be smartphone accessibility and home automation networks via Zigbee. My name is Max Wennerfeldt and I'm a software application engineer here at Texas Instruments. During this session, we will try to cover the following topics. What is the Dynamic Multi-protocol Manager or DMM for short? What value does it bring to the system? How does the DMM operate and how does it work? What is the DMM Policy Table and how does its policies define the system behavior? What is the limitations to consider when working with the DMM and where can you find training material?

This session is divided into two main halves. During the first half, we will touch on what the DMM is on a very high level, how it fits into the system, basic use cases, how it works, and the limitations connected to it. During the second half, we'll touch on how to use the DMM, what a policy table is, and how its policies are defined, what balanced mode is, and what is needed from the application in terms of code. In the end, we will go over the available training material on the DMM today.

The DMM is cross-layer software module that lives on this side of the original applications. The goal with the DMM is to simplify running multiple radio protocol stacks alongside each other on one single device.

The DMM is made up of two separate modules, the DMM Policy Manager and the DMM Scheduler. The DMM Policy Manager holds the state of the system and all the rules and policies connected to it. The DMM scheduler provides scheduling and conflict resolution features to the radio driver.

Let's start by looking at a few basic use cases for the DMM. The DMM could, for example, be used to access information from a sensor network, using a smartphone. Like in this picture, where you can see a sensor node also acting as BLE peripheral, providing a connection to a smartphone.

Another use case could, for example, be provisioning of devices into an existing network. For example, the DMM-enabled device could be a Zigbee end device and the BLE peripheral, where the BLE peripheral provides an easy way of commissioning the Zigbee end device into an existing Zigbee network.

The DMM could also be used to create a bridge between two existing networks. Like in this example, where did the DMM-enabled device creates a bridge between the sensor network to the left and the Zigbee network to the right.

Now let's look at the Policy Manager and how it works. The Policy Manager provides the rules to the DMM Scheduler and tells it how to schedule a command and how to resolve a conflict. Rules in the context of the DMM is what is referred to as policies within the Policy Table. The Policy Table makes up the complete set of rules that can be applied to the system by the Policy Manager. The Policy Manager can dynamically change between the rules based on the combined states of both of the stack applications running in the system.

As an example of what I mean with combined states, we can take this picture here. Each stack applications have multiple states. Stack application A has four-- scanning, doing OAD, transferring file, and commissioning. Stack application B has three states-- advertising, awaiting acknowledgment, and idle.

Let's assume that the bold ones are active states for each application. The DMM Policy Manager would look and see that stack A is performing scanning and stack B is performing advertising. This would result in the policy set being invoked, which means that stack A is higher priority than stack B.

Now let's look at the DMM Scheduler and how that works. The DMM Scheduler organizes the radio command queue in the system. Whenever a stack is issuing a command to the radio driver, the radio driver will ask the DMM Scheduler to place this command in the queue at the proper location.

Whenever there is a conflict between two commands, either at schedule time or during runtime, the radio driver will call out to the DMM Scheduler's conflict resolution hook, and ask it to resolve the conflict between the two commands.

The DMM Scheduler uses a dynamic scheduling method, rather than a time division multiple access one. This allows for better utilization of the shared radio, as there's no fixed time slots in the system.

Now let's look on how the DMM Scheduler handles conflicts. Whenever the DMM scheduler are putting a command into the queue, it's ordering the queue based on the start time of the command. Assuming there's no conflict between two commands when looking at their start times, both commands will be placed into the queue but the DMM scheduler.

In case of a conflict between two commands during the scheduling time, the DMM scheduler will resolve the conflict right away. In the case where there will be a runtime conflict between two commands, the DMM scheduler will handle this at runtime when the conflict occurs. Let's have a look at an example of this.

If this is the radio command timeline, stack A starts by scheduling the first command. Currently it's the only command in the queue. Now stack B schedules a command at the exact same start time as the stack A command. This is a conflict at scheduling time that is resolved right away.

Now stack A schedules another command and another command. Stack B also schedules another command. Assuming stack B's second command is about to run, we now have a conflict at runtime. This conflict is resolved by the resolution hook, which is invoked when stack B is scheduled to run.

Now let's look at some of the limitations that comes with using the DMM. The DMM is fundamentally a lossy system, which means that any conflict or utilization greater than 100% will result in a loss of data, this because DMM arbitrates a single radio source. Another limitation to keep in mind is that unlike CPU scheduling, preempted commands cannot be resumed.

Whenever the DMM scheduler aborts a command, the command will not run again until rescheduled by the stack. The DMM will occasionally try to reschedule commands itself as an alternative to resuming. We'll come back to this in a few slides. Finally, the DMM support is limited to only two radio protocol stacks at one given time.

Now let's look on how to use the DMM, how it looks in code, and what a policy table looks like. Using the DMM is supposed to be easy. What I mean by this is that the effort needed to implement DMM to an existing application should be relatively low. For example, it could be as easy as setting up the scheduling rules needed for the system, a.k.a. the policy table; initializing the DMM once during the startup; and updating the DMM with application states, if needed.

In theory, the DMM supports any radio protocol stacks combination, as long as it's a feasible one. When evaluating a combination of radio protocol stacks, ask yourself, do both the protocols stacks support DMM? Is there enough radio time for both protocols to operate? And how would the protocol handle radio rejection, a.k.a. loss.

Now let's look at what makes up the policy table and how this looks in code. First off, the policy stable defines the stack roles of the radio protocol stacks that is used in the system. This could, for example, be BLE peripheral or Zigbee device.

The roles that is available to the user is the ones defined by the DMM policy stack role and numerator. This is something that is predefined with the DMM and that cannot be extended by the user itself.

It's important to note the index order of how you assign your stack roles into the policy table, this because the index order here must match with whatever order you use when you define the policies of the system. Next the policy table contains a reference to the policies that is going to be used within the system.

Finally, the policy table contains a reference to which index table to use. The index table is currently not used. But it's something that in the future will create a deeper connection between the stacks and the DMM, and not only the user and the DMM.

Now let's look at how the policies are set up and how this makes up the ruling based on the stack application state. As a base point, the policies are made up by an array of DMM policies states. Each policy contains two app state entries, one for each stack row. The first entry for each stack row is the state entry. The state entry makes up the combination of states for which this policy will apply. For example, while stack A are in state X or state Y, and stack B are in state Z, the policy 1 will apply.

The next entry is the weight of each of the stack roles when policy 1 is active. The weight can be considered the priority of each application stack, and can be either priority low or priority high. Next where we have the timing constraint entry. This entry tells the DMM Scheduler if it should consider the commands from the stack time critical or not.

The paused entry is a tricky one. It tells the DMM if the application stack is to be considered paused or not paused. Whenever the paused state changes for a stack, the DMM will call out to the stack application to ask it to pause or un-pause its activity. The DMM itself will not take any actions based on this state.

The last entry is the applied activity one. This is currently not used, but will be used in the future together with the index table found in the policy table. Finally, there's a common entry called balanced mode that when active, will change the behavior of the policy as explained above. We will cover this in the next slide.

Whenever balanced mode is active, a time-based dynamic priority will be used, instead of the weights that we assigned within the policy. The way it works is that the stack that is considered high priority based on the weight within the policy, will be given guard times. It will be given an On MIN guard time and and Off MAX guard time.

Let's use the picture below to try to explain this. Stack A is considered high priority and is given guard times. It's giving an On MIN guard time of 100 milliseconds, and an Off MAX guard time of 50 milliseconds. What this means is that stack A is guaranteed at least 100 milliseconds of high priority radio time. After these 100 milliseconds, stack B can choose to preempt stack A, and will at that point gain the high priority instead of stack A.

Now stack B is guaranteed at maximum, 50 milliseconds of high priority radio time. After this 50 milliseconds expire, when the next preemption occurs, the priorities will shift back to stack A it will be considered the high priority stack again. Balanced mode is particularly useful for collector type applications, which is always receiving.

We'll now come back to the occasional re-scheduling of commands that the DMM Scheduler would do following a preemption. Whenever the DMM preemps a long-going receive command, it will choose to reschedule this command instead of notifying the stack about it. The DMM will mask this activity for the stack application, which means that for the stack application it all will look like one single ongoing RX activity, while in reality it could be several small ones with preemptions in between.

Now let's look into what is needed from the application in terms of code in order to run DMM. The amount of application interaction with the DMM depends on the policy table you define. If you define multiple policies, the application needs to update the DMM with state. Just only one policy or one state, the application might not need to update the DMM with state, but you're fine with just initializing the DMM once in the beginning.

Now in code, this means that as a baseline you have to start with initializing and opening the Policy Manager. When you initialize the Policy Manager, you're passing in which policy table to use and how many policies it contains. Next, you have to initialize and open the DMM Scheduler. The DMM Scheduler takes two parameters. It takes the stack roles and the index table pointer, which is also defined inside the policy table.

Finally, you have to register the clients within the DMM Schedule. You register the task handle connected to the stack in question. It binds this to a specific stack role. For example, stack A's task handle is bound to stack role stack A. If using multiple policies or applications stacks in the system, you might also need to update the DMM Policy Manager with the current state of your application.

As we're nearing the end of this session, let's look into what training material is available for the DMM today. To start with, there's a few examples available today as part of the SimpleLink software development kit. These examples showcase different combinations of the available TI stack offerings. In each of the examples, the BLE peripheral is combined with a second stack.

For example, in the case of TI 15.4, the BLE peripheral is combined with the TI 15.4 sensor. In the case of EasyLink, the BLE peripheral is combined with EasyLink wireless sensor network node. And Zigbee, the BLE peripheral is combined with the Zigbee end device or Zigbee router. In each of these examples, the BLE peripheral provides an interface into the other stack, which allows you to interact with it using a smartphone.

Regarding documentation and other training materials, the DMM user's guide that you can find in the SDK and online at dev.ti.com/tirex, provides the most up to date and detailed explanation of the DMM and how to use it.

There is a set of SimpleLink Academy training modules available for the DMM online at dev.ti.com/tirex. This training covers topics such as the DMM basics, how to customize an example to fit your own use case, and how to integrate DMM into pre-existing projects. We have now reached the end of this session. Thank you for watching.