Putting the (ultra-low) Power in GeoFence

Host-Offload GNSS Positioning

By Miguel Torroja, Steve Malkos, and Christophe Verne

Users of smartphones, tablets, and other devices expect position with the highest level of accuracy, always available, with the least amount of power consumed. One recent improvement fulfilling this demand involves operating-system services for location on smartphones, and the evolution towards lower power solutions.

“Please connect to a charger — The battery is getting low: less than 15 percent remaining.”

Handsets are battery-supplied devices, and a user’s tolerance for features is driven by battery consumption. There are many examples of technologies where users do not run certain hardware or features because it will consume the battery and make the phone useless within a short period of time.

The application processor (AP) of a handset device is very powerful, and is the part that consumes most of the battery life. Today’s smartphone multicore application processor is faster than many desktop computers that are just a few years old. Whatever the application, when it uses the AP, it can draw up to hundreds of milliamperes (mAs).

For the last few years, the trend for GNSS has been host-based positioning. Host-based designs have less logic on the GNSS integrated circuit (IC) and employ the host AP for a portion of the positioning computation. This strategy has three advantages:

• Shares memory and code resources with the application processor.
• Reduces the cost of the dedicated GNSS hardware.
• Sharing the processor makes sense since it is already running.

Traditionally, when the GNSS solution was running, a navigation application that utilized the AP was also running.

However, when we only want to compute GNSS positions in the background, and we do not need a third-party application running on the AP, a host-based IC architecture is not the optimal solution with regard to system power consumption. This article explains some of the technologies used to compute a GNSS position using an ultra-low power (ULP) hybrid solution that combines the classic host-based GNSS architecture with a host-offload architecture that minimizes the use of the AP.

We discuss here two applications that benefit from a host-offload architecture: geofencing and position batching.

We will review the requirements for a platform to support a new hybrid GNSS positioning solution. Different host-offload technologies for geofence, such as GNSS, Wi-Fi, and Cell-ID, will be compared. Broadcom’s ultralow-power host-offload GNSS solution supports any operating system. We focus here on Android’s operating system because it is the most open OS.

Always-on Applications

Geofencing is an application that sends reports or triggers alarms when a predefined area is crossed. For example, users can be alerted to discounts with e-coupons when walking through a mall, or to “don’t forget the milk” — users can set their own reminder notifications based off of location; also, social networking. One example of location-based reminders is through Google Keep, which uses Android’s Geofence APIs on platforms that support hardware geofencing; this application will automatically take advantage of the hardware geofence solution.

Geofencing applications run in the background for long periods of time, and their main task is to compute positions (fixes) without the need of assistance from other applications. An ultra-low-power GNSS position solution, or always-on positioning solution, is desirable for these scenarios. Typical applications require notifications when entering or exiting a geofence area, or require periodic reporting of user positions relative to the fence.

Geofencing is not something new. API support has been provided in mobile OS for many years, but only now can it be used without draining the battery, thanks to this new host-offload architecture.

Figure 1 shows a circular geofence boundary and an alarm. In that example, the alarm was triggered when entering the fence.

Figure 1. Alarm when the vehicle enters a geofence area.

Breadcrumbing or position batching pertains to storing of positions, referred to as crumbs, which are accumulated for a certain amount of time and then pushed all at once to the application. Examples would be fleet or asset tracking applications, or people that wants to track their position while they are running.

Currently, Android does not support breadcrumbing as a native feature. There is some ongoing work, and APIs are being defined.

GNSS Positioning Models

Before smartphones, the dominant GNSS hardware architecture employed a system-on-chip solution. The position/velocity/time (PVT) comes directly from the hardware, and all the computations are done in the GNSS IC.

On-Chip Positioning requires two things: a powerful-enough central processing unit (CPU) and lots of memory. The increase in CPU and memory performance are not free; they translate directly into more power and higher manufacturing costs.

The RF block in Figure 2 is intentionally drawn with a similar size to the CPU and memory, to emphasize the need for higher resources for a complete on-chip solution.

Figure 2. On-chip solution.

Host-Based Solution. GNSS positioning requires dedicated hardware, complex software, and protocols. This complexity led GNSS providers to move parts of the software out of the IC to the AP.

Using a mobile phone’s AP for position computation is one method of reducing the CPU and memory power footprint from the GNSS IC. At the same time, it also increases the power consumed by the platform needed to compute GNSS position, since part of the computation is not performed on the host-based IC. APs may consume approximately 100 mA just to be operational.

