System States and Scheduling Policies¶
A DMM policy tells the scheduler which stack has priority in a certain application state and whether submitted RF commands can be deferred or not. From the policy, the scheduler can deduce a how scheduling conflicts shall be resolved. A set of policies is called a policy table. Each table entry represents a comprehensive system state and consists of the following parameters:
- type of each stack in this entry
- possible states of each stack encoded as flags and OR’ed together
- stack priorities in the current system state
- timing constraints of RF commands in the current system state
During a comprehensive system state, a stack might have multiple possible states. For instance, while the BLE stack is in connected state with a high priority, a Sub-1 GHz connection might be in idle state or transmit state or might receive an acknowledgment. That is why a flag type is used for stack states.
Creating A Policy Table¶
Each application or system wishing to use the DMM must create a policy table that will be used by used by the DMM to make scheduling decisions.
The policy table is entry structure defined by
DMMPolicy_PolicyTableEntry in
dmm_policy.h. An application will usually
define multiple system states and initialize a policy table array.
A shell of a policy table could be created like so:
DMMPolicy_PolicyTableEntry samplePolicyTable[] = {
// Todo: Define DMM states here
};
Choosing A Stack Type¶
For each policy table entry, the application developer must choose a stack
type. The DMMPolicy_StackType enum defines available stack types. At
the moment, only DMMPolicy_StackType_BlePeripheral and
DMMPolicy_StackType_WsnNode are available.
For example for WSN and BLE the stack type array is initialized like this:
{DMMPolicy_StackType_BlePeripheral, DMMPolicy_StackType_WsnNode},
Note
Only BLE and WSN Node are supported at this time. Creating new stack types is not supported.
Creating a DMM State¶
A DMM state is a combination of each protocol stack state. There can be multiple
states of a protocol stack that map to a given DMM state. It is the combinations
of protocol stack states that define a DMM state. This state combination must be
mapped to a 32-bit bitmask in the stackStateBitMask[] field. For example, a
when the BLE-Stack is advertising and the WSN Node is in either sleeping,
TX or ACK state could be defined below as a DMM state as below:
{(DMMPOLICY_STACKSTATE_BLEPERIPH_ADV) , (DMMPOLICY_STACKSTATE_WSNNODE_SLEEPING | DMMPOLICY_STACKSTATE_WSNNODE_TX | DMMPOLICY_STACKSTATE_WSNNODE_ACK)},
Each DMM state has a policy assigned to each stack when that state is active.
A policy is a structure that contains timing and priority information. In a
state where the BLE-stack is low priority and has not critical timing and the
WSN Node is of high priority and of critical timing the
DMMPolicy_Policy array would be defined as:
{DMMPOLICY_PRIORITY_LOW, DMMPOLICY_TIME_NONE_CRITICAL, //BLE SP Stack
DMMPOLICY_PRIORITY_HIGH, DMMPOLICY_TIME_CRITICAL} //WSN NODE Stack
Note
The offset into both stackStateBitMask[] and DMMPolicy_Policy[] is
controlled by the stackType enumeration. Each state must contain a mapping
of stack
type to policy and stateBitMask.
The complete DMM state entry discussed above is defined as
{
{DMMPolicy_StackType_BlePeripheral, DMMPolicy_StackType_WsnNode},
{(DMMPOLICY_STACKSTATE_BLEPERIPH_ADV) , (DMMPOLICY_STACKSTATE_WSNNODE_SLEEPING | DMMPOLICY_STACKSTATE_WSNNODE_TX | DMMPOLICY_STACKSTATE_WSNNODE_ACK)},
{DMMPOLICY_PRIORITY_LOW, DMMPOLICY_TIME_NONE_CRITICAL, //BLE SP Stack
DMMPOLICY_PRIORITY_HIGH, DMMPOLICY_TIME_CRITICAL} //WSN NODE Stack
},
A DMM state structure should be created for every possible combination of stack
states and priorities that will be encountered by the application. Each of these
must be added to the DMMPolicy_PolicyTableEntry.
Initializing the Policy Table¶
Once the policy table has been defined, it must be initialized and passed to the DMM. This is done through three steps:
- Initialize the policy module
- Initialize the parameter structure used to open the module to a known default state
- Modify the necessary policy parameters as needed
- Open the policy module by passing in the parameter struct.
This initialization is generally performed in main before the RTOS is started to
prevent any stacks from running commands before the policy module is
initialized. Refer to the DMM sample application’s main.c for an example of
ow to initialize a the policy module.
Furthermore, the sample policy table that defines the DMM states for WSN Node +
BLE-Stack can be found in dmm_policy_blesp_wsnnode.[c,h].
Setting the State of the Stack¶
Since the DMM does not hook directly into the stack, it relies on each stack’s high level application to inform the policy module of any changes in the stack. Such stack changes are usually signaled to the high level application via a message, callback, or event.
Whenever the application is signaled that the stack has changed state, the
application should immediately notify the DMM of the new stack state using the
DMMPolicy_updateStackState() API.
Sample Policy: WSN Node + BLE Peripheral¶
There is one sample policy that is provided by TI alongside the DMM examples.
While the given combinations and relative priorities can be tweaked by the
application developer, this policy should serve as a starting point when
developing a DMM application. The table below defines the DMM states in the
dmm_policy_blesp_wsnnode sample policy.
| Stack Type | BLE Peripheral | WSN Node |
| Stack State(s) | Advertising | Sleeping or TX or ACK |
| Policy | Low Priority, Time Critical | High priority, Not time critical |
| Stack Type | BLE Peripheral | WSN Node |
| Stack State(s) | Connecting or Connected | TX |
| Policy | High Priority, Time Critical | Low priority, Not time critical |
| Stack Type | BLE Peripheral | WSN Node |
| Stack State(s) | Connecting or Connected | ACK |
| Policy | High Priority, Time Critical | Low priority, Not time critical |
| Stack Type | BLE Peripheral | WSN Node |
| Stack State(s) | Any | Any |
| Policy | High Priority, Time Critical | Low priority, Not time critical |