DE102010013374A1

DE102010013374A1 - Verfahren zum Übertragen von Daten

Info

Publication number: DE102010013374A1
Application number: DE102010013374A
Authority: DE
Inventors: Romain Hermenier; Francisco Lazaro Blasco; Dr. Berioli Matteo; Christina Parraga Niebla
Original assignee: Deutsches Zentrum fuer Luft und Raumfahrt eV
Current assignee: Deutsches Zentrum fuer Luft und Raumfahrt eV
Priority date: 2010-03-30
Filing date: 2010-03-30
Publication date: 2011-10-06
Anticipated expiration: 2030-03-31
Also published as: DE102010013374B4

Abstract

Die Erfindung betrifft ein Verfahren zum Übertrageer Funkverbindung. Hierbei werden Daten unter Verwendung von Protokollen übertragen. Erfindungsgemäß findet eine Komprimierung der Protokoll-Header unter Verwendung einer Form des Lempel-Ziv-Welch-Algorithmus oder eines Run Length Encoding Algorithmus statt.

Description

Die Erfindung betrifft ein Verfahren zum Übertragen von Daten, insbesondere über eine Satelliten- oder Funkverbindung.
In den letzten Jahren hat ein enormes Wachstum der Nutzung von IP-basierten Multimediadiensten und anderen Anwendungen stattgefunden. Hierbei werden unter anderem Satelliten- und Funkverbindungen verwendet. Beispielsweise verwenden IP-basierte Multimediaanwendung IP-basierte Protokolle, wie z. B. UDP oder RTP und verkapseln Video- und Audiodaten in IP-Pakete, die über Satelliten- oder Funkverbindungen übertragen werden. Diese Verkapselung optimiert die Integration von derartigen Anwendungen in das Internet, verursacht jedoch das Erzeugen von redundanten Informationen in den Protokollheadern.
Es ist aus dem Stand der Technik bekannt, Protokollheader zu komprimieren. Dies beruht auf der Tatsache, dass sie sowohl bei Multimediaanwendung als auch bei Datenkommunikation anderer Art (z. B. FTP) redundante Daten aufweisen. Z. B. sind in aufeinanderfolgenden Paketen die Mehrheit der Felder im IP-Header ähnlich, und andere Felder der Header werden von Datenpaket zu Datenpaket in vorhersehbarer Weise aktualisiert. Es ist möglich durch Header Kompression nicht nur die IP-Header sondern auch Header von höheren Protokollschichten (TCP, UDP, RTP u. a.) zu komprimieren. Hierdurch kann eine noch höhere Kompressionsrate erreicht werden.
Das Prinzip der Header Kompression, wie es aus dem Stand der Technik bekannt ist, ist beispielhaft in 1 dargestellt. Wenn das Satellitenterminal 10 mit einem Host 20 im Internet 18 kommunizieren will, wird eine Header Kompression nur im Satelliten Link angewendet. Dies bedeutet, dass das Terminal 10 die Header komprimiert, wonach die Pakete mit komprimierten Headern über den Satelliten 12 übertragen werden. Dann werden diese Pakete am Network Endpoint 16 zu ihrem ursprünglichen Zustand dekomprimiert und anschließend ins Internet 18 weitergeleitet, wo sie dann ihren Weg zum Zielhaus 20 finden.
Bisher bekannte Headerkomprimierungsverfahren komprimieren nur besondere Protokolle. Beispielsweise kann CTCP (RFC 1144), auch bekannt als Van Jacobson-Kompression, nur verwendet werden, um TCP/IPv4 Pakete zu komprimieren. Dies ist das einfachste und älteste Headerkomprimierungsverfahren. Weitere aus dem Stand der Technik bekannte Header Compression Protokolle sind IPHC (RFC 2507), das eine Weiterentwicklung des CTCP darstellt. Es kann neben IPv4 auch IPv6-Header komprimieren und zusätzlich UDP- und TCP-Header.
Das Protokoll CRTP (RFC 2508) ist sehr ähnlich zu IPHC. Der wesentliche Vorteil von CRTP im Vergleich zu IPHC ist, dass es RTP-Header komprimieren kann.
Das am weitesten fortgeschrittene Header Compression Protokoll, das von IETF standardisiert wurde, ist ROHC (RFC 3095). Es kann sowohl IPv4, IPv6 sowie TCP und RTP-über-UDP-Header komprimieren. Dieses Protokoll wurde entwickelt, um die Kommunikation in einer fehleranfälligen Umgebung, sowie die Kommunikation über Verbindungen mit hohen Verzögerungen zu bewältigen.
Ferner ist die RFC-4944 Header Compression bekannt. Dieses Protokoll definiert ein Frameformat für Multihop-Kommunikation in drahtlosen Personal Area Networks. U. a. ermöglicht dieses Protokoll auch Header Compression. Ein großer Nachteil dieses Protokolls ist, dass diese Header Compression Methoden sehr unflexibel sind. Daher ist die Anwendung dieses Protokolls auf Sensornetze und andere einfache Kommunikationsbeispiele begrenzt.
Prinzipieller Nachteil des Standes der Technik ist es, dass mit bisher bekannten Headerkomprimierungsverfahren nur bestimmte Protokolle komprimiert werden können. Beispielsweise wäre ein Szenario denkbar, in dem eine Firma, die aus zwei getrennten Standorten besteht, die miteinander kommunizieren müssen, diese beiden Standorte mittels eines Satellitenlinks verbinden möchte. Werden für diese Kommunikation verschiedene nicht-standardisierte Protokolle benutzt, ist es bisher nicht möglich die aus dem Stand der Technik bekannten Headerkomprimierungsverfahren zu verwenden.
Es ist daher Aufgabe der Erfindung ein Verfahren zum Übertragen von Daten bereitzustellen, in dem eine Komprimierung der Header der Datenpakete bei einer Vielzahl von Protokollen möglich ist.
Die Lösung der Aufgabe erfolgt erfindungsgemäß durch ein Verfahren gemäß Anspruch 1.
In einem Verfahren zur Übertragung von Daten, insbesondere über eine Satelliten- oder Funkverbindung werden Daten unter Verwendung von Protokollen übertragen und insbesondere in IP-Pakete verkapselt. Erfindungsgemäß erfolgt eine Komprimierung der Protokoll-Header (z. B. der IP-Header als auch der Header von höheren Protokollschichten, insbesondere der TCP-Header, UDP-Header und/oder RTP-Header) unter Verwendung einer Form des Lempel-Ziv-Welch Algorithmus oder eines Run Length Encoding Algorithmus.
Erfindungsgemäß wird es dadurch möglich, in einer transparenten Weise Header verschiedenster Protokolle zu komprimieren. Hierfür ist es vorteilhaft, unterscheiden zu können. Durch die Verwendung der genannten Quellkodierungsalgorithmen, die unabhängig von den übertragenen Protokollen (insbesondere IP Protokollen) sind, können beliebige Protokolle komprimiert werden.
Wenn es außerdem Redundanzen in der Nutzlast gibt, ist es möglich auch die Nutzlasten der Datenpakete zu komprimieren. Für die Kompression der Nutzlast können auch die o. g. Algorithmen genutzt werden. Prinzipiell ist es lediglich notwendig, Header und Nutzlast unterscheiden zu können, um die erfindungsgemäße Methode anzuwenden, ohne die Syntax der Protokolle kennen zu müssen.
In einer bevorzugten Ausführungsform der Erfindung werden eine Anzahl n Datenpakete vor der Komprimierung ihrer Header zwischengespeichert und ihre Header zusammen komprimiert. Dies kann dadurch erfolgen, dass alle ersten Bytes der zwischengespeicherten Header zusammen komprimiert werden, anschließend alle zweiten Bytes der zwischengespeicherten Header zusammen komprimiert werden und dieses Verfahren bis zu allen letzten Bytes der zwischengespeicherten Header fortgeführt wird.
Alternativ kann auch eine Komprimierung der Header der Datenpakete in aufeinanderfolgender Reihenfolge ohne Zwischenspeicherung erfolgen.
Nach der Komprimierung der Header können die Daten über irgendeinen Link versendet werden, z. B. eine Satelliten- oder eine terrestrische Verbindung (drahtlos oder kabelgebunden).
Im Folgenden werden bevorzugte Ausführungsformen der Erfindung anhand von Figuren erläutert.
Es zeigen:
1 den prinzipiellen Ablauf einer Header Kompression,
2 mögliche Ausführungsformen der erfindungsgemäßen Header Komprimierung,
3 eine Darstellung des IP- und UDP-Headers,
4 einen Vergleich der Kompressionsraten zwischen verschiedenen erfindungsgemäßen Algorithmen.
1 wurde bereits im Zusammenhang mit dem Stand der Technik erläutert.
Das in 2 dargestellte Verfahren 1 stellt den Anwendungsfall dar, in dem die Header der Datenpakete einer nach dem anderen ohne eine Zwischenspeicherung komprimiert werden. Das Verfahren 2 aus 2 stellt den Anwendungsfall dar, in dem eine Anzahl n an Datenpaketen vor der Komprimierung ihrer Header zwischengespeichert werden und ihre Header zusammen komprimiert werden. Somit werden die Datenpakete organisiert, damit die Redundanz zwischen den Paketen effizienter genutzt werden kann.
Es wurden verschiedene Simulationen durchgeführt, um die Leistung des erfindungsgemäßen Verfahrens zu überprüfen. Hierbei wurden beide Algorithmen (Lempel-Ziv-Welch und Run Length Encoding) verwendet. Verschiedene Mengen von Paketen wurden gewählt. In dem Beispiel, das in 3 dargestellt ist, wurden die Protokolle IP und UDP verwendet.
Es wird angenommen, dass alle Felder außer ”Identification”, ”header checksum”, und ”UDP checksum” statisch sind, d. h. dass sie sich nicht verändern. Da alle Pakete die gleiche Größe haben, ist das Feld ”Total length” auch statisch. Mit Ausnahme dreier Felder, haben daher alle andern Felder denselben Wert von Datenpaket zu Datenpaket.

