DGPS/RTK-Dienste über Internet

Transkript

1 SAPOS Georg Weber, Bundesamt für Kartographie und Geodäsie (BKG), Frankfurt Einleitung Die Nutzung des Internet für die kontinuierliche Übertragung schwacher Datenströme ist nicht neu. Diese Technik wird seit längerem vielfältig für Fernsteuerungsaufgaben eingesetzt im Zusammenhang mit der Kontrolle vernetzter Arbeitsprozesse. Mit der zunehmenden Bandbreite des Internet sind in den letzten Jahren anspruchsvollere Anwendungen wie Internet-Radio hinzu gekommen, die Bandbreiten zum Teil deutlich oberhalb 10 kbit/s benötigen. DGPS-Positionierung (Differential GPS) mit Metergenauigkeit über Internet sowie RTK-Positionierung (Real Time Kinematik) mit Zentimetergenauigkeit über Internet sind Entwicklungen, die erstmals 1999 in kleinem exemplarischen Rahmen zur Verfügung gestellt wurden [1]. Hier werden Korrekturdaten im RTCM-Format als kontinuierliche Datenströme unter Einschluss des Internet von Referenzstationen hin zu mobilen Nutzern transportiert. Der Bedarf an Bandbreite ist dabei, insbesondere DGPS betreffend, mit etwa 50 byte/s vergleichsweise gering. Dieser Beitrag erläutert einige Grundzüge der Technik und behandelt Aspekte der Einführung entsprechender Dienste in Deutschland und benachbarten Ländern. Das Prinzip Die Generierung von RTCM-Korrekturdaten erfolgt im einfachsten Fall unmittelbar im GPS-Empfänger einer Referenzstation, kann aber auch aus der Vernetzung von Beobachtungen einer Anzahl von Referenzstationen hergeleitet werden. Der erzeugte Datenstrom (siehe Abbildung 1) wird einem Server zugeführt, der die Korrekturen unter Verwendung eines geeigneten Protokolls auf dem Internet zugänglich macht. Ein mobiler Nutzer schafft sich Zugang zum Internet über Mobilfunk. Er verwendet ein Client-Programm, das die vom Server erhaltenen Korrekturdaten an einen GPS-Empfänger weiterreicht. Die Strecke zwischen dem Server mit der angeschlossenen Referenzstation und dem Client mit der angeschlossenen Roverstation wird damit in zwei Teile zerlegt. Der größere Teil der Strekke besteht aus einer Internet-Verbindung, ein verbleibender kleinerer Teil wird mittels Mobilfunktechnik überbrückt. Abb. 1: DGPS-Datenstrom auf dem Internet (Abb. 1, 2 und 7 entnommen [2]) 54

