DE69931874T2

DE69931874T2 - Verfahren zur Herstellung und Aufrechterhaltung einer mobilen TCP-Verbindung

Info

Publication number: DE69931874T2
Application number: DE69931874T
Authority: DE
Inventors: Milo Lincolnwood Orsic
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1998-10-28
Filing date: 1999-10-18
Publication date: 2006-11-30
Anticipated expiration: 2019-10-19
Also published as: BR9905817A; JP2000138976A; JP2004343805A; ATE330406T1; CN1252662A; CA2281431A1; DE69931874D1; EP0998098A2; EP0998098A3; EP0998098B1; US20050047351A1; KR20000062144A; AU5597599A

Description

ALLGEMEINER STAND DER TECHNIK
Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein mobiles TCP (m-TCP) und ein Verfahren zum Herstellen und Halten einer m-TCP-Verbindung zwischen mobilen Endgeräten/Leitrechnern, z.B. Computern, über das Internet oder dergleichen.
Beschreibung des Standes der Technik
Eine TCP/IP- (Übertragungssteuerprotokoll/Internet-Protokoll) Folge umfasst Protokolle, welche die Kommunikation zwischen Computern im Internet steuern. Diese Protokolle umfassen ein TCP, ein IP und ein Benutzerdatagrammprotokoll (UDP). Das TCP ist ein verbindungsorientierter Dienst, und das UDP ist ein verbindungsloser Dienst.
Herkömmlicherweise erfordert das TCP feste IP-Endpunktadressen, um eine TCP-Verbindung zwischen Endgeräten/Leitrechnern (T/Hs) herzustellen. Diese IP-Endpunktadressen können nicht mehr geändert werden, sobald die TCP-Verbindung hergestellt worden ist. Das heißt, eine TCP-Verbindung zwischen zwei Entitäten, (z.B. T/Hs), wird eindeutig durch ein Paar von Endpunkten identifiziert. Jeder der Endpunkte umfasst ein Zwei-Tupel, das sich aus einer IP-Adresse des Leitrechners und einer bestimmten TCP-Port-Nummer in dem Leitrechner zusammensetzt. Diese IP-Adressen und die TCP-Port-Nummern sind fest und unveränderlich, sobald die TCP-Verbindung hergestellt worden ist. Allerdings ändern sich für mobile T/Hs, die durch das Netzwerk roamen, wie beispielsweise das Internet, die Endpunkte ständig. Daher sind herkömmliche TCP-Dienste zum Herstellen und Halten einer Kommunikation zwischen mobilen T/Hs unzureichend.
Haas Z.J. und andere: "Mobile-TCP: an asymmetric transport protocol design for mobile systems", Communications, 1997. ICC '97 Montreal, Towards the Knowledge Millennium. 1997 IEEE International Conference Montreal, Que., Kanada, 8.-12. Juni 1997, New York, NY, USA, IEEE, US, 8. Juni 1997 (08.06.1997), Seite 1054-1058, offenbart das Erstellen eines Systems, in dem ein Mobil-Netzwerkübergangs-Proxy zwischen eine mobile Entität und eine feste Entität eingefügt ist. Eine Verbindungskennung und eine Rückverbindungskennung werden in einem TCP-Header bereitgestellt. Wenn das mobile Endgerät sendet, ist die Verbindungskennung die Verbindungskennung des mobilen Endgeräts, und die Rückverbindungskennung ist die Rückverbindungskennung des Mobil-Netzwerkübergangs. Des Weiteren umfassen der Ziel-Port und die Ziel-IP-Adresse, die in dem TCP-Paket-Header bereitgestellt werden, den Ziel-Port und die Ziel-IP-Adresse der Ziel-Entität; und zwar der festen Entität.
Maltz D.A. und andere: "MSOCKS: an architecture for transport layer mobility", INFOCOM '98. Seventeenth Annual Joint Conference of the IEEE Computer and Communications Societies, Proceedings, IEEE San Francisco, CA, USA, 29. März-2. April 1998, New York, NY, USA, IEEE, US, 29. März 1998 (29.03.1998), Seite 1037-1045, offenbart ebenfalls die Einfügung eines Proxy zwischen einen mobilen Client und einen Server. Der Proxy entscheidet über eine Verbindungskennung, die in Kommunikationssitzungen zwischen dem mobilen Endgerät und dem Proxy verwendet werden soll. Statt einer Bereitstellung einer Verbindungskennung für die erste Kommunikationsentität und einer Verbindungskennung für die zweite Verbindungsentität wird eine einzelne Verbindungskennung bereitgestellt, die nur vom Proxy zugewiesen wird.
Kuang-Yeh Wang und andere: "Mobile-end transport protocol: an alternative to TCP/IP over wireless links", INFOCOM '98. Seventeenth Annual Joint Conference of the IEEE Computer and Communications Societies, Proceedings, IEEE San Francisco, CA, USA, 29. März-2. April 1998, New York, NY, USA, IEEE, US, 29. März 1998 (29.03.1998), Seite 1046-1053, offenbart das Hinzufügen einer Verbindungskennung zu dem TCP-Header in einer Kommunikation zwischen einem mobilen Endgerät und einer Basisstation. Die Verbindungskennung wird allein von der Basisstation zugewiesen.
KURZDARSTELLUNG DER ERFINDUNG
Kommunikationsverfahren und Computerprogramme gemäß der Erfindung sind wie in den selbstständigen Ansprüchen dargelegt. Bevorzugte Ausführungsformen sind in den Unteransprüchen dargelegt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird besser aus der folgenden ausführlichen Beschreibung und den begleitenden Zeichnungen verständlich, die nur zu Zwecken der Veranschaulichung angeführt sind, wobei Bezugszeichen entsprechende Teile in den verschiedenen Zeichnungen bezeichnen und wobei:
1 eine schematische Darstellung eines Kommunikationssystems, das über das Internet arbeitet, entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
2 eine Struktur einer Zelle in dem Kommunikationssystem von 1 zeigt; und
3 eine interne Datenstruktur eines TCP-Headers gemäß der vorliegenden Erfindung zeigt.
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Die folgende ausführliche Beschreibung betrifft ein m-TCP und ein Verfahren zum Herstellen und Halten einer m-TCP-Verbindung gemäß den Ausführungsformen der vorliegenden Erfindung. Das m-TCP gestattet das Senden von Datagrammen zwischen mobilen T/Hs (z.B. Computern), die virtuell über das Internet miteinander verbunden sind. Ein Datagramm setzt sich aus einem Datensegment und einem IP-Header zusammen.
1 zeigt eine allgemeine schematische Darstellung eines Kommunikationssystems, das über das Internet arbeitet, gemäß der vorliegenden Erfindung. Wie hierin gezeigt, umfasst das Kommunikationssystem 10 eine Vielzahl von Zellen 12₁ , 12₂ ... 12_N und einen nichtmobilen Leitrechner 16, die über das Internet 14 kommunizieren. Diese Zellen 12₁ , 12₂ ... 12_N definieren ein untergeordnetes Netzwerk mit drahtlosem Zugang, d.h. eine m-TCP/IP-Folge.
Jeder der Zellen 12₁ , 12₂ ... 12_N (Zelle 12) umfasst eine Basisstation (BS) 18 und eine Vielzahl von mobilen T/Hs 20₁ , 20₂ ... 20_N , wie in 2 gezeigt. Die BS 18 stellt Funk-Zugang zu und von der Vielzahl von mobilen T/Hs 20₁ , 20₂ ... 20_N bereit und funktioniert als ein Router zum Leiten von IP-Verkehr zwischen den mobilen T/Hs 20₁ , 20₂ ... 20_N über das Internet 14. Der IP-Verkehr in der Richtung stromabwärts, (d.h. von der BS 18 zu dem T/H), wird durch die BS 18 rundgesendet, wogegen in der Richtung stromaufwärts, (d.h. von dem T/H zu der BS 18), der IP-Verkehr durch einen statistisch gemeinsam genutzten Stromaufwärts-Funkkanal gesendet wird. Jedes der mobilen T/Hs 20₁ , 20₂ ... 20_N (mobiles T/H 20) kann mit wenigstens zwei BSs gleichzeitig kommunizieren.
Jede Zelle 12 hat ihre eigene IP-Adresse, z.B. NETID, um die Zelle zu identifizieren, und eine Vielzahl von virtuellen Zugangs-Ports, an die verschiedenen T/Hs 20₁ , 20₂ ... 20_N angeschlossen sind, um über das Internet 14 unter der Steuerung der BS 18 miteinander zu kommunizieren. Zum Identifizieren dieser Zugangs-Ports besitzt jeder Zugangs-Port eine Leitrechner-IP-Adresse, z.B. HOSTID.
Jedes mobile T/H 20 besitzt einen permanenten Domänennamen zum Identifizieren des T/H. Der Domänenname ist in einem nichtflüchtigen Speicher des jeweiligen T/H gespeichert. Des Weiteren besitzt jedes mobile T/H 20 einen Domänennamen-Server (DNS), um darin den Domänennamen des mobilen T/H unter einer neuen Klasse von Domänennamen zu registrieren, z.B. Mobile Internet Class (MIC). Der DNS jedes mobilen T/H 20 speichert die IP-Adresse des mobilen T/H 20 und aktualisiert diese, welche die aktuelle Adresse des mobilen T/H 20 darstellt. Wenn das mobile T/H 20 durch das Netzwerk roamt, (z.B. das Internet 14), indem es sich z.B. an eine neue BS anschließt, erhält das mobile T/H 20 eine neue IP-Adresse. Der DNS des mobilen T/H 20 aktualisiert die IP-Adresse des T/H 20 mit der neu erhaltenen IP-Adresse. Wenn sich das mobile T/H 20 vollständig aus dem Netzwerk abschaltet, speichert der DNS keine IP-Adresse für das mobile T/H 20
Die neuen IP-Adressen werden durch einen m-DHCP-(Dynamic Host Control Protocol) Server zugewiesen, wenn die T/Hs 20₁ , 20₂ ... 20_N durch das Netzwerk roamen, wobei sie ihre IP-Adressen ständig ändern. Jede BS 18 kann darin einen m-DHCP-Server oder seine Funktionen aufnehmen. Wenn die BS 18 den m-DHCP-Server aufnimmt, ist eine Anzahl von IP-Adressen, die jeder BS 18 zugewiesen werden, größer als die maximale Anzahl von mobilen T/Hs 20₁ , 20₂ ... 20_N , die gegenwärtig an die entsprechende Zelle angeschlossen sind. Wann immer eine IP-Adresse, die nicht länger verwendet wird, an die Sammlung von IP-Adressen in dem m-DHCP-Server zurückge geben wird, ist die zurückgegebene IP-Adresse für eine vorbestimmte Zeitdauer vorübergehend nicht verfügbar, um Störungen zwischen vorherigen und gegenwärtigen Verbindungen zu vermeiden. Die vorbestimmte Zeitdauer ist typischerweise größer als die maximale Zeit, die ein altes Segment in dem Internet 14 bestehen bleiben kann, und dies stellt eine ausreichende Zeit für die Aktualisierung des entsprechenden DNS bereit.
Die Zuweisung der neuen IP-Adressen zu den mobilen T/Hs 20₁ , 20₂ ... 20_N wird durch ein Anforderungssignal initiiert, das von dem mobilen T/H 20 gesendet wird. Das mobile T/H 20, das eine neue IP-Adresse sucht, generiert ein m-DHCP-Anforderungssignal an den m-DHCP-Server. Das m-DHCP-Anforderungssignal von dem mobilen T/H 20 enthält den Domänennamen des T/H 20 zum Identifizieren des mobilen T/H 20 und die eindeutige Hardware-Adresse, (z.B. MAC-Adresse), des mobilen T/H 20. In Reaktion auf das m-DHCP-Anforderungssignal informiert der m-DHCP-Server das mobile T/H 20 über Folgendes: die neue IP-Adresse, die dem mobilen T/H 20 zugeordnet wurde, die Zuordnungsdauer, die IP-Adresse der BS und die IP-Adresse des DNS, der Namenauflösungsdienste für die Zelle (untergeordnetes Netzwerk) mit dem BS bereitstellt. Das mobile T/H 20 muss die Zuordnung periodisch erneuern, während es an einen bestimmten virtuellen Zugangs-Port der Zelle angeschlossen ist, um das Ablaufen der Zuordnung zu vermeiden. Die Zuordnung kann durch das mobile T/H 20 jederzeit beendet werden. Wenn die Zuordnung abläuft, verliert das mobile T/H 20 seine IP-Adresse. Der m-DHCP-Server informiert den entsprechenden DNS über die Zuordnungsaufhebung, den Zuordnungsablauf oder die Zuweisung einer IP-Adresse zu dem mobilen T/H 20.
Der Ablauf einer m-TCP-Verbindung gemäß der vorliegenden Erfindung wird im Folgenden beschrieben. Hier ist der Client ein stationäres oder mobiles T/H, das eine m-TCP-Verbindung mit seinem m-TCP-Peer initiieren möchte, und der Server, (der m-TCP-Peer), ist ein stationäres oder mobiles T/H, das die m-TCP-Verbindungsanforderungen von dem Client annehmen möchte.
Der Ablauf einer m-TCP-Verbindung kann in drei Phasen klassifiziert werden. Die erste Phase ist eine Verbindungsphase, in der eine m-TCP-Verbindung zwischen zwei Kommunikationsentitäten, z.B. einem mobilen T/H und einem Leitrechner, (z.B. stationärem oder mobilem T/H) hergestellt wird; die zweite Phase ist eine Vermittlungsphase, in der Datensegmente zwischen den verbundenen kommunizierenden m-TCP-Entitäten ausgetauscht werden; und die dritte Phase ist eine Abschlussphase, in der die hergestellte m-TCP-Verbindung beendet wird.
In der Verbindungsphase führt ein mobiles T/H 20 (Server), das eine m-TCP-Verbindung annehmen will, eine passive Öffnungsfunktion in seinem Anwendungsprogramm aus, um seiner m-PCP-Schicht anzugeben, dass es eine m-TCP-Schicht an einer bestimmten m-TCP-Port-Nummer annehmen will. Ein Leitrechner (Client), der eine m-TCP-Verbindung mit seinem m-TCP-Peer herstellen möchte, erhält dann die aktuelle IP-Adresse des mobilen T/H 20 von dem DNS des mobilen T/H 20 und führt eine aktive Öffnungsfunktion aus, um den Zielendpunkt der Verbindung zu spezifizieren (d.h. die IP-Adresse des mobilen T/H 20 und seine m-TCP-Port-Nummer). Die aktive und die passive Öffnungsfunktion sind im Fachgebiet bekannt. Das m-TCP-Programm auf der Leitrechnerseite erstellt und sendet ein Verbindungsanforderungssignal an das mobile T/H 20 unter Verwendung der erhaltenen aktuellen IP-Adresse des mobilen T/H 20.
Wenn die IP-Adresse des mobilen T/H 20 während dieses Prozesses geändert worden ist, stellt ein weicher Umschaltemechanismus sicher, dass das Verbindungsanforderungssignal des Leitrechners das mobile T/H 20 erreicht. Der weiche Umschaltemechanismus gestattet es dem mobilen T/H 20, die alte IP-Adresse beizubehalten, nachdem es die neue IP-Adresse erhalten hat. Daher kann das mobile T/H 20 die Datagramme, die in dem Netzwerk verzögert worden sind, auf der alten IP-Adresse empfangen. Nach einer vorgegebenen Zeitdauer wird die alte IP-Adresse aufgegeben.
Wenn die alte IP-Adresse des mobilen T/H 20 auf der Seite des mobilen T/H 20 aufgegeben worden ist, bevor die Verbindungsanforderung das mobile T/H 20 erreicht hat, dann schlägt der gegenwärtige Versuch einer Verbindung mit dem mobilen T/H 20 durch den Leitrechner fehl. In diesem Fall muss der Verbindungsprozess wiederholt werden, um die m-TCP-Verbindung herzustellen. Dazu greift das TCP-Programm auf der Leitrechnerseite nochmals auf den DNS des mobilen T/H 20 zu, um eine neue IP-Adresse des mobilen T/H 20 zu erhalten.
Andererseits möchte das mobile T/H 20 (jetzt Client) vielleicht eine m-TCP-Verbindung mit dem Leitrechner (jetzt Server) herstellen. In diesem Fall führt das Anwendungsprogramm in dem Leitrechner, der eine m-TCP-Verbindung annehmen möchte, eine standardmäßige passive Öffnungsfunktion aus, die angibt, dass er eine m-TCP-Schicht an einer bestimmten m-TCP-Port-Nummer annehmen will. Das Anwendungsprogramm in dem mobilen T/H 20 führt dann eine aktive Öffnungsfunktion aus und spezifiziert den Zielendpunkt der Verbindung, (d.h. die IP-Adresse des Leitrechners und seine m-TCP-Port-Nummer), wie oben erläutert, um die m-TCP-Verbindung herzustellen.
Zum Herstellen der m-TCP-Verbindung verwendet das m-TCP einen Dreiwege-Quittungsaustausch, der in dem herkömmlichen TCP bekannt ist. Zusätzlich zum Austauschen der standardmäßigen TCP-Parameter werden gemäß der vorliegenden Erfindung zwei weitere Parameter während des Einrichtens der m-TCP-Verbindung ausgetauscht. Die zwei Parameter, die global eindeutig sein müssen, sind eine lokale Verbindungsidentifizierung (local_conId) und eine Fernverbindungsidentifizierung (remonte_conId). Diese Parameter bilden eine Verbindungsidentifizierung (conId) zum eindeutigen Identifizieren der m-TCP-Verbindung, (d.h. conID = local_conId, remote_conId), und sind, selbst nach der IP-Adressenänderung, in jedem Datensegment enthalten, das zwischen den m-TCP-Entitäten kommuniziert wird. Durch die Aufnahme der conID in jedes Datensegment mit den neuen IP-Adressen bestimmt die m-TCP-Entität, welche die conID mit der neuen IP-Adresse empfängt, die m-TCP-Verbindung auf der Basis der conID und liefert die Datagramme dementsprechend, z.B. zu einer Buchse, einem Dienstzugangspunkt oder dergleichen.
Die zwei Parameter in der conID werden während der ersten Phase der m-TCP-Verbindung gewählt und identifizieren die m-TCP-Verbindung eindeutig. Jede Seite der m-TCP-Verbindung wählt eine local_conId, um sich selbst für die andere Seite zu identifizieren, so dass die local conId einer Seite die remote conId der anderen Seite wird. Diese Parameter können Zahlen sein, die zufällig von jeder Seite gewählt werden, so dass die conId beispielsweise eine Kombination aus diesen Zahlen sein kann, z.B. 27009876.
Die conID ist in dem m-TCP-Header von jedem m-TCP-Datensegment enthalten. 3 zeigt ein Beispiel einer m-TCP-Header-Struktur gemäß der vorliegenden Erfindung. Wie hierin gezeigt, enthält der m-TCP-Header 30 ein Feld Ursprungs-Port-ID, ein Feld Ziel-Port-ID, eine ursprüngliche oder inkrementierte Folgenummer, die in einem Feld Folgenummer 31 gespeichert ist, ein Feld Bestätigungs-Nummer, einen reservierten Bereich 34, ein Feld TCP-Prüfsumme und ein Feld Informationsdaten 38 entsprechend einem bekannten TCP-Header. Diese Felder werden entsprechend einem herkömmlichen TCP-Dreiwege-Quittungsaustausch verarbeitet. Des Weiteren enthält der m-TCP-Header 30 gemäß der vorliegenden Erfindung ein Feld Globale ID 32, das in ein Feld Lokale Verbin dung 32a und ein Feld Entfernte Verbindung 32b unterteilt ist. Das Feld Globale ID 32 befindet sich in einem Feld 36 für Optionen. Jedes der Felder 32a und 32b kann vorgegeben lang sein, z.B. zwei Acht-Bit-Bytes. Das Feld Lokale Verbindung 32a speichert darin die local conId, und das Feld Entfernte Verbindung 32b speichert darin die remote_conId.
Wenn insbesondere in dem Dreiwege-Quittungsaustausch-Prozess eine erste Entität, (z.B. das erste mobile T/H 20₁ ) eine m-TCP-Verbindung mit einer zweiten Entität herstellen möchte, (z.B. dem zweiten mobilen T/H 20₂ ), erstellt die erste Entität ein erstes Segmentsignal zum Anfordern einer Einrichtung einer m-TCP-Verbindung. Das erste Segmentsignal enthält ein SYN-Bit (SYN = 1), das im Feld Code 36 des TCP-Headers 30 gesetzt ist, und einen Wert local conId, der in dem Feld Lokale Verbindung 32a des m-TCP-Headers 30 gesetzt ist. Zu diesem Zeitpunkt wird das Feld Entfernte Verbindung 32b leer gelassen. Nach Empfang des ersten Segmentsignals generiert die zweite Entität ein zweites Segmentsignal zum Bestätigen des Empfangs des ersten Segmentsignals. Das zweite Segmentsignal enthält SYN- und ACK-Bits (SYN = 1, ACK = 1), die in dem Feld Code 36 seines eigenen m-TCP-Headers gesetzt sind, und den ausgewählten Wert local conId, der in seinem Feld Lokale Verbindung gesetzt ist. In dem Feld Entfernte Verbindung des m-TCP-Headers der zweiten Entität wird der Inhalt des Felds Lokale Verbindung 32a des empfangenen ersten Segmentsignals kopiert und gespeichert. Nach Empfang des zweiten Segmentsignals generiert die erste Entität ein drittes Segment zum Bestätigen des Empfangs des zweiten Segmentsignals und informiert die zweite Entität, dass die m-TCP-Verbindung erfolgreich hergestellt worden ist.
Der Ablauf der m-TCP-Verbindung in der zweiten Phase ist, sobald die m-TCP-Verbindung hergestellt worden ist, dem Ablauf eines herkömmlichen TCP in der zweiten Phase ähnlich, ausgenommen gewisse Modifizierungen, die im Folgenden erläutert werden.
In dem m-TCP der vorliegenden Erfindung ist das herkömmliche TCP so modifiziert, dass es die sich ständig verändernden Endpunkte (IP-Adresse und TCP-Port-Nummer) der m-TCP-Verbindung speichert, da die mobilen T/Hs 20 ihre Verbindungsendpunkte ständig verändern, wenn sie im Netzwerk roamen. Das m-TCP verwendet conIDs, um die eingehenden Segmente basierend auf den conIDs entsprechend weiterzuleiten, z.B. zu einer Buchse, einem Dienstzugangspunkt oder dergleichen. Für die ausgehenden Segmente sendet das m-TCP die Datensegmente basierend auf den aktuellen IP-Adressen. Des weiteren speichert das m-TCP die conID, die ursprüngliche Endpunktinformation für beide Enden und die gegenwärtige Endpunktinformation für beide Enden. Diese Informationen können für andere Anwendungsprogramme zur Verfügung stehen.
Die entfernte Endpunktinformation, (d.h. entfernte IP-Adresse und Port-Nummer), wird aus dem ankommenden Datensegment erhalten, da jedes ankommende Datensegment die conID und die gegenwärtige Ursprungs-IP-Adresse enthält, wobei die Ursprungs-IP-Adresse Bestandteil der Endpunktinformation der Entität auf der anderen Seite der m-TCP-Verbindung ist. Wenn die Datensegmente außer Reihenfolge sind, wird die Folgenummer, die ebenfalls im Feld 31 des m-TCP-Headers enthalten ist, dazu verwendet, zu bestimmen, welches Datensegment das aktuellste ist, und stellt die aktuellste Ursprungs-IP-Adresse bereit.
Wann immer ein mobiles T/H eine neue IP-Adresse erhält und keine ausgehenden Datensegmente vorhanden sind, die mit der neuen IP-Adresse gesendet werden sollen, sendet das m-TCP ein Dummy-Segment DS zu seinem m-TCP-Peer, um seinen Peer über die neue IP-Adresse zu informieren. Des Weiteren sendet das m-TCP während des Bestehens einer m-TCP-Verbindung in regelmäßigen Zeitintervallen kontinuierlich DSs (Dummy-Segmente ohne Informationsdaten) an seinen m-TCP-Peer.
Der Empfang jedes DS wird durch das empfangende m-TCP mit einem Dummy-Segment-Bestätigungssegment (DS ACK) bestätigt. Das m-TCP kennzeichnet das Datensegment, das als das DS oder das DS ACK gesendet wird, unter Verwendung eines der reservierten Bits, (z.B. UPD-Bit in dem Header 30), die in dem m-TCP-Header vorhanden sind. Zum Beispiel kann das UPD-Bit auf Eins gesetzt werden, wenn das aktuelle Datensegment ein DS ist, oder sowohl das UPD- als auch das ACK-Bit können auf Eins gesetzt werden, wenn das aktuelle Datensegment ein DS ACK ist. Wenn das gesendete DS von dem empfangenden m-TCP nicht bestätigt wird, wird es erneut gesendet, bis die Bestätigung empfangen wird.
Jedes DS enthält eine eindeutige Folgenummer zum Identifizieren des bestimmten DS. Diese Folgenummer wird in dem Feld Folgenummer 31 des m-TCP-Headers gespeichert und wird unabhängig inkrementiert. Der Folgenummer-Inkrementierungsprozess für die DSs unterscheidet sich von dem Folgenummer-Inkrementierungsprozess für Segmente mit Informationsdaten, weil DSs keine Informationsdaten tragen, und die Inkrementierung für die Segmente mit Informationsdaten wird basierend auf der Größe der Informationsdaten durchgeführt. Die Folgenummer-Inkrementierung für die DSs beginnt mit einer ursprünglichen Folgenummer, (z.B. 1), und erhöht die Folgenummer um einen voreingestellten Wert, (z.B. 1). Der Absender eines neuen DS inkrementiert die vorherige Folgenummer und nimmt die neu inkrementierte Folgenummer in das neue DS auf, so dass jedes DS eine neue Folgenummer enthält. Der Empfänger der DSs prüft die Folgenummern und verarbeitet das DS mit der aktuellsten Folgenummer, wogegen die DSs mit alten Folgenummern im Fall von Netzwerk-Verzögerungen usw. ignoriert werden. Der Empfänger des DS sendet ein DS ACK an den Absender, welches die empfangene Folgenummer enthält.
Das DS und DS ACK werden weder einer Pufferung noch einer Ablaufsteuerung unterzogen. Das DS und DS ACK werden kontinuierlich in einem regelmäßigen Zeitintervall ausgetauscht, bis die m-TCP-Verbindung vollständig geschlossen ist. Das heißt, sie werden in beide Richtungen ausgetauscht, bis die m-TCP-Verbindung in beide Richtungen geschlossen ist.
Nachdem die Datagramme zwischen den verbundenen m-TCP-Entitäten ausgetauscht worden sind, kann die Verbindung beendet werden. Die letzte Beendigungsphase des m-TCP wird in der gleichen Weise durchgeführt, wie die Beendigungsphase von herkömmlichen TCP-Verbindungsprozeduren.
Dementsprechend gestatten ein m-TCP und ein Verfahren zum Herstellen und Halten einer m-TCP-Verbindung gemäß der vorliegenden Erfindung es mobilen T/Hs, miteinander über das Internet unter Verwendung einer Mindestanzahl von Variablen zu kommunizieren.