In der folgenden Tabelle sind die Ergebnisse der Simulation dargestellt, wobei die erreichten Kompressionsraten angegeben sind. Ein entsprechender Vergleich der Kompressionsraten zwischen den beiden verwendeten Algorithmen ist in 4 dargestellt. Die Bezeichnung Verfahren 1 und Verfahren 2 bezieht sich hierbei auf die Darstellung gemäß 2.

Nummer von Paketen	10	20	30	50	100	1000	5000
Originale Größe	280 B	560 B	840 B	1400 B	2800 B	28 KB	140 KB
Verfahren 1 LZW	162 B (42,1%)	268 B (52,1%)	373 B (55,6%)	607 B 56,6%)	895 B (68%)	9,8 KB (65%)	52,3 KB (62,6%)
Verfahren 2 LZW	139 B (50,3%)	220 B (60,7%)	306 B (63,5%)	458 B (67,3%)	796 B (71,5%)	5748 B (79,4%)	24009 B (82,8%)
Verfahren 2 RLE	108 B (61,4%)	148 B (73,5%)	188 B (77,6%)	268 B (80,8%)	468 B (83,2%)	4301 B (84,6%)	21492 B (84,6%)

Die dargestellten Ergebnisse wurden für eine UDP-IP-Anwendung ermittelt. Prinzipiell könnten hier andere Protokolle zur Header Komprimierung verwendet werden (z. B. ROHC [RFC 3095]). Diese Protokolle würden wahrscheinlich eine höhere Kompression erreichen, da sie von einer genaueren Kenntnis der Protokollsyntax profitieren. Sie verursachen jedoch deswegen auch einen höheren Prozessierungsaufwand.
Ein Vorteil des erfindungsgemäßen Verfahrens ist, dass es wenig Rechenaufwand verursacht und für beliebige Protokolle benutzt werden kann, während andere Protokolle (wie z. B. ROHC) eine sehr genaue Analyse und Kenntnis der Protokollsyntax benötigen. Diese Analyse der Protokollsyntax ist eine sehr komplexe Aufgabe (wie es im Fall der Kompression von TCP mittels ROHC ist). Somit kann auf einem Server (z. B. dem Network Endpoint 16 in 1), der im Fall eines Satellitennetzes hundert tausende von Terminals verwaltet, eine große Rechenlast verursacht werden, die erfindungsgemäß vermieden werden kann.
Die Erfindung kann eingesetzt werden in verzögerungstoleranten Netzen, in anderen Formen von Datennetzwerken und insbesondere bei Imaging-Satelliten, wobei Bilder aufgenommen, gespeichert und dann an eine Erdstation übertragen werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

