AGPS server questions

[Jeff Andros]

On 12/3/06, Sean Moss-Pultz <sean_mosko at fic.com.tw> wrote:
>
> 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
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
>
pardon my ignorance, but can someone explain what LTO is? a quick google
didn't help


-- 
--Jeff
What DO you call whitewater when you live in the desert?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20061203/6bc67d0e/attachment.htm