seminar: informationssysteme in der raumfahrt

Julius-Maximilians-Universität Würzburg

Lehrstuhl Robotik und Telematik (Informatik VII) Institut für Informatik

Seminar: Informationssysteme in der Raumfahrt

“Link and Routing Issues for Internet Protocols in Space“

Stefan Issing Grzegorz Meinusch

Betreuer: Mónica Pérez Vernet

Wintersemester 2002/2003

Link and Routing Issues for Internet Protocols in Space

Gliederung

1. Einleitung ___________________________________________________ 2 2. Allgemeine Netzwerkkonzepte für die Raumfahrt _____________________ 2 3. Mögliche Architektur und Routing ________________________________ 3 4. Abgrenzung ISO/OSI Modell gegenüber Internet_____________________ 4 5. Relevante Schichten____________________________________________ 5

5.1. Physical Layer_________________________________________________ 5 5.2. Data Link Layer _______________________________________________ 6 5.3. Network Layer ________________________________________________ 7

6. OMNI Projekt________________________________________________ 9 7. Fazit und Ausblick____________________________________________ 12 8. Quellenverzeichnis ___________________________________________ 13

1. Einleitung Kann man Standardinternetprotokolle und Link Layers für die Satellitenkommunikation nutzen? Welche Möglichkeiten würde ihr Einsatz bieten? Wo liegen die Grenzen? Diese und andere Fragen sollen mit der vorliegenden Arbeit aufgezeigt und beantwortet werden. Hierzu sollen gerade die unteren Schichten, welche für den Datentransport zuständig sind, be-trachtet werden. Ferner wird untersucht, wie Protokolle mit IP verknüpft werden, um eine End-to-End-Kommunikationsarchitektur für die Raumfahrt zur Verfügung zu stellen. Gerade der Datentransfer vom All zur Erde ist eine aufwendige und komplizierte Sache und wird immer teuerer. Mit heutiger Internettechnologie soll eine Architektur entwickelt werden, die Raums-fahrtmissionen „schneller, besser und billiger machen“ soll. Im folgenden Abschnitt werden zwei verschiedene Typen für die Netzwerkarchitektur von Raumfahrzeugen sowie die grundlegenden Funktionen des Routing vorgestellt. Danach erfolgt eine Abgrenzung des ISO/OSI Modells gegenüber dem Internet. Anschleißend werden die rele-vanten Schichten vorgestellt und ihre grundlegenden Aufgaben und Funktionen beschrieben. Zum Abschluss erfolgt eine kurze Vorstellung des OMNI Projekts der NASA sowie das Fazit und ein kurzer Ausblick auf die noch nötige Arbeit auf diesem relative neuen Sektor der Raum-fahrt.

2. Allgemeine Netzwerkkonzepte für die Raumfahrt Das Internet bietet für die Raumfahrt zahlreiche Vorteile:

• Einfacher Zugriff auf die Sensorik • Einfache Datenverteilung • Geringere Entwicklungs- und Schulungskosten • Verwendung vorhandener Hardware- und Softwarelösungen • Einfache, robuste und vielfach bewährte Technologie

Seminar: Informationssysteme in der Raumfahrt 2


Vor 30 Jahren war die Weltraumkommunikation eine Wissenschaft für sich und für jede neue Mission wurden spezielle Lösungen entwickelt, welche natürlich mit enormen Kosten- und Ent-wicklungsaufwand verbunden waren. Die Kommunikationslösungen haben sich in den letzten Jahren jedoch stark weiterentwickelt, so dass auch die Raumfahrt von den neuen Technologien profitieren kann. Dennoch gibt es zahlrei-che Herausforderungen, die bewältigt werden müssen. Hierzu zählen der Aufbau einer nahtlosen Verbindung sowie ein periodische Verbindungsaufbau, die Unterstützung stark asymmetrischer Verbindungen, die Bewältigung einer hohen Bitfehlerrate, dynamische Netzwerktopologien und zu guter letzt eine eindeutige Adressierung für die einzelnen Raumfahrzeuge auch bei der Ver-wendung verschiedener Bodenstationen.

3. Mögliche Architektur und Routing Einer der Hauptgründe für die Verwendung des Internets für die Raumsfahrt war die Überle-gung, kostengünstige und kommerzielle (commercial-off-the-shelf) Produkte zu verwenden. Da-her ist eine der größten Veränderung gegenüber heutigen Kommunikationslösungen die Verän-derung des Datenformats. Auf Seiten der Satelliten ergaben sich daher zwei Arten von Netzwerktopologien: Raumfahrzeuge mit nur einer IP und solche mit mehreren IP’s, welche über ein eigenes LAN mit mobilem Rou-ter verfügen.

Die Aufgaben des Router sind die Verteilung von IP-Paketen und die Verlinkung verschiedener Protokolle auf der Data Link Layer (HDCL → Ethernet). Das Routing findet auf den drei unters-ten ISO/OSI-Schichten statt.



4. Abgrenzung ISO/OSI Modell gegenüber Internet Wie in der nebenstehenden Übersicht deutlich wird, unterscheidet sich das heutige Internet vom ISO/OSI – Modell in den obersten drei Schich-ten. Session, Presentation und Application Layer werden von der heutigen Internetsoftware zu-sammengefasst und bilden daher eine gemeinsame Application Layer.

Die Schichten des ISO/OSI – Modells haben die folgenden Aufgaben: Layer Aufgaben

Physical Bitstrom Details, Signalstärke, Kabelspezifikationen, ModulationstechnikenData Link Erkennen und/oder Beheben von Übertragungsfehlern

Network Verdeckt Details der Datenübertragung von den höheren Schichten, end-to-end addressing, Flusskontrolle, Routing

Transport Aufbau, Verwaltung und Abbau logischer Verbindungen

Session Bereitstellung der nötigen Mittel, um die Kommunikation zu organisieren, zu synchronisieren und den Datenaustausch zu managen

Presentation Gewährleistung, dass die gesendete Information vom Empfänger des ande-ren Systems gelesen und verarbeitet werden kann, Datendekompression, Umcodierung, Datenverschlüsselung, Datenbankzugriff und -verwaltung

Application Bereitstellen der Daten für den Anwender Die einzelnen Schichten haben Schnittstellen, um mit den umliegenden Schichten zu kommuni-zieren. Die Schichten sollten allerdings so gestaltet und unabhängig voneinander sein, dass der Austausch einer Schicht keine Auswirkungen auf den Gesamtablauf hat. Jede Schicht hat ihre eigene Aufgabe im gesamten Kommunikationsprozess. Die Schlüsselkomponente des Modells ist der Network Layer. Er fasst die übrigen Protokolle zusammen. Er ermöglicht eine weltweit eindeutige Adressierung zum Versenden von Datenpake-ten. Dadurch wurde es erst möglich, dass das Internet die heutige Anzahl an Anwendern mit der Möglichkeit des Datenaustausches zwischen jedem einzelnen Anwender erreicht.



5. Relevante Schichten Für die weitere Betrachtung des Themas “Link and Routing Issues for Internet Protocols in Space“ sind lediglich die drei untersten Schichten von Bedeutung. Die übrigen Schichten werden in der Aus-arbeitung zu “Transport Protocols and Applications for Internet Use in Space“ vorgestellt.

5.1. Physical Layer

Die Aufgaben des Physical Layer liegen in der grundlegenden Spezifikation der Hard- und Software auf der untersten Ebene. Zur Hardware gehören die Wahl eines geeigneten Über-tragungsmediums, Übertragungsverfahrens sowie Signalspannung und -stärke. Auch Auswahl der zu verwendenden Kabel und Stecker findet auf dieser Ebene statt. Softwareseitig sind die Bitstromeigenschaften sowie die Modellierungstechnik festzulegen. Bevor nun eine Verbindung aufgebaut werden kann, sind einige elementare Schritte notwen-dig. Zunächst muss die passende Hardware mit entsprechender Software installiert werden. Des weitern ist für einen Verbindungsaufbau die Ausrichtung der Antennen sowie die Ab-stimmung von Sender und Empfänger durchzuführen. Da zukünftige Missionen den An-spruch erheben, noch umfangreichere Datenmengen über noch größere Distanzen zu über-tragen, wird es eine enorme Herausforderung sein, die bekannten Übertagungstechniken und -umsetzungen den Anforderungen der Raumfahrt zu unterwerfen. Bei der Bitübertragung hat der Physical Layer die Aufgabe, einen Mechanismus zur Verfü-gung zu stellen, der eine Point-to-Point und Point-to-Multipoint Verbindung ermöglicht. Diese Verbindung wird entweder mit einer oder mehreren Leitungen aufgebaut. Er besitzt ferner eine Fehlerkorrekturmethode. Es gibt zahlreiche Modulations- und Codierungstechniken. Die verwendete Technik hängt vom Übertragungsmedium ab. Hier wären beispielhaft Kupferkabel, Fiberglaskabel oder auch die Radiofrequenz zu nennen. Die häufigsten Codierungsverfahren sind:

