Staging:CC31xx & CC32xx Power Management

Introduction
Power management and energy preservation are among the most cumbersome issues and of the primary focus areas for online systems. Handling power regimes effectively is fundamental for any power-aware solution. This problem becomes even more challenging in cases where a certain component of the overall solution is more power hungry than the rest of the system. Such is the case for many embedded WiFi capable systems. The application note covers CC3X00 device (CC3100 and CC3200) networking subsystem power management (PM) capabilities and the basic know-how of system behavior. It will provide the basic toolbox for developers to designing optimal system.

CC3100 contains the networking subsystem only and driven by external MCU host. CC3200 contains the same networking subsystem along with internal MCU application processor. This document describes the networking subsystem power management aspects and therefore it is relevant for both devices.

CC3X00 Networking Subsystem Quick Overview
CC3X00 device is a wireless networking device for the deeply embedded market. It contains full network stack over 802.11bgn. It is a highly integrated solution both from the HW and SW standpoint, it includes internal PA and DC2DC circuits HW accelerators for SW offloading. SW wise, the device supports industry standard BSD socket API, internal SSL/TLS security protocols, very low footprint driver requirements and advanced low power modes.

Networking Subsystem Main Blocks


The CC3X00 networking subsystem can be divided to four main blocks:
 * Hibernate Logic
 * Device top level
 * WiFi Block
 * NWS Block

Networking Subsystem Power Modes
When referring to the networking subsystem power mode, the discussion is similar to CC3100 and C3200. However, in the CC3100 case, the power mode of the networking subsystem reflects the power mode of the entire device and in the CC3200 case the power mode of the entire device is dictated also by the power mode of the MCU. Power modes of MCU are out of the scope of this document.

In Active mode, NWP, WiFi can be in active or retention mode separately. If both in retention than system in Deep Sleep mode.

Modes Description

 * Hibernate / NWP Off – Networking subsystem is off. Requires cold boot (full init process).
 * Deep Sleep – NWP will be in Deep Sleep mode if WiFi IP and NWP IP are in their low power mode. Each IP manages its own sleep and wakeup events and when both in their low power mode than the entire networking subsystem is in Deep Sleep. Device maintains its state, fast clocks are off and power levels are lowered. Networking subsystem will be in deep sleep mode if both NWP IP and WiFi IP are in their low power mode.
 * Active - At least one IP (NWP / WiFi) is running. In the context here, this mode may represent a wide variety of intermediate power states which are of transient nature and not explicitly controlled by the system.

Mode Switching
There are only 3 modes that the networking subsystem may be in during normal operation, Active, Deep Sleep and Hibernate.
 * Transition to hibernate mode or NWP off mode: in 3100, hibernate mode entry or exit is dictated by the host application which will control the device using the nHIB pin. In 3200 it is the same except that the control is done by writing internal register.
 * - sl_Start API will take the device immediately out of hibernate mode.
 * - sl_Stop API will put the device in hibernate mode no later than the timeout parameter specified by the API.


 * Transitions between Deep Sleep and Active modes: in the context of networking subsystem, entry / exit of Deep Sleep mode is dictated by activity. There is no direct intervention of the host application. Both WiFi IP and NWP IP manage their activity according to their state (e.g connected to AP, connected to server, etc’). When one of the IP has no immediate activity (within a near specific threshold) it may go to lower power mode. When both IPs are in their lower power mode than the entire networking subsystem in the Deep Sleep mode. Neither the host application nor the SL driver does know whether the networking subsystem is in active mode or Deep Sleep mode. When host application wants to communicate with the networking subsystem (assuming networking subsystem is not in hibernate mode) it simply sends a command. If it is in Deep Sleep mode when the command is sent than networking subsystem will wakeup and handle the command thereafter.

The following diagram presents the possible transitions between states and the trigger for the transition.



Power Policies
It follows that from host application perspective there are only 2 modes of operation that are explicitly selected by the host, hibernate / NWP Off or device enabled / NWP On. Selection between Active or Deep Sleep states is managed internally by the device using power management algorithms. The device is equipped with a policy management entity which allows a developer (host application programmer) to guide the behavior of power management algorithm through pre defined power policies. sl_PolicySet API is used to configure the device power management policy. The available policies are:
 *  Normal (Default)  - Best tradeoff between traffic delivery time and power performance. When connected to AP WiFi module wakeups for every beacon reception. WiFi and NWP modules will enter their low power mode after considering current activities and predict future activities.
 *  Low Power  - Device power management algorithm is more opportunistic exploiting opportunities to lower it’s power mode. Tradeoff tends toward power conservation performance (For example tag application). Device will enter deep sleep immediately once activity is over without predicting future activities. Almost every communication between host and networking subsystem will take the overhead of waking up the device. However, it will not spend any time in idle mode predicting future events. WiFi module will receive every DTIM and not every beacon unlike in the normal policy.
 *  Long Sleep Interval  - This special low power mode comes with desired max sleep time parameter. The parameter reflects the desired sleep interval between two consecutive wakeups for beacon reception. WiFi module computes the desired time and wakes up to the next DTIM that does not exceed the specified time (See table below for examples). The maximum allowed desired max sleep time parameter is 2 seconds. It is important to note that this policy will only work in client mode. It automatically terminates mDNS and internal HTTP server that is running on the device. TCP/UDP servers initiated by the user application will lead to unpredictable system behavior and performance.
 *  Low latency  - Device power management algorithm subject to latency constrains. Therefore, tradeoff tends toward traffic delivery time limit to enable fast and guaranteed traffic (For example Video, Audio, HID). NWP and WiFi modules extend their activity prediction algorithm to minimize the overhead of system wakeup from low power modes. When connected to AP WiFi module wakeups for every beacon reception.
 *  Always On  - Both WiFi and NWP modules will remain active and will not enter their low power modes. WiFi will not enter 802.11 power save mode.