Claims

Kommunikationsverfahren einer ersten Kommunikationsentität zum Herstellen einer Verbindung des mobilen Übertragungssteuerprotokolls TCP zwischen der ersten Kommunikationsentität und einer zweiten Kommunikationsentität, mit den folgenden Schritten: Senden eines ersten Segmentsignals zu der zweiten Kommunikationsentität, wobei das erste Segmentsignal eine Portkennung der ersten Kommunikationsentität, eine Portkennung der zweiten Kommunikationsentität und eine Verbindungsidentifikation der ersten Kommunikationsentität enthält, die für die Dauer der Mobil-TCP-Verbindung unverändert bleibt, falls die erste Kommunikationsentität über das Netzwerk hinweg roamt oder der ersten Kommunikationsentität eine neue Netzwerkadresse zugewiesen wird; Empfangen eines zweiten Segmentsignals von der zweiten Kommunikationsentität als Reaktion auf das erste Segmentsignal, wobei das zweite Segmentsignal die Portkennung der zweiten Kommunikationsentität, die Portkennung der ersten Kommunikationsentität, eine Verbindungsidentifikation der zweiten Kommunikationsentität und die Verbindungsidentifikation der ersten Kommunikationsentität enthält, wobei die Verbindungsidentifikation der zweiten Kommunikationsentität für die Dauer der Mobil-TCP-Verbindung unverändert bleibt, falls die zweite Kommunikationsentität über das Netzwerk hinweg roamt oder der zweiten Kommunikationsentität eine neue Netzwerkadresse zugewiesen wird, wobei die Verbindungsidentifikationen der ersten und der zweiten Kommunikationsentität eine Mobil-TCP-Verbindungsidentifikation für die erste und die zweite Kommunikationsentität bilden; und Senden eines dritten Segmentsignals zu der zweiten Kommunikationsentität als Reaktion auf das zweite Segmentsignal.
Kommunikationsverfahren nach Anspruch 1, wobei im Empfangsschritt das zweite Segmentsignal ferner Bestätigungsdaten zur Bestätigung des Empfangs des ersten Segmentsignals durch die zweite Kommunikationsentität enthält.
Kommunikationsverfahren nach Anspruch 1, wobei im Schritt des Sendens eines dritten Segmentsignals das dritte Segmentsignal Bestätigungsdaten zum Bestätigen des Empfangs des zweiten Segmentsignals durch die erste Kommunikationsentität enthält.
Kommunikationsverfahren nach Anspruch 1, wobei im Schritt des Sendens eines ersten Segmentsignals die erste und/oder die zweite Kommunikationsentität ein mobiles Endgerät mit einer veränderlichen IP-Adresse ist.
Kommunikationsverfahren einer zweiten Kommunikationsentität zur Herstellung einer Verbindung des mobilen Übertragungssteuerprotokolls TCP zwischen einer ersten Kommunikationsentität und der zweiten Kommunikationsentität, mit den folgenden Schritten: Empfangen eines ersten Segmentsignals von der ersten Kommunikationsentität, wobei das erste Segmentsignal eine Portkennung der ersten Kommunikationsentität, eine Portkennung der zweiten Kommunikationsentität und eine Verbindungsidentifikation der ersten Kommunikationsentität enthält, die für die Dauer der Mobil-TCP-Verbindung unverändert bleibt, falls die erste Kommunikationsentität über das Netzwerk hinweg roamt oder der ersten Kommunikationsentität eine neue Netzwerkadresse zugewiesen wird; und Senden eines zweiten Segmentsignals zu der ersten Kommunikationsentität als Reaktion auf das erste Segmentsignal, wobei das zweite Segmentsignal die Portkennung der zweiten Kommunikationsentität, die Portkennung der ersten Kommunikationsentität, eine Verbindungsidentifikation der zweiten Kommunikationsentität und die Verbindungsidentifikation der ersten Kommunikationsentität enthält, wobei die Verbindungsidentifikation der zweiten Kommunikationsentität für die Dauer der Mobil-TCP-Verbindung unverändert bleibt, falls die zweite Kommunikationsentität über das Netzwerk hinweg roamt oder der zweiten Kommunikationsentität eine neue Netzwerkadresse zugewiesen wird, wobei die Verbindungsidentifikationen der ersten und der zweiten Kommunikationsentität eine Mobil-TCP-Verbindungsidentifikation für die erste und die zweite Kommunikationsentität bilden.
Kommunikationsverfahren nach Anspruch 5, wobei im Sendeschritt das zweite Segmentsignal ferner Bestätigungsdaten zum Bestätigen des Empfangs des ersten Segmentsignals durch die zweite Kommunikationsentität enthält.
Kommunikationsverfahren nach Anspruch 5, ferner mit dem folgenden Schritt: Empfangen eines dritten Segmentsignals von der ersten Kommunikationsentität zum Bestätigen des Empfangs des zweiten Segmentsignals durch die erste Kommunikationsentität.
Kommunikationsverfahren nach Anspruch 5, wobei in den Schritten des Empfangens und des Sendens die erste und/oder die zweite Kommunikationsentität ein mobiles Endgerät mit einer veränderlichen IP-Adresse ist.
Auf einem computerlesbaren Medium einer ersten Kommunikationsentität gespeichertes Computerprogramm zum Herstellen einer Verbindung des mobilen Übertragungssteuerprotokolls TCP zwischen der ersten Kommunikationsentität und einer zweiten Kommunikationsentität, wobei das Computerprogramm Anweisungen enthält, die bei Ausführung die Verfahrensschritte von Anspruch 1 ausführen.
Computerprogramm nach Anspruch 9, wobei das dritte Segmentsignal Bestätigungsdaten zum Bestätigen des Empfangs des zweiten Segmentsignals durch die erste Kommunikationsentität enthält.
Auf einem computerlesbaren Medium einer ersten Kommunikationsentität gespeichertes Computerprogramm zum Herstellen einer Verbindung des mobilen Übertragungssteuerprotokolls TCP zwischen der ersten Kommunikationsentität und einer zweiten Kommunikationsentität, wobei das Computerprogramm Anweisungen enthält, die bei Ausführung die Verfahrensschritte von Anspruch 5 ausführen.
Computerprogramm nach Anspruch 11, wobei die Anweisungen bei Ausführung ferner die folgenden Schritte ausführen: Empfangen und Verifizieren eines aus der ersten Kommunikationsentität erzeugten dritten Segmentsignals als Reaktion auf das zweite Segmentsignal.