[go: up one dir, main page]

DE60312804T2 - Aufbau eines bidirektionalen IP-Tunnels in einem Mobile-IP Kommunikationssystem im Falle eines privaten Adresskonflikts - Google Patents

Aufbau eines bidirektionalen IP-Tunnels in einem Mobile-IP Kommunikationssystem im Falle eines privaten Adresskonflikts Download PDF

Info

Publication number
DE60312804T2
DE60312804T2 DE60312804T DE60312804T DE60312804T2 DE 60312804 T2 DE60312804 T2 DE 60312804T2 DE 60312804 T DE60312804 T DE 60312804T DE 60312804 T DE60312804 T DE 60312804T DE 60312804 T2 DE60312804 T2 DE 60312804T2
Authority
DE
Germany
Prior art keywords
address
mobile node
foreign
network
agent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60312804T
Other languages
English (en)
Other versions
DE60312804D1 (de
Inventor
Mingguey Michael 75025 Plano Yang
Vinod Kumar Ottawa Choyi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Application granted granted Critical
Publication of DE60312804D1 publication Critical patent/DE60312804D1/de
Publication of DE60312804T2 publication Critical patent/DE60312804T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164Adaptation or special uses of UDP protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5084Providing for device mobility
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

  • Die vorliegende Erfindung betrifft allgemein die Kommunikation von Daten mit Paketformatierung in einem Paket-Funkkommunikationssystem. Konkret betrifft die vorliegende Erfindung ein Paket-Funkkommunikationssystem gemäß der Präambel von Anspruch 1 und ein Verfahren zur Kommunikation von Daten mit Paketformatierung gemäß der Präambel von Anspruch 6. Dieses System und Verfahren sind aus dem Dokument EP 1 235 413 A bekannt.
  • HINTERGRUND DER ERFINDUNG
  • Die Kommunikation von Daten ist in der modernen Gesellschaft unverzichtbar. Die Kommunikation von Daten erfolgt über die Verwendung eines Kommunikationssystems. Neue wissenschaftliche Entdeckungen und der technologische Fortschritt ermöglichten die Entwicklung und Implementierung neuer Arten von Kommunikationssystemen. Dieser technische Fortschritt geht kontinuierlich weiter, und ständig werden neue Kommunikationssysteme entwickelt und bestehende verbessert.
  • Fortschritte im Bereich der digitalen Kommunikationstechniken gehören zu den technischen Neuerungen, die die Einführung neuer Arten von Kommunikationssystemen möglich machten, mit denen zahlreiche vielfältige Kommunikationsdienste angeboten werden können.
  • Ein Funkkommunikationssystem ist ein Beispiel für ein Kommunikationssystem, das von den Fortschritten bei den digitalen Kommunikationstechniken wie auch von anderen technologischen Neuerungen profitiert hat. In einem Funkkommunikationssystem sind die Kommunikationskanäle auf der Basis einer Funkverbindung definiert, die zumindest einen Teil eines Kommunikationspfads zwischen den Kommunikationsstationen des Funkkommunikationssystems bildet.
  • Ein Funkkommunikationssystem lässt sich im Allgemeinen kostengünstiger implementieren als ein leitungsgebundenes Gegenstück, da die Kosten für die Infrastruktur bei einem Funkkommunikationssystem im Allgemeinen niedriger liegen als die Kosten für die Installation einer Netzwerkinfrastruktur für ein leitungsgebundenes Kommunikationssystem. Darüber hinaus kann ein Funkkommunikationssystem als Mobilkommunikationssystem implementiert werden, das eine mobile Kommunikation ermöglicht. In einem solchen System ist die Kommunikation von und zwischen Standorten möglich, an denen die Verwendung konventioneller, leitungsgebundener Kommunikationssysteme nicht praktikabel wäre.
  • Die Verwendung digitaler Kommunikationstechniken in einem Kommunikationssystem erlaubt eine verbesserte Effizienz der Kommunikation im Vergleich zur Verwendung konventioneller, analoger Kommunikationssystemstechniken. Bei der Nutzung digitaler Kommunikationstechniken werden die zu übertragenden Daten typischerweise digitalisiert und anschließend formatiert, beispielsweise in Paketform als Datenpakete.
  • Es wurden Protokolle zur paketorientierten Kommunikation entwickelt und standardisiert. Das Internet-Protokoll (IP) ist ein Beispiel eines paketorientierten Kommunikationsstandards, der regelmäßig zur paketorientierten Kommunikation genutzt wird. Zu den Standards des Internet-Protokolls gehören beispielsweise die Versionen IPv4 und IPv6. In diesen Versionen des Internet-Protokolls sind operative Parameter wie auch die logische Konfiguration des IP-Netzwerks definiert.
  • Das IPv4-Protokoll wurde ursprünglich vor allem zur Verwendung in einem leitungsgebundenen Netz, beispielsweise einem Büro-Intranet, oder in Netzwerken mit Verbindung über das Internet entwickelt. Ein logisches Gerät, auch als Knoten bezeichnet, wird durch eine IP-Adresse identifiziert.
  • Wenn es sich bei dem Knoten um ein Gerät handelt, das über eine Leitungsverbindung fest mit anderen Bereichen eines Kommunikationsnetzes verbunden ist, ist dieser Knoten fest in einem Netzwerk oder in einem Teilnetz angeschlossen.
  • Die paketorientierte Kommunikation, einschließlich der über das Internet abgewickelten Kommunikation, erfolgt jedoch zunehmend mit Mobilknoten statt mit fest angeschlossenen Knoten. Die Weiterleitung von Daten an einen Mobilknoten wird problematischer, insbesondere wenn der Mobilknoten von seinem als „Heimatnetz" bezeichneten Netz, mit dem der Mobilknoten normalerweise verbunden ist, in ein als „besuchtes" oder „Fremdnetz" bezeichnetes Teilnetz außerhalb seines Heimatnetzes wechselt („Roaming"). Der Mobilknoten teilt sein Teilnetz-Präfix mit dem Heimatnetz.
  • Darüber hinaus werden Netzwerke wegen der Knappheit von IPv4-Adressen manchmal als private Netze konfiguriert, und ihre Knoten einschließlich der Mobilknoten werden mit privaten Adressen konfiguriert. Das RFC-Dokument 1918 (Request for Comments) der IETF (Internet Engineering Task Force) enthält eine Definition privater Adressen, wobei es sich um nicht registrierte IPv4-Adressen handelt, die von jedem beliebigen Netz verwendet werden können. Eine Netzkonfiguration, die private Adressen verwendet, ist gut geeignet für Netze, die keine umfangreichen externen Verbindungen erfordern, wie beispielsweise das Internet.
  • Ein Knoten oder Host eines privaten Netzes kann nicht direkt mit Knoten oder Anordnungen kommunizieren, die für das private Netz als extern gelten, da es sich bei den ihnen zugeordneten IP-Adressen um private Adressen handelt. Private Adressen können nicht zur Weiterleitung verwendet werden. Knoten mit einer privaten Adresse werden in diesem Zusammenhang gelegentlich auch als private Knoten bezeichnet. Wenn ein privater Knoten mit einem Knoten kommuniziert, der gegenüber dem privaten Netz als externer Knoten gilt, wird die private IP-Adresse des Knotens über ein NAT-Gerät (Network Address Translation, Netz-Adressumsetzung) einer externen Adresse zugeordnet, die von der NAT exklusiv für diesen Zweck reserviert wird.
  • Es werden verschiedene Implementierungen von NAT-Geräten genutzt. Manchmal werden beispielsweise herkömmliche (ausgehende) NAT-Geräte verwendet. Solche Geräte ermöglichen nur eine unidirektionale Kommunikation von aus dem privaten Netz ausgehenden Daten. Eine als Doppel-NAT-Gerät bezeichnete Anordnung setzt sowohl die Ausgangs- als auch die Zieladresse um beim Übergang eines IP-Pakets über die Grenzen des Adressbereichs. Ein NAPT-Gerät (Network Address Port Translation, Umsetzung der Port-Netzadresse) führt außerdem Umsetzungsoperationen durch, bei denen eine Gruppe interner Knoten eine einzige externe Adresse gemeinsam nutzen und über eine Transportprotokollkennung, z. B. TCP (Transport Control Protocol) und UDP-Port-Nummern identifiziert werden kann.
  • Ein bedeutsames Problem tritt auf, wenn ein privater Knoten bei der Kommunikation mit einem anderen Knoten in ein Fremdnetz wechselt oder anderweitig Netzgrenzen überschreitet. Es wurde ein Mobilstandard IPv4 definiert, der mobilen Knoten (MN) die Kommunikation mit anderen Knoten durch Verwendung der IP-Heimatadresse des Mobilknotens ermöglichen soll, auch wenn der Mobilknoten sich außerhalb seines Heimatnetz befindet. Um eine solche Operation zuzulassen, wird ein IP-Paket-Tunneling verwendet. Eine IP-in-IP-Kapselung zwischen einem mobilen IP-Home-Agent (HA) in einem dem mobilen Knoten zugeordneten Heimatnetz und die Care-of-Adresse (CoA) des mobilen Knotens können beispielsweise zum Tunneling der Datenpakete verwendet werden.
  • Das Tunneling kann jedoch fehlschlagen, wenn im Tunneling-Pfad ein NAPT-Gerät positioniert ist. Das verwendete Tunneling-Verfahren, z. B. IP-in-IP-Kapselung, enthält im Allgemeinen nicht genug Informationen, um dem NAPT-Gerät eine eindeutige Adressumsetzung zu ermöglichen.
  • Darüber hinaus kann ein Konflikt mit privaten Adressen vorliegen. Das bedeutet, mehrere Knoten können dieselbe private IP-Adresse haben. Wenn ein privater Mobilknoten in ein Fremdnetz wechselt und seine IP-Heimatadresse einen Konflikt mit der Adresse eines Fest- oder Mobilknotens in dem Fremdnetz oder mit einem oder mehreren anderen Besucherknoten aufweist, ergibt sich daraus ein Adresskonflikt. Wenn ein Adresskonflikt auftritt, kann der Mobile IP-Foreign-Agent des Fremdnetzes eingehende Datenpakete nicht an den entsprechenden Empfangsknoten weiterleiten. Darüber hinaus kann der Foreign-Agent von den am Konflikt beteiligten Mobilknoten ausgehende Pakete nicht korrekt an den jeweiligen Home-Agent des Mobilknotens weiterleiten.
  • Zur Überwindung dieses Problems wurden verschiedene Vorschläge unterbreitet. So wurde beispielsweise im Dokument RFC 3024 der IETF ein Reverse-Tunneling-Verfahren (RT) vorgeschlagen. Auch eine Erweiterung der privaten Adresse für Mobile-IP (MIP TUP) wurde vorgeschlagen. Und auch ein Mobile-IP NAT/NAPT-Geräteübergang durch UDP-Tunneling (MIP UDP) wurde vorgeschlagen.
  • Jede der vorgeschlagenen Lösungen ist in einer bestimmten Hinsicht ungeeignet. Das Reverse-Tunneling-Verfahren (RT) steht beispielsweise nur zur Verwendung beim NAT-Geräteübergang in Umkehrrichtung zur Verfügung. Bei Vorliegen eines NAPT-Geräts enthält das vom Reverse-Tunneling-Verfahren verwendete Kapselungsverfahren nicht die Nummer des Ausgangs-Ports des Mobilknotens, die vom NAPT-Gerät zur eindeutigen Adressumsetzung der Care-of-Adresse des Mobilknotens benötigt wird. Außerdem berücksichtigt das Reverse-Tunneling-Verfahren das Problem der Adresskonflikte nicht.
  • Obwohl das MIP TUP-Verfahren den NAT-Geräteübergang ermöglicht und auch eine Lösung zum Problem des Adresskonflikts bietet, unterstützt dieses Verfahren keinen NAT-Geräteübergang. Außerdem bietet das MIP TUP-Verfahren einen verschachtelten zweistufigen Tunnel vom Home-Agent zum Foreign-Agent, was eine Komponente mit hohem Overhead zur Weiterleitung von Datenpaketen an den Mobilknoten erfordert.
  • Das MIP UDP-Tunnelverfahren ermöglicht den NAT-Geräte- wie auch den NAPT-Geräteübergang, und es vermeidet das Problem der Adresskonflikte. Dieses Verfahren funktioniert jedoch nur für Mobilknoten mit Co-Located Care-of-Adresse. Außerdem müssen dafür die Mobilknoten einschließlich öffentlicher Mobilknoten so lange ein UDP-Tunneling verwenden, wie die Mobilknoten „hinter" dem NAT-Gerät bzw. dem NAPT-Gerät kommunizieren. Wenn im Fremdnetz ein Foreign-Agent mit einer öffentlichen Adresse konfiguriert ist, können die öffentlichen Mobilknoten eine reguläre Mobile-IP-Weiterleitung und ein Reverse-Tunneling des Datenverkehrs verwenden und somit den für das UDP-Tunneling erforderlichen Overhead vermeiden.
  • Wenn also ein Verfahren zur besseren Weiterleitung von Datenpaketen in einem paketorientierten Funkkommunikationssystem bereitgestellt werden könnte, das die Mobilität von Mobilknoten ermöglicht, so wäre damit eine verbesserte Kommunikation möglich.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die Erfindung löst dieses Problem durch ein System gemäß Anspruch 1 und durch ein Verfahren gemäß Anspruch 6.
  • Die Erfindung ermöglicht eine bidirektionale Kommunikation der Daten mit einem in einem Fremdnetz positionierten Mobilknoten, der von einem Mobile IPv4 Foreign-Agent bedient und über eine Care-of-Adresse identifiziert wird. Es wird ein Verfahren bereitgestellt, über das zwei separate Datenkanäle gebildet werden zur bidirektionalen Datenkommunikation mit dem Mobilknoten. NAT/NAPT-Geräteübergang (Network Address Translation/Network Address Port Translation) und die Auflösung von Konflikten mit privaten Adressen werden damit ermöglicht.
  • Durch den Betrieb einer Ausführungsform der vorliegenden Erfindung wird eine Möglichkeit zur bidirektionalen Datenkommunikation mit einem Mobilknoten bereitgestellt, der in einem Fremdnetz positioniert ist und der durch die IP-Heimatadresse des Mobilknotens und seine Care-of-Adresse identifiziert wird.
  • Es wird ein Verfahren bereitgestellt, über das zwei separate Datentunnel gebildet werden zur bidirektionalen Datenkommunikation mit dem Mobilknoten. NAT/NAPT-Geräteübergang (Network Address Translation/Network Address Port Translation) und die Auflösung von Konflikten mit privaten Adressen werden damit ermöglicht.
  • In einer Hinsicht der vorliegenden Erfindung wird ein alternatives Daten-Tunneling-Verfahren des Typs MIP UDP bereitgestellt. NAT- und NAPT-Geräteübergang werden ermöglicht für die Kommunikation von Datenpaketen, die mit Mobilknoten kommuniziert werden, die mit Care-of-Adressen von Foreign-Agents arbeiten. Auch Konflikte mit privaten Adressen an den Heimatadressen der Mobilknoten werden vermieden. Es wird ein Protokoll als Ergänzung zu dem vorhandenen MIP UDP-Verfahren bereitgestellt.
  • NAT/NAPT-Geräteübergang und die Vermeidung des Konflikts mit privaten Adressen wird über die selektive Verwendung zweier separater Tunnels erzielt, über die Datenpakete in der Ziel- und der Umkehrrichtung kommuniziert werden. Ein UPA-Tunnel (Unique Private Address, eindeutige private Adresse) wird zwischen dem Mobilknoten und dem Foreign-Agent nur gebildet, wenn ein Adresskonflikt mit der Heimatadresse des Mobilknotens, bei der es sich um eine private Adresse handelt, vorliegt. Der UPA-Tunnel ist ein eindeutiger Tunnel zwischen dem Foreign-Agent und dem durch seine UPA identifizierten Mobilknoten. Darüber hinaus arbeitet der UPA-Tunnel insofern in ähnlicher Weise wie eine temporäre eindeutige private Adresse (UPA), die gemäß einem vorhandenen MIP TUP-Verfahren definiert wurde, als ein an einem Adresskonflikt beteiligter Mobilknoten von einem Foreign-Agent angewiesen wird, eine eindeutige private Adresse (UPA) für das Tunneling von Datenpaketen zwischen dem Mobilknoten und dem Foreign-Agent zu verwenden. Die eindeutige private Adresse wird dem Mobilknoten beispielsweise vom Foreign-Agent zugeordnet. Die eindeutige private Adresse kann beispielsweise auch vom Mobilknoten von einem DHCP-Server abgerufen werden, der dem Fremdnetz zugeordnet ist, in dem der Mobilknoten liegt. Und zwischen dem Foreign-Agent und dem Home-Agent des Heimatnetzes des Mobilknotens wird ein UDP/MIP-Tunnel analog zu dem im derzeitigen MIP UDP-Verfahren beschriebenen nur dann verwendet, wenn der Foreign-Agent hinter einem NAT/NAPT-Gerät positioniert ist, d. h. wenn es sich bei der Care-of-Adresse des Foreign-Agent um eine private Adresse handelt.
  • Das UPA-Tunneling wird verwendet, um Konflikte mit privaten Adressen zu überwinden. Und das UDP/MIP-Tunneling wird verwendet, um einen NAT/NAPT-Geräteübergang zu ermöglichen. Wenn kein Adresskonflikt hinsichtlich der Heimatadresse des Mobilknotens vorliegt, ist daher kein UPA-Tunneling zwischen dem Mobilknoten und dem Foreign-Agent erforderlich. Und, wenn der Foreign-Agent eine öffentliche Adresse hat, die als Care-of-Adresse des Mobilknotens verwendet werden kann, ist kein UDP/MIP-Tunneling erforderlich. Ein MIP UPA-Protokoll wird dadurch bereitgestellt.
  • Das MIP UPA-Protokoll mit einem Reverse-Tunneling-Verfahren ermöglicht insofern die Kommunikation, als das neue MIP UPA-Protokoll durch Verwendung des UDP/MIP-Tunneling den NAT- und NAPT-Übergang in Ziel- und Umkehrrichtung ermöglicht. Im Gegensatz dazu ermöglicht das RT-Verfahren einen umgekehrten NAT-Übergang nur durch die Verwendung eines Tunnels zwischen dem Foreign-Agent und dem Home-Agent. Und das MIP UPA-Protokoll einer Ausführungsform der vorliegenden Erfindung vermeidet Konflikte mit privaten Adressen durch die Verwendung eines UPA-Tunnels zwischen dem Mobilknoten und dem Foreign-Agent. Das Reverse-Tunneling-Verfahren bietet keine Auflösung von Konflikten mit privaten Adressen.
  • Das MIP UPA-Protokoll einer Ausführungsform der vorliegenden Erfindung unterscheidet sich vom MIP TUP-Verfahren auch dadurch, dass das MIP TUP-Verfahren einen NAT-Übergang nur über die Verwendung eines zweistufigen verschachtelten Tunnels zwischen dem Home-Agent und dem Foreign-Agent ermöglicht zur Weiterleitung von paketorientiertem Datenverkehr in Zielrichtung und über den ersten Tunnel vom Foreign-Agent zum Home-Agent als dem Tunnel des Reverse-Tunnel-Verfahrens für den Datenverkehr in umgekehrter Richtung. Im Gegensatz dazu ermöglicht das MIP UPA-Protokoll einen NAT- und NAPT-Geräteübergang durch die Verwendung des UDP/MIP-Tunneling in Ziel- und Umkehrrichtung zwischen dem Home-Agent und dem Foreign-Agent.
  • Die Unterschiede zwischen dem MIP UPA-Protokoll und dem MIP UDP-Protokoll sind nachfolgend beschrieben. Das MIP UPA-Protokoll ermöglicht einen NAT- wie auch einen NAPT-Geräteübergang. UDP/MIP-Tunneling wird in Ziel- und Umkehrrichtung zwischen dem Home- und dem Foreign-Agent verwendet. Das MIP UDP-Protokoll ermöglicht außerdem den NAT- und NAPT-Geräteübergang durch Verwendung des UDP/MIP-Tunneling in Ziel- wie auch in Umkehrrichtung des Datenverkehrs zwischen dem Home-Agent und der Co-Located Care-of-Adresse des Mobilknotens. Das bedeutet, der Foreign-Agent ist an der Datenzustellung nicht beteiligt, wenn das MIP UDP-Protokoll verwendet wird. Das MIP UPA-Protokoll berücksichtigt das Problem der Konflikte mit privaten Adressen durch die Verwendung des UPA-Tunnels zwischen dem Mobilknoten und dem Foreign-Agent. Im Gegensatz dazu berücksichtigt das MIP UDP-Protokoll die Konflikte mit privaten Adressen, indem es von jedem Mobilknoten, der hinter dem NAT/NAPT-Gerät das Netz wechselt, das Abfragen und Arbeiten mit einer Co-Located Care-of-Adresse fordert, bei der es sich um eine eindeutige private Adresse innerhalb des Fremdnetzes handeln muss, selbst wenn kein Adresskonflikt vorliegt.
  • Im Hinblick auf diesen und andere Punkte werden daher ein Gerät und das zugehörige Verfahren für ein Paket-Funkkommunikationssystem bereitgestellt. Das Paket-Funkkommunikationssystem hat ein mobiles Netzwerk mit einem Mobilknoten, der in einem Heimatnetzwerk betrieben und in ein Fremdnetz wechseln kann. Das Heimatnetz umfasst einen entsprechend zugeordneten Home-Agent, und das Fremdnetz umfasst einen entsprechend zugeordneten Foreign-Agent. Der Mobilknoten kann wahlweise über eine nicht-universelle Kennungsadresse identifiziert werden. Eine bidirektionale Weiterleitung von Daten mit dem Mobilknoten wird ermöglicht, wenn sich der Mobilknoten im Fremdnetz befindet. Im Fremdnetz befindet sich ein Ermittler. Dieser Ermittler ermittelt, ob der Mobilknoten durch die nicht-universelle Kennungsadresse identifiziert ist. Ein Nachrichtengenerator kann als Reaktion auf die vom Ermittler erhaltenen Informationen darüber, ob der Mobilknoten durch die nicht-universelle Kennungsadresse identifiziert ist, verwendet werden. Der Nachrichtengenerator erzeugt eine Nachricht zur Kommunikation an den Mobilknoten. Die Nachricht weist zumindest den Mobilknoten darauf hin, dass er eine eindeutige private Adresse abrufen soll, falls ein Adresskonflikt vorliegt. Die eindeutige private Adresse wird zur Bildung eines ersten Datentunnels zwischen dem Mobilknoten und dem Foreign-Agent verwendet.
  • Ein vollständigeres Verständnis der vorliegenden Erfindung und ihres Umfangs lässt sich aus den nachfolgend kurz zusammengefassten beigefügten Zeichnungen, den nachfolgenden ausführlichen Beschreibungen der derzeit bevorzugten Ausführungsformen der Erfindung und den angehängten Patentansprüchen erzielen.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 zeigt ein Funktionsblockdiagramm eines Kommunikationssystems, in dem eine Ausführungsform der vorliegenden Erfindung betrieben werden kann.
  • 2 zeigt ein exemplarisches Nachrichtenformat einer Nachricht zur Erweiterung einer eindeutigen privaten Adresse, die während des Betriebs einer Ausführungsform der vorliegenden Erfindung wahlweise erzeugt werden kann.
  • 3 zeigt ein Flussdiagramm zur Darstellung des Betriebs einer Ausführungsform der vorliegenden Erfindung.
  • 4 zeigt ein Flussdiagramm ähnlich dem in 3, jedoch zu einem anderen exemplarischen Betrieb einer Ausführungsform der vorliegenden Erfindung.
  • 5 zeigt ein Diagramm einer Nachrichtenfolge zur Darstellung der erzeugten Signalfolge und die Datenübertragung beim Betrieb des in 1 dargestellten Kommunikationssystems gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 6a und 6b zeigen Diagramme zur Darstellung des Nachrichtenverlaufs für die beim Betrieb des in 1 dargestellten Kommunikationssystems erzeugten Mobile-IP-Signalfolge, wobei hier die verschiedenen Schichten der Nachrichten dargestellt sind.
  • 7a und 7b zeigen Diagramme zur Darstellung der Datenübertragung beim Betrieb einer Ausführungsform der vorliegenden Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Mit Bezug auf 1 ermöglicht ein allgemein an 10 dargestelltes Kommunikationssystem die Funkkommunikation mit Mobilknoten, von denen der Mobilknoten 12 repräsentativ dargestellt ist. Die Mobilknoten bilden Knoten eines Kommunikationsnetzes, hier eines Funknetzes, in dem Daten zwischen dem Mobilknoten und einer weiteren entsprechenden Einheit 25 über Kommunikationspfade, die Funkverbindungen wie die Funkverbindung 14 umfassen, kommuniziert werden. Als Paket formatierte Daten werden mit den Mobilknoten über eine Funkverbindung kommuniziert. In der exemplarischen Implementierung bildet das Kommunikationssystem ein IP-Kommunikationssystem (Internet Protocol), das gemäß dem IPv4-Protokoll betrieben werden kann.
  • Auch wenn die folgende Beschreibung im Hinblick auf die exemplarische Implementierung erfolgt, in der das Kommunikationssystem ein mobiles IP-Kommunikationssystem bildet, sollte klar sein, dass das Prinzip der vorliegenden Erfindung analog auch in zahlreichen anderen Arten paketorientierter Kommunikationssysteme implementiert werden kann. Das Kommunikationssystem und die Elemente, aus denen es gebildet wird, sind zwar hier funktional dargestellt, diese hier gezeigten Funktionselemente zur Bildung des Kommunikationssystems können jedoch in jeder beliebigen Weise und nicht nur in der hier dargestellten Weise implementiert werden.
  • Hier umfasst das Kommunikationssystem einen Netzwerkteil, der hier von einem Heimatnetz 18 gebildet wird, das ein dem Mobilknoten zugeordnetes Heimatnetz bildet. Eine funktionale Einheit, die hier als Home-Agent 22 bezeichnet wird, ist dem Heimatnetz zugeordnet. Der Home-Agent führt verschiedene Support-Funktionen durch, um die Kommunikation mit Mobilknoten zu ermöglichen, die dem Heimatnetz 18 zugeordnet sind. Das Heimatnetz ist einem Kern- oder einem anderen paketorientierten Netzwerk zugeordnet, hier dem Internet 24. Ein entsprechender Knoten (Corresponding Node, CN) 25, mit dem der Mobilknoten 12 Daten austauscht, ist ebenfalls in der Figur dargestellt.
  • Außerdem zeigt der Netzwerkteil des Kommunikationssystems hier ein Fremdnetz 26, in das der Mobilknoten mit der durch den Pfeil 28 gezeigten Bewegung vom Heimatnetz wechselt, um anschließend über das Fremdnetz kommunizieren zu können. Ein Foreign-Agent 32 ist dem Fremdnetz zugeordnet. Analog zum Home-Agent 22 bietet der Foreign-Agent verschiedene Support-Funktionen für die Kommunikation im oder durch das Fremdnetz. Ein dem Fremdnetz zugeordneter DHCP-Server 34 ist ebenfalls in der Figur dargestellt.
  • Wie zuvor erwähnt, wird die Weiterleitung von Paketdaten zum und vom Mobilknoten problematisch, wenn der Mobilknoten mit einer privaten Adresse identifiziert wird und er aus seinem Heimatnetz heraus in ein Fremdnetz wechselt. Die vorliegende Erfindung bietet eine Möglichkeit zur Weiterleitung von Paketdaten zum und vom über seine private Heimatadresse adressierten Mobilknoten, wenn der Mobilknoten dem Fremdnetz, hier dem Fremdnetz 26, zugeordnet ist. Hier umfasst der Foreign-Agent das Gerät 38 einer Ausführungsform der vorliegenden Erfindung. Das Gerät umfasst Funktionselemente, die in beliebiger Weise implementiert werden können. Die Funktionselemente werden beispielsweise als Algorithmen implementiert, die von Verarbeitungsschaltungen ausgeführt werden können. In der Darstellung hier wird das Gerät 38 so gezeigt, dass es aus dem Ermittler 42 und einem Nachrichtengenerator 44 gebildet wird.
  • Beim Betrieb einer Ausführungsform der vorliegenden Erfindung werden separate Tunnel, hier ein Datentunnel 48, zwischen dem Home-Agent 22 und dem Foreign-Agent 32 gebildet, und ein Datentunnel 52 wird zwischen dem Mobilknoten 12 und dem Foreign-Agent 32 gebildet, wenn der Mobilknoten 12 in das Fremdnetz wechselt. Durch die Bildung des Datentunnels 52 können die Paketdaten zum und vom Mobilknoten weitergeleitet werden, wenn ein Adresskonflikt zwischen dem Mobilknoten und einer anderen dem Fremdnetz zugeordneten Anordnung vorliegt. Durch die Bildung des Datentunnels 48 können die Paketdaten zum und vom Mobilknoten weitergeleitet werden, wenn der Foreign-Agent hinter einem NAT-Gerät oder einem NAPT-Gerät positioniert ist.
  • Wenn der Mobilknoten 12 aus seinem Heimatnetz 18 heraus in das Fremdnetz wechselt, erkennt der Mobilknoten den Foreign-Agent 32. Und der Mobilknoten fordert Mobile-IPv4-Support vom Home-Agent 22 an, indem er über den Foreign-Agent eine Registrierungsnachricht an den Home-Agent sendet. Nach dem Empfang einer Mobile-IPv4-Nachricht zur Registrierungsanforderung (RRQ) vom Mobilknoten ermittelt der Foreign-Agent 32 zunächst, ob es sich bei der Heimat-IP-Adresse des Mobilknotens um eine private Adresse handelt. Wenn die Heimatadresse des Mobilknotens eine öffentliche Adresse ist, fährt der Foreign-Agent mit der Weiterleitung der Registrierungsanforderung an den Home-Agent fort. Handelt es sich bei der Heimat-IP-Adresse des Mobilknotens jedoch um eine private Adresse, prüft der Foreign-Agent, ob ein Konflikt zwischen der privaten Heimatadresse des Mobilknotens und anderen Fest- oder Mobilknoten im Fremdnetz vorliegt. Eine solche Ermittlung wird hier als vom Ermittler 42 durchgeführt dargestellt.
  • Liegt ein Adresskonflikt vor, ermittelt der Foreign-Agent, ob der Mobilknoten eine UPA als seine neue Identität hat, um den Adresskonflikt aufzulösen. Der Foreign-Agent führt seine Ermittlung durch, indem er ermittelt, ob die Ausgangsadresse des RRQ die UPA des Mobilknotens ist und ob die UPA mit der UPA in einer an die RRQ angehängte UPA-Erweiterung identisch ist. Ist dies der Fall, fährt der Foreign-Agent mit der Weiterleitung der Registrierungsanforderung an den Home-Agent 22 fort. Hat der Mobilknoten jedoch keine UPA, weist der Foreign-Agent die Registrierungsanforderung zurück, indem er eine Antwort an den Mobilknoten schickt mit einem Ablehnungscode, der auf das Auftreten des Adresskonflikts hinweist. Die Antwort wird hier als vom Nachrichtengenerator 44 generiert dargestellt. Die Nachricht umfasst eine Erweiterung, die als UPA-Erweiterung (Unique Private Address, eindeutige private Adresse) bezeichnet wird und die an die Antwort angehängt ist. Die UPA-Erweiterung umfasst beispielsweise die dem Mobilknoten zugeordnete UPA, sofern der Foreign-Agent ein Set aus privaten Adressen (UPAs) reservieren kann und eine UPA aus dem Set zuordnen kann, die noch nicht bereits einem anderen Mobilknoten zugeordnet wurde. Oder der Foreign-Agent kann eine UPA vom DHCP-Server 34 abrufen, die anschließend dem Mobilknoten bereitgestellt wird. Wenn der Foreign-Agent kein Set der UPAs reservieren kann oder wenn keine verfügbare UPA innerhalb der reservierten UPAs zur Verfügung steht, oder wenn der Foreign-Agent keine UPA vom DHCP-Server abrufen kann, enthält die UPA-Erweiterung die UPA nicht. Wird die UPA bereitgestellt, muss der Mobilknoten die zugeordnete UPA verwenden. Andernfalls muss der Mobilknoten eine eindeutige private IP-Adresse vom DHCP-Server des Fremdnetzes als UPA des Mobilknotens abrufen. Die UPA-Erweiterung informiert den Mobilknoten auch darüber, welche Kapselungsverfahren der Foreign-Agent für das UPA-Tunneling unterstützt.
  • 2 zeigt eine exemplarische Nachricht, allgemein an 56 dargestellt, die vom Nachrichtengenerator 44 als Antwort auf eine Registrierungsanforderung gebildet wird. Die Nachricht umfasst ein Typenfeld 58, ein Längenfeld 62, ein reserviertes Feld 64, ein Kapselungsfeld 66 und ein Feld 68 für die eindeutige private Adresse. Der Wert des Typenfeldes kann zugeordnet werden. Das Längenfeld gibt die Länge der Erweiterung in Byte an, z. B. ausschließlich der Bytes für den Typ und die Länge. Das reservierte Feld ist reserviert und bis auf Weiteres auf 0 eingestellt, z. B. beim Senden, und es wird beim Empfang ignoriert. Das Kapselungsfeld gibt den Typ der Tunneldaten an mit der gleichen Nummerierung wie das IP-Kopf-Protokollfeld. Das Feld wird vom Foreign-Agent auf 0 eingestellt, wenn keine eindeutige private Adresse verfügbar ist. Und das Feld für die eindeutige private Adresse gibt die vom Mobilknoten zu verwendende eindeutige private Adresse beim Empfangen oder Senden der Erweiterung an. Der Foreign-Agent setzt die Werte der Felder auf 0, wenn keine eindeutige private Adresse verfügbar ist. Als Antwort darauf muss der Mobilknoten eine UPA vom DHCP-Server 34 abrufen.
  • Wenn der Mobilknoten die Antwort empfängt mit der Ablehnung der Registrierungsanforderung, prüft der Mobilknoten die UPA-Erweiterung 68, um festzustellen, ob der Mobilknoten einer UPA zugeordnet wurde. Wurde keine UPA zugeordnet, ruft der Mobilknoten eine UPA vom DHCP-Server 34 des Fremdnetzes ab und ordnet die UPA einer seiner Schnittstellen zu. Anschließend sendet der Mobilknoten die Registrierungsanforderung erneut mit einer UPA-Erweiterung an den Foreign-Agent. Die angehängte UPA-Erweiterung zeigt an, dass der Mobilknoten die UPA für das UPA-Tunneling 52 verwenden wird, sowie das für das Tunneling zu verwendenden Kapselungsverfahren, z. B. IP-in-IP-Kapselung. Wenn das Kapselungsverfahren nicht angegeben ist, d. h. wenn das Kapselungsfeld 66 den Wert 0 hat, wird in der exemplarischen Implementierung die IP-in-IP-Kapselung als Standardwert für das Kapselungsverfahren verwendet.
  • Liegt kein Adresskonflikt mit der Heimatadresse des Mobilknotens vor, weil die Heimatadresse beispielsweise eine öffentliche Adresse ist oder weil keine weiteren privaten Knoten mit der gleichen Adresse konfiguriert sind, oder weil der Mobilknoten bereits eine UPA hat, fährt der Foreign-Agent mit der Weiterleitung der Registrierungsanforderung an den Home-Agent fort. Wenn die MIP RRQ eine UPA-Erweiterung enthält, bindet der Foreign-Agent den Mobilknoten an die UPA des Mobilknotens, baut einen Tunnel zwischen sich und der UPA des Mobilknotens auf und entfernt die UPA-Erweiterung vor der Weiterleitung der Registrierungsanforderung an den Home-Agent.
  • Anschließend muss sich der Foreign-Agent um einen NAT/NAPT-Geräteübergang kümmern. In einer Art der Berücksichtigung des Übergangs ermittelt der Foreign-Agent zunächst, ob das NAT/NAPT-Gerät zwischen dem Foreign-Agent und dem Home-Agent vorhanden ist. Wenn es sich bei der Care-of-Adresse des Mobilknotens um eine öffentliche Adresse handelt, wird die Adresse vom NAT/NAPT-Gerät nicht umgesetzt. Somit braucht kein UDP/MIP-Tunneling 48 für den NAT/NAPT-Geräteübergang bereitgestellt zu werden. Bei diesem Szenario leitet der Foreign-Agent die Registrierungsanforderung ohne die Erweiterung zur UDP-Tunnelanforderung an den Home-Agent weiter, wie im MIP UDP-Verfahren beschrieben. Andernfalls leitet der Foreign-Agent die RRQ mit der Erweiterung zur UDP-Tunnelanforderung an den Home-Agent weiter. Dies gibt an, dass der Foreign-Agent das UDP-Tunneling verarbeiten kann, und es gibt außerdem an, welches Kapselungsverfahren verwendet werden soll.
  • Als alternative Vorgehensweise erlaubt es der Foreign-Agent dem Home-Agent zu ermitteln, ob das NAT/NAPT-Gerät dazwischen vorhanden ist. Der Foreign-Agent leitet die Registrierungsanforderung zusammen mit der Erweiterung zur UDP-Tunnelanforderung an den Home-Agent weiter. Beim Empfang der Registrierungsanforderung mit einer Erweiterung zur UDP-Tunnelanforderung entscheidet der Home-Agent, ob das UDP-Tunneling erforderlich ist, beispielsweise anhand einer Nichtübereinstimmung zwischen der Ausgangs-IP-Adresse der Registrierungsanforderung und der Care-of-Adresse des in der Registrierungsanforderung angegebenen Mobilknotens, wie im MIP UDP-Verfahren beschrieben.
  • 3 zeigt ein Kontrolldiagramm, allgemein an 72 dargestellt, als Muster eines Verfahrens, über das der Foreign-Agent eine vom Mobilknoten gesendete Registrierungsanforderung wahlweise verarbeitet. Die Mobile-IPv4-Registrierungsanforderungsnachricht wird empfangen, was durch den Block 74 vom Foreign-Agent angegeben wird. Anschließend wird ermittelt, wie im Entscheidungsblock 76 gezeigt, ob es sich bei der Heimat-IP-Adresse des Mobilknotens um eine private Adresse handelt. Ist dies der Fall, wird der Ja-Zweig zum Entscheidungsblock 78 gewählt, wo ermittelt wird, ob ein Adresskonflikt vorliegt. Ist dies der Fall, wird von hier aus der Ja-Zweig zum Entscheidungsblock 82 gewählt, wo ermittelt wird, ob der Mobilknoten eine UPA hat. Ist dies der Fall, wird von hier aus der Ja-Zweig zum Entscheidungsblock 84 gewählt. Andernfalls wird der Nein-Zweig zum Block 86 gewählt, die Registrierungsanforderung wird zurückgewiesen, und es wird eine UPA-Erweiterung an die somit generierte Nachricht vom Foreign-Agent an den Home-Agent angehängt.
  • Im Entscheidungsblock 84 wird ermittelt, ob es sich bei der Care-of-Adresse um eine öffentliche Adresse handelt. Ist dies der Fall, wird der Ja-Zweig zum Entscheidungsblock 88 gewählt, und die Registrierungsanforderung wird ohne Erweiterung zur UDP-Tunnelanforderung an den Home-Agent weitergeleitet. Andernfalls wird der Nein-Zweig zum Block 92 gewählt, und die Registrierungsanforderung wird vom Foreign-Agent mit einer Erweiterung zur UDP-Tunnelanforderung an den Home-Agent weitergeleitet. Der Nein-Zweig vom Entscheidungsblock 76 und 78 führt zum Entscheidungsblock 84.
  • 4 zeigt ein Flussdiagramm, allgemein an 102 dargestellt, als Muster einer alternativen Vorgehensweise des Foreign-Agent. Auch hier wird nach dem Empfang der Registrierungsanforderung, dargestellt im Block 104, im Entscheidungsblock 106 wiederum ermittelt, ob der Mobilknoten eine UPA hat. Ist dies nicht der Fall, wird von hier aus der Nein-Zweig zum Entscheidungsblock 108 gewählt, wo ermittelt wird, ob es sich bei der Heimat-IP-Adresse des Mobilknotens um eine private Adresse handelt. Ist dies der Fall, wird der Ja-Zweig zum Entscheidungsblock 112 gewählt, wo ermittelt wird, ob ein Adresskonflikt vorliegt. Ist dies nicht der Fall, wird der Nein-Zweig zum Entscheidungsblock 114 gewählt. Andernfalls wird der Ja-Zweig zum Block 116 gewählt, wo die RRQ zurückgewiesen und eine UPA-Erweiterung an die somit generierte Nachricht vom Foreign-Agent an den Home-Agent angehängt wird.
  • Im Entscheidungsblock 114 wird ermittelt, ob es sich bei der Care-of-Adresse um eine öffentliche Adresse handelt. Ist dies der Fall, wird der Ja-Zweig zum Entscheidungsblock 118 gewählt, und die Registrierungsanforderung wird ohne Erweiterung zur UDP-Tunnelanforderung weitergeleitet. Andernfalls wird der Nein-Zweig zum Block 122 gewählt, und die Registrierungsanforderung wird mit einer Erweiterung zur UDP-Tunnelanforderung an die Heimatadresse weitergeleitet. Der Ja-Zweig vom Entscheidungsblock 106 und der Nein-Zweig vom Entscheidungsblock 108 führen ebenfalls zum Entscheidungsblock 114.
  • Wenn der Home-Agent 22 die Registrierungsanforderung (RRQ) zusammen mit einer Erweiterung zur UDP-Tunnelanforderung empfängt, verarbeitet der Home-Agent die Anforderung gemäß der Beschreibung im MIP UDP-Verfahren, um anzugeben, dass der Home-Agent das UDP-Tunneling verwenden soll. Anschließend wird das UDP-Tunneling 48 zwischen dem Home-Agent und dem Foreign- Agent zur Kommunikation von Datenpaketen verwendet. Die IP-in-IP-Kapselung ist das in der exemplarischen Implementierung zu verwendende Standard-Kapselungsverfahren, falls in der Erweiterung zur UDP-Tunnelanforderung und der Antworterweiterung nichts anderes angegeben ist.
  • 5 zeigt ein Diagramm der Nachrichtenfolge, allgemein an 132 dargestellt, als Muster einer Basis-Nachrichtenfolge zwischen dem Mobilknoten 12, dem Foreign-Agent 32, dem Home-Agent 22 und einem entsprechenden Knoten 25.
  • Die Segmente 134, 136, 138, 142, 144 und 146 sind Muster einer Signalfolge, die während der Mobile-IP-Registrierung (MIP) erzeugt wird. Die Segmente 148, 152 und 154 sind Muster des MIP-Datenverkehrs in Umkehrrichtung. Die Segmente 156, 158 und 162 sind Muster des MIP-Datenverkehrs in Zielrichtung. Das Segment 164 ist ein Muster für das Erzeugen von UDP-Keepalive-Paketen, die regelmäßig vom Foreign-Agent an den Home-Agent gesendet werden.
  • Bei den Nachrichtensegmenten 148 und 162 handelt es sich hier um Muster zur Darstellung von UPA-getunnelten Paketen. Das UPA-Tunneling zwischen dem Mobilknoten und dem Foreign-Agent, wie oben beschrieben, ist nur erforderlich und wird nur verwendet, wenn die Heimat-IP-Adresse des Mobilknotens einen Konflikt mit einem anderen Knoten aufweist. Die Segmente 152 und 158 sind Muster für die Kommunikation von UDP/MIP-getunnelten Paketen. Ebenso ist, wie oben beschrieben, das UDP/MIP-Tunneling 48 zwischen dem Foreign-Agent und dem Home-Agent nur erforderlich und wird nur verwendet, wenn der Foreign-Agent den Mobilknoten keine öffentliche Adresse als Care-of-Adresse zur Verfügung stellen kann. Das bedeutet, wenn der Foreign-Agent hinter einem NAT/NAPT-Gerät liegt und die Care-of-Adresse des Foreign-Agent eine private Adresse ist, wird ein UDP/MIP-Tunneling bereitgestellt. Die gemäß der Darstellung der Segmente 164 kommunizierten UDP-Keepalive-Pakete werden zur Aufrechterhaltung des MIP UDP-Tunnels in ausgewählten Intervallen vom Foreign-Agent an den Home-Agent gesendet in einer Weise, die im MIP UDP-Verfahren beschrieben ist.
  • Das UDP-Tunneling wird durch die Verwendung von IP-in-IP- oder anderen Kapselungsverfahren zwischen dem Mobilknoten und dem Foreign-Agent implementiert. Anschließend hat das vom Mobilknoten zum Foreign-Agent UPA-getunnelte Datenpaket den folgenden Aufbau: IP-Felder (Kapselungs-Kopfdaten): Die Ausgangsadresse ist auf die UPA des Mobilknotens eingestellt, die Zieladresse ist auf die Adresse des Foreign-Agent eingestellt, und das Protokollfeld hat den Wert 4 (IP-in-IP-Kapselung). Die IP-Felder der Original-Kopfdaten (der inneren Kopfdaten) lauten wie folgt: Die Ausgangsadresse ist die Heimatadresse des Mobilknotens, und die Zieladresse ist die Adresse des entsprechenden Knotens.
  • Das über den UPA-Tunnel 52 vom Foreign-Agent an den Mobilknoten getunnelte Datenpaket ist wie folgt aufgebaut: IP-Felder (Kapselungs-Kopfdaten): Die Ausgangsadresse ist auf die Adresse des Foreign-Agent eingestellt, die Zieladresse ist auf die UPA des Mobilknotens eingestellt, und das Protokollfeld hat den Wert 4 (IP-in-IP-Kapselung). Die IP-Felder der Original-Kopfdaten (der inneren Kopfdaten) lauten wie folgt: Die Ausgangsadresse ist die Adresse des entsprechenden Knotens, und die Zieladresse ist die Heimatadresse des Mobilknotens.
  • Wenn kein UPA-Tunneling erforderlich ist, d. h. wenn kein Adresskonflikt vorliegt, wird der Datenverkehr zwischen dem Mobilknoten und dem Foreign-Agent in konventioneller Weise durchgeführt. Das bedeutet, der Datenverkehr in Zielrichtung vom Foreign-Agent zum Mobilknoten wird wie im Mobile-IPv4-Protokoll beschrieben behandelt gemäß der Beschreibung in RFC 3220, und der Datenverkehr in umgekehrter Richtung vom Mobilknoten zum Foreign-Agent wird mit einem Reverse-Tunneling-Protokoll verarbeitet gemäß der Beschreibung in RFC 3024.
  • Wenn das UDP/MIP-Tunneling zwischen dem Foreign-Agent und dem Home-Agent über das IP-in-IP-Kapselungsverfahren durchgeführt wird, sind die getunnelten Datenpakete vom Foreign-Agent zum Home-Agent wie folgt eingestellt: IP-Felder (Kapselungs-Kopfdaten): Die Ausgangsadresse ist auf die Care-of-Adresse des Mobilknotens eingestellt, die Zieladresse ist auf die Adresse des Home-Agent eingestellt, und das Protokollfeld hat den Wert 4 zur Angabe der IP-in-IP-Kapselung. Die UDP-Felder (Kapselungs-Kopfdaten): Der Ausgangs-Port ist auf den vom Mobilknoten ausgewählten Ausgangs-Port des Mobilknotens eingestellt, und der Ziel-Port ist auf 434 eingestellt. Die IP-Felder der Original-Kopfdaten (der inneren Kopfdaten) sind: Die Ausgangsadresse ist die Heimatadresse des Mobilknotens, und die Zieladresse ist die Adresse des entsprechenden Knotens.
  • Das über den UDP/MIP-Tunnel 48 vom Home-Agent an den Foreign-Agent getunnelte Datenpaket ist wie folgt eingestellt: IP-Felder (Kapselungs-Kopfdaten): Die Ausgangsadresse ist auf die Adresse des Home-Agent eingestellt, die Zieladresse ist auf die vom NAT/NAPT-Gerät umgesetzte öffentliche Adresse für die Care-of-Adresse des Mobilknotens eingestellt, und das Protokollfeld hat den Wert 4 zur Angabe der IP-in-IP-Kapselung. Die UDP-Felder der Original-Kopfdaten (Kapselungs-Kopfdaten) lauten wie folgt: Der Ausgangs-Port ist auf 434 eingestellt, und der Ziel-Port ist auf den Ausgangs-Port des Mobilknotens eingestellt, wenn das Paket über das NAT-Gerät geleitet wird, oder auf die vom NAPT-Gerät umgesetzte Port-Nummer für den Ausgangs-Port des Mobilknotens, wenn das Paket über das NAPT-Gerät geleitet wird. Die IP-Felder der Original-Kopfdaten (der inneren Kopfdaten) sind: Die Ausgangsadresse ist die Adresse des entsprechenden Knotens, und die Zieladresse ist die Heimatadresse des Mobilknotens.
  • Beachten Sie, dass das durch das NAT/NAPT-Gerät wandernde eingehende Paket beim Empfang am Foreign-Agent wie folgt erscheint: die IP-Felder (Kapselungs-Kopfdaten) lauten: Die Ausgangsadresse ist die Adresse des Home-Agent, die Zieladresse ist die Care-of-Adresse des Mobilknotens, und das Protokollfeld hat den Wert 4 zur Angabe der IP-in-IP-Kapselung. Die UDP-Felder (Kapselungs-Kopfdaten) lauten: Der Ausgangs-Port ist 434, und der Ziel-Port ist der Ausgangs-Port des Mobilknotens. Die IP-Felder der Original-Kopfdaten (der inneren Kopfdaten) sind: Die Ausgangsadresse ist die Adresse des entsprechenden Knotens, und die Zieladresse ist die Heimatadresse des Mobilknotens.
  • Wenn kein UPD-Tunneling verwendet wird, d. h. wenn kein NAT/NAPT-Gerät zwischen dem Foreign-Agent und dem Home-Agent positioniert ist, wird der Datenverkehr zwischen dem Foreign-Agent und dem Home-Agent in konventioneller Weise verarbeitet. Das bedeutet, der Datenverkehr in Zielrichtung zwischen dem Home-Agent und dem Foreign-Agent wird wie im Mobile-IPv4-Protokoll beschrieben getunnelt, beispielsweise wie in RFC 3220 beschrieben. Der Datenverkehr in umgekehrter Richtung vom Foreign-Agent zum Home-Agent wird mit einem Reverse-Tunneling-Protokoll getunnelt, beispielsweise wie in RFC 3024 beschrieben.
  • 6 zeigt ein Diagramm einer Nachrichtenfolge, allgemein an 172 dargestellt, zur Darstellung einer exemplarischen Verwendung des MIP UPA-Protokolls einer Ausführungsform der vorliegenden Erfindung für die Mobile IPv4-Registrierung. Hier handelt es sich bei dem Mobilknoten um einen privaten Mobilknoten, der in ein Netz außerhalb seines Heimatnetzes 18 (in 1 dargestellt) wechselt. Das Heimatnetz ist ein mit einem NAT-Gerät ausgestattetes privates Netz. Das Fremdnetz 52, in das der Mobilknoten 12 wechselt, ist ein mit einem NAPT-Gerät ausgestattetes privates Netz. Hier ist eine Situation dargestellt, in der die Heimat-IP-Adresse des Mobilknotens einen Konflikt mit einem oder mehreren anderen Knoten des Fremdnetzes 52 aufweist.
  • Das Diagramm der Nachrichtenfolge 172 zeigt den Nachrichtenfluss, angegeben durch die Segmente 174, 176, 178, 182, 184, 186, 188 und 190 einer Mobile-UP-Registrierung, bei der die UPA, zugeordnet oder abgerufen, vom Mobilknoten als seine nicht mehrdeutige Identifizierung verwendet wird, d. h. als seine IP-Adresse. Muster der sich daraus ergebenden Bindungsinformationen im Foreign-Agent 32 und im Home-Agent 22, zusammen mit Mustern der Adresszuordnungstabellen im NAPT-Gerät und im NAT-Gerät, sind ebenfalls in der Figur dargestellt.
  • 7 zeigt ein Diagramm einer Nachrichtenfolge, allgemein an 202 dargestellt, das hier zur Darstellung des Datenverkehrsflusses in Zielrichtung und in umgekehrter Richtung verwendet wird, wobei das UDP/MIP-Tunneling 48 zwischen dem Foreign-Agent und dem Home-Agent für den NAPT-Geräteübergang verwendet wird, und wobei das UPA-Tunneling 52 zwischen dem Foreign-Agent und dem Mobilknoten zur Behandlung des Adresskonflikts verwendet wird. Für beide Tunnel wird eine IP-in-IP-Kapselung verwendet. Hier dienen die Segmente 204, 206, 208, 212, 214 und 216 zur Darstellung des Datenverkehrsflusses in umgekehrter Richtung. Die Segmente 218, 222, 224, 226, 228 und 232 dienen der Darstellung des Datenverkehrsflusses in Zielrichtung.
  • Die Figur verdeutlicht, dass die Care-of-Adresse des Mobilknotens (CoApr) und die Port-Nummer (MNP) vom NAPT-Gerät des Fremdnetzes (NAPTf@) bzw. einem seiner Ports (NAPTfpa) umgesetzt werden und umgekehrt. Wenn statt dessen im Fremdnetz ein NAT-Gerät vorhanden ist, bleibt die Port-Nummer des Mobilknotens intakt, d. h. sie wird vom NAT-Gerät bei der Registrierung und im Datenverkehr nicht geändert. Die Heimatadresse des Mobilknotens wird einer NAT-zugeordneten öffentlichen Adresse im Datenverkehr zugeordnet.
  • Dadurch wird ein verbessertes Verfahren zur Weiterleitung von Daten zwischen einem Mobilknoten und einem entsprechenden Knoten bereitgestellt, das in einem Funkkommunikationssystem betrieben werden kann.
  • Die vorangegangenen Beschreibungen stellen bevorzugte Beispiele zur Implementierung der Erfindung dar, der Umfang der Erfindung wird jedoch durch diese Beschreibung nicht notwendigerweise begrenzt. Der Umfang der vorliegenden Erfindung wird durch die folgenden Patentansprüche definiert:
  • 1
  • 22
    HA
    25
    CN
    24
    INTERNET
    18
    HEIMATNETZ
    26
    FREMDNETZ
    12
    MN
    38
    FA
    42
    ERMITTLER
    44
    NACHRICHTENGENERATOR
    34
    DHCP-SERVER
  • 2
  • 58
    TYP
    62
    LÄNGE
    64
    RESERVIERT
    66
    KAPSELUNG
    68
    EINDEUTIGE PRIVATE ADRESSE
  • 5
  • MIP-REGISTRIERUNG
    MIP-DATENVERKEHR IN UMKEHRRICHTUNG
    MIP-DATENVERKEHR IN ZIELRICHTUNG
    12
    MN
    134
    MIP RRQ (W/P UND T BITS GESETZT)
    136
    MIP RRP + <UPA-ERW.>
    138
    MIP RRQ (W/P UND T BITS GESETZT) + <UPA-ERW.>
    144
    MIP RRP
    148
    UPA-GETUNNELTE PAKETE
    162
    UDA-GETUNNELTE PAKETE
    32
    FA
    142
    MIP RRQ (W/P UND T BITS GESETZT) + <UDP-TUNNEL ANF.ERW.>
    146
    MIP RRP + <UDP-TUNNEL ANT.ERW.>
    152
    UDP-GETUNNELTE PAKETE
    158
    UDP-GETUNNELTE PAKETE
    164
    UDP KEEPALIVE-PAKETE
    22
    HA
    154
    DIREKTE PAKETE
    156
    DIREKTE PAKETE
    25
    CN
  • 3
  • 74
    MOBILE IPv4 REGISTRIERUNGSANFORDERUNGSNACHRICHT (RRQ)
    76
    IP-HEIMATADRESSE DES MN IST EINE PRIVATE ADRESSE? NEIN JA
    78
    ADRESSKONFLIKT MIT HEIMATADRESSE DES MN? NEIN JA
    82
    MN HAT UPA? NEIN JA
    84
    IST COA (ADRESSE DES FA) INE ÖFFENTLICHE ADRESSE? NEIN JA
    88
    RRQ WEITERLEITEN OHNE ERWEITERUNG DER UDP-TUNNELANFORDERUNG
    AN HOME-AGENT
    86
    RRQ ZURÜCKWEISEN MIT ANGEHÄNGTER UPA-ERWEITERUNG
    AN MOBILKNOTEN
    92
    RRQ WEITERLEITEN MIT ERWEITERUNG DER UDP-TUNNELANFORDERUNG
    AN HOME-AGENT
  • 4
  • 102
    MOBILE IPv4 REGISTRIERUNGSANFORDERUNGSNACHRICHT (RRQ)
    106
    MN HAT UPA? JA NEIN
    108
    IP-HEIMATADRESSE DES MN IST EINE PRIVATE ADRESSE? NEIN JA
    112
    ADRESSKONFLIKT AN HEIMATADRESSE DES MN? NEIN JA
    114
    IST COA (ADRESSE DES FA) EINE ÖFFENTLICHE ADRESSE? JA NEIN
    118
    RRQ WEITERLEITEN OHNE ERWEITERUNG DER UDP-TUNNELANFORDERUNG
    AN HOME-AGENT
    116
    RRQ ZURÜCKWEISEN MIT ANGEHÄNGTER UPA-ERWEITERUNG
    AN MOBILKNOTEN
    122
    RRQ WEITERLEITEN MIT ERWEITERUNG DER UDP-TUNNELANFORDERUNG
    AN HOME-AGENT
  • 6A
  • LEGENDE
  • MNpr
    (PRIVATE) HEIMATADRESSE DES MN
    MNpu
    VON NATh ZUGEORDNETE ÖFFENTLICHE HEIMATADRESSE DES MN
    MNta
    UPA DES MN
    CN@
    ÖFFENTLICHE ADRESSE DES CN
    HA@
    ÖFFENTLICHE ADRESSE DES HA
    FAi@
    INTERNE ADRESSE DES FA
    CoApr
    (PRIVATE) CoA des FA
    NAPTf@
    ÖFFENTLICHE ADRESSE DES NAPTf
    NAPTfpa
    DEM MN ZUGEORDNETER AUSGANGS-PORT DES NAPTf
    MNp
    VON MN AUSGEWÄHLTER AUSGANGS-PORT DES MN PRIVATES FREMDNETZ PRIVATES HEIMATNETZ ((Alle Abkürzungen im Schaubild bleiben unverändert stehen; all abbreviations in the figure are the same in German))
    AN 6B
  • 6B
  • VON 6A ((Alle Abkürzungen im oberen Bereich des Schaubilds bleiben unverändert stehen; all abbreviations in the upper part of the figure are the same in German)) ((unter 190; below 190)) FA BESUCHS-BINDUNG MN@ L2@ UPA, Port MNpu MNL2@, MNta, MNp ((unter 188; below 188)) NAPTf-ZUORDNUNG NAPTf-Port-Nr. interner@ Port NAPTfp1 NAPTfpa CoApr, MNp ((unter 186; below 186)) NATh-ZUORDNUNG extern@ intern@ NATh1@ MNpu MNpr ((unter 184; below 184)) HA MOBILITÄTS-BINDUNG MN@ CoA@ MNpr CoApr HA NAT-BINDUNG MN@ NATed@, NAT-Port MNpr NAPTf@, NAPTfpa
  • 7A
  • LEGENDE
  • MNpr
    (PRIVATE) HEIMATADRESSE DES MN
    MNpu
    VON NATh ZUGEORDNETE ÖFFENTLICHE HEIMATADRESSE DES MN
    MNta
    UPA DES MN
    CN@
    ÖFFENTLICHE ADRESSE DES CN
    HA@
    ÖFFENTLICHE ADRESSE DES HA
    FAi@
    INTERNE ADRESSE DES FA
    CoApr
    (PRIVATE) CoA des FA
    NAPTf@
    ÖFFENTLICHE ADRESSE DES NAPTf
    NAPTfpa
    DEM MN ZUGEORDNETER AUSGANGS-PORT DES NAPTf
    MNp
    VON MN AUSGEWÄHLTER AUSGANGS-PORT DES MN PRIVATES FREMDNETZ PRIVATES HEIMATNETZ ((Alle Abkürzungen im Schaubild bleiben unverändert stehen; all abbreviations in the figure are the same in German))
    AN 7B
  • 7B
  • VON 7A ((Alle Abkürzungen im oberen Bereich des Schaubilds bleiben unverändert stehen; all abbreviations in the upper part of the figure are the same in German)) ((unter 232; below 232)) FA BESUCHS-BINDUNG MN@ L2@ UPA, Port MNpu MNL2@, MNta, MNp ((unter 228; below 228)) NAPTf-ZUORDNUNG NAPTf-Port-Nr. interner@ Port NAPTfp1 NAPTfpa CoApr, MNp ((unter 226; below 226)) NATh-ZUORDNUNG extern@ intern@ NATh1@ MNpu MNpr ((unter 224; below 224)) HA MOBILITÄTS-BINDUNG MN@ CoA@ MNpr CoApr HA NAT-BINDUNG MN@ NATed@, NAT-Port MNpr NAPTf@, NAPTfpa

