Doing mobile app development? Need to optimize? One way to conserve battery is by piggybacking networking transmissions.
To preserve battery life, the cellular radio in mobile devices gets put into a lower powered state after some inactivity, and then gets turned off after an additional period of inactivity. Once the radio is off, it takes some time for the radio to be turned on and for the radio to negotiate a new connection with a nearby cell tower.
Cellular vs. WiFi
WiFi works very differently from cellular with regards to setup and battery consumption. This article primarily addresses the challenges of working with the cellular radio. When both WiFi and cellular coverage options are available, it is preferable to use WiFi connectivity.
Cellular radios have 3 states:
High (DCH) state: high data throughput, high radio energy (battery consumption)
Off (IDLE) state: no radio (turned off), no radio energy
Intermediate (FACH) state: an in-between state (low data throughput, low radio energy)
For the purposes of this article, we define two types of network traffic: Primary and Secondary.
Primary - network traffic related to the core functionality of the app, and with the following characteristics:
- Typically needed on demand (for example, user taps 'Search' button within app)
- Might be scheduled at predefined interval (for example, delivery of new line-of-business transactions)
- Business needs for rapid delivery outweighs the battery life cost
Secondary - network traffic that's not part of core functionality of app.
Typically not time critical, but somewhat time sensitive (within an acceptable timeframe). Examples are: analytics, logging, debugging, operations/support metrics.
Simplistic Approach to Secondary Traffic
A simple and common approach is to force transmission of secondary traffic at fixed intervals (every x seconds). This approach is easy to implement, easy to understand, and provides secondary traffic at consistent and predictable intervals. However, depending on the nature of the primary traffic patterns, this will result in unnecessary drain on the device battery.
Secondary Traffic Transmissions Can Often Be Optimized
Due to the nature of secondry traffic, the business requirements around it are more relaxed than they are for primary traffic, thereby giving more options in how it might be handled. As long as these transmissions occur within acceptable delivery timeframes, it may be permissible to make adjustments to the delivery of these transmissions. In other words, there is less of a need to force transmissions at arbitrary intervals. If the secondary transmissions can be piggybacked on primary traffic transmissions, the delay and battery drain of turning on radio and re-establishing a new connection with the cell tower can be avoided.
Secondary traffic can be piggybacked on primary traffic in order to minimize the possibility of establishing new cellular connections (and forcing the radio on from an off state). When the cellular radio is already in high state, the battery cost and cell tower connection setup can be amortized over both transmission types. In order to piggyback the transaction properly, these transmissions need to be coordinated. This is sometimes difficult to do if the different network traffic types are handled by different parts of the application (perhaps due to separation of concerns).
It is helpful to funnel primary traffic transmissions through a common interface so that the occurrence of these transmissions can be identified (and made use of for piggybacking of secondary traffic). The key point here is that the secondary traffic should be sent where there has been 'recent' transmission of primary traffic.
But what's 'recent', and how recent?
First, it's helpful to keep in mind the behavior of the device's radio and how it transitions between high to intermediate, and intermediate to low (off) states.
The high state of the radio will automatically step down to the intermediate state after some period of network inactivity (typically, 5 seconds). Similarly, the intermediate state will automatically step down to the off state after another period of network inactivity (typically, 12 seconds).
The important point here is that the secondary traffic transmission should occur when the radio is still in the high (full power) state. However, it's not necessarily best to piggyback on each primary traffic transmission, even if it meets our bounded transmission requirements. There may be some applications where a series of primary network traffic transmissions are all needed for the application's 'unit of work'.
For such applications, it would be best hold off on secondary traffic transmissions until the primary traffic 'unit of work' transmissions are complete. To accommodate this concern, it's probably best to wait several seconds (maybe around 4) of inactivity so that it:
- doesn't interfere with other 'unit of work' primary network transmissions, and
- can still able to 'ride the coattails' of the radio being in high state (due to very recent primary network traffic transmission).
Even if one adopts the strategy of piggybacking the secondary network transmissions on the primary network transmissions, there are additional considerations.
Even if the primary network traffic is happening with high frequency, one wouldn't necessarily want to transmit the secondary traffic with that same high frequency. This might be important to avoid putting excessive load on the server that is handling the secondary traffic.
Conversely, there may be cases where the frequency of the primary traffic is too low and the secondary traffic is needed more frequently (most likely just to provide more timely and useful data).
In light of these frequency considerations, it is helpful to have the following parameters to keep some bounds (minimum and maximum) on the secondary traffic transmissions:
Min. Inter-Transmission Time: don't flood with rapid, 'chatty' transmissions.
Max. Inter-Transmission Time: don't wait so long that the timeliness/usefulness of the data degrades.
Min. Inter-Transmission Time
Even if primary traffic transmissions are happening more frequently than this value, restrict the secondary transmissions so that they don't occur more often than this. This can be important to prevent overloading servers that are servicing secondary traffic for a large number of devices.
Max. Inter-Transmission Time
Even if primary traffic transmissions are happening less frequently than this value, force a transmission to ensure that secondary traffic doesn't become overly stale or outdated.
Putting it all to work in the Apigee Mobile Analytics SDK
The current implementation of the Apigee Mobile Analytics SDK (Android and iOS) follows a simplistic timed interval (60 sec. by default) for upload of secondary traffic. This guarantees that the radio will be in the high state (turned on if it was off) at least once per minute. We will be revving our SDK to build in a bounded, piggybacked strategy for secondary traffic. Check back in - we’ll discuss this change to our SDK in some detail in an upcoming blog post.
Want to read more about building optimized user-friendly apps? Check out this excellent whitepaper By Bill Weir and Doug Sillars of the AT&T Developer Support Team: Top Radio Resource Issues in Mobile Application Development