• Manchester coding (10 Mbps Ethernet) • 4B/5B (100 Mbps Ethernet und FDDI) • 8B/10B (1000 Mbps Ethernet und SONET) • Biphsase shift keying (BPSK) und quadrature phase-shift keying (QPSK) (RF)

Die Funktionsweise der Codierungsverfahren soll hier jedoch nicht weiter erläutert werden. Zu beachten ist hierbei noch, dass Sender und Empfänger die gleiche Codierung verwenden. Um eine Fehlerkorrektur zu gewährleisten, ist ein gewisser Grad an Datenredundanz sowie die Einführung zusätzlicher Bits nötig. Es wird die so genannte forward-error-corrrection (FEC) verwendet. Die beliebtesten Verfahren sind hier Convolutional Coding und Reed-Solomon (R-S) 1. Beim Convolutional Coding haben die versendeten Datenblöcke verschiedene Größen und die Korrekturbits werden nach einem bestimmten Algorithmus innerhalb der einzelnen Strings eingesetzt. Im Gegensatz dazu arbeitet Reed-Solomon mit festen Datenblockgrößen. Hierbei kann es aber zu Problemen bei der Paketrückgewinnung kommen bzw. die Fehler-wahrscheinlichkeit steigen, da die Datenpakete zunächst verschiedene Größen haben und mittels künstlichen Füllens auf die gleiche Länge gebracht werden. Vorteil dieses Verfahrens ist es jedoch, dass die Kontrollblöcke immer an der gleich Stelle zu finden sind. Bei zu vielen Fehlern in einem Frame ist es mit Reed-Solomon nicht möglich, die Bits zu korrigieren.

1 http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-avt-reedsolomon-00.txt



Heutige Raumfahrtkommunikationssysteme verwenden eine von ISO/OSI differenzierte Da-tenarchitektur. Durch die Benutzung heutiger Internettechnologie in der Raumfahrt ist es je-doch möglich, das Framing im Data Link Layer von der Codierung im Physical Layer zu trennen. Außerdem können einzelne Schichten unabhängig voneinander erweitert bzw. geän-dert werden.

5.2. Data Link Layer Der Data Link Layer teilt die Daten in Pakete und fügt Adress- und Kontrollinformationen sowie Fehlerkorrekturmechanismen hinzu. Er wird bei der Verbindung vom All zur Erde mittels HDLC und Paket-over-SONET sowie auf der Erde selber mittels HDLC bis 45 Mbps und SONET bis 622 Mbps verwendet. Ein Versuch, die beiden Techniken IEEE-1355 (SpaceWire) und IEEE-1394 (FireWire) einzubinden, ist seitens der IETF für IEEE-1394 be-reits in Arbeit. Neuste Entwicklungen zeigen, dass der Einsatz von Standard Ethernet Technologien für die Datenübertragung in einer Echtzeitumgebung wie der Raumfahrt große Potentiale beinhaltet. Einige Firmen haben sich bereits zu den folgenden Gruppen zusammengeschlossen:

• Industrial Ethernet Association – http://www.industrialethernet.com • Industrial Automation Open Networking Alliance – http://www.iaona.com • GE Cisco Industrial Networks – http://www.gecisco.com

Der Aufbau eines Ethernet, basierend auf dem industriellen Ethernet, bietet für die Raum-fahrt enorme Möglichkeiten. Das Ethernet hat aufgrund einer immensen Anzahl an Schnitt-stellen bereits heute die Mehrheit der weltweiten Datenübertragung übernommen. Ferner un-terstützt es Geschwindigkeiten von 10, 100 und 1.000 Mbps. Eine Version mit 10.000 Mbps befindet sich in der Entwicklung. Ebenfalls in der Entwicklung befindet sich eine Programmiersprache für die höheren Level sowie ein API um die Software, welche in Echtzeit-Ethernet LAN’s verwendet wird, zu stan-dardisieren. Auf dem Data Link Layer kommt HDLC (High-level data link control) zur Anwendung. HDLC wird seit über 30 Jahre angewendet. Es bietet eine einfache Schnittstelle sowie eine hohe Kompatibilität mit zahlreichen kommerziellen Routern. Einsatzgebiete sind z.B. Syn-chronous data link control (SDLC) von IBM, Frame Relay, X.25 oder ADCCP. Auf der Ebe-ne des Physical Link Layer ist HDLC außerordentlich einfach. Aufgrund seiner strengeren Synchronisationsmechanismen wird Reed-Solomon innerhalb des Pysical Layer verwendet. Benutzt man nun HDCL auf Reed-Solomon so erhöht sich die Framerückgewinnung auch bei stark beschädigten Reed-Solomon-Paketen. Ein weiterer Vorteil ist die geringere Fehler-wahrscheinlichkeit bei längeren Folgen von 0 oder 1 Bits bei der Signalrückgewinnung. HDLC verwendet verschiedene Methoden zur Datenkapselung. Die Wahl der angewendeten Methode unterliegt verschiedenen Kriterien. Da ein Full-Duplex-Verfahren fehlt, sind Proto-kolle wie Serial Line IP (SLIP) und Point-to-Point Protocol (PPP) ausgeschlossen. Da außer-dem eine Kompatibilität mit Routern verschiedener Hersteller verlangt wird, sind ferner Pro-tokolle wie z.B. das von Ciscio, welches ein spezifiziertes HDLC Header verwendet, ebenfalls ausgeschlossen. Durch den Einsatz kommerzieller Router, welche eine höhere Übertragungsrate als 45 Mbps unterstützen, wird die Verwendung einer anderen Framingmethode als HDLC nötig. Diese HDLC-Router nutzen High-Speed Serial Interfaces (HSSI). Für höhere Geschwindigkeiten eignet sich als Framingmethode Asynchronous Transfer Mode (ATM) mittels Synchronous Optical Network (SONET) als Schnittstelle. Nachteile bei dieser Methode sind ein 10% O-



verhead, das Splitting der IP-Pakete in ATM-Zellen sowie die Gefahr, beim Verlust einer ein-zigen ATM-Zelle, das gesamten IP-Paket zu verlieren. Eine interessante Alternative ist es, diese Nachteile zu umgehen indem man IP-Pakete mit SONET ver-schickt. Die Idee, welche hinter dieser Lösung steckt, heißt Packet over SONET (POS). Ein Nachteil dieses Verfahrens ist jedoch das Hinzu-fügen eines PPP Header, da - wie oben bereits er-wähnt - ein Full-Duplex-Verfahren fehlt. Grundsätzlich sind bei großen Übertragungsraten auch sehr hohe Baudraten nötig, die bei der Kom-munikation mit dem All noch nicht erreicht werden können. Eine der größten Sorgen für Satellitensystementwickler ist sowohl der Prozess-Overhead als auch der Bit-Overhead, der im Zusammenhang mit den einzelnen Protokollen auftritt. Dieses Problem betrifft weniger die bordeigenen LAN Protokolle, bei denen die Bandbreite nicht so sehr beschränkt ist. Vielmehr betroffen sind die Verbindungen vom All zur Erde, da hier kaum von einer unbegrenzten Bandbreite ausgegangen werden kann. Diese Beschränkungen sind abhängig von Faktoren wie Sendeleistung, Fehlerrate, Signalqualität oder Entfernung. Der Overhead bei HDLC ist eher gering und besteht aus folgenden Komponenten:

• 1 byte flag • 4 byte Frame Relay und Datenkapselungschlüssel • 2 byte CRC für Fehlererkennung

Der gemessene Overhead lag in einigen Fällen wie z.B. bei WIND, POLAR oder SOHO zwi-schen 1 – 3%. Der worst case liegt aber auch hier bei rund 20% Overhead.

5.3. Network Layer Der Network Layer stellt das „Bindeglied zum Anschluss an die Welt dar“. Da innerhalb des Link Layer eine Adresse nur bis zum nächsten Netzknoten eindeutig ist, wird im Network Layer eine global eindeutige Adresse vergeben. Im folgenden ist ein IP Header v4 abgebildet, welcher eine 32-stellige Adresse mit sich führt.