Claims (11)

  1. Funkkommunikationssystem (10), das Folgendes umfasst: mobiles Netz, das ein Heimatnetz (18) mit einem diesem Netz zugeordneten Home-Agent (22) und ein Fremdnetz (26) mit einem diesem Fremdnetz zugeordneten Foreign-Agent (32) sowie einen Mobilknoten (12), der wahlweise über eine nicht-universelle Kennungsadresse identifiziert werden kann, umfasst; wobei ein Netzadressumsetzungsgerät (NAT) oder ein Netzadress-Portumsetzungsgerät (NAPT) zwischen dem Foreign-Agent und dem Home-Agent vorhanden ist und wobei eine Care-of-Adresse für den Mobilknoten vorhanden ist; wobei dieses Paket-Funkkommunikationssystem des Weiteren Folgendes umfasst: Ermittler (42) im Fremdnetz, der so angepasst wurde, dass er ermittelt, ob der Mobilknoten über eine nicht-universelle Kennungsadresse identifiziert ist, und der des Weiteren so angepasst wurde, dass er ermittelt, ob die nicht-universelle Kennungsadresse des Mobilknotens einen Konflikt mit der nicht-universellen Kennungsadresse eines oder mehrerer anderer dem Fremdnetz zugeordneter Knoten aufweist; und Nachrichtengenerator (44), der als Reaktion auf die vom Ermittler erhaltenen Informationen, dass der Mobilknoten durch die nicht-universelle Kennungsadresse identifiziert ist und dass die nicht-universelle Kennungsadresse einen Konflikt mit der nicht-universellen Kennungsadresse weiterer dem Fremdnetz zugeordneter Knoten aufweist, betrieben werden kann, wobei dieser Nachrichtengenerator zum Erzeugen einer Nachricht angepasst wurde, die an den Mobilknoten kommuniziert wird und den Mobilknoten darauf hinweist, dass er eine eindeutige private Adresse abrufen soll, wobei die eindeutige private Adresse verwendet wird, um einen ersten Datentunnel (52) zwischen dem Mobilknoten und dem Foreign-Agent zu bilden; wobei dieses Paket-Funkkommunikationssystem dadurch gekennzeichnet ist, dass: der Foreign-Agent oder der Home-Agent so angepasst wurden, dass sie erkennen, ob ein NAT-Gerät oder ein NAPT-Gerät zwischen dem Foreign-Agent und dem Home-Agent vorhanden ist, der Foreign-Agent oder der Home-Agent so angepasst wurden, dass sie mithilfe eines UDP-Protokolls (User Datagram Protocol) einen zweiten Datentunnel (48) zwischen dem Foreign-Agent und dem Home-Agent bilden, um den NAT/NAPT-Geräteübergang zu ermöglichen, wobei eine über ein NAT/NAPT-Gerät umgesetzte öffentliche Adresse für die Care-of-Adresse des Mobilknotens als Zieladresse verwendet wird für das Tunneling der Daten vom Home-Agent zum Foreign-Agent; und der erste und der zweite Datentunnel für die bidirektionale Weiterleitung der Daten mit dem Mobilknoten verwendet werden, wenn der Mobilknoten im Fremdnetz positioniert ist.
  2. Paket-Funkkommunikationssystem (10) gemäß Anspruch 1, wobei die von diesem Nachrichtengenerator erzeugte Nachricht Werte der eindeutigen privaten Adresse enthält.
  3. Paket-Funkkommunikationssystem (10) gemäß Anspruch 1, wobei das Fremdnetz ein DHCP-Gerät (Dynamic Host Configuration Protocol) umfasst und wobei die von diesem Nachrichtengenerator erzeugte Nachricht den Mobilknoten veranlasst, Werte der eindeutigen privaten Adresse vom DHCP-Gerät abzurufen.
  4. Paket-Funkkommunikationssystem (10) gemäß Anspruch 1, wobei der Mobilknoten so angepasst ist, dass er wahlweise eine Registrierungsanforderung am Fremdnetz erzeugt und wobei dieser Ermittler so angepasst wurde, dass er als Reaktion auf die Erkennung der Erzeugung der Registrierungsanforderung arbeitet.
  5. Paket-Funkkommunikationssystem (10) gemäß Anspruch 4, wobei dieser Ermittler im Foreign-Agent ausgeführt ist, und wobei die wahlweise vom Mobilknoten erzeugte Registrierungsanforderung den Mobilknoten identifiziert.
  6. Verfahren zur Kommunikation von als Paket formatierten Daten in einem Paket-Funkkommunikationssystem (10), wobei das Paket-Funkkommunikationssystem ein Heimatnetz (18) und ein Fremdnetz (26) und einen Mobilknoten (12) umfasst, wobei das Heimatnetz einen ihm zugeordneten Home-Agent (22) umfasst und das Fremdnetz einen ihm zugeordneten Foreign-Agent (32) umfasst, und wobei der Mobilknoten wahlweise über eine nicht-universelle Kennungsadresse identifiziert werden kann, wobei ein Netzadressumsetzungsgerät (NAT) oder ein Netzadress-Portumsetzungsgerät (NAPT) zwischen dem Foreign-Agent und dem Home-Agent vorhanden ist und wobei eine Care-of-Adresse für den Mobilknoten vorhanden ist; wobei dieses Verfahren die folgenden Schritte umfasst: Ermitteln am Fremdnetz, ob der Mobilknoten über eine nicht-universelle Kennungsadresse identifiziert ist, und ob die nicht-universelle Kennungsadresse des Mobilknotens einen Konflikt mit der nicht-universellen Kennungsadresse eines oder mehrerer anderer dem Fremdnetz zugeordneter Knoten aufweist; und als Reaktion auf die Ermittlung, dass der Mobilknoten durch die nicht-universelle Kennungsadresse identifiziert ist und dass die nicht-universelle Kennungsadresse einen Konflikt mit der nicht-universellen Kennungsadresse weiterer dem Fremdnetz zugeordneter Knoten aufweist, das Erzeugen einer Nachricht zur Kommunikation an den Mobilknoten, die den Mobilknoten zumindest darauf hinweist, dass er eine eindeutige private Adresse abrufen soll, wobei die eindeutige private Adresse verwendet wird, um einen ersten Datentunnel (52) zwischen dem Mobilknoten und dem Foreign-Agent zu bilden; wobei das Verfahren durch folgende Schritte gekennzeichnet ist. Ermitteln am Foreign-Agent oder am Home-Agent, ob ein NAT-Gerät oder ein NAPT-Gerät zwischen dem Foreign-Agent und dem Home-Agent vorhanden ist, und als Reaktion hierauf; Bilden eines zweiten Datentunnels (48) durch den Foreign-Agent oder den Home-Agent zwischen dem Foreign-Agent und dem Home-Agent mithilfe eines UDP-Protokolls (User Datagram Protocol), um den NAT/NAPT-Geräteübergang zu ermöglichen, wobei eine über ein NAT/NAPT-Gerät umgesetzte öffentliche Adresse für die Care-of-Adresse des Mobilknotens als Zieladresse für das Tunneling der Daten vom Home-Agent zum Foreign-Agent verwendet wird; und wobei der erste und der zweite Datentunnel für die bidirektionale Weiterleitung der Daten mit dem Mobilknoten verwendet werden, wenn der Mobilknoten im Fremdnetz positioniert ist.
  7. Verfahren gemäß Anspruch 6, wobei die in diesem Schritt „Nachrichtengenerierung" erzeugte Nachricht Werte der eindeutigen privaten Adresse enthält.
  8. Verfahren gemäß Anspruch 6, wobei das Fremdnetz des Paket-Funkkommunikationssystems ein DHCP-Gerät (Dynamic Host Configuration Protocol) umfasst und wobei dieses Verfahren des Weiteren Folgendes umfasst: Am Mobilknoten Analysieren der in der Nachricht enthaltenen Werte, und als Reaktion darauf; Abrufen von Werten der eindeutigen privaten Adresse aus dem DHCP-Gerät.
  9. Verfahren gemäß Anspruch 6, das vor dem Schritt zum Ermitteln des Weiteren den Schritt zum Erzeugen einer Registrierungsanforderung am Mobilknoten umfasst zum Anfordern einer Registrierung des Mobilknotens beim Fremdnetz.
  10. Verfahren gemäß Anspruch 6, wobei der Schritt zum Ermitteln die Ermittlung umfasst, ob die Registrierungsanforderung den Mobilknoten identifiziert.
  11. Verfahren gemäß Anspruch 6, wobei der Schritt zum Ermitteln die Ermittlung umfasst, ob die Registrierungsanforderung den Mobilknoten mit der nicht-universellen Kennungsadresse identifiziert.
