Another GPS post from a GL engineer

[Sean Moss-Pultz]

Guys,

Here are more comments to recent GPS related posts on this list. Hope you'll
find some answers here.

------------------------------------------------------

On Thu, Jan 25, 2007 at 02:38:20PM +0100, Michele Manzato wrote:
> Some additional questions on this subject:
> 
> 1. Is there any "A-GPS standard" whatsoever?

no. It's a broad term for many variants of GPS

THE SUPL (Secure User Plane) standard is promulgated by OMA, and being
investigated worldwide.
The carriers love 'em and hate 'em:
    LOVE: not a big need to add N.E.  (low $$)
    HATE: the carriers don't own the position fix (loss of $$)
The handset communicates using the OMA SUPL standard using objects
encoded in ASN.1 to a SUPL server anywhere on the net (that the carrier
allows access to).  (On the other side of the SUPL server is a reliable
feed of ephemeris from GPS receivers all over the world.  This is part
of Global Locate's WWRN business, and is distinct from the LTO and the
chip business.  The WWRN biz is standards based and quite competitive.)

Impressive performance results from AGPS when properly deployed.  There
are some absolutely kick-ass AGPS handsets in Japan:  full VGA, and with
Java's JSR179: many, many applications right away.

The eventual goal is C-Plane, where the assistance data is via the
telephony control plane.
Kinda the opposite of SUPL, so much more intensive protocol efforts.
But by far the fastest way to get a position fix, and most reliable for
E911.

> 2. I have heard elsewhere (Wikipedia) that in A-GPS the computation
> effort is shared between the device and the A-GPS Server. According to

> a previous post, the device just downloads the ephemeris table so
> there isn't any actual "computation sharing", but rather a download of

> a pre-computed table download. Correct?


THERE are four basic sorts of GPS:

    Autonomous - the standard hand-held device that gets a fix in 1
to 3 minutes outdoors, or never indoors.

    Enhanced Autonomous "etonomous" - maybe this is what you heard
about.  Global Locate predicts the satellite orbits for 2, 4, 7, or 10
days in advance, and you download that.  AKA "Long Term Orbit" or LTO.
Marketed as "Quick GPS Connection" by HP, and "Express GPS Connect" by
Global Locate.  The advantage is you can get a 40 kB burst in seconds
vs. 50 bits per second (or 0 bps if you're indoors) from the sky.  You
can cache and forward this file at your heart's content.  Consumers
don't pay for it:  the device maker pays a little bit extra per chipset
for this data.

    MS-Based - The handset tells the SUPL/C-Plane server it's MSISDN
and cell tower info.  The server responds with exactly the specific SVs
that are visible right now, and the ephemeris for them.  The MS
(handset/mobile station/fill in your telephony GCA here...) computes the
position for use on the handset.  It can also send the information back
to the server.  The ephemeris is good for (on average) about 2 hours.

    MS-Assisted - The server tells the MS what measurements to make.
The device responds with the measurements.  The server computes (and
"owns") the position.  No ephemeris at all.

This is a rather simple explanation, as the call flows are a little more
involved.

> 3. A-GPS involves additional data traffic and thus (potential)
> additional costs. Does it use a normal GSM/GPRS IP-based data
> transfer? does it use some out-of-band GSM/GPRS control messages? or
> does it get data from broadcasts in the local cell (e.g. GSM
> cell-broadcast)?

C-PLANE is in the future, and not a part of Neo1973.  OpenMoko AGPS will
be configured by the user to connect to whatever SUPL or LTO server(s)
you prefer.  However, location information is very, very sensitive, so
Sean and I have talked a lot about how to preserve QoS and security
between competing GPS applications.

Here's an example problem about security that touches on security, QoS,
and other system issues:

1)  Secure application needs position for reporting to a
vertical-integrated application, with 50m accuracy.  Needs it NOW, and
so the LTO/MS-B scheme is desired.

2)  Pedestrian application wants to do geo-blogging and needs to
preserve battery power, and 100m accuracy is more than sufficient
because we don't want to burn a lot of power.  Etonomous or autonomous
is fine.

3)  Malicious app wants to deny service, so it starts the AGPS daemon
with a connection to the wrong SUPL server, and asks for 5m accuracy
periodic position fix.  So app (1) can't get access to the AGPS
connected to it's server.

I would hope the OpenMoko community creates a network connectivity QoS
agent that can trade off the cost vs performance vs power vs environment
of the Neo1973 to make intelligent decisions based on these factors:
 - GPRS $$$$, WiFi $$, BT $,   USB to a PC $0?
 - Power/Environment - GPRS most?  Plugged into the wall/carkit - Burn,
baby, burn!
 - User perferences about importance - high for MS-A, low for LTO?, but
during E911, telephony regulations set the rules, not OpenMoko.

Microsoft has something called the "Connection Manager" that deals with
similar issues on Windows CE PocketPC.

> 4. if the answer to above is GPRS: is it possible to estimate in
> advance how much additional traffic (in Kbytes/day of full operation)?

2 days LTO is about 23 KB
7 days LTO is about 59 KB.

> 5. Are there any known estimations on the overall (A)GPS performance
> on the Neo (esp. fix time)

SORRY, this is a Sean question.  I can tell you it is really amazing.

> 6. Coming to the Neo1973. In order to save costs, can the "Assisted"
> function in A-GPS be disabled through software API?

THE LTO fetching is the chance for some creative use of web-page
caching, store & forward, etc.
All sorts of scenarios are possible.  The most "hands free" are one of
these schemes:

6.1 Whenever the Neo1973 detects a really low cost data connection (USB
sync to a PC, WiFi, etc), just get the latest LTO.
6.2 Have a cron job on your PC get LTO every 6 hours, then push it (or
pull it) whenever your Neo1973 is connected to the PC.  I saw some sync
discussions in the community...
6.3 Variant on 6.1:  don't *open* an expensive GPRS connection, but if
one is already started, then piggyback on it.
6.4 .....

Of course, I've only discussed the Etonomous variant of AGPS.

The MS-B and MS-A configurations have more complexity due to call flows
and cost.

> 7. Is it possible to tell whether A-GPS is actually in use or not?

<rant>
SEAN and I discussed some really fun things the GPS icon could show:
- the "age" of your LTO
- if the GPS is is running now, and if so, does it have a fix or not.
- etc.
The way we left it, there was plenty of chances for the OpenMokoids to
get GPS-related info and map it into the GPS icon in non-linear ways.
My personal favorites are:
- make a portion of the GPS icon (e.g. the "solar panels") blink green
for 0.5 seconds when there is a position fix, or purple if it is trying,
but doesn't have anything yet.
- Add solar panels to the GPS satellite icon if the signal strength is
better
- Change the GPS satellite body color if the LTO is getting "stale"
- Or just superimpose those boring cell-phone indicators we're all used
to.  Sigh.
</rant>

... So of course you could add the AGPS server info here.  But Harald is
right, this is a (boring compared to the fun stuff above) config item.

If you have SUPL that you're paying for with some sort of operator plan,
for the QoS and security reasons, you'll want some security on which
SUPL server is selected.

> 8. Is it possible to tell/know which is the A-GPS server currently in
> use?

yes.

------