Figure 3 shows a typical configuration with dedicated GNSS hardware and a generic AP. In host-based mode, both the AP and the GNSS IC run in parallel when computing positions. The AP controls the GNSS hardware.

Figure 3. I/O connections in on-host positioning.

With this type of shared architecture, shown in Figure 4, the CPU and the memory on the GNSS IC are reduced, shrinking the size of the chip and reducing power consumed by the chip. In Figure 4 we see that the AP is communicating with the dedicated hardware, and the final PVT is computed by the AP. This solution fits well in many applications, such as navigation, where the AP has to run a mapping application at the same time.

Figure 4. Host-based solution.

Hybrid Positioning. For geofencing, we need a hybrid model, one which keeps GNSS IC complexity similar to the host-based architecture, but also offloads some of the host-based positioning so that the host can go to sleep.

In Broadcom’s hybrid mode, the AP does not need to run when GNSS positions are computed. Broadcom’s hybrid IC does not invoke the host AP often, and thus achieves an even lower power footprint. The CPU on the GNSS IC used for computing position is a dedicated one. It needs to be carefully chosen because it has to be powerful enough to compute positions and be as power efficient as possible. All this is done while keeping the GNSS IC area size in mind, to control cost.

Detailed analysis and steps were considered to ascertain the minimum requirements for the CPU and other resources to best accomplish the on-chip positioning task.

Other considerations: the GNSS IC must be powered even when the AP is suspended, and the GNSS IC must be capable of waking up the AP. Figure 5 shows a possible implementation using a dedicated I/O signal controlled by the IC to wake up the host AP.

Figure 5. I/O connections in hybrid positioning.

With this architecture, the host AP will still be needed to provide some assistance data to the GNSS IC. The assistance provided allows the GNSS IC to not invoke the host AP often and thus achieve an even lower power footprint.

Geofencing Methods

Certain OS application APIs have been supporting geofencing for many years. Currently, we can find geofencing APIs in most of the mobile OSs in the market.

There are four main types of geofencing: GNSS software geofencing, GNSS hardware geofencing, network software geofencing, and network hardware geofencing (Table 1).

Table 1. Geofencing methods.

GNSS Hardware Geofencing. In this method, the one described in detail in this article, the OS initiates a request and offloads the areas of interest to the hardware. After that, the AP can go to sleep and the hardware is responsible for computing positions and checking the areas of interest. This method basically relies on GNSS hardware to compute positions and check the programmed fences.

GNSS Software Geofencing. Here, the OS initiates regular fixes to a host-based GNSS IC design. Then it invokes both the AP and the GNSS IC at the same time to check against the defined fence areas.

Network Geofencing. In this method, the OS requests network IDs from the hardware (that is, baseband modem Cell-ID and Wi-Fi access points). The OS uses different positioning technologies to compute position. This usually requires a connection to a server to retrieve location information about the different IDs. The position is used to check the geofences.

In network hardware geofencing, a set of network IDs is offloaded from the OS to the network hardware ICs. The hardware can poll for these IDs, and wake up the host when found.

Network versus GNSS Geofencing

A good geofencing solution combines both network and GNSS methods because each solution benefits from each other.

GNSS positioning solutions compute positions in open-sky environments with accuracy to a few meters and have worldwide coverage. However, they cannot work in deep indoor spaces.

Network geofencing using cell IDs is quite inaccurate, but works very well indoors. Network geofencing using a Wi-Fi access point provides reasonable accuracy, but location of the access points is not always known and it does not have full coverage.

Geofencing in Android 4.3. The API for applications supports geofencing. Starting from the first version of Android, the application just initiates a proximity alarm and will get an event when its boundaries are crossed. The OS is responsible for notifying the application when such an event occurs, and can use any technologies it sees fit.

The API that applications use is very simple. The monitoring is handled by the OS and is hidden to the application (for example, technologies, periodicity of checks, and accuracies).

Software Geofence in Android. Software geofencing has been the default method until recently, as there was no native hardware support. In this mode, the host-based GNSS positioning engine is started like any other position request. The Android framework is the one dealing with the monitoring of the geofences, and therefore, the AP must run continuously to handle periodic position checks. That means the software-geofencing logic is mainly in the framework layer of Android (see basic layers diagram shown in Figure 6).

Figure 6. Android framework.

More recent versions of Android dropped the support for software-based geofencing in favor of a host-based GNSS system, likely because of the big impact on the battery. Broadcom developed a low-power GNSS hardware solution for geofencing.

Hardware Geofence in Android. Starting from Android 4.3, a new interface is available to use hardware geofencing. This interface is not visible to the application, and it is only used as a low-level interface. To support the new hardware-geofence interface, the native driver only has to register to a new GNSS interface defined in the native hardware abstraction layer (HAL) of Android.

There are other protocols known to support geofencing. Table 2 provides a short list.

Table 2. Geofencing support on different platforms.

Broadcom Hybrid Positioning

Android defines interfaces to the hardware, referred to as the HAL.

GNSS Host Software. GNSS providers need to comply to the HAL interface, which is at the Java native interface (JNI) level. Below the JNI lies the GNSS host software (Figure 7).

Figure 7. Android detailed framework/native layers.

For the host-based solution, the GNSS host software handles most of the heavy computing.

For the hybrid solution, the GNSS host software does some of the heavy computing, but positions are computed inside the GNSS IC.

To support this new hybrid solution, two main changes are required compared to the usual host-based solution, as described below.

First, the hybrid GNSS IC must be autonomous while the host AP is sleeping. This implies that some power domains are maintained when the GNSS is in use. This typically means at least one of the outputs of the power management unit (PMU) should be dedicated to the GNSS only (Figure 8).

Figure 8. Power domains.

Second, the GNSS IC must be able to wake up the host AP so as to send geofence notifications, or to request assistance data. This is usually done through a dedicated pin.

Acquisition and Sleep Period. Most of the power in the GNSS IC is used by the radio and analog part. To reduce power, this part is switched on only during acquisition. As soon as enough measurements are observed, the radio part is switched off while the digital part computes a fix.

After each computed position, the GNSS IC can go into a deep power-saving mode until the next acquisition. The distance to the closest fence in conjunction with the user speed is used to determine when to compute the next position (Figure 9):

Figure 9. Start fix decision logic.

Once the GNSS IC starts computing positions, the AP can go into sleep mode (Figure 10). Total power per position computed is reduced, and the time between fixes is no longer constant, as shown in Figure 11.

Figure 10. Sleep time between fixes.

Figure 11. Duty cycling.

In Figure 12, the lower square-shaped pattern corresponds to a position computation from the hardware GNSS IC. Once we have an alarm, the host has to be woken up and we can see the impact in power in the big peaks after a position is computed.

Figure 12. Power graph.

Alarm Triggering

When a geofence area is crossed, the GNSS IC needs to wake up the AP. This is achieved using a dedicated interrupt pin. After asserting it, an alarm and geofence status is sent to the AP.

Power Consumption. We calculate the total average current by splitting it into three components, as shown in the following formula:

Some of these parameters are set by the host: for example, how often the fix should be computed. The extra current drained by the GNSS IC is the one defined by

∆I is the change in current drain when computing positions.

We can also express this formula based on the average number of position attempts:

where T_p is the average time between fixes (the time the GNSS IC stays in sleep).

Table 3 illustrates some theoretical ∆I current savings with respect to T_p.

Conclusion

As APs become faster and faster, their power consumption goes up. A novel hybrid GNSS receiver has been presented, which offloads some of the host-based processing into the GNSS hardware, offering ultra-low system power consumption versus the traditional methods. The new hybrid positioning solution is a good approach for always-on applications that need to have location information always available, without requiring the host to be running, as is the case with geofencing and breadcrumbing.

References

We would like to thank Jason Goldberg, Frank van Diggelen, and Manuel del Castillo, all of Broadcom, who reviewed this article and spent many hours with us discussing the topics point by point.

Miguel Torroja is a principal software developer at Broadcom. He has an M.Sc. in electrical  engineering from Ramon Llull University, Barcelona. Since 2011, he has been working on the design and development of algorithms for optimizing power consumption in GNSS host-offload solutions.

Steve Malkos is a senior program manager at Broadcom.  He has a B.S. in computer science from Purdue University.  He has been active in the development of A-GNSS technologies such as hybrid location services, long-term predicted orbits (LTO), Broadcom’s worldwide reference network (WWRN), and secure user-plane location (SUPL). He has five patents issued and 16 pending.

Christophe Verne is a manager of software engineering at Broadcom. He has an M.S. in electrical engineering from Ecole Centrale, Paris. He has been involved in the development of GNSS and A-GNSS technologies at EADS, Sagem, Global Locate, and Broadcom, where he has been working on low-power host-offload positioning.