Energy Efficient GPS Sensing
CO-GPS: Energy Efficient GPS Sensing with Cloud Offloading
[pdf-embedder url=”http://wellapets.com/wp-content/uploads/2019/06/CO-GPS-Energy-Efficient-GPS-Sensing-with.pdf” title=”CO-GPS Energy Efficient GPS Sensing with”]
Abstract—Location is a fundamental service for mobile computing. Typical GPS receivers, although widely available for navigation
purposes, may consume too much energy to be useful for many applications. Observing that in many sensing scenarios, the location
information can be post-processed when the data is uploaded to a server, we design a Cloud-Offloaded GPS (CO-GPS) solution
that allows a sensing device to aggressively duty-cycle its GPS receiver and log just enough raw GPS signal for post-processing.
Leveraging publicly available information such as GNSS satellite ephemeris and an Earth elevation database, a cloud service can
derive good quality GPS locations from a few milliseconds of raw data. Using our design of a portable sensing device platform called
CLEON, we evaluate the accuracy and efficiency of the solution. Compared to more than 30 seconds of heavy signal processing on
standalone GPS receivers, we can achieve three orders of magnitude lower energy consumption per location tagging.
Index Terms—Location, Assisted GPS, Cloud-offloading, Coarse-time Navigation
Localization is a fundamental service in mobility. In
outdoor applications such as wildlife tracking , ,
participatory environmental sensing , and personal
health and wellness applications, GPS is the most common
location sensor. GPS receiving, although becoming
increasingly ubiquitous and lower in cost, is processingintensive
Take ZebraNet sensor nodes  as an example. On
average, one GPS location fix requires turning on the
GPS chip for more than 25 seconds at 462mW power
consumption, which dominates its energy budget. As a
result, the unit is equipped with a 540-gram solar cell
array and a 287-gram 2A-h lithium-ion battery in order
to support one GPS position reading every 3 minutes.
Power generation and storage accounts for over 70% of
the sensor unit’s total weight of 1151 grams. Similarly, in
wearable consumer devices such as fitness trackers, high
energy consumption from GPS receivers mean bulkier
devices and low battery life.
As we will elaborate in section 2, there are two main
reasons behind the high energy consumption of GPS
receivers: 1) the time and satellite trajectory information
(called Ephemeris) are sent from the satellites at a data rate as low as 50bps. A standalone GPS receiver has to
be turned on for up to 30 seconds to receive the full
data packets from satellites for computing its location.
Even in assisted GPS, where ephemeris is sent to device
through a separate channel, a receiver needs to run for
about 6 seconds to decode time stamps. 2) The amount of
signal processing required to acquire and track satellites
is substantial due to weak signal strengths and unknown
Doppler frequency shifts. For example, in state-of-the-art
GPS receivers such as u-Blox Max-7, the acquisition state
consumes 60mW and can take on average 5 seconds to
yield the first location fix. In order to save the energy
spent on acquiring the satellites, some GPS receivers
have a low power tracking mode to keep track of the
satellite information. In case of Max-7, the low power
tracking mode consumes more than 12mW continuously.
3) The satellites move at high speed. When a GPS chip
is turned off completely for more than a few minutes,
the previous code phases and Doppler information are
no longer useful, and the device must spend substantial
energy to re-acquire the satellites. 4) Post-processing and
least-square calculation require a powerful CPU.
In this paper, we address the problem of energy consumption
in GPS receiving by splitting the GPS location
sensing into a device part and a cloud part. We take
advantage of several key observations.
Many mobile sensing applications are delaytolerant.
Instead of determining the location at the
time that each data sample is collected, we can compute
the locations off-line after the data is uploaded
to a server. This is quite different from the turn-byturn
navigation scenario that most standalone GPS
devices are designed for. The benefit is even more significant if the data uploading energy is amortized
over many data samples.
Much of the information necessary to compute the
location of a GPS receiver is available on line. For example,
NASA publishes satellite ephemeris through
its web services, so the device does not have to stay
on long enough to decode them locally from satellite
signals. The only information that the device must
provide is a rough notion of time, the set of visible
satellites, and the “code phase” information from
each visible satellite, as we explain in section 2.
Code phases can be derived from any millisecond
of satellite signal. If we can derive location without
decoding any data from the satellites, there is
significant opportunity to duty-cycle the receiver.
In comparison to the constraints on processing
power and energy consumption, storage is relatively
cheap to put on sensor devices, so we can liberally
store raw GPS intermediate frequency (IF) signals
together with sensor data. For example, at an IF of
4MHz, sampling a one-millisecond signal at 2-bit
resolution and 16MHz rate results in 4KB raw data.
Due to the split between local and cloud processing,
the device only needs to run for a few milliseconds at a
time to collect enough GPS IF signals and tag them with
a rough time stamp. A cloud service can then process the
signals off-line, leveraging its much greater processing
power, online ephemeris, and geographical information
to disambiguate the signals and to determine the location
of the receiver. We call this approach Cloud-Offloaded GPS
The CO-GPS idea is built on top of a GPS receiving
approach called Coarse-Time Navigation (CTN) .
While CTN is used for quickly estimating the first location
lock (measured as Time To First Fix, or TTFF),
we are the first to articulate and quantify its energy
saving benefits. Furthermore, we find ways to relax the
condition on knowing a reference location that is close to
the true location, and maintaining a real-time clock that
is synchronized to the satellite clock. As a result, COGPS
receivers can have an extremely short duty cycle
for long-running tracking applications.
This paper extends  by investigating ways to remove
satellite detection outliers, which are more likely to
be false positives due to weak signal strength and short
signal length. As a result, through our empirical evaluation
over 1500 real GPS traces, median location error
drops from 30m to 12m, and more than 85% of samples
have less than 30m error. Furthermore, we removed
the dependency on relatively energy-consuming WWVBbased
time synchronization, and leverage time stamps
resolved from GPS signals themselves to progressively
time stamp samples in data traces. A node only needs
to be time synchronized once at the beginning of its
We built a sensor node, called CLEON, based on
the CO-GPS principle using a GPS receiving front end
chip MAX2769 and a MSP430 microcontroller. We also
built and deployed CO-GPS location resolution web service
on Windows Azure. Through performance measurements,
we show that it takes as little as 0.4mJ to collect
enough data to compute a GPS location, in comparison
to the order of 1J for GPS sensing on mobile phones
or 300mJ for u-blox Max-7 GPS module In other words,
with a pair of AA batteries (2Ah), CLEON can theoretically
sustain continuous GPS logging (at 1s/sample
granularity) for 1.5 years.
To make this paper self-contained, the rest of the paper
is organized as follows. In section 2, we first give an
overview of how a typical GPS receiver processes satellite
signals, in order to motivate our solution. Section 3
describes the principle of CO-GPS. In section 4, we discuss
the implementation of the cloud side services. We
evaluate the performance of CO-GPS and its parameters
using real GPS traces in section 5. Finally, section 6
presents the design of the CLEON sensor node and
evaluates its energy consumption in GPS receiving.