AGPS server questions

Sean Moss-Pultz sean_mosko at fic.com.tw
Sun Dec 3 16:13:08 CET 2006


Robert-

Sorry for the time it took me to get back to you on this one. Hopefully you
still remember your original question:

" Sean I just want you to ask your AGPS experts - when you have to ask
externaly e.g. open local - you could wait a day for me doing a bit more
research:
"Would be a RTCM 2.3 Typ 17 stream enough for AGPS?"
"Would the binary from gobal locate allows to define an own routings to
a server?"
"Would it be possible to run an own server (runnnig open software)?"

Here is your answer from a senior engineer at Global Locate:

---

There is an "open" GPS
hw/fw solution out there, but it is open only because the fw side of it
went belly-up and the hw side decided to keep the silicon in their
catalog.  But there's few PhDs in signal processing or navigation to
support it.  PhDs have less time on their hands than GUI developers,
evidently.

About the questions:

What is the context?  AGPS protocol stack support on a handheld, or
The AGPS server on the network side?

I'll assume he's discussing the handset side.

First some background.

MS-A AGPS
    server sends minimum ephemeris to handset (age is about 2 hours
or less)
    handset replies with measurements;
    server computes (and "owns") the position
    Data rates are moderate, but the same for each position

MS-B AGPS
    server sends ephemeris for local conditions (age is about 2
hours)
    handset computes (and "owns") the position
    data rates are about the same, but can be smaller for subsequent
fixes.

LTO
    LTO gets to handset via:
        - GPRS
        - WiFi
        - Bluetooth
        - USB
    Only about 40KB needed every 2 days, although we prefer every 6
hours for safety
    if it is cheap enough.

The AGPS features currently only expect a NAL (network abstraction
layer) to reach the AGPS servers.
For the LTO, same thing.
Right now, our only NAL is for TCP/IP, as User-plane (SUPL) for OMA
support is easiest.
In future, C-Plane may be offered by some GSM BBs and we can use that if
the network supports it.

"Would be a RTCM 2.3 Typ 17 stream enough for AGPS?"
    If it has a TCP/IP portal on the network side to reach LTO or
AGPS servers, and
    would need a NAL on the handset side to connect to the GPS
control stack.

"Would the binary from gobal locate allows to define an own routings to
a server?"
    Right now the NAL is built in and assumes TCP/IP.
    If you configured the AGPS NAL for a local proxy, then rerouted
to
    whatever you choose, you're all set.

"Would it be possible to run an own server (runnning open software)?"
    You would need to:
    - develop a SUPL protocol stack
    - get an assistance data feed.  Network operators pay big $$$
for this from
      commercial providers.  Developing your own is a major task.
    - get authority from cell providers and network operators for
AGPS to go through them
      (Note the "own" position fix for MS-A above: you could get
between an operator
       and $$, a dangerous place to be!)
    - develop a database of {cell-tower ==> lat,long,alt}
    So it is a pretty big job with some major hurdles.

---

Hope that helps!

-Sean





More information about the community mailing list