2 Aus der Sicht eines Providers von DGPS/RTK-Korrekturdaten zeigt die Verwendung des Internet einige deutliche Vorteilen. Im Vergleich zur direkten Abgabe von Korrekturen an einen Mobilfunkknoten entfällt die Notwendigkeit zum Betrieb eigener Access-Server. Die Zuständigkeit des Providers endet mit der Abgabe der Korrekturdaten an das Internet. Es entfällt das Vorhalten von Einwahlknoten. Mit welcher Technik der Nutzer eines DGPS/RTK-Dienstes die Korrekturdaten dem Internet entnimmt (GSM, GPRS, EDGE, UMTS etc.), liegt außerhalb der Providerzuständigkeit. Dieser Bereich wird den Anbietern geeigneter Kommunikationstechnik überlassen. Das Internet ist als offenes Netz ausgezeichnet geeignet zum Transfer von Daten zwischen verschiedenen Providern über größere Entfernungen. Leicht lassen sich länderübergreifend europaweit einheitliche Strukturen schaffen. Allerdings sind die erforderlichen Server mit einer ausreichenden Bandbreite an das Internet anzubinden, was abhängig von der Anzahl der zu bedienenden Nutzer, entsprechende Betriebskosten erfordert. Transport- und Protokollfragen Bei der Paketweisen Übertragung von RTCM-Daten auf dem Internet ist zunächst das Transportprotokoll von erheblicher Bedeutung. Das TCP-Protokoll ermöglicht einen kontrollierten Transport von Informationen zwischen Sender und Empfänger. Beim Transfer von Daten mit dem UDP-Protokoll dagegen ist grundsätzlich eine Rückmeldung über den Status einer Paketübertragung nicht vorgesehen. UDP-Server benötigen keine Kenntnis über die Existenz ihrer Clients. Sie unterstützen damit insbesondere sogenannte one-to-many -Verbindungen. Im Gegensatz dazu unterstützen TCP-Server one-to-one -Verbindungen in Form eines gesicherten Datentransports. Im Hinblick auf Ihre Eignung für haben beide Protokolle Vor- und Nachteile bezüglich Umfang und Sicherheit der übermittelten Datenmengen. Dies kann je nach Qualität und Eigenschaften der einbezogenen Netze zu unterschiedlichen Entscheidungen führen. Überlegungen zur Nutzung des Internet für GPS-Datenströme gleich welchen konkreten Inhalts sind derzeit weder global noch regional so weit gediehen, daß unter dem Gesichtspunkt der Standardisierung eine Entscheidungen für oder gegen TCP oder UDP zu treffen wäre. Auch der Internationale GPS Dienst (IGS) bemüht sich derzeit zunächst um eine Diskussion der Situation und hat keine festgeschriebenen Präferenzen. Für die Situation in Deutschland und Europa liegen allerdings umfangreiche Erfahrungen aus dem Bereich des Internet-Radio vor, die eine Nutzung des TCP-Protokolls nahelegen. Eine Reihe von Diensten, die auf der Bereitstellung von TCP-Datenströmen auf dem Internet beruhen, haben die Versorgung einer Gruppe von Clients von einem einzelnen Server aus zum Ziel (siehe Abbildung 2). Audio- und Video-Dienste sowie interaktive Spiele seinen als Beispiele genannt. Prinzipiell betrachtet ist das sogenannte IP-Multicast hier eigentlich die herausragend geeignete Übertragungstechnik auch für DGPS: Ein Datenstrom wird durch eine einzige Sendeoperation am Server an alle interessierten Empfänger übertragen. Der Umfang des Datentransfers auf der Senderseite ist konstant und unabhängig von der Anzahl der empfangenden Nutzer. IP- Multicasting benötigt allerdings multicastfähige Komponenten auf der gesamten Kommunikationsstrecke zwischen Server und Client. Alle an der Datenübertragung beteiligten Netzwerkbestandteile einschließlich der Router und der Betriebssysteme auf der Server- und Client-Seite müssen IP-Multicast unterstützen. Leider trifft diese Voraussetzung für die Netzwerke der Mobilfunkbetreiber zur Zeit nicht zu. Ihre Backbone-Kabelnetze unterstützen IP-Multicast nicht. Eine Änderung der Situation in Europa ist im derzeit überschaubaren Zeitraum kaum zu erwarten. IP-Multicast, wenngleich das ideale Verfahren zur Verbreitung für RTCM-Korrekturdaten, kommt in der überschaubaren Zukunft nicht als Übertragungstechnik in Frage. 55

