[Neo1973] AGPS - globallocal cuckoo's egg? Re: AGPS server questions

Robert Michel openmoko at robertmichel.de
Wed Dec 13 13:57:42 CET 2006


Salve Harald, Sean!

I fear AGPS from globallocal is a coockoo's egg - they anounced that
their AGPS chips cost only 5 US$ - I fear they will make money with
their AGPS server services
http://www.globallocate.com/NETWORK/NET_AGPS_SERVER_Frameset.htm
Like selling cheap pringer or mobiles and make the money with ink
or the phone tariff.

There are sources like http://igs.ifag.de/index_ntrip_cast.htm
to get the GNSS data streams over the internet - for free. I'm
registrated an can use their casts.

The globallocal answers on my questions are diffuse and the information
that AGPS is not usable without globallocate server

> "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.

NAL= 
> The AGPS features currently only expect a NAL (network abstraction
> layer) to reach the AGPS servers.

Routing to a server
> "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.
free routing possible, but what is the protocoll of the AGPS data
that the globallocal chip expect?

> "Would it be possible to run an own server (runnning open software)?"
>     You would need to:
>     - develop a SUPL protocol stack
SUPL = a protocol from OMA, Open Mobil Alliance - where is it
documented?
>     - get an assistance data feed.  Network operators pay big $$$
> for this from
>       commercial providers.  Developing your own is a major task.
Just some stations - ntrip_cast for the beginning
>     - get authority from cell providers and network operators for
> AGPS to go through them
GPRS/SSL 
>       (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.
O2 in Germany serves lat,long for free.


There is also a chip from atmel "ublox" with Assist-Now(TM) and AFAIK
is their documentation linkt to a Assist-Now(TM)-AGPS server.

Maybe I don't know enough, but for me it smells like that globallocal
AGPS is only used with AGPS servers - and with the risk that this
server knows the location of every globallocal user after connection.


I will go on this topic - but I fear that AGPS from globallocal is not 
open enough to feed my mobil with own data - independend of globallocal
server. If this would be true, it would be disapointing. I would like
to pay more for a device when AGPS would be independend of third party
servers.

Without asking globallocal again, do you have some more documentations
about SUPL and NAL?

Greetings,
rob



Sean Moss-Pultz schrieb am Sonntag, den 03. Dezember 2006 um 23:13h:

> 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