DE60312804T 2002-12-20 2003-12-09 Aufbau eines bidirektionalen IP-Tunnels in einem Mobile-IP Kommunikationssystem im Falle eines privaten Adresskonflikts Expired - Lifetime DE60312804T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US325057 2002-12-20
US10/325,057 US7453850B2 (en) 2002-12-20 2002-12-20 Apparatus, and associated method, for facilitating bi-directional routing of data in a packet radio communication system

Publications (2)

Publication Number Publication Date
DE60312804D1 DE60312804D1 (de) 2007-05-10
DE60312804T2 true DE60312804T2 (de) 2007-12-06

Family

ID=32468973

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60312804T Expired - Lifetime DE60312804T2 (de) 2002-12-20 2003-12-09 Aufbau eines bidirektionalen IP-Tunnels in einem Mobile-IP Kommunikationssystem im Falle eines privaten Adresskonflikts

Country Status (4)

Country Link
US (1) US7453850B2 (de)
EP (1) EP1434406B1 (de)
AT (1) ATE358384T1 (de)
DE (1) DE60312804T2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019000465A1 (de) 2019-01-22 2019-06-13 Daimler Ag Verfahren und Vorrichtung zur unterbrechungsfreien Internet Protocol (IP) Kommunikation in einem Fahrzeug

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI106503B (fi) * 1998-09-21 2001-02-15 Nokia Networks Oy IP-liikkuvuusmekanismi pakettiradioverkkoa varten
EP1344353B1 (de) * 2000-12-22 2014-11-19 BlackBerry Limited Drahtloses routersystem und verfahren
US7697508B2 (en) * 2003-07-31 2010-04-13 University Of Florida Research Foundation, Inc. System, apparatus, and methods for proactive allocation of wireless communication resources
US7668145B2 (en) * 2003-12-22 2010-02-23 Nokia Corporation Method to support mobile IP mobility in 3GPP networks with SIP established communications
US8151348B1 (en) * 2004-06-30 2012-04-03 Cisco Technology, Inc. Automatic detection of reverse tunnels
JP4561983B2 (ja) * 2005-01-13 2010-10-13 日本電気株式会社 ローカルコンテンツ接続システム、移動端末、ローカルコンテンツ接続方法及びクライアントプログラム
US8411650B2 (en) * 2005-04-18 2013-04-02 Cisco Technology, Inc. Method and system for providing virtual private network services through a mobile IP home agent
US8117340B2 (en) * 2005-04-25 2012-02-14 Microsoft Corporation Trans-network roaming and resolution with web services for devices
WO2006136660A1 (en) * 2005-06-21 2006-12-28 Seven Networks International Oy Maintaining an ip connection in a mobile network
WO2006136661A1 (en) * 2005-06-21 2006-12-28 Seven Networks International Oy Network-initiated data transfer in a mobile network
US8731542B2 (en) 2005-08-11 2014-05-20 Seven Networks International Oy Dynamic adjustment of keep-alive message intervals in a mobile network
EP1764970A1 (de) 2005-09-19 2007-03-21 Matsushita Electric Industrial Co., Ltd. Mobile Mehrfachschnittstellen Knoten mit gleichzeitiger Heim und Fremdnetzwerksverbindung
DE602006011745D1 (de) 2006-09-08 2010-03-04 Alcatel Lucent Verfahren zur Anforderung der Verwendung von erwünschten Datentunneltyp
ATE505023T1 (de) * 2006-11-06 2011-04-15 Nokia Corp Globale erreichbarkeit in kommunikationsnetzen
CN101193130B (zh) * 2006-11-21 2010-05-12 中兴通讯股份有限公司 移动IPv6中穿越网络地址转换的方法
US8179872B2 (en) 2007-05-09 2012-05-15 Research In Motion Limited Wireless router system and method
EP2003858A1 (de) * 2007-06-14 2008-12-17 Nokia Siemens Networks Oy Durchführung interaktiver Konnektivitätsprüfungen in einer Mobilitätsumgebung
EP2003841B1 (de) * 2007-06-14 2010-08-11 Nokia Siemens Networks Oy Reduktion von Erregungsmeldungen nach Elementedurchläufen durch einen Relais-Mechanismus
CN101374139A (zh) * 2007-08-22 2009-02-25 华为技术有限公司 代理设备、会话存活检测方法及系统
US8345694B2 (en) * 2007-12-31 2013-01-01 Airvana, Corp. Network address translation for tunnel mobility
JP5298666B2 (ja) * 2008-06-30 2013-09-25 富士通株式会社 通信サービス支援装置、通信サービス支援方法および通信サービス支援プログラム
KR101129315B1 (ko) * 2008-12-18 2012-03-26 한국전자통신연구원 라우팅 확장성과 이동성을 지원하는 터널 포인트의 동작 방법
CN102215476B (zh) * 2010-04-02 2016-03-30 中兴通讯股份有限公司 中继通信网络的信息传输方法及系统
US8745722B2 (en) * 2012-03-09 2014-06-03 Wapice Oy Managing remote network addresses in communications
TWI535247B (zh) 2012-04-10 2016-05-21 財團法人資訊工業策進會 用於網路位址轉換穿透的傳輸系統及傳輸方法
CN104348821B (zh) * 2013-08-08 2018-04-27 联想(北京)有限公司 管理IPv4/IPv6业务的方法、设备和系统
CN104270461B (zh) * 2014-10-20 2017-05-10 常熟理工学院 一种车联网的实现方法
CN105991856B (zh) * 2015-03-05 2021-01-12 李明 基于rtp服务器到服务器寻路由的voip寻路由
CN107395778B (zh) * 2016-05-16 2020-09-04 华为技术有限公司 一种用户溯源的方法、装置及系统
US11122127B2 (en) * 2017-08-28 2021-09-14 Qualcomm Incorporated Techniques and apparatuses for modem-assisted heartbeat transmission
CN110417924B (zh) * 2018-04-28 2021-10-01 华为技术有限公司 分布式设备中的报文处理方法和分布式设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6195705B1 (en) * 1998-06-30 2001-02-27 Cisco Technology, Inc. Mobile IP mobility agent standby protocol
US6947401B2 (en) * 2000-03-08 2005-09-20 Telefonaktiebolaget Lm Ericsson (Publ) Hierarchical mobility management for wireless networks
JP3636637B2 (ja) * 2000-05-30 2005-04-06 三菱電機株式会社 経路最適化方法
US6856624B2 (en) 2001-02-21 2005-02-15 Alcatel Temporary unique private address

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019000465A1 (de) 2019-01-22 2019-06-13 Daimler Ag Verfahren und Vorrichtung zur unterbrechungsfreien Internet Protocol (IP) Kommunikation in einem Fahrzeug