3 SAPOS Abb. 2: Einfache TCP/IP Client/Server-Konfiguration (links) versus IP-Multicast Client/Server-Konfiguration (rechts) Laufzeiten der Korrekturdaten Von maßgeblicher Bedeutung sind bei jeder Übertragungstechnik für DGPS- und RTK-Korrekturdaten die Laufzeiten. Die Positionierungssoftware auf Seiten eines Rovers benötigt, in gewissem Maße auch abhängig vom Typus der Positionierung, die Daten möglichst unverzüglich. Erheblich verspätetes, ausbleibendes oder unregelmäßiges Eintreffen von Korrekturdaten zieht einen Genauigkeitsverlust nach sich. Dies stellt im Falle der Verwendung exklusiver Übertragungswege wie der 2-m-Band bei SAPOS kein Problem dar. Bei der Verwendung des Internet dagegen teilt sich die DGPS/RTK-Anwendung die von einem Provider bereitgestellte Bandbreite mit anderen Anwendungen und entzieht sich damit einer Kontrolle. Es stellt sich die Frage, in welchem Maße in Deutschland und Europa die üblichen Ressourcen professioneller Provider für die Positionierung und Navigation in Echtzeit ausreichen. Die Abbildung 3 zeigt Histogramme der Laufzeiten von DGPS- und RTK-Korrekturdaten (Formate RTCM 2.0 bzw. RTCM 2.1) im Falle einer aus Internet und Festnetztelefon zusammengesetzten Kommunikationsstrecke. Die hier nachgewiesenen Laufzeiten (siehe Analysesoftware unter [3]) in der Größenordnung von weniger als 2 Sekunden sind typisch für die Situation in Deutschland. Die bisher in Europa durchgeführten länderübergreifenden Tests zeigten nur in Ausnahmefällen Laufzeiten, die 4 Sekunden überschritten. Die Laufzeiten der Korrekturdaten bei Kommunikationsstrecken über das Internet sind damit so gering, dass sie keinen spürbaren Einfluss auf die erzielbare Positionierungsgenauigkeit haben. Mit der Abbildung 4 werden beispielhaft typische Ablagen von 1s-Registrierungen einer statischen Positionsbestimmung an bekanntem Ort über Internet und Festnetz bzw. Internet und Mobilfunk gezeigt. Die beiden Histogramme der Abbildung zeigen Ablagen gegenüber einer Sollposition über einen Zeitraum von jeweils 10 Minuten. Interessant ist der geringe Genauigkeitsverlust beim Einschluß der Mobilfunkstrecke in die Datenübertragung gegenüber der Verwendung des Festnetzes. 56

4 Abb. 3: Histogramm der Laufzeiten von DGPS-Korrekturdaten (links) und RTK-Korrekturdaten (rechts) durch Internet und Festnetztelefon Abb. 4: Histogramm der Ablagen von RTK-Positionierungen über Internet und Festnetztelefon (links) bzw. Internet und Mobiltelefon (rechts) DGPS/RTK-Server, Testimplementationen Abhängig von Ihrer Funktion ist für die Einrichtung eines ausgedehnten flächendeckenden Dienstes ein abgestimmter Betrieb von Servern mit verschiedenen Zielsetzungen denkbar. Sinnvoll erscheinen einige wenige Primärserver, die eine größere Anzahl von Nutzern (z.b. 1000) zeitgleichbedienen, Sekundärserver, die einen Primärserver bedienen, darüber hinaus aber auch für die Versorgung einer begrenzten Zahl von Nutzern (z.b. 100) zuständig sind sowie Single-Client-Server, die ausschließlich einen Primär- oder Sekundärserver bedienen. Welche Aufgaben von welchem Server übernommen werden, hängt von der Intention der Betreiberinstitution sowie insbesondere der Bandbreite des Internetzugangs ab, die an einem speziellen Ort bereitgestellt werden soll oder kann. Wird der Serverbetrieb an professionelle Provider übergeben, so sind für die zeitgleiche Abgabe von 1000 DGPS-Korrekturdatenströmen heute Kosten in der Größenordnung von Euro jährlich zu erwarten. 57

5 SAPOS Abb. 5a: GREF-IP-Teststationen in Deutschland (RS: schwarz, VRS: grau) Das vom BKG unter der Bezeichnung GREF täglich ausgewertete Permanentnetz von etwa 20 GPS-Referenzstationen (RS) in Deutschland wird derzeit auf einen Echtzeitbetrieb umgestellt. Sukzessive werden diese Stationen über Standleitungen mit einem Zentralrechner in Frankfurt vernetzt. Unter der Bezeichnung GREF-IP (IP für Internet Protokoll) soll hieraus ein Dienst erwachsen, der aus den Beobachtungen der Referenzstationen DGPS-Korrekturdaten für etwa 20 auf das Bundesgebiet verteilte virtuelle Referenzstationen (VRS) herleitet und über Internet anbietet. Abhängig von der Qualität der Endgeräte auf der Nutzerseite soll flächendeckend ein Potential für das Erreichen von Genauigkeit besser ± 0,5 Meter geschaffen werden. Der Zentralrechner verwendet die GPSNet-Software (Trimble/Terrasat) für das Generieren der Korrekturdaten. Seit März 2002 sind sieben der mit GPS/GLONASS-Empfängern ausgerüsteten Referenzstationen vernetzt (siehe Abbildung 5a/b). Im Testbetrieb werden für einen begrenzten Zeitraum von Servern unter den Internetadressen gref-ip.ifag.de und euref-ip.ifag.de auf den Ports 2101 und 2103 ausgewählte RTCM-Korrekturdatenströme angeboten. Die Anzahl der maximal zeitgleich zu liefernden Datenströme ist für den Zeitraum der Entwicklungs- und Testarbeiten auf 50 beschränkt. Die Server-Software wurde auf der Grundlage eines NMEA-Servers [4] am BKG entwickelt. Abb. 5b: EUREF Permanentnetz EPN 58