Die Basis, auf der das Internet aufbaut, ist im wesentlichen die Fähigkeit, Daten innerhalb ei-nes Netzes an eine bestimmte Zieladresse zu schicken. Probleme kommen jedoch auf, wenn das Netz die Größe des Internets erreicht.



In kleinen Netzwerken sind die Lookup-Tabellen, welche den Routern die nächste Zieladres-se angeben, relativ klein, einfach und weitestgehend statisch. Diese Tabellen können sehr ein-fach angelegt und gewartet werden. Diese Tatsache ist eng verwandt mit den aktuell benutz-ten Datentransportsystemen in der heutigen Raumfahrt. Wenn Netze nun die Größe und das ständige Wachstum des Internets erreichen, muss die Wartung dieser Tabellen automatisch zwischen den Routern ablaufen. In der Raumfahrt kommen nun mehrere Bodenstationen zum Einsatz. Möchte ein Raum-fahrzeug nun Daten zur Erde schicken, ist dies kein Problem, da die empfangende Bodensta-tion die eindeutige IP Adresse des zugehörigen Kontrollzentrums kennt und somit die Daten lediglich dorthin weiterleiten muss. Viel problematischer wird es beim Upload, da die Raum-fahrzeuge auf ihrem Weg um die Erde zwischen den einzelnen Subnetzen wechseln und da-her nicht über eine global eindeutige Adresse verfügen. Das Kontrollzentrum weiß nicht, welche Bodenstation sich gerade in Reichweite des Satelliten befindet. Dieser Sachverhalt wir durch die folgende Abbildung verdeutlicht.

Dieses Problem versucht man nun mittels Mobile IP zu lösen. Bisher haben die Kontroll-zentren ihre Daten für den Upload an diejenige Bodenstation geschickt, die von den Raum-fahrzeugen überquert wurden. Die Kontrollzentren mussten also wissen ,welche Bodenstati-on gerade für einen Upload geeignet war. Da die Zahl an Raumsfahrzeugen aber ständig wächst, wird die exakte Planung der „Berührpunkte“ immer komplexer und teurer. Deshalb wäre eine automatisierte Lösung dieses Problems wünschenswert. Bei der Verwendung von Mobile IP vergibt die fremde Bodenstation beim Wechsel des Raumfahrzeugs in ihr Subnetz diesem eine zweite IP Adresse. Im Anschluss daran wird ein so genannter IP Tunnel zur eigenen Bodenstation angelegt. Über diesen Tunnel können nun die Daten an das Raumfahrzeug verschickt werden. Es gibt andere Lösungen, diese sind je-doch nicht in diesem Maße automatisiert und anpassungsfähig wie Mobile IP.



Bisher wurde lediglich die Möglichkeit betrachtet, dass das Raumsfahrzeug über nur eine IP Adresse verfügt. Wie in Abschnitt 3 jedoch vorgestellt, kann es durchaus vorkommen, dass mehrere IP’s an Board eines Raumsfahrzeugs erwünscht sind. Diese Problematik könnte man mittels Mobile IP nun in der Form lösen, dass jedem Knoten mit IP Adresse eine zusätzliche Adresse des entsprechenden Subnetzes zugeteilt wir und jeweils ein Tunnel angelegt wird. Dies führt bei der Registrierung der einzelnen IP’s jedoch zu einer extremen Belastung des Netzes. Außerdem wird für jeden Knoten zusätzliche Software erforderlich. Eine andere Lö-sung wäre mittels Mobile Routing von IETF. Bei dieser Idee übernimmt der Router an Board des Raumfahrzeugs die entsprechenden Mobile IP Operationen und die Knoten verhalten sich wie in einem festen LAN. Der Network Layer ist unter anderem für die Datenpriorität verantwortlich. Bisher findet bei der Übertragung nur eine mäßige Differenzierung zwischen wichtigen und weniger wichtigen Daten statt. Dies geschieht zur Zeit mittels den virtuellen Kanälen des CCSDS Protokolls (Consultative Commitee on Space Data Systems). Das Problem hierbei ist, dass dieses Priori-sierungsverfahren nur sehr wenige Unterscheidungsebenen unterstützt und die Bedeutung dieser Ebenen in jeder Mission anders definiert sind. Durch die Einführung von Internet-technologien ist es nun jedoch möglich, die Daten gemäß ihrer Dringlichkeit zu verschicken. Hierzu stehen folgende Möglichkeiten zur Verfügung:

