DE60319846T2

DE60319846T2 - Schnittstelle für ein gps-system

Info

Publication number: DE60319846T2
Application number: DE60319846T
Authority: DE
Inventors: Steve Chang San Jose CHIAYEE; Lionel-Jacques Palo Alto GARIN; Ashutosh NOIDA PANDE; Zhang Cupertino GENGSHENG
Original assignee: Sirf Technology Inc
Current assignee: CSR Technology Inc
Priority date: 2002-08-15
Filing date: 2003-08-15
Publication date: 2009-04-16
Anticipated expiration: 2023-08-16
Also published as: CN1675564A; CN100409029C; US8301375B2; US20130006527A1; JP2005535901A; KR20050035884A; JP4255441B2; DE60319846D1; KR100722350B1; EP1537435A1; ATE389889T1; US8762054B2; AU2003265476A1; EP1537435B1; WO2004017092A1; US20060036365A1

Description

Hintergrund der Erfindung
1. Gebiet der Erfindung
Diese Erfindung betrifft allgemein das Gebiet der drahtlosen Kommunikationen. Insbesondere betrifft die Erfindung ein Verfahren und eine Vorrichtung zum Koppeln der globalen Positionsbestimmungs(GPS)-Vorrichtungen mit unterschiedlichen Kommunikationsvorrichtungen unabhängig von irgendwelchen spezifischen Hilfsprotokollen, die von den Kommunikationsvorrichtungen stammen.
2. Betreffender Stand der Technik
Die weltweite Verwendung von drahtlosen Vorrichtungen (auch bekannt als „Mobilgeräte), wie beispielsweise Zwei-Wege-Funkgeräte, tragbare Fernsehergeräte, PDA (Personal Digital Assistant), zellulare Telefone (auch bekannt als „drahtlose Telefone", „drahtlose Fernsprechgerate", „mobile Telefone", „mobile Fernsprechgeräte" und/oder „Mobilstationen"), Satellitenfunkemfpänger und Satellitenpositionsbestimmungssysteme („SATPS"), wie beispielsweise das Globale Positionsbestimmungssystem (GPS), auch bekannt als NAVSTAR, nimmt rapide zu. Da die Anzahl an Leuten, die drahtlose Vorrichtungen verwenden, zunimmt, nimmt auch die Anzahl an Funktionen, die von drahtlosen Dienstanbietern angeboten werden, zu, sowie die Integration dieser drahtlosen Vorrichtungen mit anderen Produkten.
Seit die Erzeugung des NAVSTAR GPS Systems durch das U. S. Verteidigungsministerium („DoD” = Department of Defence") in den frühen 1970ern sind viele zivile Anwendungen entstanden, die neue Technologien in Verbindung mit GPS verwenden. Diese neuen Technologien enthalten beispielsweise private GPS Empfänger, die es Benutzern erlauben ihre Positionen auf der Erdoberfläche zu bestimmen, und verschiedenen Kommunikationsnetzwerken, wie beispielsweise CDMA (Code Division Multiple Access) und TDMA (Time Division Multiple Access) zellulare Netzwerke, die GPS Taktreferenzen für den Betrieb verwenden. Als Ergebnis dieser neuen Technologien gibt es eine steigende Anforderung für mobile Kommunikationsgerate, die neben anderen Dingen ihre Orte in Notfallsituationen senden, Positionsinformation mit Kommunikationsvorrichtungen integrieren, Touristen, Kinder und alte Leute lokalisieren und verfolgen, und Sicherheit für verschiedene Wertgegenstände bereitstellen.
Im Allgemeinen sind GPS Systeme typischerweise Satelliten (auch bekannt als „Raumfahrzeug" oder „SV") basierte Navigationssysteme. Beispiele von GPS enthalten, sind aber nicht darauf beschränkt, dass Vereinigte Staaten („U. S.") Marine Navigationssatellitensystem („NNSS” = Navy Navigation Satellite System) (auch bekannt als TRANSIT), LORAN, Shoran, Decca, TACAN, das „JPO" (Joint Program Office) Globalpositionsbestimmungssystem, bekannt als NAVSTAR, das entwickelt wurde von dem Verteidigungsministerium („DoD” = Department of Defence), das russische Gegenstück, bekannt als globales Navigationssatellitensystem („GLONASS” = Global Navigation Satellite System) und ferner das zukünftige westeuropäische GPS, wie das vorgeschlagene „Galileo” Programm. Das NAVSTAR GPS (im folgenden einfach als „GPS" bezeichnet) wurde ursprünglich entwickelt als ein militärisches System, um die Bedürfnisse des U. S. Militärs zu erfüllen; jedoch hat der U. S. Kongress später das DoD angewiesen auch zivile Anwendungen des GPS zu fördern. Als Ergebnis ist GPS jetzt ein System für eine Dual-Verwendung, das verwendet werden kann von U. S. Regierungsbehörden (beispielsweise von dem Militär) und von Zivilisten. Das GPS System ist beschrieben in Global Positioning System: Theory and Practice, 5. überarbeitete Ausgabe von Hofmann-Wellenhof, Lichtenegger und Collins, Springer-Verlag, Wien, New York, 2001.
Typischerweise enthält die Verwendung von GPS ein Identifizieren von genauen Orten auf der Erde und ein Synchronisieren von Telekommunikationsnetzwerken wie die militärischen Kommunikationsnetzwerke und die zellularen Telefonnetzwerke, beispielsweise Systeme von CDMA-Typ und TDMA-Typ. Zusätzlich, mit dem Beginn des Mandats des Kongresses der Vereinigten Staaten, durch die „FCC" (Federal Communications Commission), für ein zellulares Telefonnetzwerk, das in der Lage ist, den Ort eines Zellulartelefonbenutzers innerhalb von 50 Fuß in Notfallsituationen bereitzustellen (im Allgemeinen bekannt als „Enhanced 911" Dienst oder „E911"), wird GPS verwendet zur Ortsbestimmung und Synchronisation in vielen zellularen Anwendungen.
Im Allgemeinen sendet die Anordnung der GPS Satelliten (allgemein bekannt als „GPS Konstellation") sehr genaue zeitkodierte Information, die es einem GPS Empfänger ermöglicht seine Position bezüglich Breitengrad und Längengrad auf der Erde sowie die Höhe über Meeresspiegel zu berechnen. GPS ist ausgelegt, um ein Basisnavigationssystem zu schaffen mit einer Genauigkeit innerhalb von ungefähr 100 m für nicht militärische Benutzer und mit noch größerer Genauigkeit für das Militär und für andere autorisierte Benutzer (mit selektiver Verfügbarkeit „SA" = Selective Availability auf EIN gesetzt).
Im Allgemeinen enthält GPS drei Hauptsystemsegmente: Raum, Steuerung und Benutzer. Das Raumsegment von GPS ist eine Konstellation von Satelliten, die über der Erde kreisen enthaltend Sender, die hoch genaue Zeitgebungsinformation an GPS Empfänger auf der Erde senden. Im Moment enthält eine implementierte GPS Konstellation 21 Hauptbetriebssatelliten plus drei aktive Reservesatelliten. Diese Satelliten sind in sechs Erdumlaufbahnen angeordnet, wobei jede Erdumlaufbahn drei oder vier Satelliten enthält. Die Erdumlaufbahnebenen bilden einen 55° Winkel mit dem Äquator. Die Satellitenumlaufbahn bei einer Höhe von ungefähr 10898 nautischen Meilen (20200 Kilometer) über der Erde mit Erdumlaufbahnzeitperioden für jeden Satelliten für ungefähr 12 Stunden.
Im Allgemeinen enthält jeder der die Erde umkreisende Satelliten vier hoch genaue Atomuhren (2 Rubidium und 2 Cäsium). Diese Atomuhren liefern Präzisionszeitgebungsimpulse, die verwendet werden, um einen eindeutigen Binärcode (auch bekannt als Pseudozufallscode „PRN-Code" oder Pseudorauschen „PN-Code" bekannt) zu erzeugen, der zur Erde gesendet wird. Der PRN-Code gibt den spezifischen Satelliten in der GPS Konstellation an. Der Satellit sendet auch einen Satz von digital kodierter Information, die zwei Typen von Erdumlaufbahnparametern enthält zum Bestimmen der Orte im Raum für die Satelliten, bekannt als Almanachdaten und Ephemeridedaten.
Die Ephemeridedaten (auch bekannt als „Ephemeride") definieren die präzise Umlaufbahn des Satelliten. Die Ephemeridedaten geben an, wo der Satellit zu irgendeinem gegebenen Zeitpunkt ist, und dessen Ort kann spezifiziert werden bezüglich der Satellitengrundverfolgung in präzisen Breitengrad- und Längengradmessungen. Die Information in den Ephemeridedaten ist kodiert und wird von dem Satelliten gesendet, um eine genaue Angabe des Ortes des Satelliten über der Erde zu jedem gegebenen Zeitpunkt bereitzustellen. Typischerweise sind die gegenwärtigen Ephemeridedaten ausreichend zum Bestimmen der Orte im Raum bis auf wenige Meter oder wenige Zehntelmilimeter mit gegenwärtigen Leveln von SA. Eine Bodensteuerungsstation aktualisiert die Ephemeridedaten jede Stunde, um die Genauigkeit sicherzustellen. Nach ungefähr zwei Stunden beginnt jedoch die Genauigkeit der Ephemeridedaten schlechter zu werden.
Die Almanachdaten sind ein Nebensatz der Ephemeridedaten. Die Almanachdaten enthalten weniger genaue Information bezüglich des Ortes aller Satelliten in der Konstellation. Die Almanachdaten enthalten relativ wenig Parameter und sind im Allgemeinen ausreichend zum Bestimmen der Orte im Raum bis auf wenige Kilometer. Jeder GPS Satellit sendet die Almanachdaten für alle GPS Satelliten in der GPS Konstellation in einem 12 und ½ („12,5") Minutenzyklus. Folglich, durch Verfolgen von nur einem Satelliten werden die Almanachdaten aller anderen Satelliten im Orbit gewonnen. Die Almanachdaten werden alle paar Tage aktualisiert und sind etwa einigen Monaten nützlich. Aufgrund ihrer relativ langen Lebensdauer verwenden GPS Empfänger, die für mehr als ein paar Stunden ausgeschaltet sind, typischerweise die Almanachdaten, um zu Bestimmen, welche GPS Satelliten in Sichtweite sind. Beide, die Almanachdaten und die Ephemeridedaten sind jedoch nur eine begrenzte Zeit gültig. Der Ort der Satelliten basierend auf dieser Information wird umso ungenauer, je älter die Almanachdaten und Ephemeridedaten werden, wenn die Daten nicht bei geeigneten Zeitintervallen aktualisiert werden.
Die Ephemeridedaten enthalten drei Sätze von Daten, die verfügbar sind zum Bestimmen des Positionsvektors und des Geschwindigkeitsvektors der Satelliten in einem terrestrischen Referenzrahmen zu jedem Moment. Diese drei Sätze von Daten enthalten Almanachdaten, Sendungs-ephemeride und präzise Ephemeride. Die Daten unterscheiden sich in der Genauigkeit und sind entweder in Echtzeit oder später verfügbar. Typischerweise liegt der Zweck der Almanachdaten darin, den Benutzer mit weniger präzisen Daten zu versorgen, um die Satellitensuche durch den Empfänger zu vereinfachen, oder dient für Planungsaufgaben, wie beispielsweise für die Berechnung von Sichtbarkeitsdiagrammen. Die Almanachdaten werden mindestens alle sechs Tage aktualisiert und als Teil der Satellitennachricht ausgesendet. Die Almanachnachricht enthält im Wesentlichen Parameter für die Erdumlaufbahn und Satellitenuhrkorrekturtherme für alle Satelliten. Die GPS Almanachdaten sind beschrieben in „GPS Interface Control Document ICD-GPS-200" für „NAVSTAR GPS Space Segment und Navigation User Interfaces" veröffentlicht durch NavTech Seminare & NavTech Book and Software Store, Arlington, Va., neu gedruckt Februar 1995.
In einem typischen Betriebsbeispiel, wenn ein GPS Empfänger zuerst eingeschaltet wird (allgemein bekannt als „Kaltstart") oder aufgeweckt wird aus einem Standy-By-Zustand von mehr als paar Stunden, scannt der GPS Empfänger das GPS Spektrum, um ein GPS Signal, das von einem verfügbaren GPS Satelliten gesendet wird, zu erfassen. Sobald das GPS Signal empfangen worden ist, lädt der GPS Empfänger die GPS Almanachdaten für die GPS Konstellation, die Ephemeridedaten und die Taktkorrekturinformation von dem erfassten GPS Satelliten herunter. Sobald die Almanachdaten heruntergeladen sind, scannt der GPS Satellit das GPS Spektrum gemäß der Verfügbarkeit (also „in Sicht") der GPS Satelliten, wie durch die Almanachdaten angegeben. Idealerweise kann bei ausreichender Zeit und ausreichend angenommenen Umgebungsbedingungen um den GPS Empfänger herum, der GPS Empfänger zwei oder drei zusätzliche GPS Satelliten in Sicht erfassen, der GPS Empfänger empfängt beides, die Distanzinformation und die Zeitgebungsinformation, von den drei bis vier Satelliten und berechnet seine Position auf der Erde.
Für viele Anwendungen beschränken sowohl die Zeit als auch die Umgebungsbedingungen die Fähigkeit des GPS Empfängers, die GPS Almanachdaten herunterzuladen, speziell bei Indoor-Zuständen oder beschränkten Himmelssichtbedingen. Die Probleme bezüglich der Zeit sind normalerweise beschrieben durch die TTFF (Time-to-First-Fix) Werte. Wenn die TTFF Werte groß sind, hat der GPS Empfänger beschränkte Anwendungen, da es lange dauert, um seinen Anfangsort zu bestimmen.
Als ein Beispiel kann in einer drahtlosen oder mobilen (beispielsweise zellularen) Telefonanwendung ein Mobiltelefon oder ein PDA (Person Digital Assistant) mit einem integrierten GPS Empfänger ungefähr 12,5 Minuten warten müssen (unter der Annahme von perfekten Umgebungsbedingungen mit allen notwendigen Satelliten in Sicht), damit der GPS Empfänger die GPS Almanachdaten herunterzuladen kann, bevor ein Anruf getätigt werden kann. Dies wäre für die meisten Anwendungen nicht akzeptabel.
In zellularen Telefonanwendungen ist diese Einschränkung noch mehr unakzeptabel aus Sicht des E911 Mandats, das erfordert, dass ein zellulares Telefon seine Positionsinformation an ein Notfallpersonal in einem E911 Notfallanruf sendet. Wenn die Benutzer sich selbst in einer Notfallsituation finden, mit einem GPS aktiven zellularen Telefon, das ausgeschaltet ist, oder das in einem langen Stand-By-Zustand ist, müssten diese Benutzer zuerst ungefähr 12,5 Minuten mit kontinuierlicher nicht unterbrochener Satellitensichtbarkeit warten (da der GPS Empfänger typischerweise ein starkes Signal benötigt, um die Almanachdaten und/oder die Ephemerideda ten zuverlässig zu erfassen), bevor ein Notfallanruf getätigt werden kann, der den Ort des Benutzers an das Notfallpersonal senden würde. In typischen Metropolen oder natürlich versperrten Umgebungen kann dies länger als 12,5 Minuten dauern, da die Umgebungsbedingungen das Erfassen des ersten Satelliten schwieriger gestalten können. Dies wäre nicht akzeptabel, insbesondere in einer lebensbedrohlichen Situation.
Vergangene Ansätze zum Reduzieren des Zeitaufwandes, der erforderlich ist zum Herunterladen der Almanachdaten, umfassten das Speichern einer gewissen Art von Almanach (beispielsweise fabrikmäßig installierte Almanachdaten) in einer Speichereinheit (beispielsweise eine Nur-Lese-Speicher „ROM") in dem GPS Empfänger. Typischerweise werden diese vorab gespeicherten Alamanchdaten verwendet, um TTFF in einer Kaltstartbedingung (Zustand) zu reduzieren. Bei diesem Ansatz hat dieser Kaltstartzustand üblicherweise immer noch eine relativ große TTFF Zeit, aufgrund von Unsicherheiten, die zu den Satellitenpositionen gehören, und aufgrund des Alters der vorab gespeicherten Almanachdaten. Sobald das erste Fix erfasst worden ist, kann dieser GPS Empfänger dann die aktualisierten Almanachdaten von dem erfassten Satelliten herunterladen und das ROM (oder eine Nur-Lese-Speicher „RAM") zur zukünftigen Verwendung aktualisieren. Dieser Ansatz erfordert immer noch, dass der GPS Empfänger die aktualisierten Almanachdaten empfängt (also eine „frische" Kopie der Almanachdaten empfängt) von den Satelliten für zukünftige Erfassungen. Das Empfangen der aktualisierten Almanachdaten erfordert immer noch einen signifikanten Zeitaufwand, der die Performance des GPS Empfängers beeinträchtigt.
In Antwort auf diese Probleme sind Hilfsansätze entwickelt worden für mobile Telefone, die den GPS Empfänger unterstützen, indem Hilfsdaten von einem Kommunikationsmodule (auch bekannt als „Rufprozessor" oder „CP") bereitgestellt werden für derartige Zwecke, wie Erfassung, Ortsberechnung und/oder Empfindlichkeitsverbesserung). Unglücklicherweise sind diese Hilfsansätze in drahtlosen Netzwerken typischerweise zellular Netzwerk spezifisch (also zellular plattformenspezifisch, wie TDMA, GSM, CDMA, etc.) und anbieterspezifisch, und werden bereitgestellt für Geolokations-Server-Stationen, die in dem zellularen Netzwerk lokalisiert sind. Als ein Ergebnis muss der GPS Empfänger in dem mobilen Telefon (auch bekannt als „mobile Station" oder „MS") typischerweise mit der Geolokations-Server-Station des zellularen Netzwerkes kompatibel sein.
Die US 6,389,291 offenbart eine mobile GPS Vorrichtung, die Hilfsdaten verwendet, die über ein drahtloses Kommunikationsnetzwerk empfangen werden.
Es gibt jedoch verschiedene zellulare Netzwerke im Betrieb in den Vereinigten Staaten und im Ausland, die entweder Geolokations-Server-Stationen integrieren oder integrieren werden, die Geolokations-Server-Stationsprotokolle verwenden, die zueinander nicht kompatibel sind. Folglich besteht ein Bedarf für ein System, das in der Lage ist, einem GPS Empfänger zu erlauben, mit der Vielzahl von Geolokations-Server-Stationen zu arbeiten, das Geolokations-Server-Stationsprotokoll unabhängig ist.
Zusammenfassung
Die Erfindung, wie sie definiert ist in den Ansprüchen 1, 8 und 9, erreicht dies. Weitere vorteilhafte Merkmale sind in den abhängigen Ansprüchen 2 bis 7 definiert.
Kurzbeschreibung der Figuren
Die Komponenten in den Figuren sind nicht notwendiger Weise maßstabsgetreu, sondern herben stattdessen zur Verdeutlichung die Prinzipien der Erfindung hervor. In den Figuren bezeichnen gleiche Bezugszeichen entsprechenden Teile in den unterschiedlichen Ansichten.
1 zeigt eine Darstellung eines typischen bekannten GPS Empfängers im Betrieb.
2 zeigt ein Diagramm 200 einer Anzahl von unterschiedlichen bekannten Anwendungen für GPS.
3 zeigt eine bekannte drahtlose mobile Positionsbestimmungssystemarchitektur 300, die GPS Daten von der GPS Konstellation 226 über Signalwege 302 und 304 empfängt.
4 zeigt eine typische Implementierung der mobilen Vorrichtung 400 enthaltend einen Rufprozessor 402 der über einen Signalweg 406 mit einem GPS Modul 404 in Signalkommunikation ist.
5 zeigt ein Blockdiagramm einer beispielhaften Implementierung einer protokollunabhängigen Schnittstelle in einer drahtlosen mobilen Positionsbestimmungssystemarchitektur.
6 zeigt ein Diagramm für eine beispielhafte Implementierung einer mobilen Vorrichtung unter Verwendung einer FSM in einer GSM Umgebung gemäß 5.
7 zeigt ein Blockdiagramm einer beispielhaften Implementierung einer mobilen Vorrichtung unter Verwendung einer FSM in einer CDMA Umgebung gemäß 5.
8 zeigt ein Beispiel eines RRLP für ein Protokoll unabhängiges Schnittstellennachrichtenflussdiagramm zwischen einer Geolokations-Server-Station, einem Rufprozessor und einem GPS Modul.
9 zeigt ein Bespiel eines Protokoll unabhängigen Schnittstellennachrichtenflussdiagramms zwischen einem Rufprozessor, einem GPS Modul und einer Basisstation („BS").
Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
Bezugnehmend auf 1: In 1 ist ein Diagramm 100 einer beispielhaften Implementierung eines bekannten globalen Positionsbestimmungssystems („GPS") verdeutlicht. Im Betrieb ist ein GPS Empfänger 102, der auf der Erde 104 lokalisiert ist, ausgelegt, um Signale 106, 108, 110 und 112 von verschiedenen GPS Satelliten 114, 116, 118 bzw. 120 gleichzeitig zu erfassen. Der GPS Empfänger 102 decodiert die Information und berechnet unter Verwendung der Zeitdaten und der Ephemeridedaten die Position des GPS Empfängers 102 auf der Erde 104. Der GPS Empfänger 102 enthält normalerweise einen Gleitkomma-Prozessor (nicht gezeigt), der die notwendigen Berechnungen durchführt und eine dezimale oder graphische Anzeige des Breitengrads und Längengrads sowie der Höhe auf einer Anzeige 122 ausgeben kann. Im Allgemeinen werden die Signale 106, 108 und 110 von mindestens drei Satelliten 114, 116 bzw. 118 für die Breitengrad- und Längengradinformation benötigt. Ein viertes Satellitensignal 112 von dem Satelliten 120 wird benötigt, um die Höhe zu berechnen.
2 zeigt ein Diagramm 200 einer Anzahl von unterschiedlichen bekannten Anwendungen für GPS. In 2 sind verschiedene beispielhafte Vorrichtungen 206, 204, 202, 202, 208, 210 und 212 gezeigt, die GPS Signale 214, 216, 218, 222, 220 und 224 empfangen bzw. verwenden von einer GPS Konstellation 226 von Satelliten (wobei die individuellen Satelliten nicht gezeigt sind). Die beispielhaften Vorrichtungen können einen GPS Handempfänger 202, einen GPS Automobilempfänger 204, einen GPS integrierten zellularen Telefonempfänger 206, einen GPS integrierten PDA Empfänger 208, einen GPS integrierten Mobilcomputer (beispielsweise ein typischer „Laptop" oder „Notebook" Computer) Empfänger 210, einen GPS integrierten Computer (nicht mobil) Empfänger 212 oder irgend einen anderen ähnlichen Typ von Vorrichtung enthalten, die einen GPS Empfänger integrieren kann.
Fachleute auf diesem Gebiet verstehen, dass GPS Empfänger der Vergangenheit typischerweise alleinstehende Geräte waren, die GPS Signale von der GPS Konstellation empfangen haben, ohne irgendwelcher Hilfe von einer externen Quelle. Mit dem E911 Mandat des Kongresses und mit dem kontinuierlichen Wachstum an drahtlosen Kommunikationen in zellularen und nicht zellularen Netzwerken beginnen mehr und mehr Kommunikationsvorrichtungen GPS Empfänger in die Kommunikationsvorrichtungen zu integrieren, um das E911 Mandat zu erfüllen, und/oder für eine netzwerkunterstützte Hilfe für den GPS Empfänger.
Diese neuen integrierten Kommunikationsvorrichtungen können entweder in Kommunikation mit einem zellularen Kommunikationsnetzwerk sein über Sammelknoten wie Basisstationstürme 228 oder mit einem nicht zellularen Kommunikationsnetzwerk über einen nicht zellularen Sammelpunkt 230. Die Zellularen Kommunikationsnetzwerke können TDMA, CDMA, GSM, Breitband CDMA (auch bekannt als „W-CDMA" und/oder UMTS = Universal Mobile Telecommunications System), CDMA-2000, GPRS = General Packet Radio Service oder AMPS = Advanced Mobile Phone Service-Typ von Zellularnetzwerk sein. Das nicht zellulare Kommunikationsnetzwerk kann derartige Netzwerke enthalten, wie BlueTooth^®, Wireless Fidelity („Wi-Fi^®") Netzwerk basierend auf IEEE 802.11, oder andere ähnliche drahtlose Netzwerke. Als ein Beispiel können der GPS Handempfänger 202, der integriert GPS Automobilempfänger 204, der GPS integrierte Zellulartelefonempfänger 206, PDA 208 und der mobile Computer 210 mit der zellularen Basisstation 228 über Signalwege 232, 234, 236, 238 bzw. 240 in Kommunikation sein. Ähnlich können der GPS Handempfänger 202, der PDA 208 und der mobile Computer 210 in Signalkommunikation mit dem nicht zellularen Verbindungspunkt 230 über Signalwege 242, 246 bzw. 244 sein.
Als ein Beispiel eines integrierten GPS Empfängers in einer nicht drahtlosen Kommunikationsumgebung, kann ein nicht mobiler Computer 212 einen integrierten GPS Empfänger (nicht gezeigt) enthalten, der intern auf der Hauptplatine integriert ist, durch eine intern hinzugefügte periphere Vorrichtung, oder als eine verbundene externe periphere Vorrichtung. In diesem Fall kann der integrierte GPS Empfänger (nicht gezeigt) irgendeine Unterstützung von einem Netzwerkserver 248 über ein Netzwerk 250 oder Modem 252 empfangen. Das Netzwerk 250 kann ein gut bekanntes POTS = „Plane Old Telephone Service", ein Ethernet, das Internet oder ein ähnliches Netzwerk sein. Es versteht sich von selbst, dass andere Vorrichtungen, die mit dem POTS, dem Ethernet und dem Internet verbunden sein können, beispielsweise Herstellermaschinen, Büro- und Businessausstattung oder eine andere wichtige Einrichtung ebenso verwendet werden können in der gleichen Weise wie der nicht mobile Computer 212.
3 zeigt eine bekannte drahtlose mobile Positionsbestimmungssystemarchitektur 300, die GPS Daten von der GPS Konstellation 226 über Signalwege 302 und 304 empfangt. Die Architektur 300 kann eine mobile Vorrichtung 306, eine Basisstation 308, eine Drahtlosnetzwerkinfrastruktur 310, eine Geolokations-Server-Station 312, einen GPS Referenzempfänger 314 und einen optionalen Endbenutzer 316 enthalten. Der GPS Referenzempfänger 314 empfängt GPS Signale von der GPS Konstellation 226 über einen Signalweg 302. Die mobile Vorrichtung 306 empfangt GPS Signale von der GPS Konstellation 226 über einen Signalweg 304 und ist in Signalkommunikation mit der Basisstation 308 über den Signalweg 318. Im Allgemeinen enthält die mobile Vorrichtung 306 einen Rufprozessor 320 und ein GPS Modul 322. Beide, der Rufprozessor 320 und GPS Modul 322 sind in Signalkommunikation über einen Signalweg 324. Der Signalweg 324 kann eine RS 323 Verbindung, eine logische Schnittstelle über einen Speicher, der Softwaredatenstrukturen gemeinsam verwendet, oder andere Typen von elektrischen und/oder logischen Schnittstellen sein. Fachleuten auf diesem Gebiet ist bekannt, dass das GPS Modul 322 entweder als ein separates Modul und/oder eine Vorrichtung implementiert werden kann, oder als eine Funktionseinheit, die irgendwo innerhalb der mobilen Vorrichtung 306 lokalisiert sein kann, einschließlich der Rufprozessor 320.
Im Allgemeinen erfordert die in 3 gezeigte Architektur 300, dass das GPS Modul 322 das gleiche Protokoll verwendet, das durch die Geolokations-Server-Station 312 verwendet wird, um irgendeine GPS Hilfsinformation von der Geolokations-Server-Station 312 zu empfangen.
4 zeigt eine typische Implementierung der mobilen Vorrichtung 400, die einen Rufprozessor 402 enthält, der über einen Signalweg 406 in Signalkommunikation mit einem GPS Modul 404 ist. Die mobile Vorrichtung 400 kann eine Beispielvorrichtung 202, 204, 206, 208, 210 und 212 gemäß 2 sein. Der Rufprozessor 402 ist in Signalkommunikation mit der Basisstation 308 über einen Signalweg 318, und das GPS Modul 404 empfängt GPS Daten von der GPS Satellitenkonstellation 226 über einen Signalweg 304. Als ein Beispiel kann der Signalweg 406 implementiert sein durch eine RS 232 Datenverbindung, wenn der Rufprozessor 402 und das GPS Modul 404 physikalisch getrennte Vorrichtungen sind. Der Signalweg 406 kann auch implementiert sein als logische Schnittstelle, über einen Speicher, der Softwaredatenstrukturen verteilt, oder andere Typen von elektronischen und/oder logischen Schnittstellen sein.
Im typischen Betrieb empfängt die mobile Vorrichtung 400 GPS Signale 304 von der GPS Konstellation 226, 3, und Kommunikationssignale 318 von der zellularen Telefonkommunikationsnetzwerkinfrastruktur 310 über den Basisstations-Turm 308 oder mit dem nicht zellularen Kommunikationsnetzwerk (nicht gezeigt) über einen nicht zellularen Sammelpunkt 230, 2.
Der Rufprozessor 402, 4 kann irgendeine Kommunikationsvorrichtung sein, die in der Lage ist entweder in einer Richtung oder in zwei Richtungen mit einem externen Kommunikationsnetzwerk zu kommunizieren, wie beispielsweise die zellulare Telefonkommunikationsnetzwerkinfrastruktur 310, 3, oder das nicht zellulare drahtlose oder nicht drahtlose Netzwerk (nicht gezeigt). Der Rufprozessor 402 enthält bestimmte Hardware (nicht gezeigt) und Software (nicht gezeigt) zum Aufbauen und Verwalten einer Telekommunikationsverbindung.
Beispiele eines zellularen Telefontyps des Rufprozessors 402 können ein zellulares Telefonrufverarbeitungs-IDEN^TM (Integrated Dispatch Enhanced Network) enthalten, hergestellt von Motorola, Inc., von Schaumberg, Illinois, CDMA2000^® 1X-Typ Chipsätze, die verwendet werden von Nokia Finnland, Sony Ericsson Schweden, Qualmcomm, Inc. San Diego, Kalifornien oder irgendein ähnlicher Typ von GSM/CDMA/TDMA/UMTS-Typ von Kommunikationsvorrichtung, die in der Lage ist, mit einem GPS Empfänger innerhalb eines GPS Moduls 308 zu kommunizieren. Beispiele eines nicht zellularen Telefontyps einer Kommunikationsvorrichtung können einen SX45 GPS Apparat enthalten, hergestellt von Siemens SA Deutsch land, irgendeine Vorrichtung, die in der Lage ist über BlueTooth^®, Wireless Fidelity („WiFi^®”) Netzwerk basierend auf IEEE 802.11 zu kommunizieren, oder andere ähnliche drahtlose Netzwerke. Das GPS Modul 404 kann irgendeinen GPS Empfänger enthalten, der in der Lage ist mit dem Rufprozessor 402 zu kommunizieren.
In 5 ist eine beispielhafte Implementierung einer protokollunabhängigen drahtlosen mobilen Positionsbestimmungssystemarchitektur 500 gezeigt. In 5 kann die Architektur 500 eine mobile Vorrichtung 506, eine Basisstation 508, eine drahtlose Netzwerkinfrastruktur 510, eine Geolokations-Server-Station 512, einen GPS Referenzempfänger 514 und einen optionalen Endbenutzer 516 enthalten. Die mobile Vorrichtung 506 und der GPS Referenzempfänger 514 empfangt GPS Signale von der GPS Satellitenkonstellation 226 über Signalwege 504 bzw. 502.
Die mobile Vorrichtung 506 kann einen Rufprozessor 520, ein GPS Modul 522 und eine protokollunabhängige Schnittstelle (hier bezeichnet als „PI2") 524 enthalten. Die PI2 524 ist eine Schnittstelle, die es dem GPS Modul 522 erlaubt Hilfsdaten von der Geolokations-Server-Station 512 zu empfangen, ohne dass das GPS Modul 522 das gleiche Protokoll verwenden muss, das von der Geolokations-Server-Station 512 verwendet wird. Folglich erlaubt die PI2 524 dem GPS Modul 522 frei zu sein von spezifischen Implementierungen mehrerer Protokolle für unterschiedliche Geolokations-Server-Stationen. Die Verwendung des Begriffs Modul kann ein unabhängiges Modul oder ein Subsystem, das in einer Hauptplatine oder integrierten Schaltung integriert ist, umfassen.
Im Betrieb kann jedes Geolokationsprotokoll implementiert werden durch einen Übersetzer in der PI2 524, der das Protokoll der Geolokations-Server-Station 512 in ein unabhängiges Protokoll übersetzt, das von dem GPS Modul 522 verwendet wird. Dies erlaubt eine nahtlose Verfügbarkeit der Geolokationsinformation, wenn die mobile Vorrichtung 506 von einem Drahtloskommunikationsstandard zu einem anderen übergeht, wodurch die Art und Weise geändert wird, in der die mobile Vorrichtung 506 die Hilfsdaten empfängt, und die Position oder andere Geolokationsergebnisse von Rufprozessor 520 zu der Geolokations-Server-Station 512 sendet. Als ein Ergebnis kann jedes eindeutige Geolokationsprotokoll (beispielsweise IS-817, IS-801, etc.) für alle unterschiedlichen Luftschnittstellen, die an verschiedenen Plätzen in der Welt verwendet werden, von der GPS Vorrichtung 506 verwendet werden, ohne das GPS Modul 522 zurückzusetzen oder neu zu konfigurieren, da die PI2 524 in der Lage ist, die GPS Information von der Geolokations-Server-Station 512 des Kommunikationssystems, an dem der Benutzer (nicht gezeigt) der mobilen Vorrichtung 506 teilnimmt, in das Protokoll zu übersetzen, das von dem GPS Modul verwendet wird. Ein Beispiel der PI2 524 enthält nicht einschränkend die hilfsunabhängige Zwischenbetriebsschnittstelle („AI3"), entwickelt und in Besitz von SiRF Technology, Inc. San Jose, Kalifornien.
Fachleute auf diesem Gebiet erkennen, dass es unterschiedliche Geolokationsstandards gibt, die für unterschiedliche Typen von Drahtlosnetzwerken entwickelt worden sind. Als ein Beispiel kann die Schnittstelle 526 zwischen der Basisstation 508 und der Infrastruktur 510 irgendeine Luftschnittstelle sein. Die Schnittstelle 526 wird typischerweise gesteuert durch den Rufprozessor 520 Hersteller. Typischerweise enthält die PI2 524 zwei Schnittstellen, die im Allgemeinen bekannt sind als „F" Schnittstelle (nicht gezeigt) und „G” Schnittstelle (nicht gezeigt).
Die F Schnittstelle, die die Client Systemschnittstelle zwischen dem GPS Modul 522 und dem Rufprozessor 520 ist, arbeitet als ein Bootstrap-Protokoll, immer vorhanden, das es dem Rufprozessor 520 erlaubt eine Laufzeit zu wählen, wie die Hilfe an das GPS Modul 522 in der Hilfseinkapselungsschicht transportiert wird. Der Rufprozessor 520 kann wählen zwischen einer Luftschnittstelle (wie die Schnittstelle 526 in dem Fall der End-To-End Systemarchitektur) oder der G Schnittstelle. Die F Schnittstelle kann die folgenden Aufgaben durchführen: Das GPS Modul 522 Hardwaremanagement von dem Rufprozessor 520 (Energie ein/aus, Reset); wenn verfügbar eine implizite Hilfsschnittstelle, also sendet Zeit und Frequenztransfer von dem Netzwerk (oder von dem Rufprozessor 520 Echtzeittakt) über den Rufprozessor 520, und eine ungefähre Mobilvorrichtung 506 Position (im Allgemeinen implizit von dem Netzwerk, wenn sie existiert); Sitzung Öffnen/Schließen (also das GPS Modul 522 benachrichtigen, das eine Luftschnittstellenverbindung geöffnet/geschlossen ist); und in einem Dualmodus-Mobilgerät 506 das GPS Modul 522 benachrichtigen, welche Luftschnittstelle ein ist, wodurch das GPS Modul 522 benachrichtigt wird, welcher Satz von Geolokationsluftschnittstellenprotokollen für einen Dialog mit der Geolokations-Server-Station zu verwenden ist.
Im Gegensatz zu der F Schnittstelle wird die G Schnittstelle verwendet, um die GPS Hilfsinformation, die von der Basisstation 508 empfangen wird, zu dem GPS Modul 522 zu transpor tieren. Da typischerweise viele Geolokationsprotokolle existieren, ist die G Schnittstelle designed, um für einen großen Bereich von Geolokationsstandards und luftschnittstellenunabhängig verwendbar zu sein, also es ist einzigartig für anwendbare Luftschnittstellen. Die PI2 524 kann implementiert sein als eine Reduzierung der anwendbaren Geolokationsstandards.
Im Betrieb sendet der Rufprozessor 520 Positionsanfrageinformation und Netzwerkhilfsinformation im PI2 Format an das GPS Modul 522 über die G Schnittstelle. Umgekehrt sendet das GPS Modul 522 Positionsergebnisse oder eine Fehlerbenachrichtigung an den Rufprozessor 520 über die gleiche Schnittstelle. Es sei erwähnt, dass alle Geolokationsprotokolle einschließlich SAMPS, GSM und CDMA unter dem Interaktionsmodell arbeiten. Die Basisstation 508 sendet nur zurück, was die Mobilvorrichtung 506 angefordert hat. Im Allgemeinen hängt die Strategie zum Durchführen der Interaktion sehr stark von der Kenntnis über die GPS Modul 522 Verarbeitung ab.
Zusätzlich, im Gegensatz zu vielen Protokollstapellevels sind Geolokationsprotokolle Anwendungsprotokolle, was bedeutet, dass sie mit der Semantik (Bedeutung) der Nachricht umgehen. Sie transportieren folglich nicht nur Daten von einer Seite zu der anderen Seite, ohne Fehlerkorrektur und Eliminierung von Überlagerung oder Wiederholung, wie in einem TCP-IP Stack. Als Solches muss jeder Eintrag, der das Protokoll handhabt (beispielsweise entscheidet einige Daten anzufordern), Wissen, für was diese Daten verwendet werden, und die Bedeutung jedes Parameters kennen, der über das Protokoll ausgetauscht wird (also es muss wissen, was auf der GPS Seite passiert). Als solches sollte der Implementierer des Geolokationsprotokolls GPS „intelligent" sein.
Folglich verwendet die PI2 524 eine Luftschnittstellen FSM („Finite State Machine"; Endliche Automaten) (nicht gezeigt). Im Allgemeinen resultiert dies in dem Zustand, in dem sich die FSM gegenwärtig befindet, eingeführt durch die gegenwärtige Kenntnis der Inhalte des GPS Speichers (nicht gezeigt), und in der Entscheidung eine Anfragenachricht zu senden, um einige nicht komplette GPS Information zu vervollständigen, die in der FSM selbst eingebaut ist.
Bezugnehmend auf 6 zeigt 6 ein Blockdiagramm für eine mobile Vorrichtung 600, die eine FSM verwendet. Die mobile Vorrichtung 600 enthält einen Rufprozessor 602 und das GPS Modul 604. Der Rufprozessor 602 enthält ein Luftschnittstellen CP Modul 606, ein Luft schnittstellenprotokoll für den GPS Modulschnittstellenumwandler 608, eine GPS Moduldatenstruktur 610, einen GPS Luftschnittstellen Paketierer/Depaketierer 612, einen GPS Modul/CP Systemnachrichtenprotokoll Paketierer/Depaketierer 614 und ein GPS Modul Schnittstellenmodul 616. Das GPS Modul 604 enthält ein CP Schnittstellenmodul 618, ein PI2 Schnittstellenmodul 620, eine PI2 Datenstruktur, eine CP Systemschnittstelle FSM 624 und einen GPS Kern 626. Der GPS Kern 626 empfängt GPS Signale von der GPS Satellitenkonstellation 226 über einen Signalweg 632 und das Luftschnittstellen CP Modul 606 ist in Signalkommunikation mit der Basissation (nicht gezeigt) über einen Signalweg 630.
6 zeigt eine High Level Architektur der PI2, die innerhalb einer IS-801 basierend auf einer CDMA Mobilvorrichtung 600 zu implementieren ist. Der Rufprozessor 602 kann mit dem GPS Modul 604 über einen Signalweg kommunizieren (der, nicht darauf eingeschränkt, eine RS 232 Verbindung sein kann) 628 und Hardwareleitungen (für die Zeit- und Frequenztransfers). Der Signalweg 628 kann als eine RS 232 Schnittstelle implementiert werden, eine logische Schnittstelle über ein Speicherteilen von Software, Datenstrukturen, andere elektronische und/oder logische Schnittstellen. Die F und G Schnittstellen 636 und 634 sind zwei unabhängige logische Kanäle für die RS 232 Schnittstelle. Die G Schnittstelle 364 ist designed, um die PI2 Hilfsdaten an das GPS Modul 604 durchzulassen. Der Rest der Hilfsdaten kommt zu dem GPS Modul 604 über die F Schnittstelle 636. Auf der Seite des GPS Moduls 604 ist die F Schnittstelle 638 eine standardmäßige GPS (beispielsweise SiRFLoc) Client Schnittstelle und die G Schnittstelle 640 ist transparent für irgendwelche Standardluftprotokolle. Für den IS-801 Rufprozessor 602 werden die PI2 Daten erzeugt über ein Luftschnittstellenprotokoll zu dem GPS Modulschnittstellenkonverter (auch bekannt als IS-801 Nachricht für PI2 Konverter). Die PI2 Daten werden in das G Nachrichtenformat gepackt über einen GPS Modulluftschnittstellen Paketierer/Depaketierer (auch bekannt als PI2 Schnittstellennachrichtenhandler) 612, bevor sie über den Signalweg 628 zu dem GPS Modul 604 verlaufen. Der Rufprozessor 602 gewinnt die Zeit, den Ort und die Frequenzdaten von entsprechenden Luftschnittstellennachrichten. Die Ortdaten werden weitergegeben zu dem GPS Modul 604 über eine „F" Schnittstelle 636 Nachricht (die ungefähre mobile Vorrichtung 600 Positionsantwortnachricht). Die Zeit- und Frequenzdaten werden zu dem GPS Modul 604 weitergeleitet.
Die PI2 Datenstruktur enthält Information über die Ionosphäre, Satellitenephemeride und Positionsanfrageparameter der mobilen Vorrichtung 600. Alle diese Daten sind typischerweise byteorientiert. Die PI2 Datenstruktur muss auf 0 zurückgesetzt werden, nachdem der Rufprozessor 602 eine Kommunikationsverbindung mit der Basisstation (nicht gezeigt) aufgebaut hat. Es gibt ein paar Quellen von Hilfsdaten, die die ungefähre Position der mobilen Vorrichtung 600, Ortsanfrageparameter, Ephemeridedaten, GPS Zeit und Frequenz enthalten. Die erste Quelle kann gewonnen werden durch die Kenntnis der Position der Basisstation. Die Basisstationsposition kann verwendet werden als ungefähre Position der mobilen Vorrichtung 600. Es gibt zwei Wege, um die Basisstationspositionsdaten IS-95 implizit Nachricht und IS-801 Protokollnachrichten zu bekommen. Der IS-95 Pagingkanal „Systemparameternachricht" enthält die BS Positionsdaten mit Längengrad und Breitengrad. Da die Höhendaten nicht verfügbar sind in dieser Nachricht wird die Höhe der ungefähren Position der mobilen Vorrichtung 600 auf 0 gesetzt. Der Rufprozessor 602 kann auch die Basisstationspositionsdaten über die IS-801 „Provide Base Station Almanac" (Anfragebasisstationsalmanach) Nachricht bekommen. Diese Nachricht enthält ausreichend Daten, die verwendet werden können, um den Längengrad, Breitengrad und die Höhe der Basisstation zu berechnen. In diesem Verfahren muss der Rufprozessor 602 die IS-801 „Anfragenbasisstationsalmanach" Nachricht senden, bevor die PDE mit der „Bereitstellen der Basisstationen Almanach" Nachricht antworten kann. Dies erfordert typischerweise ein zusätzliches Nachrichtenhandhaben, verglichen mit dem Impliziten IS-95 Verfahren.
Die Ortsanfrageparameter können auch dabei helfen die mobile Vorrichtung 600 zu lokalisieren. Die IS-801 „Anfrageortsantwort" Nachricht liefert Daten, um die Anzahl an Fixes und die Zeit zwischen den Fixes für PI2 Ortsanfrageparameter zu berechnen. Zusätzlich, mit den Ephemeridedaten liefert die IS-801 „Bereitstellungs GPS Ephemeride" Nachricht alle Daten, die in die Ephemeridedaten für RI2 zu konvertieren sind.
Eine Hilfs-GPS-Zeit erlaubt auch eine Reduktion der GPS Zeitunsicherheit, das GPS Modul 604 kann den GPS Takt mit dem CDMA Systemtakt über ein Zeittransferverfahren synchronisieren. Der Rufprozessor 602 synchronisiert den Handapparat Takt mit der CDMA Systemtakt, was erhalten werden kann aus der CDMA Sync Channel „Sync Channel Nachricht". Ähnlich kann ein Frequenzhelfen verwendet werden, um die GPS Frequenzunsicherheit zu reduzieren, das GPS Modul 604 kann den GPS Takt mit dem Rufprozessor 602 und dem Basisstationstakt über das Frequenztransferverfahren synchronisieren.
Im Betrieb handhabt die Software des Rufprozessors 602 die Kommunikation mit der Basisstation für Netzwerkhilfsdaten über IS-801 und IS-95 Nachrichtenprotokolle. Die PI2 Daten enthalten Positionsanfrageparameter der mobilen Vorrichtung 600 sowie die ephemeriden Hilfsdaten. Der Rufprozessor 602 kann die Positionsanfrageparameter der mobilen Vorrichtung 600 berechnen, indem die Anzahl der Positionsfixdaten verwendet wird, die zu holen ist aus der IS-801 „Anfrageortsantwort" Nachricht. Der Rufprozessor 602 erzeugt die Ephemeridehilfsdaten in dem PI2 Format, indem die komprimierten Ephemerdidedaten von der IS-801 „Bereitstellungs GPS Ephemeride" Nachricht geholt werden. Der Rufprozessor 602 soll die Positionsanfrageparameter der mobilen Vorrichtung 600 und die ephemeriden Hilfsdaten in die PI2 Datenstruktur speichern.
Der Rufprozessor 602 kann die Basisstationspositionsdaten verwenden, wie sie erhalten werden von der IS-95 „Systemparameternachricht" während des Leerlaufzustands der mobilen Vorrichtung 600, und sie verwenden als ungefähre Position der mobilen Vorrichtung 600. Aufgrund der fehlenden Höheninformation der Basisstation in der IS-801 „Systemparameternachricht" setzt der Rufprozessor 602 die Höhe der ungefähren Position der mobilen Vorrichtung 600 auf 0.
Der Rufprozessor 602 kann wählen, um die BS Positionsdaten aus der IS-801 „Bereitstellung Basisstationalmanach" Nachricht zu erhalten. Durch Auswählen dieses Verfahrens muss der Rufprozessor 602 die IS-801 „Anfragebasisstationalmanach" Nachricht während des Systemleerlaufzustands der mobilen Vorrichtung 600 oder während der Steuerung des Verkehrskanalzustands der mobilen Vorrichtung 600 senden. Verglichen mit dem impliziten IS-95 Verfahren erfordert dieses Verfahren die Verarbeitung von zwei IS-801 Nachrichten und mit Zeitverzögerung – später als der Leerlaufzustand der mobilen Vorrichtung 600. Von der Mehrzahl der Basisstationsparameter, die in der „Basistationsalmanach" Nachricht gefunden werden, sollte der Rufprozessor 602 die Basisstation auswählen, mit der er eine direkte Funkverbindung hat, als Referenzbasisstation für die ungefähre Position der mobilen Vorrichtung 600.
Der Rufprozessor 602 verwendet die CDMA Systemzeit, wie sie von der FS-95 „Sync Kanal Nachricht" gewonnen wird, als Rufprozessor 602 Zeit. Der Rufprozessor 602 sendet Zeitgebungsinformation an das GPS Modul 604 über das Zeittransverfahren. Ähnlich synchronisiert der Rufprozessor 602 seine Taktfrequenz mit der GPS Modul 604 Frequenz über das Frequenztransferverfahren.
Der Rufprozessor 602 sendet die PI2 Daten über die G Schnittstelle 634 an das GPS Modul 604 „PI2 Datennachricht". Der Rufprozessor 602 sendet die ungefähre Position der mobilen Vorrichtung 600, Zeit und Frequenztransferdaten über entsprechende F Schnittstellen 636 Nachrichten.
Um den PI2 basierten Ortsdient bereitzustellen setzt der Rufprozessor 602 entsprechende Werte für bestimmte Datenfelder IS-801 Nachrichten. Wenn der Rufprozessor 602 das Positionsergebnis von dem GPS Modul 604 über die F Schnittstelle 636 empfängt wandelt er das Positionsergebnis in das IS-801 Nachrichtenformat, das an die PDE zu senden ist.
In Antwort auf die IS-801 „Anfrage MS Informations" Nachricht, die von der PDE gesendet worden ist, setzt der Rufprozessor 602 den REQ_PAR_RECORD der IS-801 „Bereitstellen Mobilvorrichtung 600 Information" Nachricht, wie folgt:

1. GPS_ACQ_CAP und LOC_CALC_CAP des RESP_PAR_RECORD werden auf Werte gesetzt, die wie folgt beschrieben werden: GPS_ACQ_CAP (12 Bits) – Bit 4 (GPS Ephemeride) und Bit 7 (GPS autonome Erfassung verfügbar) werden auf „1" gesetzt, die anderen Bits werden auf „0" gesetzt, und
2. LOC_CALC_CAP (12 Bits) – Bit 5 (Ortsberechnung möglich unter Verwendung von Ephemeride) und Bit 7 (autonome Ortsberechnung möglich) werden auf "1" gesetzt, andere Bits werden auf "0" gesetzt.

Wenn der Rufprozessor 602 die ungefähre Position der mobilen Vorrichtung 600 auswählt über die IS-801, um Basisstationsalmanachdaten zu gewinnen, dann setzt der Rufprozessor 602 den REQ_PAR_RECORD der IS-801 „Anfragebasisstationalmanach" Nachricht wie folgt: EXT_BS_ALM (1 Bit) – auf 1 gesetzt.
Der Rufprozessor 602 sendet die IS-801 „Anfrage GPS Ephemeride" Nachricht, um die Ephemeridehilfsdaten zu gewinnen. Der Rufprozessor 602 setzt den REQ_PAR_RECORD der IS-801 „Anfrage GPS Ephemeride" Nachricht wie folgt: AB_PAR_REQ (1 Bit) – auf 1 gesetzt.
Nach Empfangen der „F" Schnittstellen „Positionsergebnis" Nachricht von dem GPS Modul 604 wandelt der Rufprozessor 602 die Positionsergebnisdaten in die IS-801 „Bereitstellung Ortsantwort" Nachricht wie folgt um:

1. TIME_REF_CDMA (14 Bits). Der Rufprozessor 602 wandelt die GPS Zeit in die CDMA Systemzeit. Die GPS Zeit wird definiert durch MEAS_GPS_WEEK und MEAS_GPS_SECONDS „F" Schnittstellen „Positionsergebnis" Nachricht. Der MEAS_GPS_WEEK ist eine erweiterte GPS Wochennummer und MEAS_GPS_SECONDS ist die verstrichene Zeit seit dem Beginn der gegenwärtigen GPS Woche in der Einheit 1/1000 Sekunden. Die CDMA Systemzeit wird definiert durch 1,2 der TIA/EIA-95-B. TIME_REF_CDMA sollte gesetzt sein auf (t/50) mod 16384, wie definiert in IS-801, wobei t die CDMA Systemzeit im Rahmen ist.
2. LAT (25 Bits) LAT = scale_factor_meas_lat × MEAS_LAT (Positionsergebnisnachricht) LAT ist in Einheiten von 180/2²⁵ und MEAS_LAT ist in Einheiten von 180/2³², folglich scale_factor_meas_lat = (180/2³²)/(180/2²⁵) = 1/2⁷;
3. LONG (26 Bits) LONG = scale_factor_meas_long × MEAS_LONG (Positionsergebnisnachricht). LONG ist in Einheiten von 360/2²⁶ und MEAS_LONG ist in Einheiten von (360/2³²), folglich scale_factor_meas_long = (360/2³²)/(360/2²⁶) = 1/2⁶;
4. LOC_UNCRTNTY_ANG (4 Bits), LOC_UNCRTNTY_A (5 Bits), LOC_UNCRTNTY_P (5 Bits). Wenn das Bit 0 (LSB) der OTHER_SECTIONS (Positionsergebnisnachricht) gleich "0" ist (kein Horizontalfehlerabschnitt in den Daten), dann LOC_UNCRTNTY_ANG = 0, LOC_UNCRTNTY_A '11111' (nicht berechenbar), LOC_UNCRTNTY_P = '11111' (nicht berechenbar);
5. FIX TYPE (1 Bit) wenn POS_TYPE (Positionsergebnisnachricht) = 0x00, dann FIX_TYPE = 0, wenn POS_TYPE = 0x01, dann FIX TYPE = 1;
6. VELOCITY_INCL (1 Bit), VELOCITY_HOR (9 Bits), VELOCITY_VER (8 Bits), HEADING (10 Bits) VELOCITY_INCL (IS-801, 1 Bit) = Bit 2 von OTHER_SECTIONS (Positionsergebnisnachricht); wenn VELOCITY_INCL = '1', VELOCITY_HOR = scale_factor_hv × HOR_VEL (Positionsergebnisnachricht) scale_factor_hv = 0,0625/0,25 = 0,25; HEADING = scale_factor_heading × HEADING (Positionsergebnisnachricht); scale_factor_heading = (360/2¹⁶)/(360/2¹⁰) = 2^–6; wenn VELOCITY_INCL = '1' und FIX_TYPE = '1', VELOCITY_VER (IS801, 8 Bits) = VER_VEL (Positionsergebnisnachricht); wenn VELOCITY_INCL = '0', dann ist IS-801 "Bereitstellungsortsantwort" sollte nicht VELOCITY_HOR, VELOCITY_VER und HEADING Parameter enthalten;
7. CLOCK_INCL (1 Bit), CLOCK_BIAS (18 Bits), CLOCK_DRIFT (16 Bits) CLOCK_INCL = Bit 3 von OTHER_SECTIONS (Positionsergebnisnachricht); wenn CLOCK_INCL = '1', CLOCK_BIAS = scale_factor_clk_bias × CLK_BIAS (Positionsergebnisnachricht) + offset_clk_bias; wobei scale_factor_clk_bias = 1e9; offset_clk_bias = 13.000 ns.
8. HEIGHT_INCL (1 Bit), HEIGHT (14 Bits) = HEIGHT_INCL = Bit 1 von OTHER_SECTIONS (Positionsergebnisnachricht); wenn HEIGHT_INCL = '1', HEIGHT = scale_factor_height × HEIGHT (Positionsergebnisnachricht) scale_factor_height = 0,1; und
9. LOC_UNCRTNTY_V (5 Bits), wenn HEIGHT_INCL = '1', LOC_UNCRTNTY_V = HEIGHT_STD_ER (Positionsergebnisnachricht).

Der Rufprozessor 602 empfangt die IS-801 "Bereitstellung Basisstationsalmanach" Nachricht von dem PDE in Antwort auf die IS-801 „Anfragebasisstationsalmanach". Diese Nachricht liefert eine Alternative zu dem IS-95 impliziten Verfahren, um die ungefähren Positionsdaten der mobilen Vorrichtung 600 zu erhalten.
Die Nachrichtenabbildung von der IS-801 „Bereitstellung Basisstationsalmanach" für „F" Schnittstelle" ungefähre Positionsantwort der Mobilvorrichtung 600" ist in diesem Abschnitt beschrieben. Die Feldnamen von der „F" Schnittstelle „ungefähre Positionsantwort der Mobilvorrichtung 600" Daten sind mit (F) gekennzeichnet. Die Feldnamen von IS-801 „Bereitstellung Basisstationsalmanach" sind gekennzeichnet mit (IS-801).
Die „Bereitstellung GPS Ephemeride" Nachricht liefert die Ephemeridedaten als Teil der PI2 Schnittstelledaten. In Abhängigkeit von der Größe des Ephemeridedatensatzes kann der PDE die IS-801 „Bereitsstellung GPS Ephemeride" in verschiedenen Teilen senden. Die Gesamtanzahl der Teile und die Teilnummer der Nachricht sind angegeben in den Elementen TOTAL_PARTS bzw. PART_NUM. Wenn der Rufprozessor 602 alle Teile der Ephemeridedaten empfängt, bildet er diese in die PI2 Struktur ab.
Im Betrieb interagiert der Rufprozessor 602 mit dem GPS Modul 604 über die „F" Schnittstellennachrichten. Der Rufprozessor 602 soll die PI2 Daten an das GPS Modul 604 senden, wann immer die Daten des neuen Rufprozessors 602 verfügbar sind (ohne Anfrage von dem GPS Modul 604). Es gibt keine Interaktion zwischen dem CP und dem GPS Modul 604 über die PI2 Schnittstelle.
Die IS-801 Sitzung des Rufprozessors 602 kann geöffnet werden, bevor das GPS Modul 604 eingeschaltet wird oder bevor die GPS Modul 604 Sitzung (gesetzt mit dem PI2 Schnittstellenflag) geöffnet wird. Die Sitzung des GPS Moduls 604 soll geschlossen sein, bevor die IS-801 Sitzung geschlossen wird. Wenn die IS-801 Sitzung geöffnet wird, soll der Rufprozessor 602 die PI2 Datenstruktur zurücksetzen.
Wenn die IS-801 Sitzung geöffnet wird, bevor das GPS Modul 604 mit Energie versorgt wird, wird die CDMA Systemzeit verfügbar, bevor der Rufprozessor 602 bereit ist den Zeittransfer mit dem GPS Modul 604 durchzuführen. In diesem Szenario kann der Rufprozessor 602 auch die ungefähren Positionsdaten der mobilen Vorrichtung 600 bekommen, bevor das GPS Modul 604 bereit ist die „F" Schnittstelle „ungefähre Positionsanfrage der Mobilvorrichtung 600" zu senden, und folglich wird die GPS Performance des GPS Moduls 604 mehr optimiert.
Der Rufprozessor 602 kann die ungefähre Position der mobilen Vorrichtung 600 entweder über das implizite IS-95 Verfahren (von IS-95 „Systemparameternachricht") oder die IS-801 Nachrichten erhalten. Das implizite IS-95 Verfahren wird als der schnellere Weg angesehen, um die BS Position zu erhalten, verglichen mit den IS-801 Nachrichten. Der IS-95 „Systemparameter" ist eine erforderliche Nachricht, die an den Rufprozessor 602 von der Basisstation zu senden ist, während des Leerlaufzustands der CDMA Mobilvorrichtung 600, unabhängig von der IS- 801 Sitzung. Andererseits erfordert IS-801 „Anfrage/Bereitstellung Basisstationsalmanach" nicht nur zwei interaktive Nachrichtenaustauschvorgänge, sondern auch das nicht aufgeweckt werden, bis die IS-801 Sitzung geöffnet ist.
Wenn der Rufprozessor 602 einen komplett neuen Satz von Ephemeridedaten von der Basisstation über das IS-801 Interface umgewandelt wird, werden die PI2 Daten als bereit betrachtet. Der Rufprozessor 602 soll die PI2 Daten an das GPS Modul 604 senden, weniger als zwei Sekunden nachdem die PI2 Daten bereit sind, ohne Anfrage von dem GPS Modul 604. Der Rufprozessor 602 soll periodisch die Basisstation abfragen, um die Ephemeridedaten mit einer Rate nicht länger als zwei Stunden zu senden. Je schneller die Rate, desto optimierter ist die GPS Performance.
Das GPS Modul 604 soll periodisch das Positionsergebnis des Rufprozessors 602 senden über die „F" Schnittstelle, basierend auf der Anzahl an Position-Fixes, wie in der PI2 Datenstruktur spezifiziert. Der Rufprozessor 602 soll die Anzahl an Positions-Fixes in der PI2 Struktur setzen, selbst wenn die Daten nicht verfügbar sind.
Bezugnehmend auf 7 zeigt 7 ein Blockdiagramm für eine mobile Vorrichtung 700 unter Verwendung einer FSM in einer GSM Umgebung. Die mobile Vorrichtung 700 enthält einen Rufprozessor 702 und ein GPS Modul 704, die in Signalkommunikation sind, über den Signalweg 706. Erneut kann der Signalweg 706 implementiert sein als eine RS232 Schnittstelle, eine logische Schnittstelle über gemeinsames Speicherverwenden von Softwaredatenstrukturen oder andere elektronische und/oder logische Schnittstellen. Der Rufprozessor 702 enthält ein Luftschnittstellen CP Modul 708, RRLP Nachricht für den PI2 Datenkonverter 710, eine GPS Modul PI2 Datenstruktur 712, einen PI2 Schnittstellennachrichten Assembler/Disassembler 714, einen CP/GPS Modulsystemnachrichtenprotokoll Assembler/Disassembler 716 und ein GPS Modulschnittstellenmodul 718. Das GPS Modul 704 enthält ein CP Schnittstellenmodul 720 ein PI2 Schnittstellenmodul 722, eine PI2 Datenstruktur 724, eine CP Systemschnittstellen FSM 726 und einen GPS Kern 728. Der GPS Kern 728 empfängt GPS Signale von der GPS Satellitenkonstellation 226 über einen Signalweg 732 und das Luftschnittstellen CP Modul 708 ist in Signalkommunikation mit der Basisstation (nicht gezeigt) über einen Signalweg 730.
Das Blockdiagramm der mobilen Vorrichtung 700 ist eine High-Level Architektur von PI2, um innerhalb des RRLP basierten Handsets implementiert zu werden (also ein GSM Basiszellulartelefon). Der Rufprozessor 702 kann mit dem GPS Modul 704 über einen Signalweg 706 und Hardwareleitungen (für die Zeit und Frequenztransfers) kommunizieren, wie in 7 beschrieben. Die F 736 und G 734 Schnittstellen sind zwei separate logische Kanäle für die RS 232 Schnittstelle 706. Die G Schnittstelle 734 kann designed sein, um die PI2 Hilfsdaten zu dem GPS Modul 704 zu geben. Der Rest der Hilfsdaten wird über die F Schnittstelle 736 zu dem GPS Modul 704 gegeben. Auf dem GPS Modul 704 kann die F Schnittstelle 738 eine standardmäßige GPS Clientschnittstelle sein (beispielsweise SiRFLoc von SiRF Technology, Inc.) und die G Schnittstelle 740 ist transparent für irgendwelche standardmäßigen Luftschnittstellenprotokolle. Der Rufprozessor 702 kann die PI2 Daten über das Luftschnittstellenprotokoll erzeugen zu einer RRLP Nachricht zu dem PI2 Datenkonverter 710. Die PI2 Daten werden in das G Nachrichtenformat gepackt über den PI2 Schnittstellennachrichten Paketierer/Depaketierer 712 (beispielsweise ein PI2 Schnittstellennachrichtenhandler), bevor sie über den Signalweg 706 zu dem GPS Modul 704 gegeben werden. Der Rufprozessor 702 kann die Zeit und Referenzortdaten von den ungefähren RRLP Luftschnittstellennachrichten erhalten und sie zu dem GPS Modul 704 geben über die entsprechenden F Schnittstellen 736 Nachrichten durch den CP/GPS Modulsystemnachrichtenprotokoll Paketierer/Depaketierer 716.
Die PI2 Schnittstelle kann verwendet werden von dem Rufprozessor 702 und dem GPS Modul 704 bekanntgegeben werden durch einen speziellen „Luftschnittstellen" Code in der Sitzungsöffnungsnachricht der F Schnittstelle 736. Anschließend kann sämtliche implizite Unterstützung (wie Zeittransfer, Frequenztransfer) über die F Schnittstelle 736 gesendet werden. Wenn verfügbar kann die ungefähre Position der mobilen Vorrichtung 700 von der Basisstation 518 gesendet werden, durch den Rufprozessor 702 an das GPS Modul 704 über die F Schnittstelle 736. Das GPS Modul 704 kann dann antworten mit einem Positionsbericht der mobilen Vorrichtung 700 über die F Schnittstelle 738.
Es sei erwähnt, dass die PI2 Schnittstelle typischerweise definiert wird durch eine große Datenstruktur, die als Speicherabschnitt (nicht gezeigt) implementiert werden kann. Im Allgemeinen hat die gesamte Information, die in der Schnittstelle vorhanden ist, eine vorbestimmte Position in dieser großen Datenstruktur. Um die Gültigkeit jedes Informationsstücks zu kennzeichnen kann auch ein Gültigkeitsflag mit jedem Feld in dieser Struktur verknüpft werden.
Die Übertragung der Information wäre dann ein „Lesen und Senden Byte für Byte" der vollständigen Struktur in einer vorbestimmten Reihenfolge (MSB zuerst, etc.). Die Clientseite kann eine ähnliche Datenstruktur aufweisen, und wird Byte für Byte aufgefüllt, sobald Information eintrifft. Ein einzelner Prüfsummentest kann für die gesamte Struktur durchgeführt werden, um diese zu validieren.
Es sei erwähnt, dass in einigen Fällen nicht alle Ephemeride validiert werden, und theoretisch kann die Nachricht verkürzt werden, indem nur die Ephemerideschlitze gesendet werden, die tatsächlich gültige Information aufweisen. Dies wird jedoch vorzugsweise vermieden, so dass der Speicherspiegelmechanismus nicht von der Bedeutung der Nachricht abhängt. Eine Art und Weise, um dies zu verhindern, ist das Wählen des Platzierens aller ungenutzten Felder (einschließlich der Validierungsfelder) auf einen Wert von „0". Ein einfacher Kompressionsmechanismus, ein Senden der Anzahl an aufeinanderfolgenden Bits, die auf Null gesetzt sind, anstatt der Bits selbst, könnte dann verwendet werden für den gleichen Zweck. Bei diesem Ansatz könnte ein Mechanismus ein eindeutiges spezielles Meta-Zeichen verwenden, vorausgehend ein festes Feld, das eine Anzahl von Wiederholungen von aufeinanderfolgenden Bits, die auf „0" gesetzt sind, angibt, anstelle der Bits selbst. In dieser Situation würden die Inhalte der Speicherspiegelstruktur streng gebildet aus Ephemerideinformation und möglichen ionisphärischen Parametern.
Fachleute auf diesem Gebiet erkennen, dass die F 736 und G 734 Schnittstelle über eine serielle Verbindung zwischen dem Rufprozessor 702 und dem GPS Modul 704 übertragen werden kann. Eine RS 232 ist als eine beispielhafte Implementierung lediglich dargestellt, und es soll verstanden werden, dass andere serielle Verbindungen äquivalent gut funktionieren. Zusätzlich, bei der Situation, bei der beide, der Rufprozessor 702 und das GPS Modul 704 auf dem gleichen Halbleiter-Die integriert sind, können viele andere Techniken zum Weitergeben der Daten zwischen dem Rufprozessor 702 und dem GPS Modul 704 verwendet werden, einschließlich, aber nicht einschränkend, das gemeinsame Verwenden eines Speichermoduls oder System (oder Subsystem)-Busses.
Als eine beispielhafte Implementierung der F und G Schnittstellen 736 und 734 kann die serielle Verbindung eine bidirektionale TTL-Levelkommunikationsschnittstelle sein, die verwendet wird für einen Austausch von Nachrichten zwischen dem Rufprozessor 702 und dem GPS Mo dul 704. Zwei Hardwareleitungen können verwendet werden für einen Zeit- und Frequenztransfer. Als ein Beispiel kann die PI2 Schnittstelle ein generisches Paketformat verwenden, wo ein TYPE_FIELD gleich „0x01" sein kann, entsprechend entweder einer „Luftschnittstellennachricht" oder einer „PI2 Nachricht". Um zu der PI2 Schnittstelle in einer Sitzungsöffnenanfragenachricht zu schalten, kann der Rufprozessor 702 das GPS Modul 704 benachrichtigen, dass es die Hilfsdaten in „PI2" senden soll, indem ein entsprechender Wert in einem „SESSION_OPEN_REQ_INFO" Format verwendet wird. Es sei erwähnt, dass neben „PI2" der Rufprozessor 702 und das GPS Modul 704 andere Luftschnittstellen unterstützen können, die in Echtzeit aktiviert werden können unter Verwendung des entsprechenden Werts für das „SESSION_OPEN_REQ_INFO" Feld.
Die PI2 Paketstruktur verwendet PI2 Segmente, die definiert werden können und sendet sie in einem PAYLOAD Feld, wie in der folgenden Tabelle gezeigt:

KOPF LÄNGE LOGIKKANAL PAYLOAD PRÜFSUMME TERMINATOR

MSG_ID SEGMENT

2 Bytes 2 Bytes 1 Byte 1 Byte M Bytes 2 Bytes 2 Bytes

Tabelle 1 – Beispielhafte PI2 Paketstruktur wobei MSG_ID der Nachrichtenidentifizierer ist, und SEGMENT das Nachrichtensegment ist.
Als ein Beispiel kann ein PI2 Segmentformat drei Felder enthalten, wie in Tabelle 2 gezeigt. Das erste Byte stellt die Gesamtanzahl an Segmenten dar, die für einen Transport der PI2 Nachricht verwendet werden. Das zweite Byte ist der Segmentindex, beginnend mit 1. Das letzte Feld stellt die komprimierten PI2 Daten dar, mit einer maximalen Größe von 1016 Byte.

PAYLOAD

MSG_ID SEGMENT

NUM_OF_SEGMENTS SEGMENT_INDEX COMPRESSED_A13_DATA

1 Byte 1 Byte 1 Byte <= 1016 Bytes

Tabelle 2 – PI2 Segmentformat wobei NUM_OF_SEGMENTS die Anzahl der Segemente ist, und die PI2 Daten können in verschiedenen Segmenten gesendet worden sein. Dieses Feld gibt die Gesamtanzahl von Segmenten für einen vollständigen Satz von PI2 Daten an. In diesem Fall ist 0 eine ungültige Nummer.
SEGMENT_INDEX ist der Segmentindex, und der Wert dieses Felds kann eine Sequenznummer des PI2 Datensegments sein, das durch diese Nachricht transportiert wird. Er reicht von 1 bis 255. Die letzte Nachricht des PI2 Datensatzes hat SEGMENT_INDEX gleich NUM_OF_SEGMENTS, und erneut ist 0 eine ungültige Nummer für dieses Feld.
COMPRESSED_PI2_DATA stellt komprimierte PI2 Daten dar, und dieses Feld kann ein Abschnitt der komprimierten PI2 Daten sein.
Jedes PAYLOAD Feld in einem PI2 Paket kann eine maximale Gesamtgröße von 1019 Byte haben, und folglich werden nur maximal 1018 Bytes in dem Segmentfeld transportiert. In diesem Beispiel hat jedes Segment einen 2-Byte Kopf, wenn die Größe der komprimierten PI2 Daten größer als 1016 Bytes ist, muss es segmentiert werden; jedes Segment soll sequentiell in einem separaten Paket gesendet werden.
Es sei erwähnt, dass in diesem Beispiel die Größe von einigen Nachrichten sehr groß sein kann. Als ein Beispiel, bei einer 9600 Baudrate kann es ungefähr 2,14 Sekunden dauern, bis die PI2 Datennachricht mit acht sichtbaren Ephemeridedaten und ohne Almanachdaten gesendet werden kann.
Zusätzlich, sind nicht alle Daten in einer Nachricht gültig, was bedeutet, dass es viele Felder gibt, die auf 0 gesetzt sind. Ein einfacher Datenkomprimierungsalgorithmus sollte signifikant die Größe der Daten, die zu senden sind, reduzieren. Der Datenkomprimierungsalgorithmus kann von einem verlustfreien Typ von Kompression sein und kann Bytestreams (Byteströme) manipulieren bezüglich der Bedeutung der Bytes.
Der Datenkompressionsalgorithmus, der für alle PI2 Nachrichten angewendet wird, kann ein „Packbits" Verfahren sein, das eine einfache und populäre Variante des Lauflängencodie rungsverfahrens ist. Ein Lauf ist eine Gruppe von identischen aufeinanderfolgenden Zeichen.
Jeder Lauf wird als ein 2-Byte Kopf codiert, der beschreibt welche Art von Lauf vorliegt und dessen Länge, und ein oder mehrere Bytes, die die Daten enthalten. In allen Fällen kann der Kopf in zwei Abschnitte gesplittet werden: Sein MSB beschreibt, ob ein wörtlicher Lauf (nicht komprimiert) oder ein Fülllauf (komprimiert) vorliegt, und die nächsten 15 Bits spezifizieren die Länge des Laufs, wie in Tabelle 3 gezeigt.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

RUN_INDICATOR_BIT 0 = nicht komprimiert 1 = komprimiert LÄNGE (Bytes)

Tabelle 3 – RLL Komprimierungs-Kopf Format
In diesem Beispiel ist ein wörtlicher Lauf ein Lauf von wörtlichen Bytes (also Bytes, die gespeichert werden anstatt komprimiert zu werden). In diesem Fall ist RUN_INDICATOR_BIT gleich 0 und weniger als 15 Bits spezifizieren die Länge des Laufs der wörtlichen Bytes. Die wörtlichen Bytes können dann direkt nach diesem Kopf codiert werden.
Ein Fülllauf ist eine Sequenz von Bytes, bei dem alle Bytes identisch sind. In diesem Fall ist RUN_INDICATOR_BIT gleich 1 und weniger als 15 Bits spezifizieren die Länge des Laufs. Der Kopf wird gefolgt von einem Byte, das die gegebene Anzahl an Zeitpunkten kopiert werden soll. Ein Beispiel ist gegeben, wie es folgt, um zu zeigen, wie der Datenkompressionsalgorithmus arbeiten kann.
Ursprungsbytestream: 0x01 0xFF 0x00 0x89 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x12.
Nach der Komprimierung: 0x00 0x04 0x01 0xFF 0x00 0x89 0x80 0x07 0x00 0x00 0x01 0x12.
Ein beispielhafter Datendekomprimierungsalgorithmus sollte ebenfalls einfach sein. Das GPS Modul 704 würde das RUN_INDICATOR_BIT und die Länge bekommen. Wenn der RUN_INDICATOR_BIT gleich 0 ist, werden lediglich die nächsten LENGTH Bytes kopiert.
Wenn der RUN_INDICATOR_BIT gleich 1 ist, sollte das nächste kommende Byte „LENGTH" oft kopiert werden. Beispielsweise:
Komprimierte Daten: 0x80 0x08 0x00 0x00 0x05 0x44 0x00 0x01 0x66 0x45.
Nach der Dekomprimierung: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x44 0x00 0x01 0x66 0x45.
Abgesehen von ACK/NACK/ERROR Nachrichten können die PI2 Nachrichten eine vorbestimmte Position in einer großen Struktur aufweisen. Um die Gültigkeit jedes Informationsstücks zu validieren kann auch ein Validierungsflag zugewiesen werden zu jeder Gruppe von Information in dieser Struktur. Die spezielle Anordnung kann gewählt werden, um die Umwandlung dieses Protokolls als ein gemeinsam verwendeter Speicher zwischen Aufgaben auf einem gleichen Prozessor zu erleichtern. Für jetzt kann das PI2 Protokoll speziell designed sein, um über eine serielle Verbindung verwendet zu werden, zwischen zwei separaten Prozessoren.
Als ein Beispiel kann eine PI2 Anfrage streng gebildet sein aus einer Positionsanfrageinformation, ionisphärischen Parametern, Erfassungshilfsdaten, Satellitenephemeride und Almanach. Andere Hilfsdaten, die über das Luftschnittstellenprotokoll empfangen werden, können an das GPS Modul 704 über die F Schnittstelle 736 geliefert werden (beispielsweise ungefährer Benutzerort, Zeit- und Frequenztransfer).
In diesem Fall kann die gesamte Information, die in der PI2 Anfrage präsentiert wird, eine vorbestimmte Position in einer großen Struktur haben. Um die Gültigkeit jedes Informationsstücks zu validieren kann auch ein Validierungsflag jeder Gruppe von Information in dieser Struktur zugeordnet werden.
Die PI2 Anfrage und die Antwort können als große Datenstrukturen definiert werden. Diese Nachrichten können implementiert werden, indem ein Speicherspiegelmechanismus verwendet wird. Für jede Nachricht wird die gleiche Speicherstruktur definiert auf der Seite des Rufprozessors 702 und der Seite des GPS Moduls 704. Ein Satz von Speicher kann pro Richtung definiert werden.
Die Übertragung der Information kann ein „Lesen, Kompression und Sendung Byte-für-Byte" der vollständigen Struktur auf der Sendeseite sein. Die gleiche Datenstruktur auf der Empfangsseite kann Byte-für-Byte aufgefüllt werden, sobald die Information ankommt und dekomprimiert ist.
Der Rufprozessor 702 kann die PI3 Anfragenachricht beim Öffnen der „PI2" Sitzung senden, selbst wenn die PI2 Datenstruktur nicht aktualisiert worden ist. Das GPS Modul 704 kann die Validierungsflags in der Datenstruktur selbst verwenden, um zu bestimmen, welche Information relevant ist.
Typischerweise kann weder das GPS Modul 704 noch der Rufprozessor 702 irgendeine PI2 Nachricht senden, bevor ein Sitzungsöffnen-Anfrage/Antwort-Paar vom „RI2" Typ oder nachdem ein Sitzungsschließen-Anfrage/Antwort-Paar über die F Schnittstelle 736, 738 ausgetauscht worden sind. Wenn die Sitzung identifiziert worden ist als vom „PI2" Typ, sollen die PI2 Nachrichten ausgetauscht werden.
Für jede empfangene Nachricht wird typischerweise eine ACK/NACK/ERROR Nachricht zurückgegeben, um die Wiederholung der Nachricht zu beschleunigen, wenn sie falsch empfangen worden ist. Dieser Mechanismus wird vorzugsweise auf einer lokalen seriellen Verbindung verwendet, und hat keinen starken Fehlerdetektions- und Korrekturmechanismus.
Als ein Beispiel können die GPS Modul 704 Empfangsprozeduren folgende Schritte enthalten. Zuerst, bei Empfang einer PI2 Anfragenachricht nach einem Öffnen einer PI2 Sitzung, kann das GPS Modul 204 die empfangene PI2 Nachricht untersuchen. Wenn die PI2 Nachricht in verschiedenen Paketen transportiert wird, baut das GPS Modul 704 die segmentierten Daten erneut auf. Nach dem Empfangen aller Pakete einer PI2 Nachricht, zerlegt das GPS Modul 704 kollektiv die neu aufgebauten Daten und kopiert sie in die Struktur auf der Seite des GPS Moduls 704. Zweitens, bei Empfangen einer PI2 Nachricht vor dem Öffnen einer PI2 Sitzung, sollte das GPS Modul 704 leise die Nachricht verwerfen. Drittens, wenn die Segmentdaten fehlen, wird die gesamte Nachricht verworfen.
Ähnlich, kann ein Beispiel einer Sendeprozedur des GPS Moduls 704 die folgenden Schritte aufweisen. Zuerst, bei Empfang einer PI2 Anfragenachricht mit POS_REQ_FLAG auf 1 gesetzt, untersucht das GPS Modul 704, ob das angeforderte Ortsverfahren unterstützt wird. Wenn LOCATION_METHOD auf 0x00 oder 0x03 gesetzt ist, und das GPS Modul 704 nicht die angeforderten Ortsverfahren (das Ortsverfahren) unterstützt, sendet das GPS Modul 704 eine PI2 Antwortnachricht mit GPS_MEAS_FLAG auf „1” gesetzt (gültiger GPS Messabschnitt) und MEAS_ERROR_STATUS auf „angefordertes Ortsverfahren nicht unterstützt". Wenn LOCATION_METHOD auf 0x01 oder 0x02 gesetzt ist, unterstützt das GPS Modul 704 nicht das oder die angeforderten Ortsverfahren, das GPS Modul 704 sendet eine PI2 Antwortnachricht mit POSITION_RESULTS_FLAG auf „1" (gültiger Positionsabschnitt) gesetzt und mit POSITION_ERROR_STATUS gesetzt auf „angeforderte Ortsverfahren nicht unterstützt".
Für ein unterstütztes Ortsverfahren einer mobilen Vorrichtung 700, unabhängig von der Zeit, die gesetzt ist durch das MAX_RESP_TIME Feld, das in der PI2 Anfragenachricht gefunden wird, sendet bei genügend gültigen GPS Messungen das GPS Modul 704 eine PI2 Antwortnachricht, die die GPS Messungen bereitstellt, mit dem GPS_MEAS_FLAG auf „1" gesetzt (gültiger GPS Messabschnitt) und mit MEAS_ERROR_STATUS auf „0" gesetzt (gültige GPS Messungen).
Zusätzlich für ein mobiles Vorrichtung 700 basiertes Ortsverfahren, bei Zeitablauf des MAX_RESP_TIME Felds, das in der PI2 Anfrage gefunden wird, und bei noch keinem Positions-Fix soll das GPS Modul 704 eine PI2 Antwortnachricht senden mit dem POSITION_RESULTS_FLAG auf „1" (gültiger Positionsabschnitt) und dem POSITION_ERROR_STATUS auf „brauche mehr Zeit" gesetzt.
Ähnlich, für ein mobilvorrichtungs 700 unterstütztes Ortsverfahren, bei Zeitablauf des MAX_RESP_TIME Felds, das in der PI2 Anfragenachricht gefunden wird, und bei noch keinen gültigen GPS Messungen, soll das GPS Modul 704 eine PI2 Antwortnachricht senden mit GPS_MEAS_FLAG auf „1" gesetzt (gültiger GPS Netzabschnitt) und mit MEAS_ERROR_STATUS auf „brauche mehr Zeit" gesetzt.
Für ein mobiles vorrichtungs 700 basiertes Positionsbestimmungsverfahren, bei Erreichen des Endes des GPS Suchbereichs, und mit keiner Position gefunden, sendet das GPS Modul 704 eine PI2 Antwortnachricht mit POSITION_RESULTS_FLAG auf „1" gesetzt (gültiger Positionsabschnitt) und mit POSITION_ERROR_STATUS auf „kein Fix verfügbar nach vollständiger Suche".
Für ein MS unterstütztes Positionsbestimmungsverfahren, bei Erreichen des Endes des GPS Suchraums, und mit nicht genügend gültigen GPS Messungen, sendet das GPS Modul 704 eine PI2 Antwortnachricht mit GPS_MEAS_FLAG auf „1" gesetzt (gültiger GPS Messabschnitt) und mit MEAS_ERROR_STATUS auf „nicht genügend Satelliten verfolgt" gesetzt.
Wenn das GPS Modul 704 mehr Ephemeridehilfsdaten benötigt, kann das GPS Modul 604 eine PI2 Antwortnachricht senden mit POSITION_RESULTS_FLAG auf „1" gesetzt (gültiger Positionsabschnitt) und mit POSITION_ERROR_STATUS auf „GPS Hilfsdaten fehlen" gesetzt.
Wenn das GPS Modul 704 mehr Erfassungshilfsdaten benötigt, sendet das GPS Modul 704 eine PI2 Antwortnachricht mit GPS_MEAS_FLAG auf „1" gesetzt (gültiger GPS Messabschnitt) und mit MEAS_ERROR_STATUS auf „GPS Hilfsdaten fehlen" gesetzt.
Optional und gemäß Kriterien, die von Fall zu Fall zu definieren sind, kann das GPS Modul 704 einen Almanachreferenzdatumsabschnitt in irgendeiner PI2 Antwortnachricht hinzufügen. Diese Fähigkeit ermöglicht es dem Rufprozessor 702 das Alter der Almanachdaten in dem GPS Modul 704 zu evaluieren, und möglicherweise mit neueren durch eine PI2 Anfragenachricht zu ersetzen.
Beispiele von Rufprozessor 702 Empfangsprozeduren enthalten bei Empfang einer Luftschnittstellenprotokollnachricht (oder einer Gruppe davon), der Rufprozessor 702 füllt (während er neu formatiert wird, falls notwendig) die relevanten Felder der „PI2 Datenstruktur" auf der Seite des Rufprozessors 702, unter Verwendung der empfangenen Luftschnittstellennachrichteninformation. Wenn eine PI2 Sitzung gegenwärtig geöffnet ist, soll der Rufprozessor 702 die PI2 Anfragenachricht senden, wenn die Information oder ein Teil davon in der Struktur des Rufprozessors 702 ohne irgendeine Anfrage aktualisiert worden ist.
Bei Empfang einer PI2 Antwortnachricht prüft der Rufprozessor 702 die empfangene PI2 Nachricht. Wenn die PI2 Nachricht in verschiedenen Paketen transportiert wird, baut der Rufprozessor 702 die segmentierten Daten erneut zusammen. Nach einem korrekten Empfangen an Pakete einer PI2 Nachricht, dekomprimiert der Rufprozessor 702 die erneut zusammengebauten Daten und kopiert sie in die Struktur auf der Seite des Rufprozessors 702.
Bei Empfangen einer PI2 Nachricht, bevor eine PI2 Sitzung geöffnet ist, verwirft der Rufprozessor 702 die Nachricht. Wenn segmentierte Daten fehlen wird die gesamte Nachricht verworfen.
Als ein Beispiel von Sendeprozeduren des Rufprozessors 702, innerhalb von 2 Sekunden nach dem die Sitzungsöffnungsbenachrichtigungsnachricht mit dem SESSION_OPEN_STATUS Feld auf Sitzung erfolgreich geöffnet gesetzt empfangen worden ist, startet der Rufprozessor 702 das Senden der PI2 Anfragenachricht unabhängig davon, ob sie gültige Hilfsinformation enthält oder nicht. Die PI2 Anfrage wird komprimiert und nur der komprimierte Strom wird an das GPS Modul 704 gesendet. Wenn die Größe des komprimierten Datenstroms größer als das Maximum ist, kann er in verschiedene Datenpakete segmentiert werden. Die Datenpakete werden dann sequentiell in der Reihenfolge ihrer Segmentierung gesendet.
Beispielhafte Ausnahmeprozeduren für die PI2 Anfragenachricht von dem Rufprozessor 702 an das GPS Modul 704 enthalten eine auf der Seite des Rufprozessors 702, wenn der Rufprozessor 702 eine PI2 Anfragenachricht sendet, erwartet der Rufprozessor 702 eine ACK/NACK/ERROR Nachricht zurück von dem GPS Modul 704 innerhalb von drei Sekunden nach dem Senden der Nachricht.
Wenn der Rufprozessor 702 innerhalb von drei Sekunden nichts empfangt, sendet er erneut die PI2 Anfragenachricht. Der Rufprozessor 702 kann die Sequenz bis zu drei Mal wiederholen. Nach der dritten Wiederholung schließt der Rufprozessor 702 den PI2 Kanal.
Wenn der Rufprozessor 702 eine ACK/NACK/ERROR Nachricht mit dem ACK/NACK/ERROR Feld auf 0xFE gesetzt, empfängt, schließt der Rufprozessor 702 den PI2 Kanal.
Wenn der Rufprozessor 702 eine ACK/NACK/ERROR Nachricht mit dem ACK/NACK/ERROR Feld auf 0xFF gesetzt, empfängt, sendet der Rufprozessor 702 sofort die gleiche Nachricht erneut. Nach drei Wiederholungen schließt der Rufprozessor 702 den PI2 Kanal. Ähnlich auf der Seite des GPS Moduls 604, sobald das GPS Modul 704 die Nachricht von dem Rufprozessor 702 empfängt und die Nachricht korrekt dekodiert, prüft das GPS Modul 704 des Wert des ICD_REV_NUM Felds. Dann kann das GPS Modul 704 eine ACK/NACK/ERROR Nachricht senden, mit dem ACK/NACK/ERROR Feld auf 0x00 gesetzt, innerhalb von 3 Sekunden nach dem Empfang. Alternativ kann das GPS Modul 704 eine ACK/NACK/ERROR Nachricht innerhalb von 3 Sekunden des Empfangs senden, mit dem ACK/NACK/ERROR Feld auf 0xFE gesetzt. Wenn die Nachricht nicht korrekt dekodiert werden kann, sendet das GPS Modul 704 eine ACK/NACK/ERROR Nachricht innerhalb von 3 Sekunden, mit dem ACK/NACK/ERROR Feld auf 0xFF gesetzt.
Wenn Segmente der gleichen Nachricht außer Reihenfolge empfangen werden, wirft das GPS Modul 704 die bereits empfangenen Segmente weg, ignoriert die verbleibenden Segmente und sendet eine ACK/NACK/ERROR Nachricht mit dem ACK/NACK/ERROR-Feld auf OFF gesetzt innerhalb von 3 Sekunden.
Zusätzlich, für eine PI2 Antwortnachricht, die von dem GPS Modul 704 an den Rufprozessor 702 gesendet worden ist, erwartete das GPS Modul 704 eine ACK/NACK/ERROR Nachricht zurück von dem Rufprozessor 702 innerhalb von 3 Sekunden nach dem Senden der Nachricht. Wenn das GPS Modul 70 innerhalb von 3 Sekunden nichts empfängt, sendet das GPS Modul 704 erneut die PI2 Antwort. Es kann die Sequenz bis zu drei Mal wiederholen. Nach der dritten Wiederholung stoppt das GPS Modul 704 das Senden der Nachricht. Wenn das GPS Modul 704 eine ACK/NACK/ERROR Nachricht empfängt, mit dem ACK/NACK/ERROR Feld auf 0xFF gesetzt, sendet das GPS Modul 704 sofort die gleiche Nachricht erneut. Nach drei Wiederholungen stoppt das GPS Modul 704 das Senden der Nachricht.
Auf der Seite des Rufprozessors 702, sobald der Rufprozessor 702 die Nachricht von dem GPS Modul 704 empfängt und sie korrekt dekodiert, sendet der Rufprozessor 702 eine ACK/NACK Fehlernachricht innerhalb von 3 Sekunden nach dem Empfang, mit dem ACK/NACK Feld auf 0x00 gesetzt. Wenn die Nachricht nicht korrekt dekodiert werden kann, sendet der Rufprozessor 702 eine ACK/NACK/ERROR Nachricht innerhalb von 3 Sekunden, mit dem ACK/NACK/ERROR Feld auf 0xFF gesetzt. Nach drei Wiederholungen stoppt das GPS Modul 704 das Senden der Nachricht. Wenn Segmente der gleichen Nachricht in falscher Reihenfolge empfangen werden, schmeißt der Rufprozessor 702 die Segmente, die bereits empfangen worden sind, weg, ignoriert die verbleibenden Segmente und sendet ACK/NACK/ERROR-Nachricht innerhalb von 3 Sekunden, mit dem ACK/NACK/ERROR Feld auf 0xFF gesetzt.
Das System kann auch spezielle Prozeduren enthalten, wie beispielsweise das Aktualisieren der Almanach im Flash vom Netzwerk. Diese beispielhafte Prozedur wird verfolgt, wenn der Rufprozessor 702 gültige Almanachdaten von dem Netzwerk empfangen hat und die Almanachdaten in dem Flash des GPS Moduls 704 aktualisieren will: 1) der Rufprozessor 702 sendet eine „PI2 Anfragenachricht" mit dem ALM_REQ_FLAG auf „0" gesetzt, und mit dem ALM_DATA_FLAG auf „1" gesetzt, und gültige Almanachinformation in dem Almanachabschnitt; 2) das GPS Modul 704 speichert die Almanachdaten in dem RAM sobald es die PI2 Anfragenachricht bekommt; und 3) wenn der Rufprozessor 702 die PI2 Sitzung von der F-Schnittstelle 736 schließt, überträt das GPS Modul 704 die Almanachinformation von dem RAM zum FLASH.
Wenn der Transfer der Almanachdaten von dem RAM zum FLASH erfolgreich war, wird SESSION_CLOSE_STATUS in „Sitzung geschlossen Benachrichtigungsnachricht" schließe Sitzung in der F Schnittstelle 736 auf „Sitzung geschlossen" gesetzt. Wenn der Transfer der Almanachdaten von dem RAM zum FLASH fehlschlägt wird SESSION_CLOSE_STATUS in „Sitzungsschließenbenachrichtigungsnachricht" schließe Sitzung in der F Schnittstelle auf „Sitzung schließen fehlgeschlagen" gesetzt.
Das System kann auch spezielle Prozeduren enthalten, wie beispielsweise das Aktualisieren der Almanachdaten im Almanach von einem Satelliten („SV"). Die Folgende Prozedur wird verfolgt, wenn der Rufprozessor 702 das GPS Modul 704 zwingen will neue Almanachdaten zu sammeln und die Almanachdaten in dem Flash des GPS Moduls 704 mit dem gesammelten Almanachinformationen zu aktualisieren:

1) Der Rufprozessor 702 sendet eine PI2 Anfragenachricht mit ALM_REQ_FLAG auf „2" gesetzt (Anfragealmachnachsammlung von SV), und ALM_DATA_FLAG auf „0” gesetzt und keinen Almanachabschnitt;
2) Bei Empfang versuch das GPS Modul 704 Almanachdaten von dem Broadcast zu sammeln;
3) Um den Fortschritt zu prüfen sendet der Rufprozessor 702 periodisch eine PI2 Anfragenachricht mit ALM_REQ_FLAG auf „3" gesetzt (Bericht über Almanachaktualisierungsstatus). Bei Empfang der Aktualisierungsstatusanfragenachricht soll das GPS Modul 704 sofort eine PI2 Antwortnachricht senden mit: ALM_DATA_STATUS auf „1" gesetzt, wenn SLC nach Satelliten sucht und keine NAV Nachricht sammelt; ALM_DATA_STATUS auf „2" gesetzt, wenn das GPS Modul 704 mindestens einen Satelliten verfolgt, der stark genug ist, um Daten zu sammeln und sammelt tatsächlich Daten; ALM_DATA_STATUS auf „3" gesetzt, wenn das GPS Modul 704 durch eine volle Suchsequenz gegangen ist und keinen Satelliten gefunden hat, der für ein Datensammeln geeignet ist; und ALM_DATA_STATUS auf „4" gesetzt, wenn das GPS Modul 704 ein volles Almanach gesammelt hat und ALM_WEEK_NUMBER und TOA entweder von dem im RAM gespeicherten oder in dem FLASH gespeicherten Almanach.
4) Wenn der Rufprozessor 702 die PI2 Sitzung von der F Schnittstelle 736 schließt, überträgt das GPS Modul 704 Almanachinformation von dem RAM zum FLASH. Wenn der Transfer der Almanachdaten von dem RAM zum FLASH erfolgreich gewesen ist, wird SESSION_CLOSE_STATUS in „Sitzung schließen Benachrichtigungsnachricht" schließe Sitzung in F Schnittstelle 736 auf „Sitzung geschlossen" gesetzt.

Wenn der Transfer der Almanachdaten von dem RAM zu dem FLASH fehlschlägt, wird SESSION_CLOSE_STATUS in „Sitzungsschließenbenachrichtigungsnachricht" schließe Sitzung in der F Schnittstelle auf „Sitzung schließen fehlgeschlagen" gesetzt. Wenn kein volles Almanach während der Sitzung gesammelt worden ist (und der ALM_DATA_STATUS nie bei „4" während Schritt 3 gefunden wurde), versucht das GPS Modul 704 erneut den Transfer des unvollständigen Almanach von dem RAM zu dem FLASH. Der SESSION_CLOSE_STATUS in der „Sitzungsbenachrichtigungsnachricht" wird auf „Sitzung geschlossen" gesetzt. Ein voller Almanachsammelzyklus dauert im Allgemeinen weniger als 13 Minuten. Der Rufprozessor 702 sollte nicht erwarten ein ALM_DATA_STATUS auf „4" gesetzt zu empfangen, bevor eine derartige Zeit verstrichen ist, seit dem ersten Mal, bei dem der ALM_DATA_STATUS bei „2" gesetzt gefunden wurde.
Wenn eine PI2 Sitzung offen ist, kann der Rufprozessor 702 zu jedem Zeitpunkt prüfen, welches Alter das Almanach aufweist, das gegenwärtig im Flash ist. Der Rufprozessor 702 sendet eine PI2 Anfragenachricht mit ALM_REQ_FLAG auf „1" gesetzt, und mit ALM_DATA_FLAG auf „0" gesetzt und ohne Almanachabschnitt. Bei Empfang des Alters der Almanachanfragenachricht soll das GPS Modul 704 sofort eine PI2 Antwortnachricht senden mit ALM_DATA_STATUS auf „0" gesetzt und ALM_WEEK_NUMBER und TOA von dem FLASH-gespeicherten Almanach. Wenn der Rufprozessor 702 eine PI2 Anfragenachricht sendet mit beiden, den POS_REQ Flag und ALM_REQ_FLAG auf „1" gesetzt, wird die Antwort undefiniert.
8 zeigt ein Beispiel von RRLP zu dem PI2 Nachrichtenflussdiagramm 800 zwischen einer Geolokations-Server-Station 802, einen Rufprozessor 804 und ein GPS Modul 806. 8 zeigt graphisch den vorher beschriebenen Prozess.
9 zeigt ein Beispiel des PI2 Nachrichtenflussdiagramms 900 zwischen einem Rufprozessor 902, dem GPS Modul 904 und einer Basisstation („BS") 906. Der Rufprozessor 902 enthält einen Basisstationsschnittstellenhandler 908, einen PI2 Konverter 910, einen F Schnittstellenhandler 912 und einen G Schnittstellenhandler 914. 9 zeigt graphisch den oben beschriebenen Prozess.
Obwohl verschiedene Ausführungsbeispiele der Erfindung beschrieben worden sind, ist es für einen Fachmann auf diesem Gebiet selbstverständlich, dass viel mehr Ausführungsbeispiele und Implementierungen möglich sind, ohne den Bereich dieser Erfindung zu verlassen.

Claims

Protokollunabhängige Schnittstelle zum Verarbeiten, innerhalb einer Mobilvorrichtung, die ein GPS-Modul (522) und einen Rufprozessor (520) aufweist, von GPS-Hilfsdaten, die mit einer GPS-Schnittstelle an dem Rufprozessor (520) empfangen werden, wobei die GPS-Hilfsdaten gemäß irgendeinem von mehreren Geolokations-Server-Stations(512)-Protokollen erzeugt werden, wobei die protokollunabhängige Schnittstelle aufweist: ein Mittel zum Empfangen der GPS-Hilfsdaten, die an dem Rufprozessor (520) empfangen werden, an der GPS-Schnittstelle; ein Mittel zum Umwandeln der empfangenen GPS-Hilfsdaten in Schnittstellendaten, die für die mehreren Geolokations-Server-Stations(512)-Protokolle transparent sind, durch Übersetzen der empfangenen GPS-Hilfsdaten von dem Geolokations-Server-Stations(512)-Protokoll in ein unabhängiges Protokoll, das von dem GPS-Modul (522) verwendet wird; und ein Mittel zum Weitergeben der Schnittstellendaten an das GPS-Modul (522).
Schnittstelle nach Anspruch 1, ferner enthaltend ein Packen der Schnittstellendaten in ein Nachrichtenformat, bevor die Schnittstellendaten an das GPS-Modul (522) weitergegeben werden.
Schnittstelle nach Anspruch 1 oder 2, wobei der Rufprozessor (522) die GPS-Hilfsdaten von einer Basisstation (508) empfangt.
Schnittstelle nach einem der Ansprüche 1 bis 3, wobei eine Geolokations-Server-Station (512) die GPS-Hilfsdaten erzeugt.
Schnittstelle nach Anspruch 4, wobei die Geolokations-Server-Station (512) eine CDMA (Code Division Multiple Access) Protokoll verwendet, um die GPS-Hilfsdaten zu erzeugen.
Schnittstelle nach Anspruch 5, wobei das Protokoll gleich IS-801 ist.
Protokollunabhängige Schnittstelle nach einem der Ansprüche 1 bis 6, ferner enthaltend: eine GPS-Moduldatenstruktur.
Mobilvorrichtung, enthaltend: einen Rufprozessor (520); und ein GPS-Modul (522), gekennzeichnet durch ferner eine protokollunabhängige Schnittstelle (524) gemäß einem der Ansprüche 1 bis 7.
Verfahren zum Verarbeiten, innerhalb einer Mobilvorrichtung, die ein GPS-Modul (522) und einen Rufprozessor (520) aufweist, von GPS-Hilfsdaten, die mit einer GPS-Schnittstelle an dem Rufprozessor (520) empfangen werden, wobei die GPS-Hilfsdaten gemäß einem von einer Mehrzahl von Geolokations-Server-Stations(512)-Protkollen erzeugt werden, wobei das Verfahren aufweist: Empfangen der GPS-Hilfsdaten, die an dem Rufprozessor (520) empfangen werden, an der GPS-Schnittstelle; Umwandeln der empfangenen GPS-Hilfsdaten in Schnittstellendaten, die für die Mehrzahl der unterschiedlichen Geolokations-Server-Stations(512)-Protokolle transparent sind, durch Übersetzen der empfangenen GPS-Hilfsdaten von dem Geolokations-Server-Stations(512)-Protokoll in ein unabhängiges Protokoll, das von dem GPS-Modul (522) verwendet wird; und Weiterleiten der Schnittstellendaten an das GPS-Modul (522).