Enhanced Data Request

In a lot of practical network, most of the devices are sleeping devices, which are connected to a few Full Function Devices (FFDs). Usually, the sleeping devices wake up periodically, asking data from the FFDs and report information back to the network. 

For most of the applications, it is critical to provide long battery life for the sleeping devices. A majority portion of power is consumed when the sleeping device is active, asking for data and sending data in the duty cycle. Since the power consumption in active mode is around ten thousand times higher than in sleep mode, lower the total active time plays an important role to prolong the battery life. 

According to IEEE 802.15.4 specification, there are typically three message exchanges after a sleeping device wakes up:

1. Data Request command from the sleeping device to FFD, asking for indirect message from FFD.
2. Indirect message from FFD to sleeping device
3. Message from sleeping device to FFD.

In order to save battery power, we can combine message 1 and 3 together, attach message 3 as payload of message 1. In this way, there are only two messages transmitted, saving the time in CSMA-CA detection/protocol header transmission and put the device into sleep earlier. Our tests show that the total active time could be lowered up to 20-30% in certain usage case. 

To enable Enhanced Data Request feature, ENABLE_ENHANCED_DATA_REQUEST must be defined in configuration files for protocols: ConfigP2P.h or ConfigMiWi.h. The reason of enabling this feature in protocol layer instead of application layer is that both sleeping devices and FFDs must enable this feature at the same time. While configuration files in application layer is for each individual devices and configuration file in protocol layer is for every devices, it makes sense to enable/disable this feature in the protocol layer to avoid any mismatch in feature enabling. 

There is no special function call for the Enhanced Data Request feature. However, the application function call procedure is different with or without Enhanced Data Request feature. 

For applications without Enhanced Data Request feature, the procedure after MCU waking up is following:

1. Wake up the transceiver by calling MiApp_TransceiverPowerState with parameter POWER_STATE_WAKEUP_DR. It will wake up the transceiver as well as asking FFD for indirect message by sending out Data Request command.
2. Send data from sleeping device to FFD.

For application with Enhanced Data Request feature, the procedure after MCU waking up is revised, as shown below:

1. Send data from sleeping device to FFD. However, the data is just queue up in the memory. Actual data is not sent yet.
2. Wake up the transceiver by calling MiApp_TransceiverPowerState with parameter POWER_STATE_WAKEUP_DR. It will wake up the transceiver and send Data Request command for indirect message. The data that is sent in step 1 will be the payload of Data Request command. At FFD side, it will handle such message by spliting it into Data Request command as well as the individual message.

The implementation of Enhanced Data Request feature can be found in feature demo in the release package. 

Enhanced Data Request feature can be used to transmit unicast message from the sleeping device to the FFD, but broadcast message still depends on normal message delivery method, because broadcast message and Data Request command have different destination address. 

Because Enhanced Data Request is a brand new feature, ZENA sniffer program has not been updated to decode it. However, this limitation would not affect the operation of the stack.