• Data Link Connection Identifier (DLCI) im HDLC/Frame Relay Header • Typ of Service bit aus IP Header • Router können verschiedene Pakete der Priorität nach in Schlangen einordnen • Mittels Session Layer auf Seiten des Senders durch Auf- und Abbau bzw. Kontrolle

der Verbindungen

Am Ende dieses Abschnitts soll noch der Overhead im Network Layer angesprochen wer-den. Heutige Satellitenprotokolle konzentrieren sich auf einen minimalen Overhead bei der Übertragung vom All zur Erde. Auf dem Link Layer wird dies mittels HDLC ermöglicht. Der größte Overhead entsteht jedoch im Network und im Transport Layer. Wie die folgende Ü-bersicht verdeutlicht, nimmt der Overhead mit der Größe der IP Pakete ab.

Das einzige Problem, das in diesem Zusammenhang auftritt, ist die Tatsache, dass in der Raumfahrt aufgrund niedrigerer Paketfehlerwahrscheinlichkeit eher kleine Pakete versendet werden sollen. Nach entsprechenden Lösungen wird aber bereits gesucht.

6. OMNI Projekt Das OMNI Projekt (Operating Missions as Nodes on the Internet) setzte zum ersten Mal Inter-netlösungen in der Raumfahrt um. Im folgenden sollen die einzelnen Phasen des Projekts kurz erläutert werden.



Das Projekt wurde im Februar 1999 gestartet. Zunächst wurden mit Hilfe eines Kleinbusses Da-ten zu einem provisorischen Kontrollzentrum auf dem GSFC Gelände (Goddard Space Flight Center) gesendet. Diese Übertragung wurde mit Hilfe von TDRSS (Tracking and Data Relay Satellite System) realisiert. Während der ersten Versuche wurden one-way und später auch two-way Verbindungen aufgebaut. Gelegentlich Übertragungsunterbrechung, wenn Kleinbus zwi-schen Gebäuden oder unter Bäumen fuhr, wurden toleriert, da diese Unterbrechungen in der Raumfahrt unvermeidbar sind. In der nächsten Phase der Bodenversuche wurden auch Protokol-le wie FTP, NFS sowie Audio- und Videostreaming durchgeführt.

OMNI-Van Zu Beginn des Jahres 2000 sollten die ersten Versuche im All gestartet werden. Hierzu wurde ein geeignetes Raumsfahrzeug gesucht, welches HDLC von Seiten der Kommunikationshardware unterstützte, um die „Internet in Space“ Konzepte zu testen. Schließlich wurde UoSAT-12 ge-wählt. Grund hierfür war, dass UoSAT-12 bereits über HDLC-fähige Hardware verfügte, da er bisher mit dem AX.25 Protokoll arbeitete. Somit war lediglich eine Softwareänderung nötig, um die Benutzung von IP zu ermöglichen. Die zugehörige Bodenstation wurde um einen Stan-dardrouter sowie eine programmierbaren Switch erweitert.

UoSAT-12

Der erste Versuch im Weltraum fand im April 2000 statt. Hierbei wurde UoSAT-12 sowohl von der Bodenstation als auch vom GSFC angepint. UoSAT-12 antwortete auf die einzelnen Anfra-gen. Die Übersicht auf der nächsten Seite zeigt den Verlauf dieses Test.



UoSat-12 – PING-Test-Ergebnisse Die PING-Pakete wurden im 10 Sekundentakt gesendet. Die Verzögerungszeit bei der Antwort war abhängig von der Distanz zwischen UoSAT-12 und der Bodenstation. Im weiteren Verlauf des Projekt wurden/werden Internetdienste wie http (erfolgreich getestet am 25.01.2001), FTP, SMTP usw. mittels Mobile IP und Virtual Private Networks durchgeführt. Die Standardkonfiguration bei diesen Test ist in der nachstehenden Grafik abgebildet.



