I think the issue here is the Google Location Services, AKA "Network" location, relies heavily on Wi-Fi networks to determine location.
Getting a location from the cellular network can be flaky, especially depending on where you are. If you are in the downtown area of a city, there are lots of cell towers around, so triangulation can better determine your location than if you're in a less dense area.
It's not really explicitly stated in the documentation, but it looks like using PRIORITY_BALANCED_POWER_ACCURACY
probably uses "passive" use of the GPS radio, meaning that it will only give you data from the GPS radio if another app requested a location callback, so you basically piggy-back onto that request, and your app doesn't get blamed for any battery drain even though you get the location data.
The documentation states:
In between these two extremes is a very common use-case, where
applications definitely want to receive updates at a specified
interval, and can receive them faster when available, but still want a
low power impact. These applications should consider
PRIORITY_BALANCED_POWER_ACCURACY combined with a faster
setFastestInterval(long) (such as 1 minute) and a slower
setInterval(long) (such as 60 minutes). They will only be assigned
power blame for the interval set by setInterval(long), but can still
receive locations triggered by other applications at a rate up to
setFastestInterval(long). This style of request is appropriate for
many location aware applications, including background usage. Do be
careful to also throttle setFastestInterval(long) if you perform
heavy-weight work after receiving an update - such as using the
network.
See here: http://developer.android.com/reference/com/google/android/gms/location/LocationRequest.html#setFastestInterval(long)
See this post as well: PRIORITY_LOW_POWER vs PRIORITY_BALANCED_POWER_ACCURACY for google play service v2