Also Published As

Publication number Publication date
US7453850B2 (en) 2008-11-18
EP1434406B1 (de) 2007-03-28
ATE358384T1 (de) 2007-04-15
DE60312804D1 (de) 2007-05-10
EP1434406A3 (de) 2004-07-07
EP1434406A2 (de) 2004-06-30
US20040120294A1 (en) 2004-06-24

Similar Documents

Publication Publication Date Title
DE60312804T2 (de) Aufbau eines bidirektionalen IP-Tunnels in einem Mobile-IP Kommunikationssystem im Falle eines privaten Adresskonflikts
DE60211657T2 (de) System und verfahren für ein mobilitätsverwaltungsprotokoll mit geringem zusatzaufwand in einer internet protokollschicht
DE602004008692T2 (de) Drahtloses lokales Netzwerksystem mit der Möglichkeit zur Unterstützung von mobilen Hosts und ein entsprechendes Betriebsverfahren
DE69634690T2 (de) Paketfunksystem und verfahren zur protokollunabhängigen wegesuche eines datenpakets in paketfunknetzen
DE69925453T2 (de) Mobiles IP ohne Einkapselung
DE60028254T2 (de) Steuerungsgerät und -verfahren für paketbasierte kommunikation
DE69327019T2 (de) Routing von Datenpaketen zwischen einem mobilen und einem fest installierten Rechner durch ein Netzwerk
DE69821393T2 (de) Proxy-Leitweglenkung
DE60033162T2 (de) Erleichterung der datenübertragung
DE69822516T2 (de) Mobiler datenleitweg
DE60133641T2 (de) Kommunikationssystem und verfahren dafür
EP1438829B1 (de) Verfahren und vorrichtung zur abbildung von netzwerk-headern auf mpls-header in bearer-architekturen
EP1391081A2 (de) Heterogenes mobilfunksystem
DE60312184T2 (de) Verfahren eines gateways zum auswählen eines kanals zur übertragung von datenpaketen
DE69931874T2 (de) Verfahren zur Herstellung und Aufrechterhaltung einer mobilen TCP-Verbindung
DE10131561A1 (de) Verfahren zur Übertragung von Anwendungspaketdaten
DE19742681A1 (de) GPRS-Teilnehmerauswahl von mehreren Internet-Dienstanbietern
DE60125266T2 (de) Durchgehendes Tunneling für dynamische lokale Adressierung von mobilen Rechnern
DE60018913T2 (de) Verfahren und Apparat um mit Apparate zu kommunizieren die nicht zum selben virtuellen privaten Netzwerk (VPN) gehören
DE60215053T2 (de) Verfahren zur unterstützung der mobilität in drahtlosen netzwerken
DE112006001655B4 (de) Verfahren und Vorrichtung zur Vereinfachung einer Kommunikation unter Verwendung von Ersatz- und Care-of-Internetprotokolladressen
EP1798905B1 (de) Verfahren zur Übertragung von auf dem Ethernet-Übertragungsprotokoll basierenden Datenpaketen zwischen zumindest einer mobilen Kommunkationseinheit und einem Kommunikationssystems
DE602004013051T2 (de) Routingverfahren und- system zum beispiel für ip-mobilfunknetze, entsprechendes netz und computerprogrammprodukt
EP2005667B1 (de) Verfahren zur kommunikation von endgeräten über paketvermittelte mobilfunknetze
DE10164919B4 (de) Verfahren zum Vermitteln von Daten zwischen einem lokalen Netzwerk und einem externen Gerät und Router dafür

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: ALCATEL LUCENT, PARIS, FR

8364 No opposition during term of opposition