DE69935863T2

DE69935863T2 - Mobilendgerät und drahtloses gerät mit gemeinsamer ip-adresse

Info

Publication number: DE69935863T2
Application number: DE69935863T
Authority: DE
Inventors: Marcello San Diego LIOY
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 1998-10-26
Filing date: 1999-10-26
Publication date: 2008-01-17
Anticipated expiration: 2019-10-27
Also published as: CA2348030A1; EP1125418B1; JP2010114905A; CA2660174A1; CA2348030C; CN1331878A; CN1157032C; JP4477239B2; CA2660174C; BRPI9914806B1; WO2000025497A1; JP2002529021A; JP4856233B2; EP1125418A1; JP2010109987A; DE69935863D1; AU1235300A; KR100897239B1; HK1040850A1; JP4886022B2

Description

HINTERGRUND DER ERFINDUNG
I. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf drahtlose Datendienste. Insbesondere bezieht sich die vorliegende Erfindung auf ein neues und verbessertes Verfahren und ein System zum Verschieben von Internetprotokoll-(IP)-Endpunkten zwischen Geräten, die an ein Netzwerk angeschlossen sind.
II. Beschreibung der verwandten Technik
Internetworking, d.h., die Verbindung von individuellen Lokalbereichsnetzwerken (LANs = Local Area Networks) ist sehr schnell sehr populär geworden. Die Infrastruktur und die zugeordneten Protokolle, die üblicherweise als das „Internet" bezeichnet werden, sind sehr bekannt geworden und weit genutzt. Im Herzen des Internets sitzt das Internetprotokoll (IP = Internet Protocol), das das Lenken der Datagramme zwischen den LANs unterstützt, wie auf dem Fachgebiet bekannt, und weiterhin beschrieben ist in dem Request For Comment (RFC) 791 mit dem Titel „INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", mit September 1981 datiert.
IP ist ein datagrammorientiertes Protokoll, das mehrere Dienste vorsieht, einschließlich Adressierung. Das IP-Protokoll kapselt Daten in ein IP-Paket für die Sendung ein und hängt Adressierungsinformationen an den Header des Pakets an. IP-Header enthalten 32-Bit-Adressen, die die Sendehosts und die Empfängerhosts identifizieren. Diese Adressen werden vom dazwischen liegenden Router benutzt, um einen Weg durch das Netzwerk für das Paket zu dessen letztendlichen Ziel bei der beabsichtigen Adresse auszuwählen. Ein grundlegendes Konzept für IP-Adressierung ist, dass die anfänglichen Präfixe der IP-Adresse benutzt werden können, und zwar für allgemeine Lenkungsentscheidungen. Zum Beispiel könnten die ersten 16 Bits einer Adresse QUALCOMM Incorporated identifizieren, die ersten 20 Bits identifizieren das Hauptbüro von QUALCOMM, die ersten 26 Bits identifizieren ein bestimmtes Ethernet in diesem Büro, und die gesamten 32 Bits identifizieren einen bestimmten Host in diesem Ethernet. Als ein weiteres Beispiel, könnte jede Adresse in dem IP-Netzwerk von QUALCOMM in der Form (in „gepunkteter Vierernotation") sein: 129.46.xxx.xxx, wobei „xxx" sich auf irgendeine erlaubbare ganze Zahl zwischen Null und 255 bezieht.
Wie es offensichtlich ist mit dieser präfixbasierenden Lenkungscharakteristik vom IP, enthalten die IP-Adressen implizierte geografische Informationen über die Position bzw. den Ort eines bestimmten Hosts im Internet. Mit anderen Worten, wann immer irgendein Router im Internet ein Paket mit einer Ziel-IP-Adresse empfängt, die mit „129.46" beginnt, dann leitet der Router diese Paket in eine bestimmte Richtung weiter, und zwar in Richtung des QUALCOMM Incorporated–Netzwerks in San Diego, Kalifornien, USA. Somit ermöglicht es das IP-Protokoll Datagrammen, die von irgendeinem Internetknoten in der Welt ihren Ursprung haben, zu jedem anderen Internetknoten in der Welt gelenkt zu werden, unter Voraussetzung, dass der Ursprungsteilnehmer die IP-Adresse des Zielteilnehmers kennt.
Da Mobilcomputer und mobiler Internetzugriff Popularität gewonnen haben, ist ein Bedarf hervorgegangen, mobile Datenunterstützung für Mobilendgeräte vorzusehen, wie z.B. Laptop oder Palmtop-Computer unter Verwendung des IP-Protokolls. Wie jedoch gerade zuvor angemerkt, enthält das IP-Adressierungsschema, das für die Internetlenkung benutzt wird, implizierte geografische Informationen. Mit anderen Worten, wenn ein Benutzer wünscht, eine feste IP-Adresse zu benutzen, um sein Mobilendgerät zu identifizieren, werden die IP-Pakete, die für das Mobilendgerät gedacht sind, nicht zum Mobilendgerät gelenkt werden, wenn es sich entfernt von seinem „Heim"-Netzwerk befindet (d.h., das Netzwerk, das dessen feste IP-Adresse umfasst), und zwar in Abwesenheit von einigen Techniken für das „Weiterleiten" von IP-Paketen zum Mobilendgerät.
Zum Beispiel, angenommen ein Benutzer entscheidet sich, sein Mobilendgerät von seinem „Heim"-IP-Netzwerk bei QUALCOMM Incorporated in San Diego zu entfernen, und es mit sich auf eine Reise nach Palo Alto, Kalifornien, mitzunehmen, und da mit dem Stanford-University-IP-Netzwerk zu verbinden, während es noch immer seine QUALCOMM zugeordnete feste IP-Adresse behält. Jedes IP-Datagramm, das für das Mobilendgerät gedacht ist, wird immer noch zum QUALCOMM-IP-Netzwerk geleitet, weil die geografische Positionsinformation in der festen IP-Adresse des Mobilendgeräts inbegriffen ist. Solche IP-Pakete werden nicht zum Mobilendgerät geliefert, während es sich entfernt von dessen „Heim"-Netzwerk befindet, solange irgendein Mechanismus da ist, um die IP-Pakete von QUALCOMMs IP-Netzwerk zu dem Mobilendgerät in seinem momentanen Verknüpfungspunkt zum Internet bei dem Stanford-University-IP-Netzwerk in Palo Alto weiterzuleiten.
Um diesen Bedarf zu erfüllen, spezifiziert RFC 2002 mit dem Titel „IP Mobility Support", datiert auf Oktober 1996, Protokollverbesserungen, die es ermöglichen, IP-Datagramme zu Mobilknoten in dem Internet transparent zu lenken. Unter Verwendung dieser Techniken, die in dem RFC 2002 beschrieben sind, kann jeder Mobilknoten immer durch seine „Heim"-IP-Adresse identifiziert werden, ungeachtet seines momentanen Verknüpfungspunktes mit dem Internet. Während es entfernt von seinem Heim-IP-Netzwerk gelegen ist, kann ein Mobilendgerät mit einer „Care-Of-Adresse assoziiert werden, um dadurch Weiterleitungsinformationen vorzusehen, die notwendig sind, um die IP-Datagramme zu seinem momentanen Verknüpfungspunkt im Internet zu lenken. RFC 2002 erfüllt dies durch Vorsehen von einer Registrierung der Care-Of-Adresse mit einem „Heimagenten". Dieser Heimagent leitet IP-Datagramme, die für das Mobilendgerät gedacht sind, durch Verwenden einer Technik, die „IP-Tunnelung" genannt wird, weiter. IP-Tunnelung involviert den Heim-Agenten, einen neuen IP-Header anzuknüpfen, der die Care-Of-Adresse enthält, und zwar an jedes ankommende IP-Paket, das eine Zieladresse entsprechend der Heim-IP-Adresse des Mobilendgeräts hat. Nach der Ankunft bei der Care-Of-Adresse streift ein „Fremdagent" bei der Care-Of-Adresse den IP-Tunnelungsheader ab, und liefert das IP-Paket zu dem Mobilendgerät bei seinem aktuellen Verknüpfungspunkt im Internet.
Auf diesem Weg sehen die Techniken von RFC 2002 Mobildatendienste für Benutzer vor, die sich wünschen, den Verknüpfungspunkt der Mobilendgeräte im Internet umzustellen, ohne die IP-Adresse des Mobilendgerätes zu ändern. Diese Möglichkeit hat mehrere Vorteile. Erstens ermöglicht es dem Ursprungsknoten, irgendwo im Internet periodische „Push"-Dienste zum Mobilendgerät zu senden, ungeachtet der Tatsache wo es ist. Solche Dienste könnten Aktienkurse oder Email beinhalten. Dies vermeidet den Bedarf des Mobilbenutzers sich „einzuwählen" oder anderenfalls sein Heimnetzwerk zu kontaktieren, um Informationen abzurufen. Weiterhin ermöglicht es dem mobilen Endgerät, so oft wie gewünscht sich umzupositionieren, ohne dass irgendwelche Ursprungsteilnehmer den momentanen Ort des Mobilendgeräts verfolgen müssen.
Um die Freiheit der Mobilität des Mobilendgeräts zu erhöhen, werden viele Mobilbenutzer typischerweise Drahtlos-Kommunikationsgeräte, wie z. B. zellulare oder portable Telefone, benutzen, um sich mit dem Internet zu verbinden. Mit anderen Worten werden viele Mobilbenutzer Drahtlos-Kommunikationsgeräte benutzen, die üblicherweise als „Mobilstationen" oder MT2-Geräte bezeichnet werden, und zwar als Zugriffspunkt zum landbasierten Netzwerk. Wie hierin benutzt, wird sich die „Mobilstation" oder das „MT2-Gerät" auf irgendeine Teilnehmerstation in dem öffentlichen Drahtlos-Funknetzwerk beziehen, die dafür gedacht ist, während in Bewegung oder während Aufenthalten an unspezifizierten Punkten benutzt zu werden. Mobilstationen und MT2-Gerate beinhalten tragbare Einheiten (z.B. handgehaltene persönliche Telefone) und Einheiten, die in Fahrzeugen installiert sind, wie auch Drahtlos-Local-Loop-(WLL = Wireless Local Loop)-Telefone.
1 zeigt ein Blockdiagramm eines Drahtlos-Datenkommunikationssystems auf höchster Ebene, in dem ein Mobilendgerät (TE2-Gerat) 102 mit einer Interworking-Funktion (IWF = Interworking Function) 108 über ein Drahtlos-Kommunikationssystem kommuniziert, das ein Drahtlos-Kommunikationsgerät (MT2-Gerät) 104 und eine Basisstation/Mobilvermittlungsstelle (BS = Base Station/MSC = Mobile Switching Center) 106 beinhaltet. In 1 dient die IWF 108 als Zugriffspunkt zum Internet. IWF 108 ist gekoppelt mit und oft neben der BS/MSC 106 angeordnet, die eine konventionelle Drahtlos-Basisstation, wie auf dem Fachgebiet bekannt, sein kann. Das TE2-Gerat 102 ist an das MT2-Gerät 104 gekoppelt, das wiederum in Drahtlos-Kommunikation mit BS/MSC 106 und IWF 108 ist.
Viele Protokolle existieren, die Datenkommunikation zwischen dem TE2-Gerät 102 und dem IWF 108 ermöglichen. Zum Beispiel, definiert der Telecommunications Industry Association (TIA)/Electronics Industry Association (EIA) Interim Standard IS-707.5, mit dem Titel „Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services", veröffentlicht im Februar 1998, Anforderungen für die Unterstützung von Paketdatensendungsfähigkeit auf TIA/EIA-IS-95-Breitbandspreizspektrumssystemen, von denen BS/MSC 106 und IWF 108 ein Teil sein können. IS-707.5 spezifiziert einen Paketdatenträgerdienst, der für Kommunikation zwischen TE2-Gerat 102 und IWF 108 über BS/MSC 106 benutzt werden kann. Es sieht Prozeduren bzw. Verfahren vor, die auf vielfache Paketdatendienste angewendet werden können, einschließlich des Mobil-IP- bzw. Mobile-IP-Dienstes von RFC 2002, wie auch des Cellular Digital Packet Data (CDPD), der in CDPD-1995 beschrieben ist, mit dem Titel „Cellular Digital Packet Data System Specification, Version 1.1", veröffentlicht am 29. Januar 1995, von dem CDPD Forum, Inc.
CDPD ist ein AMPS-(analog)-Zellulardatendienst, der einiges von seiner eigenen Unterstützung für Mobilität beinhaltet. CDPD unterscheidet sich von Mobil-IP (Mobile-IP) auf mehrere signifikante Arten. Vor allem hat ein CDPD-Modem eine zugewiesene IP-Adresse, die zum CDPD-Netzwerk gehört. Obwohl also ein CDPD-Modem innerhalb des CDPD-Netzwerkes sich hin und her bewegen kann (roam), kann es nicht seine IP-Adresse außerhalb des CDPD-Netzwerkes auf die gleiche Weise benutzen wie ein Mobil-IP-unterstütztes Endgerät seine „Heim"-IP-Adresse außerhalb seines „Heim"-Netzwerkes benutzen kann.
IS-707.5 sieht ebenso Anforderungen vor für Kommunikationsprotokolle auf den Verbindungen zwischen TE2-Gerat 102 und dem MT2-Gerät 104 (das R_m-Interface) zwischen dem MT2-Gerät 104 und der BS/MSC 106 (das U_m-Interface) und zwischen der BS/MSC 106 und der IWF 108 (das L-Interface).
Bezüglich 2 wird ein Diagramm der Protokollstapel in jeder Entität bzw. Einheit des IS-707.5-Weiterleitungsmodells gezeigt. 2 entspricht annäherungsweise der 1. 4.2.1-1 von IS-707.5. Am linken Rand der Figur ist ein Protokoll stapel, gezeigt in konventionellem vertikalen Format, der die Protokollschichten zeigt, die auf dem TE2-Gerät 102 (z.B. dem Mobilendgerät, Laptop oder Palmtop-Computer) laufen. Der TE2-Protokollstapel wird gezeigt als logisch verknüpft mit dem Protokollstapel des MT2-Geräts 104 über das R_m-Interface. Das MT2-Gerät 104 ist gezeigt als logisch verknüpft mit dem Protokollstapel der BS/MSC 106 über das U_m-Interface. Der BS/MSC-106-Protokollstapel ist wiederum gezeigt als logisch verknüpft mit dem IWF-108-Protokollstapel über das L-Interface.
Ein Beispiel der Operation der 2 ist wie folgendermaßen. Eine Funktionseinheit des oberen Schichtenprotokolls 202, wie z.B. ein Anwendungsprogramm, das auf dem TE2-Gerät 102 läuft, hat Bedarf, IP-Pakete über das Internet zu senden. Eine Beispielanwendung kann ein Webbrowser, wie z. B. Netscape Navigator oder Microsoft Internet Explorer oder dergleichen sein. Der Webbrowser fordert einen Universal Resource Locator (URL) an, wie z.B. http://www.qualcomm.com. Ein Domain-Name-System-(DNS)-Protokoll, auch in den oberen Schichtprotokollen 202, übersetzt den auf Text basierten Rostnamen „www.qualcomm.com" in eine numerische 32-Bit-IP-Adresse. Das Hypertext Transfer Protocol (HTTP), auch ein oberes Schichtprotokoll 202, konstruiert eine GST-Nachricht für die angeforderte URL, und spezifiziert ebenso, dass das Sendekontrollprotokoll (TCP = Transmission Control Protocol) benutzt werden wird, um die Nachricht zu senden, und dass der TCP-Anschluss bzw. Port 80 für HTTP-Operationen benutzt wird.
Das TCP-Protokoll, ebenso ein oberes Schichtprotokoll 202, öffnet eine Verbindung zu der IP-Adresse, die von dem DNS, Port 80, spezifiziert wurde und sendet die HTTP-GET-Nachricht. Das TCP-Protokoll spezifiziert, dass das IP-Protokoll für Nachrichtentransport benutzt werden wird. Das IP-Protokoll, ein Netzwerkschichtprotokoll 204, sendet die TCP-Pakete zur IP-Adresse, die spezifiziert wurde. Das Punkt-Zu-Punkt-Protokoll (PPP = Point to Point Protocol), ein Verbindungsschichtprotokoll 206, kodiert die IP/TCP/HTTP-Pakete und sendet sie über das R_m-Interface unter Verwendung des Weiterleitungsschichtprotokolls 208 EIA-232 zu dem EA-232-kompatiblen Anschluss bzw. Port des MT2-Geräts. Das PPP-Protokoll wird beschrieben im Detail in RFC 1661, mit dem Titel „The Point-To-Point-Protocol (PPP)".
Das EIA-232-Protolkoll 210 auf dem MT2-Gerät 104 reicht das gesendete PPP-Paket zu einer Kombination des Funkverbindungsprotokolls (RLP = Radio Link Protocol) 212 und IS-95-Protokoll 214 für die Sendung zur BS/MSC 106 über das U_m-Interface weiter. Das RLP-Protokoll 212 ist definiert in IS-707.2 und das IS-95-Protokoll ist definiert im IS-95, wie oben angemerkt. Ein komplementärer Weiterleitungsschichtprotokollstapel auf dem BS/MSC 106, einschließlich einer Kombination von RLP-Protokoll 216 und IS-95-Protokoll 218, empfängt die PPP-Pakete über das U_m-Interface und reicht diese zum MT2-Weiterleitungsschichtprotokoll 220 für das L-Interface zu dem IWF–Weiterleitungsschichtprotokoll 228 weiter. Das MT2-Weiterleitungsschichtprotokoll 220 und das IWF–Weiterleitungsschichtprotokoll 228 sind im TIA/EIA IS-658 beschrieben, mit dem Titel „Data Services Interworking Function Interface Standard for Wideband Spread Spectrum Digital Cellular System".
Das PPP-Protokoll 226 in der Verbindungsschicht 227 des IWF dekodiert die PPP-Pakete von dem TE2-Gerät 102 und dient zur Beendigung der PPP-Verbindung zwischen dem TE2-Gerat 102 und der IWF 108. Die dekodierten Pakete werden von dem PPP-Protokoll 226 zum IP-Protokoll in den Netzwerkschichtprotokollen 224 des IWF 108 zur Untersuchung weitergereicht und werden weiter zu der IP-Adresse, die von dem TE2-Gerat 102 in dem IP-Paketheader (hier die IP-Adresse für www.qualcomm.com), gelenkt. Wenn es irgendwelche Aufgaben der oberen Schichtprotokolle gibt, die bei IWF 108 durchgeführt werden sollen, wie z.B. TCP, werden sie in den oberen Schichtprotokollen 222 durchgeführt.
Angenommen, dass das letztendliche Ziel der IP-Pakete, die von dem TE2-Gerat 102 generiert wurden, nicht die IWF 108 ist, werden die Pakete durch die Netzwerkschichtprotokolle 224, Verbindungsschicht 227 und Weiterleitungsschichtprotokolle 228 der IWF 108 zum nächsten Router (nicht gezeigt) im Internet weitergeleitet. Auf diese Weise werden IP-Pakete von dem TE2-Gerat 102 über das MT2-Gerät 104, die BS/MSC 106 und die IWF 108 zu deren letztendlichen beabsichtigten Ziel im Internet kommuniziert, um dadurch drahtlos Paketdatendienste für das TE2-Gerat 102 gemäß dem IS-707.5-Standard-Weiterleitungsmodell vorzusehen.
Wie in der 2 dargestellt, sieht der IS-707.5-Standard die Anforderungen für Kommunikationsprotokolle auf den Verbindungen zwischen einem TE2-Gerät 102 und einer IWF 108 vor, einschließlich den Anforderungen für die R_m-, die U_m- und die L-Interfaces. Diese Anforderungen und Verfahren sind anwendbar, um Mobil-IP-Dienste, die im RFC 2002 beschrieben sind, zu unterstützen. IS-707.5 sieht jedoch keine Verfahren zum Aufbauen von Mobil-IP-Diensten in der ersten Instanz vor. Mit anderen Worten, IS-707.5 sieht ein Rahmenwerk zur Unterstützung für Mobil-IP-Dienste vor, aber sieht keine Verfahren zum Aushandeln von Mobil-IP-Diensten oder das Registrieren des TE2-Gerätes 102 mit einem Heimagenten und einem Fremdagenten für Mobil-IP-Dienste vor. Diese Verfahren werden im RFC 2002 selbst gefunden.
Weiterhin implizieren sowohl die Netzwerk- und Weiterleitungsmodelle von IS-707.5 die Zuweisung von einer einzelnen IP-Adresse zu dem TE2-Gerät 102. Keine separate Versorgung wird für die Zuweisung einer zweiten IP-Adresse für die exklusive Benutzung des MT2-Gerätes 104 gemacht. Stattdessen ist es zur Zeit nicht möglich, mehr als eine IP-Adresse pro PPP-Sitzung zu bekommen. Die zusätzlichen Kosten der Ressourcen in der IWF 108, um mehrere PPP-Sitzungen pro Mobiltelefon zu unterstützen, machen es für die Dienstprovider bzw. -anbieter unattraktiv.
Diese Unterscheidung ist wichtig, wenn in Betracht gezogen wird, dass typischerweise einige Anwendungsschichtfunktionseinheiten deswegen in dem TE2-Gerät 102 existieren müssen, um Mobil-IP zu unterstützen. Unglücklicherweise hat die populärste Betriebssystemsoftware für Personalcomputer, Microsoft Windows, keine Unterstützung für Mobil-IP und es ist momentan nicht geplant, eine solche Unterstützung zu haben. Als Ergebnis sind TE2-Geräte, die Microsoft Windows (oder eines von vielen anderen Betriebssystemen) laufen lassen, nicht in der Lage, deren „Heim"-IP-Adresse zu benutzen, wenn sie nicht mit deren „Heim"-IP-Netzwerk verbunden sind. Dies verhindert, dass der Mobilbenutzer aus den Gewinnen der Mobil-IP-Dienste, wie „Push"-Dienste und direkte Email-Lieferung wäh rend der Benutzer sich entfernt von dem „Heim"-IP-Netzwerk aufhält, seinen Vorteil zieht.
Was gebraucht wird, ist ein Verfahren und ein System zum Durchführen von Mobil-IP-Registrierung eines TE2-Gerätes mit dem MT2-Gerät, das als Proxy für das TE2-Gerät agiert, um Mobil-IP-Unterstützung für das TE2-Gerät aufzubauen. Noch allgemeiner ist, was gebraucht wird, ein Verfahren und System zum Ermöglichen, dass zwei vernetzte Geräte (z.B. das MT2 und das TE2) sich eine einzelne IP-Adresse teilen.
„IP Multiplexing by Transparent Port-Address Translation", veröffentlicht im September 1996, beschreibt eine Technik, um Adressenübersetzung ohne einen DNS durchzuführen. Patent Nr. 5,708,655 der Vereinigten Staaten beschreibt ein Verfahren und eine Vorrichtung zum Adressieren einer Drahtlos-Kommunikationsstation mit einer dynamisch zugewiesenen Adresse.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein Gerät, wie definiert in den angehängten Ansprüchen.
Die vorliegende Erfindung ist ein neues und verbessertes System und Verfahren zum Verschieben von IP-Endpunkten, was z.B. als Teil der Proxy-Mobilknotenregistrierung durchgeführt werden kann. Das Verfahren beinhaltet das Signalisieren, von einem Endgerät, eines Bedarfs für Mobildatendienste, und das Initialisieren, in einem Drahtlos-Kommunikationsgerät, einer Mobilknotenregistrierung des Endgerätes ansprechend auf den Signalisierungsschritt. Das Endgerät sendet paketisierte Daten und das Drahtlos-Kommunikationsgerät, das an das Endgerät gekoppelt ist, überwacht die paketisierten Daten für eine Internetprotokoll-(IP)-Adresse, die in einer IP-Adressenanfrage bzw. -anforderung enthalten ist. Das Drahtlos-Kommunikationsgerät initiiert die Mobilknotenregistrierung und -verwendung der IP-Adresse, wenn die IP-Adressenanfrage eine Anfrage für eine statische IP-Adresse ist. Das Drahtlos-Kommunikationsgerät verhindert, dass das Endgerät paketisierte Daten versendet oder empfängt, wenn es beim Initiieren der Mobilknotenregistrierung ist und erlaubt dem Endgerät paketisierte Daten bei der Vollendung der Mobilknotenregistrierung zu senden und zu empfangen. Als Ergebnis erscheint die Mobilknotenregistrierung transparent für das Endgerät, was den Bedarf für das Endgerät vermeidet, seine eigene Mobil-IP-Unterstützung zu haben.
In einem anderen Aspekt der vorliegenden Erfindung teilt ein vernetztes Gerät (das das Drahtlos-Kommunikationsgerät sein kann) eine IP-Adresse mit einem getrennt vernetzten Gerät (das das Endgerät sein kann). Das Teilen erscheint bei dem vernetzten Gerät als Untersuchen einer Anschlussnummer eines empfangenen IP-Paketes. Das vernetzte Gerät lenkt das IP-Paket zu einer Anwendung auf dem vernetzten Gerät, wenn die Anschlussnummer des empfangenen IP-Paketes der Anwendung, die auf dem vernetzten Gerät läuft, entspricht. Andererseits lenkt das vernetzte Gerät das IP-Paket zu einem getrennt vernetzten Gerät, wenn die Anschlussnummer des empfangenen IP-Paketes nicht der Anwendung entspricht, die auf dem vernetzten Gerät läuft.
Weiterhin bringt das vernetzte Gerät IP-Pakete hervor, einschließlich als eine Ursprungsadresse, eine IP-Adresse, die dem getrennt vernetzten Gerät zugeordnet wurde, und zwar nach dem Bestimmen, ob die Anwendung auf dem vernetzten Gerät einen Bedarf hat, IP-Pakete hervorzubringen.
Als Alternative kann die IP-Adresse „verschoben" werden, und zwar zwischen dem vernetzten Gerät und einem getrennt vernetzten Gerät. Das vernetzte Gerät verschiebt die IP-Adresse von dem getrennt vernetzten Gerät zu sich selbst durch Blockieren der gesendeten IP-Pakete, die in dem getrennt vernetzten Gerät ihren Ursprung haben, und verschiebt hervorzubringende IP-Pakete, die als eine Ursprungsadresse eine IP-Adresse beinhalten, die dem getrennt vernetzten Gerät zugeordnet wird, wenn das vernetzte Gerät bestimmt, dass eine Anwendung auf dem ersten vernetzten Gerät einen Bedarf hat, IP-Pakete auszusenden bzw. hervorzubringen. Das vernetzte Gerät kann ebenso die empfangenen IP-Pakete ver werfen, die an das getrennt vernetzte Gerät adressiert sind, während es die IP-Adresse des getrennt vernetzten Gerätes benutzt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale, Ziele und Vorteile der vorliegenden Erfindung werden ausgehend von der detaillierten Beschreibung, die nachstehend dargelegt ist, noch deutlicher werden, wenn sie mit den Zeichnungen in Verbindung gebracht wird, in denen gleiche Bezugszeichen entsprechende Gegenstände durchgehend identifizieren und wobei:
1 ein Blockdiagramm auf höchster Ebene eines Drahtlos-Kommunikationssystems darstellt, in dem ein Endgerät sich mit dem Internet über ein Drahtlos-Kommunikationsgerät verbindet;
2 ein Diagramm des Protokollstapels in jeder Funktionseinheit des IS-707.5-Weiterleitungsmodells ist.
3 ein Zustandsdiagramm höchster Ebene des Betriebs des MT2-Gerätes der vorliegenden Erfindung ist;
4 ein Diagramm der Protokollstapel für jede Funktionseinheit eines Ausführungsbeispiels der vorliegenden Erfindung ist;
5 ein erweitertes Zustandsdiagramm des Mobil-IP-Moduszustands 310 der 3 ist;
6 ein Diagramm der Protokollstapel von jeder Funktionseinheit eines alternativen Ausführungsbeispiels der vorliegenden Erfindung ist;
7 ein erweitertes Zustandsdiagramm eines alternativen Ausführungsbeispiels des Mobil-IP-Modus 310 der 3 darstellt;
8 ein Flussdiagramm zeigt, das ein Verfahren zum Durchführen von IP-Adressenverschiebung darstellt;
9A ein Flussdiagramm ist, das ein alternatives Verfahren zum Durchführen von IP-Adressenverschiebung in Verbindung mit empfangenen IP-Paketen darstellt; und
9B ein Flussdiagramm ist, das ein alternatives Verfahren zum Durchführen von IP-Adressenverschiebung in Verbindung mit gesendeten IP-Paketen darstellt.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
Die vorliegende Erfindung ist dazu gedacht, transparente Mobilität für Benutzer von datendienstfähigen MT2-Geräten zu unterstützen. Verschiedene Ausführungsbeispiele der vorliegenden Erfindung sind dafür gedacht, Datendienste unter drei unterschiedlichen Verwendungsmodellen zu unterstützen.
Das erste Verwendungsmodell ist eines, wo Mobil-IP nicht unterstützt wird, aber Datendienste unter Verwendung einer dynamisch zugewiesenen IP-Adresse nichtsdestotrotz immer noch unterstützt werden. In diesem ersten Verwendungsmodell wird dem TE2-Gerat dynamisch eine IP-Adresse zugeordnet bzw. zugewiesen, und zwar durch den Internet Dienst Provider (ISP = Internet Service Provider), mit dem das TE2-Gerät momentan verknüpft ist. Dieses erste Verwendungsmodell verwendet keine Mobil-IP-Unterstützung und verwendet nicht seine „Heim"-IP-Adresse. Als Ergebnis empfängt das TE2-Gerät nur die Daten, die es explizit anfordert, während es mit dem ISP verbunden ist, anstatt Daten zu haben, die von seinem Heim-IP-Netzwerk zu sich weitergeleitet werden.
Das zweite Verwendungsmodell ist eines, wo Mobil-IP-Unterstützung in dem MT2-Gerät vorgesehen ist, und zwar als ein Proxy im Auftrag bzw. im Namen des TE2-Gerätes. Dieses zweite Modell gilt für Mobilbenutzer, die sich wünschen, Mobil-IP-Unterstützung zu haben, aber die kein TE2-Gerät haben, das Mobil-IP unterstützt. Zum Beispiel fallen Benutzer von TE2-Geräten, wie z.B. Laptops, die das Microsoft Windows Betriebssystem laufen haben, in dieses zweite Verwendungsmodell. In diesem zweiten Verwendungsmodell kann das TE2-Gerät seine „Heim"-IP-Adresse (d.h. die „permanente" IP-Adresse, die von dessen Heimnetzwerk zugewiesen wurde) benutzen, ob sie nun mit deren Heim-IP-Netzwerk verknüpft sind oder sich in einem Mobil-IP-fähigen Drahtlosnetzwerk hin und her bewegen (roaming). Dieses zweite Verwendungsmodell sieht ebenso Mobilitätsunterstützung für Geräte vor, die das TE2-Gerät und das MT2-Gerat integrieren, wie z.B. sogenannte „Smart Phones".
Das dritte Verwendungsmodell ist eines, wo Mobil-IP-Unterstützung in dem TE2-Gerät vorgesehen ist. Das dritte Verwendungsmodell ist anwendbar für Benutzer von TE2-Geräten, die Mobil-IP-Unterstützung haben und deswegen keiner Proxy-Dienste von einem MT2-Gerät bedürfen. Die verschiedenen Ausführungsbeispiele der vorliegenden Erfindung sind dazu gedacht, den Anforderungen von einem oder mehreren dieser drei Verwendungsmodelle zu genügen.
Es wird für den Fachmann ersichtlich sein, dass die vorliegende Erfindung, wie nachstehend beschrieben, in vielen verschiedenen Ausführungsbeispielen von Software, Firmware und Hardware in jeder der Funktionseinheiten, die in den Figuren dargestellt sind (TE2-Gerät 102, MT2-Gerät 104, BS/MSC 106 und IWF 108) implementiert werden kann. Der eigentliche Softwarecode oder die Steuerungshardware, die benutzt wird, um die vorliegende Erfindung zu implementieren, ist nicht begrenzt auf die vorliegende Erfindung. Somit wird der Betrieb bzw. Operation und das Verhalten der vorliegenden Erfindung ohne spezifische Referenz auf den eigentlichen Softwarecode beschrieben, wobei es angemerkt ist, dass ein Fachmann in der Lage sein würde, Software und Steuerungshardware zu entwickeln, um die verschiedenen Ausführungsbeispiele der vorliegenden Erfindung, basierend auf der Beschreibung hierin, zu implementieren.
Nun zu 3, in der ein Zustandsdiagramm höchsten Grades von dem Betrieb des MT2-Gerätes der vorliegenden Erfindung dargestellt ist. In 3 beginnt das MT2-Gerät in einem geschlossenen Zustand 308. Im geschlossenen Zustand 308 ist das MT2-Gerät momentan nicht in einem Anruf, aber erwartet eine Entstehung eines Anrufs. Mobil terminierte Anrufe (d.h., solche, wo das MT2-Gerat der angerufene Teilnehmer ist) werden in diesem Zustand nicht betrachtet, weil sie annehmen, dass dem MT2-Gerät entweder schon eine IP-Adresse zugewiesen wurde, oder es sich schon für Mobil-IP registriert hat. Wenn das MT2-Gerät sich schon für Mobil-IP registriert hat, dann ist es nicht in diesem geschlossenen Zustand 308, sondern ist im Mobil-IP-Moduszustand 310, wie untenstehend noch weiter diskutiert.
Wenn ein Paketdatenanruf von dem TE2-Gerät initiiert wurde, wechselt das MT2-Gerät von dem geschlossenen Zustand 308 in den Mobilität-Eingeschaltet?-Zustand 304. In dem Mobilität-Eingeschaltet?-Zustand 304, prüft das MT2-Gerat den Wert des Mobilitätsdatenelements 302, um zu bestimmen, ob die Mobilitätsunterstützung (für Mobil-IP) eingeschaltet ist. In einem Ausführungsbeispiel kann das Mobilitätsdatenelement 302 einen von drei Werten haben, die optional vom Mobilbenutzer, wie gewünscht, konfiguriert werden können, und zwar über z.B. ein Benutzerinterface am TE2-Gerät oder am MT2-Gerät. Andere Ausführungsbeispiele können mehr oder weniger Werte benutzen, um dem Mobilbenutzer zu ermöglichen, mehr oder weniger Konfigurationswahlmöglichkeiten zu geben bzw. zu haben. Noch andere Ausführungsbeispiele erlauben keine Benutzerkonfiguration des Mobilitätsdatenelements 302. In noch anderen Ausführungsbeispielen existiert das Mobilitätsdatenelement 302 nicht, sondern die Entscheidung ist vielmehr in eine Steuerungssoftware hart-kodiert.
Der erste Wert des Mobilitätsdatenelements ist „abgeschaltet". Wenn der Wert des Mobilitätsdatenelements 302 „abgeschaltet" ist, unterstützt das MT2-Gerät keine Mobil-IP-Verhandlung und -registrierung. Als Ergebnis benutzen alle Paketdatenanrufe, die entstehen, wenn das Mobilitätsdatenelement 302 den Wert „abgeschaltet" hat, den einfachen IP-Modus 306, wie nachstehend weiter diskutiert.
Der zweite Wert ist „wenn verfügbar". Wenn der Wert des Mobilitätsdatenelementes 302 „wenn verfügbar" ist, dann wird das MT2-Gerät Mobil-IP-Verhandlung und -Registrierung vorsehen, außer die Infrastruktur (BS/MSC 106 und IWF 108) unterstützen kein Mobil-IP oder außer die Mobilknotenregistrierung, die von dem MT2-Gerat versucht wurde, schlägt fehl. Wenn die Infrastruktur kein Mobil-IP unterstützt, dann wird der Paketdatenanruf ein einfacher IP-Modus-306-Anruf. Mit anderen Worten, ermöglicht es der „wenn verfügbar"-Wert für das Mobilitätsdatenelement 302 dem Benutzer des TE2-Gerätes und des MT2-Gerätes die Vorteile des Mobil-IP zu erlangen, wenn es von der Infrastruktur unterstützt wird und es erfolgreich ausgehandelt wurde, aber es ermöglicht immer noch einen Paketdatenanruf ohne Mobil-IP-Unterstützung, für den anderen Fall. In einem Ausführungsbeispiel, in dem dem Mobilbenutzer nicht erlaubt wird, den Wert für das Mobilitätsdatenelement 302 zu ändern, wird dieser zweite Wert benutzt. Als Alternative kann das Mobilitätsdatenelement 302 immer auf „wenn verfügbar" gesetzt werden, oder komplett ausgelassen werden, was den Übergang zwischen dem Mobilitität-Eingeschaltet?-Zustand 304 und dem einfachen IP-Moduszustand 306 eliminiert.
Der dritte Wert ist „ausschließlich". Wenn der Wert des Mobilitätsdatenelementes 302 „ausschließlich" ist, dann wird das MT2-Gerät Mobil-IP-Aushandlung und -Registrierung vorsehen, außer die Infrastruktur (BS/MSC 106 und IWF 108) unterstützt kein Mobil-IP oder die Mobilknotenregistrierung, die von dem MT2-Gerät versucht wurde, schlägt fehl. Jedoch, im Gegensatz zu dem „wenn verfügbar"-Wert wie oben, wenn entweder die Infrastruktur kein Mobil-IP unterstützt oder der Mobilknotenregistrierungsversuch fehlschlägt, dann beendet das MT2-Gerät einen einfachen IP-Anruf nicht, sondern zwingt den Paketanrufsursprungsversuch komplett fehlzuschlagen. Mit anderen Worten, der „ausschließlich"-Wert für das Mobilitätsdatenelement 302 verhindert, dass irgendein Paketdatenanruf, außer dem Mobil-IP-unterstützten Anruf, von dem MT2-Gerät hervorgebracht wird.
Wenn der Wert des Mobilitätsdatenelements 302 „abgeschaltet" ist, oder wenn der Wert des Mobilitätsdatenelements 302 „wenn verfügbar" ist, aber Mobil-IP von der Infrastruktur nicht unterstützt wird, dann wird das MT2-Gerät in den einfachen IP-Modus 306 auf einen Paketdatenanrufentstehungsversuch hin eintreten. In einem Ausführungsbeispiel wendet der einfache IP-Modus 306 das konventionelle (S-707.5 Weiterleitungsmodell an, wie dargestellt und beschrieben mit Bezug auf 2.
Wenn der Wert des Mobilitätsdatenelementes 302 entweder „wenn verfügbar" oder „ausschließlich" ist, wechselt das MT2-Gerät von dem Mobilität-Eingeschaltet?-Zustand 304 zum Mobil-IP-Modus 310. In diesen Mobil-IP-Modus 310, tritt das MT2-Gerät in Mobilknotenregistrierung für die Mobil-IP-Dienste als ein Proxy im Namen des TE2-Gerätes, wie nachstehend beschrieben, ein.
Nun zu 4, in der ein Diagramm der Protokollstapel von jeder Funktionseinheit von einem Ausführungsbeispiel der vorliegenden Erfindung gezeigt ist. Ein signifikanter Unterschied zwischen dem Diagramm der 4 und dem der 2 ist, dass in 4 zusätzliche Protokollschichten in dem MT2-Gerät 104 existieren, die die Mobilknotenregistrierung der vorliegenden Erfindung unterstützen. Diese zusätzlichen Protokollschichten beinhalten PPP-Protokol 415, IP-Protokoll 413, UDP-Protokoll 411 und Mobil-IP-Protokoll 409. Soweit die Protokollschichten der 4 auf die gleiche Art und Weise operieren wie die der 2, werden sie nicht im Detail erläutert. Stattdessen wird sich die folgende Diskussion auf die Unterschiede zwischen 4 und 2 konzentrieren.
Ein Beispiel für die Operation der 4 ist das Folgende. Eine Funktionseinheit des oberen Schichtprotokolls 402, wie z.B. ein Anwendungsprogramm, das auf dem TE2-Gerat 102 läuft, hat einen Bedarf, IP-Pakete über das Internet zu senden, ähnlich der Funktionseinheit bzw. Einheit des oberen Schichtprotokolls 202 der 2. Die Anwendung generiert eine Nachricht unter Verwendung von z.B. entweder dem TCP- oder UDP-Protokollen und kapselt das TCP- oder UDP-Paket durch das IP-Protokoll 404 unter Verwendung der Ziel-IP-Adresse ein. Das Punkt-Zu-Punkt-Protokoll (PPP) 406 rahmt die IP-Pakete ein und sendet sie über das R_m-Interface unter Verwendung des Weiterleitungsschichtprotokolls 408 EIA-232 zu dem EIA-232-kompatiblen Anschluss im MT2-Gerat, das das EIA-232-Protokoll 410 laufen lässt.
Wie jedoch auf dem Fachgebiet bekannt ist, um Kommunikationen über eine Punkt-Zu-Punkt-Verbindung aufzubauen, muss jedes Ende der PPP-Verbindung (hier das TE2-PPP-Protokoll 406 und IWF-PPP-Protokoll 426) zuerst Verbindungssteuerungsprotokoll-(LCP = Link Control Protocol)-Pakete zum Aufbauen, Konfigurieren und Testen der Datenverbindungsverknüpfung senden. Nachdem die Verbindung von dem LCP aufgebaut worden ist, sendet anschließend das PPP-Protokoll 406 Netzwerk-Steuerungsprotokoll-(NCP = Network Control Proto col)-Pakete, um die Netzwerkschichtprotokolle (hier das TE2-IP-Protokoll 404 und IWF-IP-Protokoll 425) zu konfigurieren. Nachdem jedes der Netzwerkschichtprotokolle konfiguriert worden ist, können Datagramme von jedem Netzwerkschichtprotokoll über die Verbindung zwischen diesen gesendet werden.
In einem Ausführungsbeispiel ist das NCP für IP das IP-Steuerungsprotokoll (IPCP = IP Control Protocol). Das IPCP ist im Detail beschrieben im RFC 1332 mit dem Titel „The PPP Internet Protocol Control Protocol (IPCP)" veröffentlicht im Mai 1992. Das IPCP ist verantwortlich für das Konfigurieren, Einschalten und Ausschalten von sowohl dem TE2-IP-Protokoll 404 als auch dem IWF-IP-Protokoll 425, die auf beiden Seiten der Punkt-Zu-Punkt-Verbindung laufen. Wie auf dem Fachgebiet bekannt ist, benutzt IPCP Konfigurationsanfragen, die Nachrichten sind, die eine Konfigurationsoption für die IP-Adresse beinhalten. Dieser Konfigurationsoptionsteil der Konfigurationsanfragenachricht sieht einen Weg vor, um die IP-Adresse, die vom Sender der Konfigurationsanfrage (hier das TE2-Gerät 102) benutzt werden soll, auszuhandeln. Es ermöglicht dem Sender der Konfigurationsanfrage mitzuteilen, welche IP-Adresse gewünscht ist, und zwar durch Spezifizieren einer IP-Adresse oder durch Anfragen, dass der Peer (hier die IWF 108) eine dynamische IP-Adresse für den Sender vorsieht. Wenn der Sender der Konfigurationsanfrage das IP-Adressenfeld in der IP-Adressenkonfigurationsoption auf nur Nullen stellt, dann kann der Peer eine dynamische IP-Adresse vorsehen, und zwar durch Senden einer Konfigurations-NAK (Negativbestätigung, NAK = Negative Acknowledgement) für diese Option, und durch Zurückgeben einer gültigen IP-Adresse. Wenn auf der anderen Seite der Sender der Konfigurationsanfrage das IP-Adressenfeld in der IP-Adressenkonfigurationsoption auf eine spezifizierte IP-Adresse setzt, kann der Peer anzeigen, dass die spezifizierte IP-Adresse akzeptabel ist, und zwar durch Senden einer Konfigurations-ACK für die Option. Die vorliegende Erfindung zieht Vorteil aus den IPCP-Kommunikationen zwischen dem TE2-Gerat 102 und der IWF 108, um zu bestimmen, ob und wann als Proxy für das TE2-Gerät während der Mobilknotenregistrierung agiert werden soll.
5 stellt ein erweitertes Zustandsdiagramm des Mobil-IP-Modus-Zustands 310 der 3 dar. Wenn der Mobilität-Eingeschaltet?-Zustand 304 (3) bestimmt, dass das Mobilitätsdatenelement 302 abgeschaltet ist, wechselt es in den Überwachungs-PPP-Unterzustand 502. Es sei angemerkt, dass es möglich ist, von jedem Unterzustand der 5 in den Schließen-Unterzustand 516 zu wechseln, wenn der Anruf beendet ist. Zwecks Einfachheit ist jedoch der Anruf-Beendet-Übergang bzw. –Wechsel nur vom Offen-Unterzustand 508 zum Schließen-Unterzustand 516 gezeigt.
In dem Überwachungs-PPP-Unterzustand 502 fügt das MT2-Gerät 104 einen Netzwerk-„Zapfen" bzw. -„Spigot" bzw. -„Einschub" 417 in den MT2-Gerät-Protokollstapel zwischen die RLP-Protokoll-412- und die EIA-232-Protokoll-410-Peers ein. Mit anderen Worten werden PPP-Pakete, die zwischen dem EIA-232-Protokoll 410 und dem RLP-Protokoll 412 weitergereicht werden, überwacht und untersucht durch das MT2-Gerät 104. Dies ermöglicht dem MT2-Gerät 104 PPP-Pakete, wenn sie zwischen dem TE2-Gerät 102 und dem IWF 108 laufen bzw. weitergereicht werden, zu überwachen.
Das erste LCP-Paket wird vom MT2-Gerät 104 für die Benutzung nach einem Zwischen-IWF-Handoff zwischengespeichert (cached), wie nachstehend mit Bezug auf den Initiierer-PPP-Resync-Zustand 504 beschrieben wird. Das MT2-Gerät 104 fährt fort, die PPP-Pakete zu überwachen, die zwischen dem TE2-Gerät 102 und der IWF 108 ausgetauscht werden, bis ein IPCP-Paket von dem TE2-Gerat 102 von dem MT2-Gerat 104 detektiert wird. Das IPCP-Paket wird anschließend untersucht von dem MT2-Gerät 104, um zu bestimmen, ob eine statische oder dynamische IP-Adresse in der IP-Adressenkonfigurationsoption der Konfigurationsanfrage angefordert worden ist. Wenn das IP-Adressenfeld eine IP-Adresse enthält, die nur aus Nullen besteht, dann fordert das TE2-Gerät eine dynamische Adresse an. In einem solchen Fall gibt es keine Anfrage für Mobil-IP-Unterstützung von dem TE2-Gerät 102 und das MT2-Gerät 104 wechselt in den einfachen IP-Modus 306 (3).
Wenn auf der anderen Seite das IP-Adressenfeld in der Konfigurieren-Anfrage, die von dem TE2-Gerät 102 gesendet wird, eine statische (d.h. nicht Nullen) IP-Adresse enthält, wechselt das MT2-Gerät 104 anschließend in den Überwa chungs-IPCP-Zustand 506. In dem Überwachungs-IPCP-Zustand 506 überwacht das MT2-Gerät 104 die IPCP-Pakete, die zwischen dem TE2-Gerät 102 und dem IWF 108 ausgetauscht werden. Im Speziellen untersucht das MT2-Gerät 104 die IPCP-Pakete, um zu bestimmen, ob die statische IP-Adressenanfrage, die von dem TE2-Gerat 102 gemacht wurde, von der IWF 108 mit einer Konfigurieren-ACK akzeptiert worden ist.
Wenn die statische IP-Adressenanfrage, die von dem TE2-Gerat 102 gemacht wurde, von der IWF 108 verweigert wurde, dann wechselt das MT2-Gerät 104 in den Mobilitätsmodus?-Zustand 514, wo es den Wert des Mobilitätsdatenelementes 302 prüft. Wenn der Wert des Mobilitätsdatenelements 302 „wenn verfügbar" ist, dann wechselt das MT2-Gerat 104 in den einfachen IP-Moduszustand 306 (3), weil angenommen wird, dass der Benutzer mit dem einfachen IP-Anruf (d.h., einer dynamisch zugewiesenen IP-Adresse) zufrieden ist, wenn Mobil-IP-Unterstützung nicht verfügbar ist. Wenn jedoch der Mobilitätsdatenelement-302-Wert „ausschließlich" ist, dann wechselt das MT2-Gerät 104 in den Schließen-Zustand 516, weil angenommen wird, dass der Benutzer nicht mit einem einfachen IP-Anruf zufrieden ist.
Wenn die statische IP-Adressenanfrage, die von dem TE2-Gerät 102 gemacht wird, von der IWF 108 akzeptiert wird, dann wechselt das MT2-Gerät 104 in den Mobilregistrierungszustand 512 bei Beendigung der IPCP-Aushandlung. In dem Mobilregistrierungszustand 512 initiiert das MT2-Gerät 104 das PPP-Protokoll 415, das IP-Protokoll 413, das UDP-Protokoll 411 und das Mobil-IP-Protokoll 409. Das MT2-Gerät 104 flusssteuert anschließend das TE2-Gerät 102. Wie hierin benutzt, bezieht sich „Flusssteuern" auf den Schritt des Vermeidens, dass das TE2-Gerät 102 Daten über das Weiterleitungsschichtinterface sendet oder empfängt. In dem Ausführungsbeispiel der 4 ist dies die Verbindung zwischen dem EIA-232-Protokoll 408 des TE2-Gerätes und dem EIA-232-Protokoll 410 des MT2-Gerätes. Software- oder Hardware-Flusskontrolle kann benutzt werden. In einem Ausführungsbeispiel schaltet z.B. das MT2-Gerat 104 eine der Pinspannungen zwischen dem MT2-Gerät 104 und dem TE2-Gerat 102 hin und her.
Durch Flusssteuern des TE2-Gerätes 102 kann nun das MT2-Gerät 104 und insbesondere das IP-Protokoll 413 der IP-Endpunkt für die Zwecke der Mobilknotenregistrierung werden. Dies ermöglicht dem MT2-Gerät 104 Mobilknotenregistrierung im Namen bzw. Auftrag des TE2-Gerätes 102 durchzuführen, transparent zu dem TE2-Gerät 102. Konzeptuell „verschiebt" dies den IP-Endpunkt von dem TE2-Gerät 102, wo es anderenfalls sein würde, zum MT2-Gerät 104.
Das MT2-Gerät 104 liest die Mobilknotenregistrierungs-(MNR = Mobile Node Registration)-Datenelemente 510. In einem Ausführungsbeispiel werden diese Datenelemente in einem geeigneten nicht flüchtigen Speicherschaltkreis (nicht gezeigt) gespeichert. Diese MNR-Datenelemente 510 sind die Datenelemente, die für die Durchführung der Mobilknotenregistrierung gebraucht werden. Diese MNR-Datenelemente 510 können einen Sicherheitsparameterindex, MD5-Authentifizierungsschlüssel, wie beschrieben in RFC 2002, und die Heimagent-IP-Adresse beinhalten.
Das MT2-Gerät 104 führt anschließend Mobilknotenregistrierung, wie beschrieben in RFC 2002 durch, und zwar unter Verwendung der statischen IP-Adresse, die von dem TE2-Gerät 102 und den MNR-Datenelementen 510 angefragt bzw. angefordert wurden. Die Details für die Mobilknotenregistrierung sind in RFC 2002 beschrieben und werden deswegen hierin nicht im Detail beschrieben. Kurz, das Mobil-IP-Protokoll 409 sendet eine Fremdagentenbewerbungs- bzw. -ansuchungsnachricht an das Mobil-IP-Protokoll 421 in IWF 108. Diese Fremdagentenbewerbungsnachricht wird zum UDP-Protokoll 411 runtergereicht. UDP-Protokoll 411 agiert als ein Datagrammdienst, wie auf dem Fachgebiet bekannt ist, und reicht die Fremdagentenbewerbungsnachricht zum IP-Protokoll 413, wo es mit dem IP-Header von entweder der Broadcast- bzw. Ausstrahladresse oder der „Alle-Router"-Multicastadresse gemäß RFC 2002 paketisiert wird.
Das IP-Protokoll 413 reicht anschließend das IP-Paket zum PPP-Protokoll 415 weiter, das es in ein PPP-Paket paketisiert, und leitet es weiter zum RLP-Protokoll 412 und IS-95-Protokoll 414 für die Sendung über das U_m-Interface. Ein komplementäres RLP-Protokoll 416 und IS-95-Protokoll 418 in der BS/MSC 106 reicht die Daten zu dem Weiterleitungsschichtprotokoll 420 zur Sendung über das L-Interface zum Weiterleitungsschichtprotokoll 428.
Das PPP-Protokoll 426 entpaketisiert anschließend die PPP-Pakete, die empfangen wurden und reicht sie zum IP-Protokoll 425 weiter. Das IP-Protokoll 425 entfernt den IP-Header und lenkt die Pakete zum UDP-Protokoll 423, das wiederum die entpaketisierte Fremdagentenbewerbungsnachricht zum Mobil-IP-Protokoll 421 reicht. Wenn das Mobil-IP-Protokoll 421 in der IWF 108 vorliegt, dann ist eine Fremdagenteneinheit in der IWF 108 angesiedelt, und es antwortet mit einer Agentenwerbungsnachricht, die dem Rückwärtspfad zurück zum Mobil-IP-Protokoll 409 in dem MT2-Gerät 104 folgt.
Das Mobil-IP-Protokoll 409 sendet anschließend eine Mobilknotenregistrierungsnachricht zu dem Fremdagenten in der IWF 108 aus. Wenn die Mobilknotenregistrierungsnachricht für den Fremdagenten akzeptabel ist, wird er die Mobilknotenregistrierungsnachricht zu einer Heimagenteneinheit, die in dem Heim-IP-Netzwerk des TE2-Gerätes (d.h., das Netzwerk, das die statische IP-Adresse umfasst, das von dem TE2-Gerät 102 angefragt wurde) angesiedelt ist, weiter reichen.
Wenn die Mobilknotenregistrierungsnachricht für den Heimagenten akzeptabel ist, dann erzeugt der Heimagent eine Mobilitätsbindung für das TE2-Gerät 102 unter Verwendung der „Care-Of"-Adresse des Fremdagenten. Eine Mobilitätsbindung, wie im RFC 2002 beschrieben, ist eine Lenkung, die alle IP-Pakete, die für das TE2-Gerät 102 gedacht sind, die beim Heimnetzwerk des TE2-Gerätes ankommen, nimmt und sie zum Fremdagenten unter Verwendung der IP-Tunnelung weiterleitet.
Beim Empfang einer Benachrichtigung von dem Heimagenten, dass die Mobilitätsbindung erzeugt worden ist, erzeugt der Fremdagent anschließend eine Zuordnung zwischen der inneren IP-Adresse in dem getunnelten Paket (d.h., die statische IP-Adresse, die von dem TE2-Gerät 102 angefordert wurde), und der „Telefonnummer" des MT2-Gerätes 104. Hier wird das Wort „Telefonnummer" benutzt im weitesten Sinn, um die Identifikationsnummer des MT2-Gerätes 104 zu reprä sentieren. Wie hierin benutzt, ist sie dafür gedacht, sich auf die Mobilidentifikationsnummer (MIN = Mobile Identification Number) des MT2-Gerätes 104, seine elektronische Seriennummer (ESN = Electronic Serial Number) oder einen anderen einzigartigen Identifikator zu beziehen, die bzw. den das MT2-Gerät 104 mit der BS/MSC 106 registriert hat, wie auf dem Fachgebiet bekannt ist. Die IWF 108 hält diese IP-zu-MIN- oder IP-zu-ESN-Übersetzung aufrecht.
Um diese Mobilknotenregistrierung durchzuführen, leitet die vorliegende Erfindung IP-Pakete vom RLP-Protokoll 412 zum MT2-PPP-Protokoll 415 um, um die Lieferung der erforderlichen Daten zur Mobilknotenregistrierungssoftware abzusichern, die auf dem Mobil-IP-Protokoll-409-Level des MT2-Gerät-Protokollstapels läuft. Es sei angemerkt, dass das MT2-PPP-Protokoll 415 keine volle PPP-Implementierung, wie im RFC 1661 beschrieben, ist. In dem Ausführungsbeispiel der 4 führt das MT2-PPP-Protokoll 415 keine Aushandlung für Protokoll- oder Verbindungsaufbau durch, es rahmt nur ein, entrahmt und führt jedes benötigte Zeichen-Escaping der IP-Pakete durch, die vom MT2-Gerät 104 während des Mobilregistrierungszustandes 512 gesendet und empfangen werden, weil PPP bereits zwischen dem TE2-Gerat 102 und der IWF 108 ausgehandelt wurde, wie oben beschrieben.
Wenn die Mobilknotenregistrierung, die oben beschrieben ist, und die während des Mobilknotenregistrierungszustands 512 durchgeführt wird, aus irgendeinem Grund fehlschlägt, verlässt in einem Ausführungsbeispiel das MT2-Gerät 104 das Mobil-IP-Protokoll 409, das UDP-Protokoll 411, das IP-Protokoll 413 und das PPP-Protokoll 415 und wechselt in den Schließen-Zustand 516. Mögliche Gründe für ein Fehlschlagen können beinhalten, dass der Fremdagent oder Heimagent die Mobilknotenregistrierungsnachricht zurückweist. In anderen Ausführungsbeispielen kann das MT2-Gerät 104 versuchen, mit einer dynamischen IP-Adresse PPP zu resynchronisieren, anstatt mit der statischen IP-Adresse, die von dem TE2-Gerät angefordert wurde.
Andernfalls, bei erfolgreicher Mobilknotenregistrierung in dem Mobilknotenregistrierungszustand 512, verlässt das MT2-Gerät das Mobil-IP-Protokoll 409, das UDP-Protokoll 411, das IP-Protokoll 413 und das PPP-Protokoll 415 und wechselt anschließend in den Offen-Zustand 508. In dem Offen-Zustand 508 agiert das MT2-Gerät 104 gemäß dem IS-707.5-Weiterleitungsmodell, wie in 2 gezeigt. Sobald es in diesem Offen-Zustand 508 ist, werden die Daten, die beim RLP-Protokoll 412 des MT2-Gerätes 104 ankommen, einfach über die EIA-232-Schnittstelle bzw. -Interface zwischen dem TE2-Gerät 102 und dem MT2-Gerät 104 gesendet.
Das MT2-Gerat bleibt in dem Offen-Zustand 508 bis eines der drei Dinge passiert: der Anruf endet, das MT2-Gerät 104 geht über (hand off) in eine andere IWF oder die Mobilregistrierungslebenszeit wurde überschritten. Der Anruf kann auf viele Arten beendet werden. Zum Beispiel kann der Benutzer den „Ende"-Knopf (nicht gezeigt) oder dergleichen auf dem MT2-Gerät 104 drücken, um dabei absichtlich den Datenanruf zu beenden. Ein anderes Beispiel ist, dass das TE2-Gerät oder die IWF 108 unilateral bzw. einseitig die PPP-Sitzung zwischen den beiden beendet. Nach einem anderen Beispiel kann der Datenanruf einfach beendet werden, weil die Funkverbindung zwischen dem MT2-Gerät 104 und der BS/MSC 106 so nachlässt, dass der Anruf fallengelassen wird. Wenn der Anruf in einer dieser Arten beendet wird, wechselt das MT2-Gerät 104 in den Schließen-Zustand 516.
In dem Schließen-Zustand 516 führt das MT2-Gerät 104 Organisationsfunktionen durch, die benötigt werden, um den Mobil-IP-Protokollstapel (Mobil-IP-Protokoll 409, UDP-Protokoll 411, IP-Protokoll 413 und PPP-Protokoll 415) runterzufahren, wenn sie noch da sind. Zusätzlich entfernt das MT2-Gerät 104 den Netzwerk-„Spigot" 417, wenn es immer noch da ist. Letztendlich kann irgendeine geeignete Benutzerbenachrichtigungsnachricht angezeigt werden (z.B. auf einem Benutzerinterface, nicht gezeigt) oder andernfalls dem Benutzer präsentiert werden, um anzuzeigen, dass der Mobil-IP-Registrierungsprozess nicht erfolgreich war. Optional kann eine detailliertere Beschreibung von dem aufgetretenen Fehler und eine Ursache (wenn bekannt) ebenso angezeigt werden. Nachdem jegliche Benachrichtigungen gemacht wurden und jegliche Organisationsaufräumungsaktionen beendet wurden, wechselt das MT2-Gerät 104 anschließend in den Geschlossen-Zustand 308 (3).
Alternativ kann das MT2-Gerät 104, während es in dem Offen-Zustand 508 ist, zu einer anderen BS/MSC 106 übergehen (hand off). Typischerweise wird dies passieren, wenn das MT2-Gerät 104 von einem geografischen Ort zum anderen sich bewegt, der außerhalb des Dienstbereiches der ursprünglichen BS/MSC 106 ist. Wenn die zwei BS/MSCs nicht von der gleichen IWF 108 versorgt werden, dann tritt ein Zwischen-IWF-Handoff auf. Das MT2-Gerät 104 kann dies detektieren, entweder durch Untersuchen der IS-95-Paketzonen-ID oder durch Bemerken einer Änderung in der Systemidentifikation (SID = System Identification) oder Netzwerkidentifikation (NID = Network Identification) der versorgenden BS/MSC 106. In beiden Fällen wird das M12-Gerät 104 in den Initiiere-PPP-Resync-Zustand 504 wechseln.
In dem Initiiere-PPP-Resync-Zustand 504 initiiert das MT2-Gerät 104 eine PPP-Resynchronisation mit der IWF 108 durch Senden des ersten LCP-Pakets, das am Beginn der PPP-Aushandlungen, wie oben beschrieben, zwischengespeichert worden ist. Dies löst einen Austausch von LCP-Paketen in Reaktion hierzu aus, und zwar von der IWF 108. Bei der Detektion dieses Austauschs von LCP-Paketen wechselt das MT2-Gerat anschließend zurück in den Überwachungs-PPP-Zustand 502, wie oben beschrieben.
Wenn auf der anderen Seite während des Offen-Zustands 508 die Mobilregistrierungslebenszeit, wie definiert im RFC 2002, überschritten ist, wechselt das MT2-Gerät direkt zurück in den Mobilregistrierungszustand 512, um die Mobilknotenregistrierung, wie oben beschrieben, neu zu verhandeln.
Somit wurden in dem Ausführungsbeispiel der 4 die zusätzlichen Protokollschichten in dem MT2-Gerät 104 (PPP-Protokoll 415, IP-Protokoll 413, UDP-Protokoll 411 und Mobil-IP-Protokoll 409) nur vorgebracht, um Mobilknotenregistrierung in dem Mobilregistrierungszustand 512 durchzuführen, und werden runtergefahren nach dem Verlassen des Mobilregistrierungszustands 512. Der gesamte IP-Verkehr während der Zeit, in der diese zusätzlichen Protokollschichten hochgefahren sind, beginnt und endet beim MT2-Gerät 104. Konzeptuell „verschiebt" dies den IP-Endpunkt von dem TE2-Gerät 102 während der Mobilknotenregistrierung und geht zurück zu dem TE2-Gerät 102 bei Beendigung der Mobilknotenregistrierung. Auf diese Weise dient das MT2-Gerät 104 als ein Proxy für das TE2-Gerät 102 während der Mobilknotenregistrierung, was den Bedarf verhindert bzw. umgeht, dass das TE2-Gerät 102 seine eigene IP-Mobilitätsunterstützung haben muss.
6 zeigt ein Diagramm der Protokollstapel jeder Einheit eines alternativen Ausführungsbeispiels der vorliegenden Erfindung. Ein signifikanter Unterschied zwischen 6 und 4 ist, dass in dem Ausführungsbeispiel der 6 ein Peer-Verhältnis zwischen dem MT2-Gerät 104 und dem TE2-Gerat 102 auf dem PPP-Level existiert. Es sei angemerkt, dass das PPP_R-Protokoll 605 des MT2-Gerätes 104 als die Terminierung für das PPP_R-Protokoll 606 des TE2-Geräts 102 dient. Es sei ebenso angemerkt, dass das PPP_U-Protokoll 626 der IWF 108 als die Terminierung für das PPP_U-Protokoll 615 des MT2-Gerätes 104 dient. Im Gegensatz zu dem Ausführungsbeispiel der 4 überleben bzw. bleiben die PPP_R- und PPP_U-Verbindungen in dem MT2-Gerät 104 nach der Mobilknotenregistrierung aufrechterhalten.
Die Operation der 6 wird ebenso mit Bezug auf das Zustandsdiagramm der 7 erklärt. 7 ist ein Zustandsdiagramm eines alternativen Ausführungsbeispiels des Mobil-IP-Modus 310 der 3. Das MT2-Gerat 104 beginnt im Überwachungs-PPP_R-Zustand 702. In dem Überwachungs-PPP_R-Zustand 702 initiiert das MT2-Gerät 104 das PPP_R-Protokoll 605 und handelt die PPP_R-Verbindung zwischen dem MT2-Gerät 104 und dem TE2-Gerät 102 aus. Das MT2-Gerät 104 speichert ebenso das erste LCP-Paket, das von dem TE2-Gerät 102 empfangen wurde, zwischen, und zwar für die Benutzung in einer späteren PPP-Resynchronisation, wenn benötigt.
Das MT2-Gerät 104 fährt fort, die PPP_R-Verbindung zu überwachen, um nach der IPCP-Konfigurieren-Anfrage bzw. -Anforderung des TE2-Gerätes zu schauen. Beim Detektieren der IPCP-Konfigurieren-Anfrage des TE2-Gerätes untersucht das MT2-Gerät 104 das IP-Adressenfeld. Wenn die angeforderte IP-Adresse dy namisch ist, d.h., nur Nullen, dann wechselt das MT2-Gerät 104 in den Starte-Resync-PPP-Zustand 704.
In dem Starte-Resync-PPP-Zustand 704 schaltet das MT2-Gerät 104 das PPP_R-Protokoll 605 ab und leitet das ursprüngliche LCP-Paket (vorher zwischengespeichert in dem Überwachungs-PPP_R-Zustand 702) zur IWF 108 weiter, um dadurch eine PPP-Verbindung direkt zwischen dem TE2-Gerät 102 und der IWF 108 zu initiieren. Dies wird gemacht, um Overhead des Laufenlassens des PPP_R-Protokolls 605 und des PPP_U-Protokolls 615 auf dem MT2-Gerät 104 für einen einfachen IP-Anruf zu vermeiden. Da eine dynamische Adresse angefordert wurde, sind die zusätzlichen PPP-Schichten in dem MT2-Gerät 104 nicht notwendig und das normale IS-707.5-Weiterleitungsmodell der 2 findet Anwendung.
Wenn jedoch die IPCP-Konfigurieren-Anfrage des TE2-Gerätes eine statische IP-Adresse enthält, dann wechselt das MT2-Gerät 104 zum Aushandeln-PPP_U-Zustand 706, nachdem die PPP_R-Verbindung in dem Überwachungs-PPP_R-Zustand 702 vollkommen ausgehandelt wurde. Sobald das MT2-Gerät 104 sich in dem Aushandeln-PPP_U-Zustand 706 befindet, initiiert es die zusätzlichen Schichten in dem MT2-Protokollstapel, einschließlich dem Mobil-IP-Protokoll 609, UDP-Protokoll 611, IP-Protokoll 613 und PPP_U-Protokoll 615. Das MT2-Gerät 104 flusskontrolliert ebenso das TE2-Gerät 102. Nochmal, Flusskontrolle bezieht sich auf das Vermeiden, dass das TE2-Gerät 102 irgendwelche Daten über das R_m-Interface sendet oder empfängt.
Das MT2-Gerat 104 handelt anschließend die PPP_U-Verbindung zwischen dem PPP_U-Protokoll 615 und dem PPP_U-Protokoll 626 aus. In der Aushandelung der PPP_U-Verbindung benutzt das MT2-Gerat 104 die gleichen Parameter so wie sie von dem TE2-Gerat 102 während der Aushandelung der PPP_R-Verbindung angefordert wurden. Insbesondere wird die statische IP-Adresse, die von dem TE2-Gerät 102 von dem MT2-Gerät 104 angefordert wurde, benutzt von dem MT2-Gerät 104 in der Aushandelung der PPP_U-Verbindung mit der IWF 108.
Während der PPP_U-Verbindungsaushandlung überwacht das MT2-Gerat 104 die IPCP-Pakete, die von der IWF 108 zurückkommen. Wenn die IPCP-Konfigurieren-Anfrage, die die statische IP-Adresse enthält, von der IWF 108 zurückgewiesen wird, dann wechselt das MT2-Gerät 104 in den Mobilitätsmodus?-Zustand 708.
Im Mobilitätsmodus?-Zustand 708 wird das Mobilitätsdatenelement 302 geprüft. Wenn der Wert des Mobilitätsdatenelements 302 „wenn verfügbar" ist, dann wechselt das MT2-Gerät 104 zum Starte-Resync-PPP-Zustand 704 in Vorbereitung für einen einfachen IP-Anrufversuch im einfachen IP-Modus 306. Wenn der Wert des Mobilitätsdatenelements 302 „Mobil-IP ausschließlich" ist, dann wechselt das MT2-Gerat 104 zum Schließen-Zustand 710. Der Schließen-Zustand 710 ist ähnlich der Operation des Schließen-Zustands 516 der 5.
Wenn die ICPC-Konfigurieren-Anfrage, die die statische IP-Adresse enthält, von der IWF 308 akzeptiert wird, dann wechselt das MT2-Gerät 104 in den Mobil-Registrierungszustand 712. Die Bedingung des Systems bei Eintritt in den Mobil-Registrierungszustand 712 ist, dass aus der Sicht des TE2-Gerätes 102 die IP-Adresse des MT2-Gerätes 104 als die der IWF 108 erscheint. Weiterhin erscheint aus der Sicht der IWF 108 die IP-Adresse des MT2-Gerätes 104 als die des TE2-Gerätes 102. Mit anderen Worten hält das MT2-Gerät 104 zwei IP-Adressen wie zwischen PPP_R-Protokoll 605 und PPP_U-Protokoll 615. Als Ergebnis reicht das MT2-Gerät 104 PPP-Pakete zwischen PPP_R-Protokoll 605 und PPP_U-Protokoll 615 ohne Rücksicht auf die IP-Adressen weiter.
Der Mobil-Registrierungszustand 712 ist sehr ähnlich zu dem Mobil-Registrierungszustand 512 der 5, mit einigen signifikanten Ausnahmen. Erstens, im Mobil-Registrierungszustand 712 werden die Mobil-Registrierungspakete vom PPP_U-Protokoll 615 hoch zum IP-Protokoll 613 gereicht, anstatt zum PPP_R-Protokoll 605. Dies ist unterschiedlich zu der Operation bzw. zum Betrieb der 4 und 5, indem das Lenken der Mobil-Registrierungspakete eine Schicht höher in dem MT2-Protokollstapel auftritt. Zweitens, kein Netzwerk-Spigot wird in dem Ausführungsbeispiel der 6 gebraucht, weil das PPP_U-Protokoll 615 dazu dient, die PPP-Verbindung zwischen dem MT2-Gerät 104 und der IWF 108 zu beenden. Als Ergebnis haben all die PPP-Pakete, die während der Aushandelung mit der IWF 108 ausgetauscht werden, ihren Ursprung und ihr Ende beim MT2-Gerät 104 selbst, anstatt dass das MT2-Gerat 104 bei der PPP-Aushandelung zwischen dem TE2-Gerät 102 und der IWF 108 „mithören" (eavesdrop) muss, wie es bezüglich des Ausführungsbeispiels der 4 und 5 der Fall ist.
Wenn die Mobilknotenregistrierung in dem Mobil-Registrierungszustand 712 Erfolg hat, dann wechselt das MT2-Gerat 104 in den Offen-Zustand 714. Der Offen-Zustand 714 ist sehr ähnlich zu dem Offen-Zustand 508 der 5. Ein signifikanter Unterschied zwischen dem Ausführungsbeispiel der 7 und 5 ist, dass in 7 das PPP_R-Protokoll 605 und das PPP_U-Protokoll 615 aktiv bleiben bzw. dableiben, und zwar während des Offen-Zustands 714. Als Ergebnis werden IP-Pakete, die beim MT2-Gerat über das U_m-Interface ankommen, von dem RLP-Protokoll 612 zum PPP_U-Protokoll 615 und wiederum zum PPP_R-Protokoll 605 und dann zum EIA-232-Protokoll 610 gelenkt, anstatt direkt zum EIA-232-Protokoll 610. Auf ähnliche Weise werden alle IP-Pakete, die von dem MT2-Gerät 104 über das R_m-Interface empfangen werden, vom EIA-232-Protokoll 610 zum PPP_R-Protokoll 605 und wiederum zum PPP_U-Protokoll 615 und RLP-Protokoll 612 gelenkt, anstatt direkt zum RLP-Protokoll 612.
Wenn ein Zwischen-IWF-Handoff während des Offen-Zustands 714 auftritt, dann wechselt das MT2-Gerät 104 in den Initiiere-PPP-Resync-Zustand 709. Der Initiiere-PPP-Resync-Zustand 709 operiert auf ähnliche Weise wie der initiiere-PPP-Resync-Zustand 504. Es sei jedoch angemerkt, dass in dem Initiiere-PPP-Resync-Zustand 709 nur die PPP_U-Verbindung neu ausgehandelt wird, anstatt der PPP_R-Verbindung. Als Ergebnis bleibt die PPP_R-Verbindung unverändert, was den Zwischen-IWF-Handoff transparent für das TE2-Gerat 102 macht und deswegen werden keine zwischengespeicherten LCP-Pakete benötigt.
Wenn der Anruf während des Offen-Zustands 714 beendet wird (oder in der Tat, in jedem anderen Zustand der 7), wechselt das MT2-Gerät 104 in den Schließen-Zustand 710. Der Schließen-Zustand 710 ist sehr ähnlich zum Schließen-Zustand 516 der 5. In dem Schließen-Zustand 710 gibt es jedoch keinen Netzwerk-Spigot, der entfernt werden muss. Zusätzlich, abhängig von dem Timing der Anrufbeendigung, können einige PPP-Instanzen übrig bleiben, die Mitten in der Aushandlung sind. Auf jeden Fall schaltet das MT2-Gerät 104 das Mobil-IP-Protokoll 609, das UDP-Protokoll 611, das IP-Protokoll 613, das PPP_R-Protokoll 605 und das PPP_U-Protokoll 615 ab, wenn sie gerade am Laufen sind. Wie in dem Ausführungsbeispiel der 5 kann der Grund für einen Anruffehlschlag optional angezeigt werden.
Somit werden in dem Ausführungsbeispiel der 6 die zusätzlichen Protokollschichten in dem MT2-Gerät 104 (Mobil-IP-Protokoll 609, UDP-Protokoll 611 und IP-Protokoll 613) eingebracht bzw. angeschaltet, nur um Mobilknotenregistrierung im Mobil-Registrierungszustand 712 durchzuführen, und werden abgeschaltet nach dem Verlassen des Mobil-Registrierungszustands 712. Das PPP_R-Protokoll 605 und das PPP_U-Protokoll 615 bleiben jedoch intakt, während des Offen-Zustands 714. Auf diese Weise dient das MT2-Gerät 104 als Proxy für das TE2-Gerät 102 während der Mobilknotenregistrierung, was den Bedarf für das TE2-Gerät 102 vermeidet, seine eigene IP-Mobilitätsunterstützung zu haben.
Die obige Beschreibung sieht ein Beispiel für die Benutzung der IP-Adressenverschiebung vor, um Proxy-Dienste im Namen bzw. im Auftrag eines verknüpften Endgerätes vorzusehen. Es gibt zusätzliche. Anwendungen für das IP-Adressenverschiebungsverfahren der vorliegenden Erfindung außer der Mobil-IP-Registrierung. Das IP-Adressenverschiebungsverfahren der vorliegenden Erfindung kann für jeden Proxy-Dienst benutzt werden oder für jede zwei Netzwerkdienste, die eine einzelne IP-Adresse teilen müssen. Zum Beispiel kann es benutzt werden zwischen einem MT2-Gerat 104 und einem TE2-Gerat 102, wenn das TE2-Gerät 102 in einem aktiven Datendienstanruf ist (z.B. der Benutzer des TE2-Gerätes 102 wählt sich von einer entfernten Position ein, um Emails abzurufen), und das MT2-Gerät 104 eine Anwendung laufen hat, die einen Bedarf hat, IP-Pakete (z.B. eine Webbrowser-Anwendung) zu senden oder zu empfangen.
Ein einzigartiger Aspekt der vorliegenden Erfindung ist, dass sie eine Technik für Proxy-Dienste in einem System vorsieht, wo nur eine einzelne IP-Adresse für die Benutzung von sowohl dem MT2-Gerät 104 als auch dem TE2-Gerät 102 verfügbar ist. Zum Beispiel implizieren sowohl die Netzwerk- als auch Weiterleitungsmodelle von IS-707.5 die Zuweisung einer einzelnen IP-Adresse zu dem TE2-Gerät 102. Keine getrennte Versorgung ist für die Zuweisung einer zweiten IP-Adresse für die exklusive Benutzung des MT2-Gerätes 104 vorgesehen. In der Tat ist es momentan nicht möglich, mehr als eine IP-Adresse pro PPP-Sitzung zu erhalten. Die zusätzlichen Kosten für Ressourcen in der IWF 108, um mehrere PPP pro Mobilsitzungen zu unterstützen, macht es unattraktiv für Dienstprovider.
Die Tatsache, dass nur eine IP-Adresse zu dem TE2-Gerät 102 zugewiesen wird, impliziert ebenso, dass jede andere Anwendung, die auf dem MT2-Gerät 104 läuft, und die eine IP-Adresse benötigt, sei es für Proxy-Dienste oder nicht, irgendwie die IP-Adresse mit dem TE2-Gerät 102 „teilen" muss. Ein Verfahren zum Durchführen dieser IP-Adressenverschiebung ist oben angemerkt und grafisch in dem Flussdiagramm der 8 dargestellt. Das Verfahren der 8 kann von Systemen, die mit Bezug auf die 4 und 6 beschrieben sind, durchgeführt werden.
Der Prozess der 8 beginnt mit der Entscheidung 802, wo bestimmt wird, ob irgendeine Anwendung, die auf dem MT2-Gerät 104 läuft, den Bedarf hat, IP-Pakete hervorzubringen. Zum Beispiel hat die Mobil-IP-Anwendung 409 der 4 oder 609 der 6 einen Bedarf, IP-Pakete hervorzubringen, um ihre Funktionen als ein Proxy für die Mobil-IP-Knotenregistrierung durchzuführen. Ein anderes Beispiel für eine Anwendung, die auf dem MT2-Gerät 104 läuft, und die einen Bedarf haben kann, IP-Pakete hervorzubringen, würde ein Webbrowser sein. Es gibt viele andere Anwendungen, die IP-Paketdienste anwenden, die auf dem MT2-Gerat 104 laufen können, insbesondere, wenn das MT2-Gerät 104 eine Kombination Computer/Telefon (oder „Smartphone") ist.
Das MT2-Gerat 104 blockiert anschließend Ausgabe-IP-Pakete von dem TE2-Gerät 102 im Block 804. Das kann, wie oben beschrieben, durch das MT2-Gerät 104 bewerkstelligt werden, das das TE2-Gerät 102 „flusskontrolliert" (d.h., das TE2-Gerät 102 hindert Daten über das Weiterleitungsschichtinterface zu senden oder zu empfangen). Zum Beispiel, in dem Ausführungsbeispiel der 4, wird die Verbindung zwischen dem EIA-232-Protokoll 408 des TE2-Gerätes und dem EIA-232-Protokoll 410 des MT2-Gerätes durch das MT2-Gerät 104 flusskontrolliert. Dabei kann Software- oder Hardware-Flusskontrolle bzw. -Steuerung benutzt werden. In einem Ausführungsbeispiel schaltet das MT2-Gerät 104 zum Beispiel einen der Spannungsgins zwischen dem MT2-Gerät 104 und dem TE2-Gerät 102 hin und her.
Durch das Flusskontrollieren des TE2-Gerätes 102 kann das MT2-Gerät 104, und insbesondere das IP-Protokoll 413, nun der IP-Endpunkt für die Zwecke des Sendens oder Empfangens von weiteren IP-Paketen werden. Konzeptuell „verschiebt" dies den IP-Endpunkt vom TE2-Gerät 102, wo es andernfalls sein würde, zum MT2-Gerät 104. Somit sendet und empfängt anschließend das MT2-Gerät im Block 806 IP-Pakete unter Verwendung der IP-Adresse, die ursprünglich dem TE2-Gerat 102 zugewiesen wurde.
In diesem ersten Ausführungsbeispiel des IP-Adressenverschiebungsverfahrens der vorliegenden Erfindung werden jegliche IP-Pakete, die für das TE2-Gerät 102 gedacht sind, von dem MT2-Gerät 104 im Block 808 verworfen. Dies kann auftreten einfach dadurch, dass das IP-Paket von jeder Anwendung, die auf dem MT2-Gerät 104 läuft, ignoriert wird.
Ein zweites Ausführungsbeispiel des IP-Adressenverschiebungsverfahrens der vorliegenden Erfindung ist in den 9A bis 9B gezeigt. In diesem zweiten Ausführungsbeispiel wird die IP-Adresse konzeptuell „verschoben", wie zwischen dem MT2-Gerät 104 und dem TE2-Gerat 102 auf einer Paket-für-Paket.-Basis, anstatt des Flusskontrollierens des TE2-Gerätes 102. Das Verfahren der 9A bis 9B kann von den Systemen, die mit Bezug auf die 4 und 6 beschrieben wurden, durchgeführt werden.
Im Block 902 untersucht das MT2-Gerät die Anschlussnummer der eingehenden IP-Pakete. Wie oben angemerkt, wird die Anschlussnummer von einem Transportschichtprotokoll, wie z.B. TCP oder UDP zugewiesen. Somit, obwohl zwei IP-Pakete die gleiche IP-Zieladresse haben können, können sie verschiedene An schlussnummern haben. Wie auf dem Fachgebiet bekannt ist, können unterschiedliche Anwendungen, die auf dem gleichen Gerät laufen oder auf unterschiedlichen Geräten, unterschiedliche Anschlussnummern benutzen. Das Untersuchen der Anschlussnummern des eingehenden IP-Pakets im Block 902 kann das Entrahmen der PPP-Pakete involvieren, um die IP-Pakete direkt zu untersuchen. Zum Beispiel, in dem Netzwerkmodell, das in 6 abgebildet ist, würde das PPP_U-Protokoll 615 das eingehende PPP-Paket von der IWF 108 entrahmen. Das MT2-Gerät 104 würde dann anschließend die Anschlussnummer des IP-Pakets untersuchen. Alternativ kann es nur das Indizieren in das IP-Paket durch eine vordefinierte Anzahl von Bits involvieren. Die Länge der PPP-Header, IP-Header und die Stelle der Anschlussnummer innerhalb des IP-Pakets ist definiert gemäß den verschiedenen Standards.
Bei der Entscheidung 904 bestimmt das MT2-Gerät 104, ob das IP-Paket eine Anschlussnummer beinhaltet, die von einer Anwendung, die auf dem MT2-Gerät 104 läuft, benutzt wird. Wenn zum Beispiel das MT2-Gerät 104 eine Internetbrowseranwendung laufen haben würde, würde die Browseranwendung eine bestimmte Anschlussnummer benutzen, vielleicht den Anschluss 200. Wenn die Anschlussnummer in dem IP-Paket ebenso der Anschluss 200 ist, dann beinhaltet das IP-Paket eine Anschlussnummer, die von der Beispielanwendung, die auf dem MT2-Gerät 104 läuft, benutzt wird. Wenn jedoch die Anschlussnummer in dem IP-Paket anders als 200 ist, dann würde das IP-Paket keine Anschlussnummer haben, die von der Beispielanwendung, die auf dem MT2-Gerät 104 läuft, benutzt wird.
Wenn die Anschlussnummer des IP-Pakets eine ist, die von einer Anwendung auf dem MT2-Gerät 104 benutzt wird, dann geht es weiter im Block 906, wo das MT2-Gerät 104 das IP-Paket zur MT2-Anwendung lenkt. Wenn jedoch die Anschlussnummer des IP-Pakets eine ist, die nicht von einer Anwendung auf dem MT2-Gerät 104 benutzt wird, dann fährt der Fluss fort im Block 908, wo das MT2-Gerät 104 das IP-Paket zum TE2-Gerät lenkt. Dies kann das erneute Rahmen des PPP-Pakets und dessen Sendung über die R_m-Verbindung des TE2-Gerätes 102 involvieren. In diesem Netzwerkmodellausführungsbeispiel, beschrieben in 6, wür de dies von dem PPP_R-Protokoll 605 bewerkstelligt werden. Auf diesem Weg fängt das MT2-Gerät 104 alle IP-Pakete, die für die Anwendungen gedacht sind, die auf dem MT2-Gerät 104 laufen, ab und verarbeitet sie, während immer noch alle anderen IP-Pakete zum TE2-Gerät 102 gereicht werden. Somit wird keines der IP-Pakete von dem MT2-Gerät 104 verworfen und das TE2-Gerät 102 wird nicht flusskontrolliert.
Wenn die Anwendung auf dem MT2-Gerät 104 den Bedarf hat, IP-Pakete, wie bestimmt, in der Entscheidung 910 der 9B hervorzubringen, dann bringt die MT2-Geräteanwendung IP-Pakete unter Verwendung der IP-Adresse hervor, die dem TE2-Gerät 102 im Block 912 zugewiesen wurde. In jedem Fall kehrt der Fluss zurück in den Block 910, wo das MT2-Gerät 104 fortfährt, zu bestimmen, wenn es einen Bedarf gibt, IP-Pakete hervorzubringen. Somit „teilt" das MT2-Gerät 104 die IP-Adresse, die dem TE2-Gerät 102 zugewiesen wurde, auf einer Paket-für-Paket-Basis.
Die vorhergehende Beschreibung der bevorzugten Ausführungsbeispiele ist vorgesehen, um dem Fachmann zu ermöglichen, die vorliegende Erfindung zu produzieren oder zu benutzen.

Claims

Ein Verfahren zum Teilen bzw. gemeinsamen Nutzen einer Internet Protocol- bzw. IP-Adresse zwischen einer Drahtlos-Kommunikationsvorrichtung (104) und einer Terminal- bzw. Endgerätvorrichtung (102), wobei das Verfahren folgende Schritte aufweist: Untersuchen in der Drahtlos-Kommunikationsvorrichtung (104), einer Port- bzw. Anschluss-Nummer eines empfangenen IP-Pakets; Routen bzw. Lenken, in der Drahtlos-Kommunikationsvorrichtung (104), des IP-Pakets zu einer Anwendung auf der Drahtlos-Kommunikationsvorrichtung (104), wenn die Port-Nummer des empfangenen IP-Pakets der Anwendung entspricht; Routen von der Drahtlos-Kommunikationsvorrichtung (104), des IP-Pakets zu der Terminalvorrichtung (102), wenn die Port-Nummer des empfangenen IP-Pakets nicht der Anwendung entspricht.
Verfahren nach Anspruch 1, das weiterhin folgenden Schritt aufweist: Hervorbringen von IP-Paketen von der Drahtlos-Kommunikationsvorrichtung (104), wobei die IP-Pakete als eine Herkunfts- bzw. Ursprungsadresse eine IP-Adresse beinhalten, die der Endgerätvorrichtung (102) zugewiesen ist.
Verfahren gemäß Anspruch 1 oder Anspruch 2, das weiterhin das Verschieben einer Internet-Protokoll- bzw. IP-Adresse zwischen der Drahtlos-Kommunikationsvorrichtung (104) und der Endgerätvorrichtung (102) aufweist, wobei das Verschieben der IP-Adresse folgende Schritte aufweist: Blockieren in der Drahtlos-Kommunikationsvorrichtung (104), von gesendeten IP-Paketen, die von der Endgerätvorrichtung (102) abstammen; und Hervorbringen von IP-Paketen von der Drahtlos-Kommunikationsvorrichtung (104), wobei die IP-Pakete als eine Herkunfts -bzw. Ursprungsadresse eine IP-Adresse zugewiesen zu der Endgerätvorrichtung (102) aufweisen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren weiterhin folgenden Schritt aufweist: Bestimmen in der Drahtlos-Kommunikationsvorrichtung (104), ob eine Anwendung der Drahtlos-Kommunikationsvorrichtung (104) ein Bedarf besitzt IP-Pakete zu senden oder zu empfangen.
Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin folgenden Schritt aufweist: Verwerfen, in der Drahtlos-Kommunikationsvorrichtung (104) von empfangenen IP-Paketen adressiert zu der Endgerätvorrichtung (102).
Eine Drahtlos-Telekommunikationsvorrichtung (104), die Folgendes aufweist: Mittel angepasst zum Untersuchen einer Port- bzw. Anschlussnummer eines empfangenen IP-Pakets; Mittel angepasst zum Routen bzw. Lenken des IP-Pakets an eine Anwendung der Drahtlos-Telekommunikationsvorrichtung (104), wenn die Port-Nummer des empfangenen IP-Pakets der Anwendung entspricht; und Mittel angepasst zum Lenken des IP-Pakets zu einer Endgerätvorrichtung (102), wenn die Port-Nummer des empfangenen IP-Pakets nicht der Anwendung entspricht.
Drahtlos-Telekommunikationsvorrichtung (104) nach Anspruch 6, die weiterhin Folgendes aufweist: Mittel angepasst zum Hervorbringen von IP-Paketen von der Drahtlos-Telekommunikationsvorrichtung (104), wobei die IP-Pakete als eine Herkunfts- bzw. Ursprungsadresse, eine IP-Adresse zugewiesen zu der Endgerätvorrichtung (102) aufweisen.
Eine Drahtlos-Telekommunikationsvorrichtung (104) nach Anspruch 6 oder 7, die weiterhin Folgendes aufweist: Mittel angepasst zum Blockieren von gesendeten IP-Paketen, die in der Endgerätvorrichtung (102) ihren Ursprung haben; Mittel angepasst zum Hervorbringen von IP-Paketen von der Drahtlos-Kommunikationsvorrichtung (104), wobei die IP-Pakete als eine Herkunfts- bzw. Ursprungsadresse eine IP-Adresse zugewiesen zu der Endgerätvorrichtung (102) aufweist.
Drahtlos-Kommunikationsvorrichtung (104) nach einem der Ansprüche 6 bis 8 die weiterhin Folgendes aufweist: Mittel angepasst zum Bestimmen, ob eine Anwendung der Drahtlos-Kommunikationsvorrichtung (104) ein Bedarf zum Hervorbringen von IP-Paketen besitzt.
Drahtlos-Kommunikationsvorrichtung (104) nach einem der Ansprüche 6 bis 9, die weiterhin Folgendes aufweist: Mittel angepasst zum Verwerfen in der Drahtlos-Telekommunikationsvorrichtung (104), von empfangenen IP-Paketen, die an die Endgerätvorrichtung (102) adressiert sind.