6 Für DGPS-Dienste erscheint es heute unerlässlich, ein länderübergreifendes Angebot an Korrekturdatenströmen bereitzustellen. Das von den nationalen Landesvermessungen in Europa im Rahmen der IAG-Subkommission EUREF betriebene Netz von etwa 160 kontinentweit verteilten GPS-Permanentstationen stellt eine geeignete Datengrundlage für die Ausbreitung des Konzeptes von GREF-IP dar. Unter der Bezeichnung EUREF-IP wird analysiert, ob und in welcher Weise ein kontinentaler DGPS-Dienst mit fachlicher Unterstützung von EUREF eingerichtet werden kann. Als geeignete für die Einbeziehung in EUREF-IP erschienen diejenigen Stationen, die in unmittelbarer Nähe von Internetanschlüssen betrieben werden und GPS-Empfänger verwenden, die eigenständig RTCM-Korrekturdaten generieren können. Testimplementationen für Server bestehen außer in Deutschland zur Zeit in Italien und der Schweiz. In Portugal und Norwegen sind sie im Aufbau. DGPS und RTK, Besonderheiten Im Hinblick auf die Übertragung von Korrekturdaten über Internet zeigen sich zwischen DGPSund RTK-Anwendungen einige Unterschiede. Im Bereich RTK ist die zu transportierende Datenmenge um den Faktor zehn größer als bei DGPS, was allerdings nur einen geringen Anstieg der Kosten für einen Servers-Betrieb mit ausreichender Bandbreite zur Folge hat. Bei RTK-Anwendungen wird in der Regel die Übertragung von Korrekturdaten auf vergleichsweise geringe Entfernungen beschränkt sein. Bei DGPS-Anwendungen dagegen ermöglicht auch die Nutzung von Korrekturdaten relativ entfernter Referenzstationen (z. B. 500 km) noch Genauigkeiten zumindest besser ± 3 Meter. Die Client-Software bei RTK-Anwendungen könnte langfristig in Rover- Ausrüstungen integriert werden. Bei DGPS unter Verwendung einfacher C/A-Code Empfänger erscheint es dagegen sinnvoll, die Client-Software auf einem separaten Gerät zu implementieren. Geeignet sind insbesondere Pocket-PC unter dem Betriebssystem Windows CE (siehe Abbildung 6). Ausgerüstet mit Modem-Steckplätzen für Mobilfunkverbindungen ins Internet können sie eine leistungsfähige und dennoch handliche Plattform für Location Based Services darstellen. Abb. 6: DGPS/RTK Client-Software [5] auf Compaq ipaq Pocket-PC unter Windows CE und GPRS-Modem Nokia D211 59