Application Use-cases Implementation
When approaching a design of a low power system using the CC3100 device one should consider the following aspects: By applying the above considerations to a specific usage model, in conjunction with the current consumption level at each mode, it is possible to determine the overall energy dissipation.
 * Traffic model - What is the payload to be transmitted or received and the frequency of this activity. For example, sensor which is expected to deliver 100B every few minutes or a video camera which is expected to stream average throughput of 4mbps
 * System latency - What is the expected latency time responding to incoming traffic. This parameter dictates the sleep policy of the networking device
 * Connection policy – Does the system need to be always connected or off line between communication events
 * Protocol properties – This includes the transport protocol (UDP/TCP) and the application protocol running on top of it
 * Type of connection – The security protocols at the link layer and the transport layer

CC3100 current consumption
The following table lists CC3100 current consumption at different key modes



Idle connected parameter refers to average current consumption of the CC3100 device while connected to AP and receiving a beacon every 102.4ms

Intermittently Connected Test Case
System has to transmit 100B and check messages on its server every few minutes. In this test case, the system is initiating the communication and does not have to be responsive at all times. Therefore it can initiate a new connection every cycle and does not have to keep connection. If cycle time is long enough, system will conserve more power if it switches to hibernate mode between transactions and re-connect again to AP and server every time rather than maintain the connection. In this test case, the total energy per activity cycle is a summation of the following activities:
 * E1 - Energy spent during system initialization
 * E2 - Energy spent during re-connecting to AP (802.11 association and authentication)
 * E3 - Energy spent while re-connecting to server (IP layer and transport layer protocols per application requirements)
 * E4 - Energy spent during application traffic
 * E5 - Energy spent by the CC3100 device between cycles while in hibernate mode

In this test case, the application will enable the CC3100 device, the device will automatically re-connect to the AP, the application will open and bind a socket, initiate traffic and disable the device. While the CC3100 device is enabled, it will manage its power state according to defined policy. For example, it may be at Deep Sleep state while waiting for server response or if host is delaying between commands. The total energy spent and system life span are given by:



Where:
 * E – Total energy per cycle [Joule]
 * B – Battery capacity [mAh]
 * C – Cycle time [min]
 * V – Voltage [Volts]
 * T – Device life span [days]



 Example: 
 * Energy
 * C – (Activity period) = 2min
 * Average current draw over singe activity period = 200uA
 * E = 200uA x 2min x 3.0V = 24mC x 3.0V = 0.072J
 * Battery - 2AA alkaline battery rated at 1.5V each connected in series with capacity of 2000mAh:
 * B = 2000mAh
 * V = 3.0V
 * T (device lifespan) = 3 x 2000 x 2 / 0.072 / 400 = 416Days

Always Connected Test Case
In this test case, the application requires that system maintain its connection. It must stay on line and response to notifications within certain latency (few hundreds of msec). The traffic itself is scarce and most of the time system is idle. For example, a server who is waiting for clients to connect or to waiting for client to send data. In this case the host will enable the CC3100 device once and initiate a connection to the AP. As long as there is no activity in the system, it will be in the lowest possible mode (using 802.11 power save protocol to handle low power at the link layer).

System will manage the following activities: The average energy consumed by the system is a summation of the following activities: The total energy spent and system life span is given by:
 * Wakeup for beacons to check if an incoming traffic exists at AP buffers
 * Upon indication of incoming traffic the system will exit low power mode, receive the traffic and transfer to host if necessary according to configured filters
 * Manage keep alive handshake in the AP to maintain connection
 * E1 – Energy spent during deep sleep mode (between beacons).
 * E2 – Energy spent for receiving a single beacon and connection maintenance
 * E3 – Energy spent during application traffic



Where:
 * B – Battery capacity [mAh]
 * V – Voltage [Volts]
 * P2 – Period cycle for connection maintenance activity [sec]
 * P3 – Period cycle for application traffic activity [sec]
 * W1 – Power consumed during sleep (Watt). For calculation simplicity assuming this power is consumed also during other activity times. Assuming other activities are shorts
 * E2 - Energy spent for receiving a single beacon and connection maintenance [Joule]
 * E3 - Energy spent during application traffic [Joule]



 Example: 
 * Energy
 * W1 = 85uA x 3.0V = 0.00015W
 * E2 = 23mA x 2msec x 3.0V = 0.138mJ
 * E3 = 0 (No application activity)
 * P2 = 0.1024sec
 * Battery - 2AA alkaline battery rated at 1.5V each connected in series with capacity of 2000mAh:
 * B = 2000mAh
 * V = 3.0V
 * T (device lifespan) = 3.6 x 2000 x 3.0 / (0.00015 + 0.000138/0.1024) =~ 14,400,000sec =~ 166Days

Errata

 * Math equations are a picture and not text.
 * Need to update current consumption picture