RFC 1144 [0005]
RFC 2507 [0005]
RFC 2508 [0006]
RFC 3095 [0007]
RFC-4944 Header Compression [0008]
RFC 3095 [0029]

Claims

Verfahren zum Übertragen von Daten, insbesondere über eine Satelliten- oder Funkverbindung, wobei Daten unter Verwendung von Protokollen wie RTP, UDP, TCP oder IP übertragen werden, dadurch gekennzeichnet, dass eine Komprimierung der Protokoll-Header unter Verwendung einer Form des Lempel-Ziv-Welch Algorithmus oder eines Run Length Encoding Algorithmus erfolgt.
Verfahren zum Übertragen von Daten nach Anspruch 1, dadurch gekennzeichnet, dass eine Anzahl n Datenpakete vor der Komprimierung ihrer Header zwischengespeichert werden und ihre Header komprimiert werden, indem insbesondere alle ersten Bytes der zwischengespeicherten Header zusammen komprimiert werden, anschließend alle zweiten Bytes der zwischengespeicherten Header zusammen komprimiert werden und dieses Verfahren bis zu allen letzten Bytes der zwischengespeicherten Header fortgeführt wird.
Verfahren zum Übertragen von Daten nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass neben den Headern der Datenpakete auch die Nutzlasten der Datenpakete komprimiert werden.
Verfahren zum Übertragen von Daten nach einem der Ansprüche 1 oder 3, dadurch gekennzeichnet, dass die Header der Datenpakete einer nach dem anderen ohne eine Zwischenspeicherung komprimiert werden.