7 SAPOS Besondere Bedeutung für DGPS-Anwendungen hat die Einführung des General Packet Radio Service (GPRS) als paketvermittelter Dienst für die mobile Datenkommunikation. GPRS stärkt vor allem die mobile Nutzung des Internets und gilt als Wegbereiter für UMTS. Im Gegensatz zu GSM werden bei dieser Technologie die Daten in Pakete zerlegt und getrennt übertragen, wodurch eine optimale Nutzung der gesamten in einer Mobilfunkzelle nutzbaren Bandbreite möglich ist. Entscheidend für DGPS-Anwendungen ist, dass mit GPRS eine Abrechnung nach Datenvolumen erfolgt. Der Nutzer zahlt nicht mehr für die Verbindungsdauer, sondern nur für die Menge der übertragenen Daten. Die zur Verfügung stehende Übertragungskapazität wird unter allen Teilnehmern einer Funkzelle aufgeteilt und dabei die Funkstrecke nur belegt, wenn wirklich Datenpakete übermittelt werden. Im Vergleich zur GSM-Technik sinken bei GPRS die Kosten für die Übertragung von DGPS-Korrekturdaten bis zu 90%. Bei RTK-Anwendungen führt heute die Nutzung von GPRS wegen der zehnfach höheren Datenrate leider noch zu keiner nennenswerten Reduzierung der Kosten. Ausstehende Entwicklungsarbeiten Wesentlicher Bestandteil der Server- und Client-Software aller heutigen Testimplementationen ist die Umsetzung serieller Datenströme in Socket-Verbindungen, wobei speziell zu vereinbarende Ports angesprochen werden (vergleiche Abbildung 2). Hierin liegt eine erhebliche Schwierigkeit. Für jeden von einem Server abgegebenen spezifischen Datenstrom ist ein spezieller Port zu definieren. Leider sind diese Ports bisher nicht standardisiert. Ihre Bedienung wird daher in aller Regel von den häufig ungünstig konfigurierten Firewalls abgelehnt. Damit liegt auf Seiten der DGPS/RTK-Service Provider ein Problem vor, das entweder durch das für Sicherheitsfragen zuständigen IT-Personal gelöst werden muss oder dadurch zu beheben ist, daß Server außerhalb der Firewalls betrieben werden. Auf Seiten der Nutzer Internetbasierter DGPS/RTK-Dienste würde ergänzend ein Problem entstehen, sobald Internet Service Provider ebenfalls dazu übergehen, nicht standardisierter Ports zu schließen. Dies ist heute nicht der Fall, langfristig allerdings auch nicht auszuschließen. Abb. 7: HTTP Splitter-Server, Server/Client/Source-Konfiguration 60

8 Einen Ausweg aus dieser Situation bietet die in [2] empfohlene Verwendung von http als Anwendungsprotokollschicht auf TCP im Zusammenhang mit einem http-splitter-server (Abbildung 7). Ein http-client initiiert danach zunächst eine TCP-Verbindung zu einem Server. Im Anschluß daran kommunizieren Client- und Server-Prozesse durch Ihre Socket-Verbindungen. Der Splitter-Server erkennt aufgrund der Verwendung verschiedener Message-Typen ob es sich im Einzelnen um den Kontakt zu einem Client, zu einer Datenquelle oder zu einem autorisierten System-Verwalter handelt. Dazu werden bei der Kontaktaufnahme zunächst für jeden Datenstrom typische Kennungen empfangen bzw. gesendet, die den Gehalt der nachfolgenden Daten für Client bzw. Server vorab charakterisieren. Der gesamte Datenstrom wird ausschließlich über einen einzigen Port geleitet (z.b. Port 2101 für RTCM-Korrekturen oder Port 80 für http). Der Splitter-Server kann folglich hinter einem schützenden Firewall aufgestellt werden. Das BKG befaßt sich derzeit mit der Bewertung des Konzeptes der Verwendung eines http- Splitter-Servers für die Einrichtung eines bundesweiten DGPS-Dienstes über Internet. Es scheint heute absehbar, daß die Verwendung des Internet auch für den Transport von RTK-Korrekturdaten eine Bedeutung hat. Das Internet ist in besonderer Weise geeignet, dezentrale Aktivitäten zu bündeln und nutzerfreundlich mit einer einheitlichen Oberfläche zu versehen. Quellen [1] DGPS corrections over the Internet: [2] Real-Time Streaming of Differential GPS Corrections via Internet, Feasibility Study: Gebhard, H. und R. Kays, Informatic Centrum Dortmund, unveröffentlicht. [3] RTCM-Dekodierungsprogramm, FH-Bochum: [4] NMEA Server: [5] WinCE DGPS/RTK Client Program: 61