7. Fazit und Ausblick Die Einführung heutiger Internettechnologien in der Raumfahrt lieferte eine flexible und kosten-günstige Kommunikationsarchitektur. Dazu wurden keine speziellen Lösungen für einzelne Mis-sionen entwickelt, sondern kommerzielle, weit verbreitete und vielfach bewährte Techniken ver-wendet. Die Realisierung fand mittels HDLC Framing und IP statt. Damit wurden auch die Kompatibilitätsprobleme bei der Verwendung missionsspezifischer Hardware beseitigt. Die Einführung eines Netzwerkprotokolls wie IP ermöglicht den Zugriff auf die Daten des Raumsfahrzeuges ähnlich wie bei einem Webserver. Die Datenarchivierung und -verteilung ver-einfacht sich ganz erheblich und Prozesse der Datentransformation entfallen komplett. Neue Anwendungen bedürfen keiner Entwicklung, da sie bereits durch am Markt erhältliche ersetzbar sind. Folglich entfällt der Aufwand, die verantwortlichen Entwickler seitens der Raumfahrt bei der Einführung neuer Technologien immer aufs Neue umzuschulen. Um das Internet in der Raumfahrt flächendeckend einsetzen zu können, bedarf es zunächst einer Anpassung und Aktualisierung der Bodenstationen. Bestehende Systeme müssen sowohl seitens der Hardware als auch Software erweitert werden. Dies wird allerdings einige Probleme mit sich bringen. Zunächst muss geprüft werden, welche Bodenstationen überhaupt IP-fähig sind und ob sie mit den entsprechenden Satelliten kommunizieren können. Außerdem ist die hohe Anzahl an Bodenstationen zu berücksichtigen.

Dabei darf aufgrund der großen Anwenderzahl und hohen Zugriffsmöglichkeiten die Problema-tik der Datensicherheit nicht außeracht gelassen werden. Gerade beim Mobile IP Tunnel sind enorme Anstrengungen zum Aufbau sicherer Verbindungen nötig. Bisher wurden Ethernet und HDLC in low-orbit Raumfahrzeugen eingesetzt. Hier spielt die Strahlung keine allzu große Rolle. Aus diesem Grund ist die Entwicklung neuer Bauteile gerade für die Raumfahrzeuge wichtig. Hierzu zählen unter anderem die Schnittstellen zwischen den RF-Komponenten und den Netzwerkkomponenten.



8. Quellenverzeichnis

• Consultative Committee for Space Data Systems. Radio Frequency and Modulation Systems. Part 1, Earth Stations, Blue Book, Juni 2001

• Consultative Committee for Space Data Systems. Radio Frequency and Modulation Systems. Part 1, Earth Stations, Green Book, Mai 1997

• Criscuolo, E., Computer Sciences Corp. (CSC) – NASA. Performance Efficiency of Internet Protocol (IP) in Space Applications. Applied Engineering and Technology Directorate Revision 0, November 1999.

• Keith Hogie, Ed Criscuolo, Ron Parise, Computer Science Corp. (CSC) – NASA. Link and Routine Issues for Internet Protocols in Space. In Proceedings of 2001 IEEE Aerospace Conference, Big Sky, Montana, March 2001.

• Perkins, C.E., Sun Microsystems, Nokia Research Center. Mobile Networking Through Mobile IP. In IEEE Internet Computing online, 1997.

• Rash, J., Goddard Space Flight Center – NASA, Ron Parise, Keith Hogie, Ed Criscuolo, Jim Langston, Computer Sciences Corp. (CSC). Internet Technology on Spcaecraft. In Proceedings of the 2000 AIAA Small Satellite Conference, Logan Utah, September 2000.

• Rash, J., Goddard Space Flight Center – NASA, Ron Parise, Keith Hogie, Ed Criscuolo, Jim Langston, Computer Sciences Corp. (CSC). Chris Jackson, Surrey Satellite Technol-ogy Ltd. (SSTL), Harold Price, Vytek Wireless Inc. Internet Access to Spacecraft. In Proceedings of the 14th Annual/USU Conference on Small Satellite, August 2000.

• Internetquellen: o Consultative Committee for Space Data Systems (CCSDS) – http://www.ccsds.org o Operating Missions as Nodes on the Internet – http://ipinspace.gsfc.nasa.gov


seminar: informationssysteme in der raumfahrt

Documents