DE10212589A1 - Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket - Google Patents

Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket

Info

Publication number
DE10212589A1
DE10212589A1 DE10212589A DE10212589A DE10212589A1 DE 10212589 A1 DE10212589 A1 DE 10212589A1 DE 10212589 A DE10212589 A DE 10212589A DE 10212589 A DE10212589 A DE 10212589A DE 10212589 A1 DE10212589 A1 DE 10212589A1
Authority
DE
Germany
Prior art keywords
field
user data
packet
header
additional user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE10212589A
Other languages
English (en)
Other versions
DE10212589B4 (de
Inventor
Frank-Uwe Andersen
Cornel Pampu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE10212589A priority Critical patent/DE10212589B4/de
Publication of DE10212589A1 publication Critical patent/DE10212589A1/de
Application granted granted Critical
Publication of DE10212589B4 publication Critical patent/DE10212589B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Abstract

Die Erfindung betrifft ein Verfahren zum Übertragen von Nutzdaten in einem Nutzdatencontainer eines IP-Paketes und ein IP-Paket. Dabei werden Zusatznutzdaten in mindestens einem Feld eines Headers des IP-Paketes transportiert.

Description

  • Die Erfindung betrifft ein Verfahren zum Übertragen von Nutzdaten in einem Nutzdatencontainer eines IP-Paketes und ein IP-Paket.
  • In drahtlosen und in drahtgebundenen Kommunikationsnetzen werden häufig Kommunikationsverfahren verwendet, welche auf der Übertragung von Datenpaketen (z. B. sog. IP-Paketen, IP = Internet Protocol) beruhen. Derartige IP-Pakete bestehen aus einem Header (Kopfteil) und einem an den Header anschließenden Nutzdatencontainer (Payload). Der Aufbau eines derartigen Headers ist beispielsweise in der Druckschrift "Network Working Group, Request for comments 2460, Internet Protocol, Version 6 (IPv6) Specification" von S. Deering und R. Hinden vom Dez. 1998, insbesondere im Kapitel 3 "IPv6 Header Format" beschrieben. Header und Nutzdatencontainer bilden das IP-Paket. In dem Header sind Übertragungsdaten gespeichert, welche für die Übertragung des IP-Paketes von einem IP-Paket-Sender zu einem IP-Paket-Empfänger notwendig sind. In dem Nutzdatencontainer werden die Nutzdaten übertragen; dies sind solche Daten, die von dem Sender zu dem Empfänger transportiert werden sollen.
  • Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren der obengenannten Art und ein IP-Paket anzugeben, mit denen in zuverlässiger und kostengünstiger Art und Weise die Nutzdatenübertragung verbessert werden kann.
  • Diese Aufgabe wird bei einem Verfahren der oben angegebenen Art erfindungsgemäß dadurch gelöst, dass Zusatznutzdaten in einem Feld eines Headers des IP-Paketes transportiert werden. Hierbei ist insbesondere vorteilhaft, dass in dem Feld des Headers, welches zur Aufnahme von Übertragungsdaten vorgesehen ist, Zusatznutzdaten transportiert werden. Dadurch ist es möglich, neben den in dem Nutzdatencontainer übertragenen Nutzdaten zusätzliche Datenmengen (Zusatznutzdaten) mittels ein und desselben IP-Paketes zu transportieren. Durch den Transport der Zusatznutzdaten tritt vorteilhafterweise keine Vergrößerung des IP-Paketes ein, da die Felder des Headers sowieso mit dem IP-Paket mittransportiert werden; und zwar unabhängig davon, ob sich in diesen Feldern Zusatznutzdaten befinden oder nicht.
  • Das erfindungsgemäße Verfahren kann so ausgestaltet sein, dass ein Feld des Headers verwendet wird, dessen Feldelemente unvollständig belegt sind mit zur Übertragung des IP-Paketes vorgesehenen Übertragungsdaten. Dadurch können vorteilhafterweise "ungenutzte" Feldelemente sinnvoll genutzt werden. Dies betrifft solche Feldelemente des Headers, die beim Übertragen nicht oder nicht vollständig für die Aufnahme von Übertragungsdaten benötigt werden, die aber dennoch (ggf. zum Teil mit "Nullen" gefüllt) mitübertragen werden.
  • Für das erfindungsgemäße Verfahren kann ein IP-Paket verwendet werden, welches nach Vorgaben des Internet Protocols Version 6 (IPv6) aufgebaut ist.
  • Vorteilhafterweise kann als Feld des Headers das "Flow Label"-Feld verwendet werden. Dieses Feld wird oftmals nicht zur Speicherung von Übertragungsdaten benötigt, so dass die 3 Feldelemente dieses Feldes nicht belegt sind und Platz für den Transport von Zusatznutzdaten bieten.
  • Ebenso kann vorteilhaft als Feld des Headers das "Interface ID"-Feld eines Adressfeldes des Headers des IP-Paketes verwendet werden. Das "Interface ID"-Feld eines Adressfeldes des Headers ist oftmals so groß dimensioniert, dass nicht alle Feldelemente (Bits bzw. Bytes) zur Aufnahme der Interfache- ID-Informationen benötigt werden. Dadurch können erfindungsgemäß die ungenutzten Bits bzw. Bytes für die Übertragung der Zusatznutzdaten verwendet werden.
  • Vorteilhafterweise können bei dem erfindungsgemäßen Verfahren die Zusatznutzdaten in verschlüsselter Form in dem Feld des Headers transportiert werden. Durch die Verschlüsselung der Zusatznutzdaten können mit diesen Zusatznutzdaten auch vertrauliche Informationen übertragen werden, welche vor einem Zugriff Dritter geschützt werden sollen.
  • Das erfindungsgemäße Verfahren kann so ausgestaltet sein, dass die Zusatznutzdaten an einem ersten Dateneinspeisungspunkt in das Feld des Headers eingeschrieben werden, wobei der erste Dateneinspeisungspunkt zwischen einem senderseitigen IP-Stack und einem empfängerseitigen IP-Stack an einem Datenkanal angeordnet ist. Dadurch wird es vorteilhafterweise für Einrichtungen, die Zugriff auf den Datenkanal haben (z. B. Vermittlungsstellen eines Betreibers des Datenkanals, Rechner eines Internet-Providers) möglich, über diesen Datenkanal transportierte IP-Pakete zur Übertragung von Zusatznutzdaten einzusetzen.
  • Das erfindungsgemäße Verfahren kann auch so ausgestaltet sein, dass die Zusatznutzdaten an einem zweiten Dateneinspeisungspunkt in das Feld des Headers eingeschrieben werden, wobei der zweite Dateneinspeisungspunkt zwischen einem IP-Paket-Sender und einem senderseitigen IP-Stack an einer Datenübertragungsstrecke angeordnet ist. Bei einer derartigen Ausgestaltung des Verfahrens kann vorteilhafterweise ein mit dem senderseitigen IP-Stack kommunizierendes Kommunikationsendgerät (z. B. Mobiltelefon, Laptop, Palmtop, Computer) die von ihm selbst generierten Pakete zum Transport von Zusatznutzdaten verwenden.
  • Die Zusatznutzdaten können auch bei einem IP-Sender (z. B. einer Rechner-Applikation) in das Feld des Headers eingeschrieben werden. Dadurch ist vorteilhafterweise jedem einzelnen IP-Sender die Benutzung des erfindungsgemäßen Verfahrens zum Übertragen von Zusatznutzdaten möglich.
  • Das erfindungsgemäße Verfahren kann so ablaufen, dass die Zusatznutzdaten durch einen empfängerseitigen IP-Stack für eine Weiterverarbeitung aus dem Feld des Headers ausgelesen werden. Dadurch können vorteilhafterweise die Zusatznutzdaten aus dem IP-Paket extrahiert und einer Weiterverarbeitung zugeführt werden, noch bevor das IP-Paket seinen endgültigen Empfänger (der beispielsweise an den IP empfängerseitigen - Stack angeschlossen ist) erreicht.
  • Das erfindungsgemäße Verfahren kann auch so ausgestaltet sein, dass die Zusatznutzdaten bei einem an einen empfängerseitigen IP-Stack angeschlossenen Netzknoten für eine Weiterverarbeitung aus dem Feld des Headers ausgelesen werden.
  • Das Verfahren kann erfindungsgemäß so ablaufen, dass die Zusatznutzdaten mittels mehrerer aufeinanderfolgender IP-Pakete transportiert werden. Dadurch können vorteilhafterweise auch Zusatznutzdaten mittels des erfindungsgemäßen Verfahrens transportiert werden, welche mehr Speicherplatz benötigen als der in den jeweiligen Feldern des Headers eines einzelnen IP- Pakets vorhandene, zur Übertragung von Zusatznutzdaten geeignete Platz.
  • Das Verfahren kann erfindungsgemäß so ablaufen, dass die Zusatznutzdaten mit einem Kennzeichen übertragen werden, welches die Information enthält, dass die Zusatznutzdaten auf mehrere IP-Pakete verteilt sind. Anhand dieses Kennzeichens kann der Empfänger des IP-Paketes vorteilhafterweise erkennen, dass er den Inhalt von mehr als dem einen IP-Paket auswerten muss, um die kompletten Zusatznutzdaten zu erhalten.
  • Die obengenannte Aufgabe wird ebenfalls erfindungsgemäß gelöst durch ein IP-Paket mit einem Header und einem Nutzdatencontainer, bei dem Zusatznutzdaten in einem Feld des Headers eingetragen sind. Dadurch kann vorteilhafterweise das Feld des Headers für den Transport von zusätzlichen Nutzdaten (Zusatznutzdaten) verwendet werden.
  • Das IP-Paket kann erfindungsgemäß so aufgebaut sein, dass das Feld des Headers ein Feld ist, dessen Feldelemente unvollständig belegt sind mit zur Übertragung des IP-Paketes vorgesehenen Übertragungsdaten. Dadurch kann vorteilhafterweise der aufgrund der unvollständigen Belegung des Feldes vorhandene Platz genutzt werden für die Übertragung von Zusatznutzdaten.
  • Das IP-Paket kann so aufgebaut sein, dass die Zusatznutzdaten in das "Flow Label"-Feld des Headers eingetragen sind. Ebenso kann das IP-Paket so aufgebaut sein, dass die Zusatznutzdaten in das "Interface ID"-Feld eines Adressfeldes des Headers eingetragen sind.
  • Die Zusatznutzdaten können auch in verschlüsselter Form in das Feld des Headers eingetragen sein.
  • Das IP-Paket kann erfindungsgemäß so gestaltet sein, dass es ein IP-Paket einer Folge von IP-Paketen ist.
  • Das IP-Paket kann vorteilhafterweise so aufgebaut sein, dass die Zusatznutzdaten ein Kennzeichen aufweisen, welches die Information enthält, dass die Zusatznutzdaten auf mehrere IP- Pakete verteilt sind.
  • Zur weiteren Erläuterung der Erfindung ist in
  • Fig. 1 ein Ausführungsbeispiel eines IP-Paketes, in
  • Fig. 2 eine detaillierte Darstellung eines Ausführungsbeispiels eines Adressfeldes eines IP-Paketes, in
  • Fig. 3 eine detaillierte Darstellung eines Ausführungsbeispiels eines weiteren Adressfeldes eines IP-Paketes, in
  • Fig. 4 eine schematische Darstellung eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens, in
  • Fig. 5 eine weitere schematische Darstellung eines Teilaspektes eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens, in
  • Fig. 6 eine weitere schematische Darstellung eines Ausführungsbeispiels eines Teilsaspektes des erfindungsgemäßen Verfahrens und in
  • Fig. 7 ein weiteres schematisch dargestelltes Ausführungsbeispiel dargestellt.
  • In Fig. 1 ist schematisch ein Ausführungsbeispiel eines IP- Paketes IP dargestellt. Das IP-Paket IP besteht aus einem Header HD und einem Nutzdatencontainer NC. Ein Beispiel für einen derartigen Header HD ist aus der obenerwähnten Druckschrift "Internet Protocol Version 6 Specification" aus Kapitel 3 "IPv6 Header Format" bekannt. Der Header HD weist verschiedene Teilbereiche auf, von denen als eine Auswahl die Teilbereiche V (= Version), TC (= Traffic Class), FL (= Flow Label), PL (= Payload Length), SA (= Source Address) und DA (= Destination Address) abgebildet sind. An den Header HD schließt sich der Nutzdatencontainer NC an, welcher die Nutzdaten (auch Payload genannt) beinhaltet. Unter Nutzdatencontainer wird im Rahmen dieser Anmeldung der gesamte "Rest" des IP-Paketes verstanden, welcher zusammen mit dem Header HD das vollständige IP-Paket bildet.
  • Das Feld "Flow Label" FL des Headers HD ist gelegentlich nicht belegt mit Daten (Übertragungsdaten), welche zur Durchführung der Übertragung des IP-Paketes von einem IP-Paket- Sender zu einem IP-Paket-Empfänger benötigt werden. Dieses Feld wird erfindungsgemäß dazu genutzt, Zusatznutzdaten zu beinhalten; diese Zusatznutzdaten können also auf diese Art und Weise mit dem IP-Paket transportiert werden. Unter Zusatznutzdaten werden im Rahmen dieser Anmeldung solche Nutzdaten verstanden, die zusätzlich zu den im Nutzdatencontainer NC übertragenen Nutzdaten mittels des IP-Paketes zu dem vorgesehenen Empfänger transportiert werden.
  • In diesem Ausführungsbeispiel werden in dem Feld "Flow Label" FL die Zeichen der zwei Buchstaben I und N übertragen. Dazu können beispielsweise zwei Bytes des Feldes verwendet werden. In dem Adressfeld SA des Headers werden als Zusatznutzdaten die Zeichen der Buchstaben F und O und in dem Adressfeld DA werden als Zusatznutzdaten die Zeichen der Buchstaben B und O transportiert. (Es ist natürlich auch möglich, jeweils nur ein Feld des Headers oder zwei Felder des Headers für den Transport der Zusatznutzdaten zu verwenden. Beispielsweise können für den Transport der Zusatznutzdaten nur die beiden Adreßfelder SA und DA benutzt werden, das "Flow Label"-Feld FL für den Transport der Zusatznutzdaten jedoch unbenutzt bleiben.)
  • In Fig. 2 ist ein detailliertes Ausführungsbeispiel für das Adressfeld "Source Address" SA angegeben; das Adressfeld DA kann einen ähnlichen Aufbau aufweisen. Das Adressfeld "Source Address" SA weist in diesem Ausführungsbeispiel übereinstimmend mit der IPv6-Spezifikation eine Länge von 128 Bits auf. Die ersten n Bits dieses Adressfeldes bilden ein sog. "subnet prefix"; dabei handelt es sich um eine Adressangabe, welche ein Kommunikationsendgerät (Handy, Palmtop oder Computer) eindeutig adressiert. Der zweite Teil des Adressfeldes SA beinhaltet eine sog. "Interface ID". Dieser Teil des Adressfeldes belegt (128- n) Bits. Mit Hilfe dieser "Interface ID" können dem Kommunikationsendgerät eine Vielzahl von (Unter-) Adressen zugeordnet werden.
  • In Fig. 3 ist ein detaillierteres Ausführungsbeispiel des Adressfeldes "Source Address" SA dargestellt; das Adressfeldes "Destination Address" DA kann einen ähnlichen Aufbau haben. In diesem Beispiel unterteilt sich der "subnet prefix" in fünf verschiedene Felder:
    FP 3 Bits
    TLA ID 13 Bits
    RES 8 Bits
    NLA ID 24 Bits
    SLA ID 16 Bits.
  • Die "Interface ID" hat in diesem Ausführungsbeispiel eine Länge von 64 Bits; insgesamt ergibt sich damit eine Länge des Adressfeldes SA von 128 Bits. Durch Nutzung sämtlicher 64 Bits der "Interface ID" ließe sich eine sehr große Anzahl (264) Unteradressen pro Kommunikationsendgerät realisieren. Eine derartig große Anzahl von Unteradressen wird allerdings in der Praxis oftmals nicht benötigt. Beispielsweise könnten in einem praktischen Anwendungsfall 256 Unteradressen pro Kommunikationsendgerät gewünscht werden. Zur Unterscheidung dieser 256 Unteradressen wären 8 Bit (28 = 256) ausreichend. In diesem Beispiel blieben von den 64 Bits 56 Bits (= 7 Bytes) unbenutzt; diese 7 Bytes können zum Transport von Zusatznutzdaten verwendet werden. In der Fig. 3 ist dies dadurch symbolisiert, dass in das Feld "Interface Id" die Zeichen der Buchstaben B und E eingetragen sind, welche einen Teil der Zusatznutzdaten darstellen.
  • In Fig. 4 ist ein Ausführungsbeispiel eines Transportvorganges für Zusatznutzdaten dargestellt. Ein erster IP-Paket-Sender S1, ein zweite IP-Paket-Sender S2 und ein dritter IP-Paket-Sender S3 sind an einen senderseitigen IP-Stack IPS1 angeschlossen. Der IP-Paket-Sender S1 verfügt über eine Nutzlast "payload", die an einen ersten Empfänger E1 übertragen werden soll. Daher wird ein IP-Paket IP1 erzeugt, welches von dem senderseitigen IP-Stack IPS1 über einen Datenkanal DK zu einem empfängerseitigen IP-Stack IPS2 übertragen wird. Dieses erste IP-Paket IP1 enthält die Nutzdaten des IP-Paket-Senders S1 als "payload" im Nutzdatencontainer NC.
  • An dem Datenkanal DK ist zwischen dem senderseitigen IP-Stack IPS1 und dem empfängerseitigen IP-Stack IPS2 ein Dateneinspeisungspunkt DP1 angeordnet. Mit diesem Dateneinspeisungspunkt DP1 ist ein Zusatznutzdatensender ZS1 verbunden. Dieser Zusatznutzdatensender ZS1 verfügt über Zusatznutzdaten (in diesem Beispiel symbolisiert durch die Zeichenkette "INFOBOTSCHAFT"); diese Zusatznutzdaten sollen unter Nutzung des ersten IP-Paketes IP1 transportiert werden. Zu diesem Zweck überträgt der Zusatznutzdatensender ZS1 die Zeichenkette "INFOBOTSCHAFT" an den Dateneinspeisungspunkt DP1, an welchem die Zusatznutzdaten in das IP-Paket IP1 eingeschrieben werden. Dies erfolgt im Detail so, dass in das Feld "Flow Label" FL des Headers die Zeichen I und N, in das Adressfeld "Source Address" SA die Zeichen F und 0 und in das Adressfeld "Destination Address" DA die Zeichen B und O eingeschrieben werden. Danach wird das IP-Paket IP1 in gewohnter Art und Weise zu dem empfängerseitigen IP-Stack IPS2 transportiert. Dieser empfängerseitige IP-Stack verfügt über eine erste Leseeinrichtung LE1, mittels der er die Zusatznutzdaten aus dem IP-Paket IP1 herausliest. So ist der empfängerseitige IP- Stack IPS2 in der Lage, aus dem ersten IP-Paket IP1 die Zeichenfolge "INFOBO" auszulesen.
  • Da das erste Internetpaket IP1 keinen ausreichenden Platz im Header bietet, um die kompletten Zusatznutzdaten zu übertragen, werden die restlichen Teile der Zusatznutzdaten (die Zeichenkette "TSCHAFT") mit Hilfe eines zweiten vom senderseitigen IP-Stack IPS1 zum empfängerseitigen IP-Stack IPS2 übertragenen IP-Paketes IP2 transportiert. Diese restlichen Zeichen der Zusatznutzdaten werden wie in der Figur ersichtlich auf die entsprechenden Felder des Headers des zweiten Internetpaketes IP2 verteilt.
  • Der empfängerseitige IP-Stack IPS2 liest nun aus dem zweiten Internetpaket IP2 die restlichen Zeichen ("TSCHAFT") der Zusatznutzdaten aus und ist nun in der Lage, die einzelnen Zeichen zu den vollständigen Zusatznutzdaten zusammenzusetzen.
  • Daraufhin können die Zusatznutzdaten ("INFOBOTSCHAFT") einer weiteren Verarbeitung zugeführt werden; sie können beispielsweise auf eine Anzeige Anz eines Mobiltelefons dargestellt werden.
  • Um z. B. dem empfängerseitigen IP-Stack IPS2 zu signalisieren, dass die Zusatznutzdaten auf mehrere IP-Pakete verteilt übertragen werden, kann beispielsweise an die Zeichenkette "BO" im ersten IP-Paket IP1 ein Kennzeichen "&" angehängt werden. Dadurch wird dem empfängerseitigen IP-Stack IPS2 mitgeteilt, dass es notwendig ist, weitere IP-Pakete auszuwerten, um die vollständigen Zusatznutzdaten zu erhalten.
  • In einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens können die Zusatznutzdaten auch bei einem an den empfängerseitigen IP-Stack IPS2 angeschlossenen Netzknoten aus den IP-Paketen IP1 und IP2 ausgelesen werden. In diesem Ausführungsbeispiel verfügt ein zweiter Empfänger E2 über eine zweite Leseeinrichtung LE2, mittels der er die Zusatznutzdaten aus den IP-Paketen ausliest. Dies geschieht in der oben bereits beschriebenen Art und Weise. Von dem zweiten Empfänger E2 können die Zusatznutzdaten an ein Datenverarbeitungsgerät DV weitergeleitet werden, welches eine Weiterverarbeitung der Zusatznutzdaten vornimmt.
  • In Fig. 5 ist eine weitere Möglichkeit dargestellt, wie die IP-Pakete mit den Zusatznutzdaten versehen werden können. In diesem weiteren Ausführungsbeispiel ist ein zweiter Dateneinspeisungspunkt DP2 zwischen dem IP-Paket-Sender S1 und dem senderseitigen IP-Stack IPS1 an einer Datenübertragungsstrecke DS angeordnet. Ein zweiter Zusatznutzdatensender ZS2 überträgt die Zusatznutzdaten an den zweiten Dateneinspeisungspunkt DP2, wo diese in die Header der IP-Pakete eingetragen werden.
  • In Fig. 6 ist eine dritte Möglichkeit dargestellt, Zusatzdaten in die IP-Pakete einzutragen. Bei diesem dritten Ausführungsbeispiel ist ein dritter Zusatznutzdatensender Z53 direkt mit dem ersten IP-Paket-Sender S1 verbunden und überträgt die Zusatznutzdaten zu diesem Sender. Dort werden die Zusatznutzdaten in das IP-Paket eingeschrieben.
  • In Fig. 7 sind schematisch weitere vorteilhafte Stellen dargestellt, an denen mittels Dateneinspeisungspunkten "+" die Zusatznutzdaten in die IP-Pakete eingeschrieben werden können. Dies kann geschehen bei dem IP-Stack des Senders S1, aber auch bei IP-Stacks von IE-Einheiten (IE = Internet Equipment, z. B. Router), welche auf dem Datenübertragungsweg zwischen Sender S1 und Empfänger E angeordnet sind.
  • Die Zusatz-Nutzdaten können auch mittels eines an sich bekannten Verschlüsselungsverfahrens (beispielsweise des DES- Verfahrens) verschlüsselt werden. Anstelle der Zeichenkette "INFOBOTSCHAFT" wird dann z. B. die Zeichenkette "7H&tsf436" in die entsprechenden Felder des Headers eingetragen.
  • Das erfindungsgemäße Verfahren lässt sich besonders vorteilhaft mit IP-Paketen anwenden, welche nach den Spezifikationen des Internet-Protokolls Version 6 (IPv6) aufgebaut sind. Bei der Verwendung dieses Protokolls (das auch als "Next Generation Internet Protocol" bezeichnet wird) haben die Adressfelder mit 128 Bit gegenüber den Adressfeldern des Vorgängerprotokolls eine vierfache Länge. Dies führt zu einem stark erweiterten Adressraum, allerdings ergeben sich zwangsweise auch vergrößerte Datenpakete. Der dadurch entstandene "Overhead" wirkt sich besonders bei einer wiederholten Übertragung von kleinen Datenmengen negativ aus. Dies ist insbesondere bei der Luftschnittstelle von Mobilfunknetzen relevant, da diese Luftschnittstelle einen Engpass der Datenübertragung darstellt. Die Verarbeitung von vielen kleinen Paketen wirkt sich auch auf die Performance der Netzknoten von Kommunikationsnetzen negativ aus.
  • Um die vorhandenen Netzressourcen optimal auszunutzen, können zwar Kompressionstechniken zum Einsatz kommen, aber auch dabei ist es notwendig, bei einer wiederholten Übertragung von nur kleinen Datenmengen immer neue komplette IP-Pakete zu versenden. Außerdem ist auch die Komprimierung von Daten mit Aufwand verbunden. Durch das erfindungsgemäße Verfahren können vorteilhaft insbesondere kleine Datenmengen als Zusatznutzdaten mit IP-Paketen mittransportiert werden. Dabei können vorzugsweise solche IP-Pakete verwendet werden, die sowieso über ein Kommunikationsnetz transportiert werden müssen. Ein Beispiel für derartige sowieso zu transportierende IP-Pakete wären IP-Pakete zur Realisierung einer "Voice over IP" (VoIP)-Applikation. Als Zusatznutzdaten können z. B. Daten von Kurznachrichten, SMS = Short Messages, MMS = Multi Media Messages, Emails, Werbeinformationen oder Kontrollnachrichten zwischen Netzelementen von Kommunikationsnetzen übertragen werden. Ein weiteres Beispiels für IP-Pakete, welche sowieso über das Netz transportieren sind, sind IP-Pakete zum Abruf einer Internetseite (HTML-Seite). Das erfindungsgemäße Verfahren ist jedoch nicht auf diese Bespiele beschränkt, prinzipiell können sämtliche Arten von Daten als Zusatznutzdaten in IP-Paketen "mitgegeben" werden.
  • Beim Versenden von IP-Paketen von beliebigen Diensten können also automatisch Zusatzinformationen mitgesendet werden. Dadurch kann die Anzahl der zu sendenden IP-Pakete verringert werden (gegenüber der Anzahl der IP-Pakete, die bei den aus dem Stand der Technik bekannten Verfahren gesendet werden). Dadurch können die Ressourcen (z. B. Luftschnittstelle) besser ausgenutzt werden. Die Erfindung kann bei beliebigen Nutzdatenübertragungen angewendet werden, bei denen IP-Pakete mit IP-Headern oder eine IP-Adressierung verwendet wird. Besonders vorteilhaft kann die Erfindung angewendet werden bei Verwendung des Internet Protokolls Version 6 (Ipv6). Bei Verwendung einzelner Felder des IP-Headers (z. B. Feld "Flow Label" FL, Adressfelder "Source Address" SA oder "Destination Address" DA) werden andere Felder des IP-Headers nicht beeinflusst; eine Abhängigkeit von in diesen anderen Feldern gespeicherten Daten besteht nicht. Die mitgesendeten Zusatznutzdaten in die IP-Headern können aus beliebigen Diensten oder Nutzungsvorgängen stammen.
  • Bei Anwendung des erfindungsgemäßen Verfahrens und der erfindungsgemäßen IP-Pakete sind für die Übertragung von Zusatznutzdaten, insbesondere von kleineren Datenmengen, keine zusätzlichen IP-Pakete erforderlich. Daraus resultiert ein Performance-Zuwachs von Netzelementen der Kommunikationsnetze und eine bessere Ausnutzung der Ressourcen (z. B. der Luftschnittstelle). Insbesondere bei Verwendung des Internet Protokolls Version 6 kann der regelmäßig auftretende Overhead an Feldern bzw. Feldlängen in den IP-Paket-Headern ökonomisch genutzt werden. Bei dem Verfahren können die unterschiedlichsten Arten von Zusatznutzdaten transportiert werden. Diese Zusatznutzdaten können allen denkbaren Protokollen, welche oberhalb der Schicht 3 des ISO/OSI-Modells angesiedelt sind, entstammen. Bei Nutzung von einer großen Anzahl von IP- Paketen können auch Zusatznutzdaten, welches eine hohe Datenkapazität aufweisen, transportiert werden.

Claims (20)

1. Verfahren zum Übertragen von Nutzdaten (payload) in einem Nutzdatencontainer (NC) eines IP-Paketes (IP1, IP2), dadurch gekennzeichnet, dass Zusatznutzdaten (INFOBOTSCHAFT) in einem Feld (FL, SA, DA, Interface ID) eines Headers (HD) des IP-Paketes (IP1, IP2) transportiert werden.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Feld (FL, SA, DA, Interface ID) des Headers (HD) verwendet wird, dessen Feldelemente unvollständig belegt sind mit zur Übertragung des IP-Paketes vorgesehenen Übertragungsdaten.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein IP-Paket (IP1, IP2) verwendet wird, welches nach IPv6- Vorgaben aufgebaut ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Feld des Headers (HD) das "Flow Label"-Feld (FL) verwendet wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Feld des Headers das "Interface Id"-Feld (Interface ID) eines Adressfeldes des Headers (HD) des IP-Paketes verwendet wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten in verschlüsselter Form in dem Feld des Headers (HD) transportiert werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten an einem ersten Dateneinspeisungspunkt (DP1) in das Feld des Headers (HD) eingeschrieben werden, wobei der erste Dateneinspeisungspunkt (DP1) zwischen einem senderseitigen IP-Stack (IPS1) und einem empfängerseitigen IP-Stack (IPS2) an einem Datenkanal (DK) angeordnet ist.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten an einem zweiten Dateneinspeisungspunkt (DP2) in das Feld des Headers (HD) eingeschrieben werden, wobei der zweite Dateneinspeisungspunkt (DP2) zwischen einem IP-Paket-Sender (S1) und einem senderseitigen IP-Stack (IPS1) an einer Datenübertragungsstrecke (DS) angeordnet ist.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten bei einem IP-Sender (S1) in das Feld des Headers (HD) eingeschrieben werden.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten durch einen empfängerseitigen IP-Stack (IPS2) für eine Weiterverarbeitung (Anz) aus dem Feld des Headers (HD) ausgelesen werden.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten bei einem an einen empfängerseitigen IP- Stack (IPS2) angeschlossenen Netzknoten (E2) für eine Weiterverarbeitung (DV) aus dem Feld des Headers (HD) ausgelesen werden.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten mittels mehrerer aufeinanderfolgender IP- Pakete (IP1, IP2) transportiert werden.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zusatznutzdaten mit einem Kennzeichen übertragen werden, welches die Information enthält, dass die Zusatznutzdaten auf mehrere IP-Pakete (IP1, IP2) verteilt sind.
14. IP-Paket (IP1) mit einem Header (HD) und einem Nutzdatencontainer (NC), dadurch gekennzeichnet, dass Zusatznutzdaten (IN, FO, BO) in einem Feld (FL, SA, DA, Interface ID) des Headers eingetragen sind.
15. IP-Paket nach Anspruch 14, dadurch gekennzeichnet, dass das Feld (FL, SA, DA, Interface ID) des Headers (HD) ein Feld ist, dessen Feldelemente unvollständig belegt sind mit zur Übertragung des IP-Paketes (IP1) vorgesehenen Übertragungsdaten.
16. IP-Paket nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass die Zusatznutzdaten in das "Flow Label"-Feld (FL) des Headers (HD) eingetragen sind.
17. IP-Paket nach einem der Ansprüche 14 bis 16, dadurch gekennzeichnet, dass die Zusatznutzdaten in das "Interface Id"-Feld (Interface ID) eines Adressfeldes (SA, DA) des Headers (HD) eingetragen sind.
18. IP-Paket nach einem der Ansprüche 14 bis 17, dadurch gekennzeichnet, dass die Zusatznutzdaten (IN, FO, BO, TSC, HA, FT) in verschlüsselter Form in das Feld des Headers (HD) eingetragen sind.
19. IP-Paket nach einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, dass es ein IP-Paket (IP1) einer Folge (IP1, IP2) von IP-Paketen ist.
20. IP-Paket nach einem der Ansprüche 14 bis 19, dadurch gekennzeichnet, dass die Zusatznutzdaten (IN, FO, BO, TSC, HA, FT) ein Kennzeichen aufweisen, welches die Information enthält, dass die Zusatznutzdaten auf mehrere IP-Pakete (IP1, IP2) verteilt sind.
DE10212589A 2002-03-15 2002-03-15 Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket Expired - Fee Related DE10212589B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE10212589A DE10212589B4 (de) 2002-03-15 2002-03-15 Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10212589A DE10212589B4 (de) 2002-03-15 2002-03-15 Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket

Publications (2)

Publication Number Publication Date
DE10212589A1 true DE10212589A1 (de) 2003-10-09
DE10212589B4 DE10212589B4 (de) 2007-06-06

Family

ID=27815840

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10212589A Expired - Fee Related DE10212589B4 (de) 2002-03-15 2002-03-15 Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket

Country Status (1)

Country Link
DE (1) DE10212589B4 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5650825A (en) * 1995-03-31 1997-07-22 Matsushita Electric Corporation Of America Method and apparatus for sending private data instead of stuffing bits in an MPEG bit stream
WO2000035163A1 (en) * 1998-12-08 2000-06-15 Nokia Mobile Phones Ltd. A method for optimizing of data transmission
WO2002073908A2 (en) * 2001-03-09 2002-09-19 Vitesse Semiconductor Corporation A method and a system for transmitting information through a communication line

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10047131B4 (de) * 2000-09-22 2006-01-19 Siemens Ag Verfahren zum Betreiben eines Zugangsnetzes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5650825A (en) * 1995-03-31 1997-07-22 Matsushita Electric Corporation Of America Method and apparatus for sending private data instead of stuffing bits in an MPEG bit stream
WO2000035163A1 (en) * 1998-12-08 2000-06-15 Nokia Mobile Phones Ltd. A method for optimizing of data transmission
WO2002073908A2 (en) * 2001-03-09 2002-09-19 Vitesse Semiconductor Corporation A method and a system for transmitting information through a communication line

Also Published As

Publication number Publication date
DE10212589B4 (de) 2007-06-06

Similar Documents

Publication Publication Date Title
AT411312B (de) Verfahren zum übermitteln von kurznachrichten (sms) zwischen rechnern im internet
DE60110311T2 (de) Verfahren und Vorrichtung zur Mehrfachsendung
EP1405422B1 (de) Verfahren zur optimierten nutzung von sctp (stream control transmission protocol) in mpls (multi protocol label switching) netzen
EP1994677B1 (de) Verfahren zur übertragung der identität einer multicast-nachricht, verfahren und vorrichtung zur übertragung einer multicast-nachricht sowie vorrichtung zum empfangen einer multicast-nachricht
EP1283650A1 (de) Verfahren, Sende-/Empfangseinheit und Kommunikationssystem zur Übertragung von Daten von einem Versender an mehrere Empfänger
WO2001045320A2 (de) Verfahren zur übertragung von elektronischen postnachrichten
DE60012168T2 (de) Verfahren und anordnung zur übertragung multimediabezogener information in einem paketvermittelten zellularen funknetz mit externer verbindung
DE19730159A1 (de) Kommunikationsverfahren und System
EP1438825B1 (de) Verfahren und vorrichtungen zur header-kompression in paketorientierten netzwerken
DE60108324T2 (de) System und Verfahren zur Erhöhung von Nachrichtendurchsatz in einem Funknetzwerk
DE19637026A1 (de) Lokales Netzwerk mit zur Funkübertragung vorgesehenen Terminals
DE102004003549B4 (de) Kommunikationssystem und Verfahren zum Verarbeiten einer von einem Mobilfunkendgerät eines Mobilfunk-Kommunikationsnetzes einem Nachrichtenfilter-Rechner zugeführten Anforderungs-Nachricht
DE60219263T2 (de) Überwachung und Übertragung von QOS-Daten in einem Telekommunikationsnetzwerk
EP1293099B1 (de) Verfahren zur übertragung von kurznachrichten
EP1049294A2 (de) Netzwerk mit mehreren Netzwerk-clustern zur drahtlosen Übertragung von Paketen
DE19959528B4 (de) Verfahren zur Übertragung von elektronischen Postnachrichten
DE10212589B4 (de) Verfahren zum Übertragen von Nutzdaten mittels eines IP-Paketes und IP-Paket
EP1992127B1 (de) Kommunikationssystem, rechner und verfahren zum ermitteln eines zu verwendenden kommunikationsprotokolls in einem kommunikationssystem
WO2007098721A1 (de) Verfahren zum erzeugen eines adressfeldes, verfahren und vorrichtung zur übertragung einer electronischen nachricht sowie datenpaket
EP1265408A1 (de) System und Verfahren zum Verteilen von Nachrichten
WO2004006593A1 (de) Mms-nachrichtenübertragungsverfahren und -system
DE10156197A1 (de) Verfahren zur Datenübertragung in einem Datenkommunikationsnetz, zugehörige Sende-/Empfangseinheit sowie Funkkommunikationssystem
DE10207286B4 (de) Verfahren zum Zusammenstellen und Zerlegen von Internet-Protokoll-Paketen
WO2003026330A1 (de) Verfahren zur datenübertragung in einem datenkommunikationsnetz, zugehörige sende-/empfangseinheit sowie funkkommunikationssystem
DE10219316A1 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem Kommunikationssystem

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8327 Change in the person/name/address of the patent owner

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee