DE60216862T2 - System und Verfahren zum mikromobilitätsbasierten Netz-Routing - Google Patents

System und Verfahren zum mikromobilitätsbasierten Netz-Routing Download PDF

Info

Publication number
DE60216862T2
DE60216862T2 DE60216862T DE60216862T DE60216862T2 DE 60216862 T2 DE60216862 T2 DE 60216862T2 DE 60216862 T DE60216862 T DE 60216862T DE 60216862 T DE60216862 T DE 60216862T DE 60216862 T2 DE60216862 T2 DE 60216862T2
Authority
DE
Germany
Prior art keywords
bsr
mobile node
mobile
micromobility
address
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
DE60216862T
Other languages
English (en)
Other versions
DE60216862D1 (de
Inventor
Vincent Oak Park Magret
Vinod Ottawa Kumar Choyi
Behcet Sarikaya
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
Publication of DE60216862D1 publication Critical patent/DE60216862D1/de
Application granted granted Critical
Publication of DE60216862T2 publication Critical patent/DE60216862T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/087—Mobility data transfer for preserving data network PoA address despite hand-offs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/18—Performing reselection for specific purposes for allowing seamless reselection, e.g. soft reselection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/18—Performing reselection for specific purposes for allowing seamless reselection, e.g. soft reselection
    • H04W36/185—Performing reselection for specific purposes for allowing seamless reselection, e.g. soft reselection using make before break
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248—Connectivity information update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/26—Connectivity information management, e.g. connectivity discovery or connectivity update for hybrid routing by combining proactive and reactive routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Description

  • Die Erfindung betrifft ein mikromobilitätsbasiertes Netz-Routingverfahren gemäß dem Oberbegriff von Anspruch 1, ein computernutzbares Medium, das computerlesbare Programmcodemittel aufweist, die mikromobilitätsbasierte Netz-Routingfunktionalität gemäß dem Oberbegriff von Anspruch 11 bereitstellen, und ein mikromobilitätsbasiertes Netz-Routingsystem gemäß dem Oberbegriff von Anspruch 21.
  • GEBIET DER ERFINDUNG
  • Übersicht
  • Das Internet hat die Art und Weise revolutioniert, wie die Menschen heutzutage arbeiten. Ob es das Lesen unserer täglichen Morgenzeitungen ist, der Aktienhandel, die Wettervorhersage, das Kaufen von Bekleidung oder sonst noch etwas, woran man denken kann. Langsam hat sich die Technologie der drahtlosen Kommunikation im letzten Jahrzehnt verbessert. Sie begann damals in den Sechzigern mit dem ersten analogen Funksystem, um digital zu werden, und nun in der Übergangszeit, um Breitbandzugang zu bieten. Der Grund, daß diese langsame Revolution der Funkvernetzung nun explosionsartig in den nächsten Jahren erfolgen wird, ist, weil jetzt ein Medium (Internet) zum Kommunizieren und eine enorme Menge von Anwendungen vorhanden sind.
  • Mobile IP stellt einen Rahmen bereit, in dem sich die mobilen Knoten von einem Anschlußpunkt (z.B. einem Subnetz in einem Unternehmen) zu einem anderen Subnetz (z.B. einem anderen Subnetz in einem anderen Unternehmen) bewegen können und weiter in der Lage sein werden, mit den Knoten zu kommunizieren. Mobile IP stellt die Mittel bereit, um den aktuellen Aufenthaltsort zu verfolgen (bezeichnet als ein Binding in der Mobile IP-Spezifikation) und den gesamten Verkehr, der an den mobilen Knoten gesendet wurde, transparent an den aktuellen Aufenthaltsort weiterzuleiten. Mobile IP bedeutet, daß wann immer sich der mobile Knoten von einem Subnetz zu einem anderen bewegt, die Verfolgung (d.h. das Binding) zu aktualisieren, das heißt in seinem Heimatnetz (z.B. dem Netz, in dem der Benutzer offiziell registriert ist) aufrechtzuerhalten.
  • Gebiet der Problemlösung
  • Das Problem mit Mobile IP ist der Overhead, der während des Durchführens der Verbindungsübergabe eingebracht wird. Wenn der mobile Host in einem Fremdnetz ist und jedesmal, wenn er eine Verbindungsübergabe durchführt, werden Nachrichten der Mobile IP-Registrierungsanforderung an den Heimatagenten gesendet. Die Basisstationen in Zellularnetzen sind in der Regel gebündelt, die zusammen mit den Routern Domänen in dem Upstream bilden, die bestimmen, wohin die Pakete weiterzuleiten sind. Eine Lösung des Problems der häufigen Nachrichten der Registrierungsanforderung, die an den HA gesendet werden, ist die Domänenkonzeption und die Topologie der Domäne (in der Regel baumähnlich) auszunutzen.
  • Die vorliegende Erfindung betrifft das allgemeine Gebiet des Telekommunikations- und Computernetz-Nachrichtenroutings innerhalb des Kontextes von Mobile IP. Während der Stand der Technik im Allgemeinen die Makromobilität innerhalb der Mobile IP-Netze behandelt, erweitert die vorliegende Erfindung diese Konzeption, um einem mobilen Knoten zu erlauben, den Zugang zum Internet zu erlangen, während die gleiche IP-Adresse beibehalten wird. Um eine signifikante Reduzierung des Protokolloverheads zu erlauben, reduziert das Protokoll der vorliegenden Erfindung die Gesamtnetzkommunikation auf das Beispiel, wenn der mobile Knoten den Versorgungsbereich einer Fremddomäne betritt (eventuell seine Heimatdomäne).
  • ALLGEMEINER STAND UND BESCHREIBUNG DES STANDES DER TECHNIK
  • Übersicht
  • Mobile IP unterstützt Mobilfunkteilnehmer, um von einem Netz zu einem anderen ohne Unterbrechung in seinen Diensten zu wechseln. Die Konzeption leidet unter einem großen Nachteil, wenn die Bewegung des Benutzers eine hohe Häufigkeit von Verbindungsübergaben dem Netz auferlegt. Mobile IP verlangt von dem mobilen Knoten, daß er seinen Heimatagenten über seinen neuen Aufenthaltsort jedesmal informiert, wenn sich sein Anschlußpunkt ändert. Die Konzeption, die manchmal als Makromobilität bezeichnet wird, ist nicht geeignet, wenn häufige Verbindungsübergaben vorhanden sind, wegen der Latenzzeit, die infolge des Austausches der Registrierungsnachrichten zwischen dem mobilen Knoten und dem Heimatagenten eingebracht wird.
  • Vorliegende Erfindung im Vergleich mit Lösungen des Standes der Technik
  • Die Mikromobilität ist eine Erweiterung auf Mobile IP und wird durch Verdecken des genauen Aufenthaltsortes des mobilen Knotens vor dem Heimatagenten erreicht, so daß Registrierungsnachrichten nicht den ganzen Weg an den HA gesendet werden müssen, statt dessen werden die Nachrichten lokal verarbeitet. Der genaue Aufenthaltsort des mobilen Knotens wird lokal innerhalb der Wireless-Domäne gehalten, die er besucht hat. Dieses Dokument präsentiert ein neuartiges Protokoll, das entworfen ist, um sich an die Mikromobilität zu wenden. Das Protokoll basiert auf IP-Multicast und ist unter Verwendung von Explicit Multicast weiter vervollkommnet worden, um sich an die Belange der schnellen und problemlosen Verbindungsübergaben zu wenden. Explicit Multicast ist verwendet worden, um einige der Nachteile des normalen IP-Multicast zu überwinden.
  • Beispielhafte Lösungen des Standes der Technik
  • Mehrere Protokolle, wie zum Beispiel HAWAII [Lucent], Cellular IP [Ericsson] und Hierarchical Foreign Agent sind vorgeschlagen worden, um die Menge der an den Heimatagenten (HA) gesendeten Nachrichten zu verringern. Jedes dieser Protokolle verwendet die Domänenkonzeption, um die Häufigkeit der gesendeten Nachrichten zu reduzieren.
  • Die Vorschläge HAWAII und Cellular IP sind sehr ähnlich, aber HAWAII findet besseren Anklang, weil es eine vollständigere Lösung des oben angegebenen Problems anbietet. Eine Übersicht des Designs des Protokolls ist unten gegeben. Kurzbeschreibungen der Vorschläge von der Universität Singapur und des hierarchischen Mikromobilitätsmanagements sind ebenfalls unten gegeben.
  • Es sind zwei Protokolle vorhanden, die innerhalb der IETF und der akademischen Gemeinschaft viel diskutiert worden sind, die auf einem Host-Route-basiertem Verfahren beruhen. Die Host-Route-basierten Verfahren verwenden den Hop-by-Hop-Mechanismus, um das Routing durchzuführen, wodurch bei jedem Hop der Eintrag für den mobilen Host gesucht wird und die Datenpakete unter Verwendung der entsprechenden Schnittstelle weitergeleitet werden. Die zwei Protokolle sind Hand-off-Aware Inter-Domain Infrastructure und Cellular IP. Diese werden nun im Detail diskutiert.
  • Das Dokument "Mobility Support in IPv6", 18. November 1998, von David B. Johnson und Charles Perkins, diskutiert die Mobile IP-Architektur. Ebenfalls diskutiert das Dokument "IP Mobility Support", RFC 2002, Oktober 1996, von C. Perkins die Mobile IP-Architektur.
  • Handoff Aware Inter-Domain Infrastructure [HAWAII]
  • Übersicht
  • Eine Domäne, wie in HAWAII definiert, kann mehrere Hundert Basisstationen einschließen, dadurch die Wahrscheinlichkeit erhöhen, daß ein MN (der eine Fremddomäne besucht), nachdem er sich mit seinem Heimatagenten registriert hat, innerhalb der gleichen Wireless-Domäne bleibt. In solch einem Szenario ist die Rolle des Heimatagenten sehr stark reduziert.
  • HAWAII definiert einen Domänen-Root-Rooter (Domain Root Router/DRR) als das Verbindungsgerät zwischen dem Internet und der Wireless-Domäne. Der mobile Knoten oder mobile Host verwendet die gewöhnlichen Mobile IP-Konzeptionen, wenn er sich zum ersten Mal in eine Fremddomäne bewegt.
  • Das Protokoll erfordert, daß der mobile Knoten eine Co-located Care-of-Adresse verwendet, eine Adresse, die nicht durch den Fremdagenten gegeben ist. Die Adresse kann zum Beispiel über DHCP erhalten werden. Der mobile Knoten fügt eine Erweiterung der Netzadreßkennung (Network Address Identifier Extension) hinzu, so daß die Domäne zwischen einem fremden mobilen Knoten und einem mobilen durch die Domäne verwalteten Knoten unterscheiden kann. Für einen Besucherknoten legt die Basisstation (d.h. der Router, der mit der Basisstation verbunden ist) einen Eintrag in dem Routing-Cache für den mobilen Knoten an und leitet die Registrierungsanforderung an den Heimatagenten des mobilen Knotens weiter. Jeder Knoten entlang dem Weg führt den gleichen Vorgang durch (d.h. Anlegen eines Eintrags des Routing-Caches) bis die Nachricht den DRR erreicht, von wo die Registrierungsanforderung an den Heimatagenten weitergeleitet wird.
  • Der mobile Knoten muß sich die Adresse der aktuellen Basisstation merken, so daß er die IP-Adresse zusammen mit seiner Registrierungsanforderung bereitstellen kann, wenn eine Verbindungsübergabe an die neue Basisstation durchgeführt wird. Das Vorhandensein der Erweiterung des vorherigen Fremdagentenknotens (Previous Foreign Agent Node Extension) hilft der Basisstation zu bestimmen, ob sich der mobile Knoten vorher über eine andere Basisstation von innerhalb der gleichen Wireless-Domäne registriert hat.
  • Wenn die Basisstation diese Erweiterung erkennt, löst sie den Routenaktualisierungsalgorithmus aus. Zwei Möglichkeiten sind in Abhängigkeit von der Kapazität definiert, die durch die verwendete Wireless-Technologie angeboten wird. Wenn der mobile Knoten Pakete von zwei Basisstationen gleichzeitig empfangen kann, geht der Routingaktualisierungsprozeß weiter bis zum Crossover-Router (der Router, der eine Schnittstelle aufweist, die zu der alten Basisstation führt, und die andere, die zu dem neuen führt); dieses Schema wird auch als das Nichtweiterleitungsschema (non-forwarding scheme) bezeichnet. In dem Weiterleitungsschema, in dem die mobilen Knoten nicht imstande sind, gleichzeitig mehrfachen Basisstationen zuzuhören, wird die Routenaktualisierungsnachricht gesendet, bis sie die alte Basisstation erreicht. Dieses Schema erlaubt der alten Basisstation, die für den mobilen Knoten bestimmten Pakete an den neuen Aufenthaltsort des mobilen Knotens weiterzuleiten.
  • Wenn kein Verkehr vorhanden ist und der mobile Knoten noch nicht frei ist, muß der Knoten die Wegaktualisierungsnachrichten übermitteln. Diese Nachrichten werden an den DRR verbreitet und an jedem Router auf seinem Weg werden die Routingeinträge aufgefrischt.
  • Die Correspondent Nodes senden Pakete an die Heimatadresse des mobilen Knotens. Der Heimatagent fängt diese Pakete ab und erzeugt einen Tunnel unter Verwendung der Co-located Care-of-Adresse des mobilen Knotens. Wenn die Pakete an dem DRR ankommen, werden sie auf eine Hop-by-Hop-Weise weitergeleitet. An dieser Stelle verwendet jeder Hop die Routingeinträge, die vorher durch den MN aktualisiert wurden. Dieses Protokoll ist außerdem mit einer Unterstützung für Paging erweitert.
  • Die allgemeinen Charakteristika von HAWAII sind wie folgt:
    • • Definiert eine Zweiebenenhierarchie entlang den Domänengrenzen und definiert separate Mechanismen für Interdomänen- und Intradomänenmobilität. Eine eindeutige Co-located Care-of-Adresse wird dem mobilen Host zugewiesen, um problemlose QoS-Unterstützung bereitzustellen.
    • • Spezielle Wege werden aufgebaut, um die Ende-zu-Ende-Konnektivität aufrechtzuerhalten, wenn sich der mobile Host bewegt. Diese Wege werden verwendet, um das Hop-by-Hop-Routing von Paketen bereitzustellen.
    • • Soft-State-Mechanismen werden verwendet, um einen Grad der Toleranz gegenüber Router- oder Verbindungsstörungen innerhalb des Netzwerkes bereitzustellen.
    • • In Abhängigkeit von der Fähigkeit des mobilen Hosts werden zwei verschiedene Schemata für problemlose Verbindungsübergaben bereitgestellt. Ein Nichtweiterleitungsschema (Non Forwarding Scheme) für mobile Knoten, die Daten gleichzeitig von zwei verschiedenen Basisstationen empfangen können, und ein Weiterleitungsschema (Forwarding Scheme) für Knoten, die Daten nur von einer Basisstation zu einem Zeitpunkt empfangen können.
  • Terminologie, die in HAWAII verwendet wird
  • Heimatdomäne (Home Domain)
  • Das ist die Domäne, zu der ein mobiler Knoten gehört.
  • Fremddomäne (Foreign Domain)
  • Jede Domäne, die der mobile Knoten besucht und nicht seine Heimatdomäne ist.
  • Domänen-Root-Router (Domain Root Router)
  • Der Domänen-Root-Router ist der Gateway zu einer Domäne.
  • Aktualisierungsnachrichten (Update Messages)
  • Das sind Nachrichten, die durch die Basisstation an die Router netzaufwärts gesendet wurden, um die Einträge eines mobilen Knotens zu aktualisieren, wenn eine Verbindungsübergabe vorkommt oder periodisch (unter Verwendung einer Lebensdauer).
  • Prinzipien
  • Der Gateway in jede Domäne wird als Domänen-Root-Router bezeichnet. Jeder Host weist eine IP-Adresse und eine Heimatdomäne auf. Eine Domäne kann ein Gebiet abdecken, das einige hundert Basisstationen einschließt, dadurch die Wahrscheinlichkeit erhöhen, daß der mobile Host innerhalb seiner Heimatdomäne ist. Die Arbeit des Heimatagenten wird sehr reduziert.
  • Wenn sich ein mobiler Knoten (mobile node/MN) in eine Fremddomäne bewegt, kommen die gewöhnlichen mobilen IP-Konzeptionen ins Spiel. Jedem mobilen Host wird eine eindeutige Care-of-Adresse zugewiesen und die Adresse ist beim Bewegen innerhalb der Fremddomäne unverändert. Der Heimatagent tunnelt die Pakete an die Care-of-Adresse. Der Heimatagent wird von den Bewegungen innerhalb der Fremddomäne nicht benachrichtigt und die Konnektivität wird unter Verwendung von dynamisch aufgebauten Wegen in der Fremddomäne aufrechterhalten.
  • Ablauffolge – Einschalten
    • • Die Basisstation ermittelt, ob der MN zuhause oder in einer Fremddomäne ist, durch Vergleichen der Netzzugangskennung (network access identifier/NAI), die zusammen mit der Registrierungsanforderung mit der NAI der aktuellen Wireless-Domäne gesendet wurde. Wenn das Mobiltelefon zuhause ist, muß die Basisstation einen Routeneintrag in jedem Knoten bis zu dem Domänen-Root-Router anlegen. Andernfalls muß die Basisstation die Registrierungsanforderung an den Heimatagenten weiterleiten und einen Routeneintrag in jedem Knoten bis zu dem Domänen-Root-Router anlegen.
    • • Die Pakete von einem Correspondent Node (CN) werden an das Heimatnetz des MN gesendet.
    • • Die Pakete werden durch den HA abgefangen und dann an den MN unter Verwendung der Co-located Care-of-Adresse (CCOA) getunnelt. Wenn die Pakete die Wireless-Domäne erreichen, werden sie unter Verwendung der vorher angelegten Hop-by-Hop-Routeneinträge geroutet.
  • Ablauffolge – Intradomänenbewegung (Nichtweiterleitung)
    • • Beim Empfangen einer Registrierungsanforderung von einem MN rechnet die Basisstation (BS) die alte Basisstation aus, da der MN die vorherige Fremdagenterweiterung zusammen mit der Registrierungsanforderung senden muß.
    • • Wenn die Bewegung eine Intradomänenbewegung war, dann würde die BS eine Hawaii-Aktualisierungsnachricht den ganzen Weg zu der alten BS hin senden, indem der Cache von allen Routern auf dem Weg zwischen der neuen BS und der alten BS aktualisiert wird.
    • • Die alte BS sendet dann eine Bestätigung zurück an die neue BS.
  • Die obenerwähnten Operationen werden durchgeführt, um die problemlose Verbindungsübergabe bereitzustellen.
  • Ablauffolge – Intradomänen-Verbindungsübergabe (Intra-Domain Handoff)
    • • Die durch den CN gesendeten Pakete werden an das Heimatnetz des MN gesendet, der Heimatagent fängt diese Pakete ab und tunnelt sie an die CCOA. Der DRR sendet dann die Pakete netzabwärts durch die entsprechende Schnittstelle auf einer Hop-by-Hop-Basis.
    • • Der Crossover-Router leitet dann die Pakete an den nächsten Hop-Router durch die Schnittstelle gemäß dem HAWAII-Eintrag.
  • Cellular IP [CIP]
  • Übersicht
  • Cellular IP ist bestimmt, um das Routing von IP-Datagrammen an einen mobilen Host zu ermöglichen. Das Protokoll zusammen mit mobilem IP ist bestimmt, um Weitverkehrs-Mobilitätsunterstützung bereitzustellen. Cellular IP ist entworfen worden, um auf einer lokalen Ebene wie in einem Campus- oder Großstadtnetz verwendet zu werden.
  • Cellular IP ist HAWAII ähnlich, da es auf einem Hop-by-Hop-Prinzip aufbaut, um den Verkehr innerhalb der Wireless-Domäne abzuwickeln. Die Protokolle unterschieden sich in der verwendeten Terminologie, den Nachrichten und ihrer Wechselwirkung mit Mobile IP. Der CIP-Gateway steuert den Verkehr, der an die CIP-Domäne geleitet wird und von ihr abgeht. Der CIP-Gateway schließt zwei Subkomponenten ein: den Gateway-Controller und das Gateway-Filter.
  • Der Gateway-Controller (GC) empfängt Pakete, die in der Regel Aktualisierungspakete sind, die durch den Gateway verwendet werden, um die Aufenthaltsorte des MN zu aktualisieren und dann fallengelassen werden. Das Filter (GPF) prüft, um zu sehen, ob Pakete, die von innerhalb der Domäne kommen, an den GC zu senden oder im Internet weiterzuleiten sind. Eines der primären Merkmale dieses Protokolls ist die Unterscheidung, die zwischen freien und aktiven Knoten gemacht wird, und die Unterstützung für Paging.
  • Terminologie
  • Cellular IP-Knoten (Cellular IP Node)
  • Ein zellulares IP-Netz setzt sich aus miteinander verbunden Cellular IP-(CIP-)Knoten zusammen. Die Knoten routen Pakete innerhalb des Cellular IP-Netzes und kommunizieren über drahtlose Schnittstelle mit mobilen Hosts.
  • Gateway-Controller (Gateway Controller)
  • Der Gateway-Controller (GC) empfängt Pakete, die in der Regel Aktualisierungspakete sind, die durch den Gateway verwendet werden, um die Aufenthaltsorte des MN zu aktualisieren und dann fallengelassen werden.
  • Gateway-Paketfilter (Gateway Packet Filter)
  • Das Filter (GPF) prüft, um zu sehen, ob Pakete, die von innerhalb der Domäne kommen, an den GC zu senden oder im Internet weiterzuleiten sind.
  • Cellular IP-Gateway (Cellular IP Gateway)
  • Er setzt sich aus einem GC, CIP-Knoten und GPF zusammen.
  • Steuerpaket (Control Packet)
  • Ein Routenaktualisierungs- und Paging-Aktualisierungspaket.
  • Paging-Cache (Paging Cache)
  • Ein durch einige Cellular IP-Knoten verwalteter Cache, der verwendet wird, um Pakete an mobile Hosts zu routen.
  • Mängel von HAWAII und CIP
  • Die in den vorherigen Abschnitten beschriebenen Lösungen ermöglichen die Unterstützung der Mikromobilität. HAWAII erfordert, daß der mobile Knoten ein Agent-Advertisement empfängt, wie in Mobile IP definiert ist, bevor er imstande ist, die Routingeinträge entlang dem Weg von dem DRR zu dem letzten Router zu aktualisieren. Die Latenzzeit, die am Aktualisieren der Zwischenrouter von der BS zu dem DRR nach einer Verbindungsübergabe beteiligt ist, braucht nicht mit den Anforderungen für Echtzeit-Anwendungen in Übereinstimmung sein. CIP auferlegt Modifikationen auf Mobile IP an dem mobilen Knoten und die Implementierung von CIP an jedem mobilen Knoten, was strenge Einschränkungen und ein Nachteil der Lösung sind. Beide Protokolle können Skalierbarkeitsproblemen gegenüberstehen, wenn sie über zellulare Infrastruktur angewendet werden, wo die Anzahl der Benutzer sehr groß sein könnte.
  • Aufenthaltsverwaltung (Location Management) und Routing
  • CIP verwendet zwei parallele Cachesysteme, um die Informationen zu speichern, die den Aufenthaltsort von mobilen Hosts betreffen. Mappings für aktive Hosts werden in dem Routing-Cache aufrechterhalten, der einen kleinen Timeout-Wert verglichen mit dem Timeout in dem Paging-Cache aufweist. Für einen Host, der die Verbindungsübergabe häufig durchführt, werden Mappings an dem Routing-Cache aufrechterhalten. Da die Timeout-Werte des Routing-Caches sehr klein sind, läuft es auf das Entleeren des Eintrags für ein Mobiltelefon aus dem Routing-Cache eines Knotens hinaus. Folglich würden Pakete nicht an die alte Adresse des mobilen Hosts gesendet werden, was zu weniger Verschwendung von Ressourcen führt. Ein freier Host sendet weniger Aktualisierungspakete, da die Timeout-Werte für den Routing-Cache größer sind.
  • Funktionen des Cellular IP
  • Aufenthaltsverwaltung
  • Paging-Aktualisierungspakete werden durch freie Hosts gesendet, um die Paging-Cache-Mappings zu aktualisieren, um den aktuellen Aufenthaltsort widerzuspiegeln, aber nicht die Routing-Cache-Mappings zu modifizieren. Paging-Aktualisierungspakete werden verworfen, wenn sie einmal den Gateway erreichen, um zu verhindern, daß Cellular IP-spezifische Steuerungsoperationen das Internet erreichen.
  • Wenn ein IP-Paket an einem Zellularknoten eintrifft, der an einen mobilen Host adressiert ist, für den kein aktualisiertes Routing-Cache-Mapping zur Verfügung steht, wird dann das Mapping in dem Paging-Cache verwendet, um das Paket zu routen. Diese Phase wird als "implizites Paging" bezeichnet.
  • Routing
  • Die durch mobile Hosts gesendeten Pakete werden an den Gateway unter Verwendung des normalen Hop-by-Hop-Routings geroutet, die zellularen IP-Knoten überwachen diese Pakete und aktualisieren ihre Routing-Cache-Einträge mit der Hostadresse und der Schnittstelle, auf der sie eintreffen. Die an den mobilen Host adressierten Pakete werden hop-by-hop umgekehrt durch die Routing-Cache-Mappings geroutet. Die mobilen Hosts, die aktiv sind, aber keine zu sendenden Daten haben, müssen periodische Route-Aktualisierungspakete senden, um sicherzustellen, daß die Route-Caches nicht gelöscht sind. Der Zuverlässigkeit halber können Paging-Caches ebenfalls mobile Hosts einschließen, die ebenfalls durch Routing-Caches eingeschlossen sind.
  • Verbindungsübergabe
  • Der mobile Host löst die Verbindungsübergabe aus. Wenn ein mobiler Host migriert, werden Pakete an die neue Basisstation gelenkt und diese Pakete aktualisieren die Caches entlang ihrem Weg zu dem Gateway. Wenn Knoten vorhanden sind, die beide Wege gemeinsam nutzen, dann werden die alten Mappings aufgefrischt. Die Pakete würden an die alten Basisstationen und an die neue Basisstation für eine Zeit gesendet werden, die gleich dem Timeout der Route-Cache-Mappings ist. Nach dem Ablauf des Timeouts werden die Cache-Einträge für die alten Basisstationen gelöscht.
  • Weitverkehrsmobilität
  • Weitverkehrsmobilität tritt auf, wenn sich ein mobiler Host von einem Cellular IP-Netz zu einem anderen bewegt. Die mobilen Knoten unterscheiden zwischen Cellular IP-Netz durch Verwendung des Cellular IP-Netzkennzeichens, das in den Bakensignalen der Basisstation enthalten ist. Das Bakensignal schließt ebenfalls die IP-Adresse des Gateways ein. Ein mobiler Host kann sofort mit dem Senden von Paging-Aktualisierungspaketen beginnen. Beim Empfangen des ersten Paging-Aktualisierungspakets führt der Gateway die Zugangskontrolle durch, die Gebührenentscheidungen usw. umfassen könnte. Ist einmal die Anforderung akzeptiert worden, kann der mobile Host eine mobile IP-Registrierungsnachricht an seinen Heimatagenten senden, die die IP-Adresse des Gateways als Care-of-Adresse angibt.
  • Vorschlag der Universität Singapur
  • Dieses Schema schlägt vor, eine hierarchische Mobilitätsverwaltungsarchitektur zu verwenden, um die Verarbeitung der Verbindungsübergabe innerhalb der Domäne einzuschränken, und verwendet Multicast als einen Mechanismus, um Pakete an mehrfache Basisstationen zu liefern, um schnelle Verbindungsübergaben zu erreichen.
  • Terminologie
  • Domänen-Fremdagent (Domain Foreign Agent/DFA)
  • Der DFA arbeitet wie ein Gateway in die Domäne. Der DFA führt die ganze Funktionalität durch, wie in Mobile IP erwähnt ist.
  • Dynamische virtuelle Makrozellen (Dynamic Virtual Macrocells/DVMs)
  • Die Basisstationen werden in DVMs logisch organisiert. Die DVMs werden durch Cluster von Basisstationen benachbart zueinander gebildet und können sich sogar überlappen. Jede BS kann zu mehrfachen DVMs gehören, aber jede BS kann nur der Kern von nur einem DVM sein.
  • Prinzipien
  • Der MN registriert sich mit der IP-Adresse des DFA, die im Auftrag des DFA durch die BS rundgesendet wird. Der DFA weist eine Multicastadresse zu, die innerhalb seiner Domäne für den MN eindeutig ist. Der MN informiert die bedienende BS, um diese Multicastadresse zu abonnieren. Die BS teilt der Reihe nach ihren benachbarten BSs mit, um die Multicastgruppe zu abonnieren.
  • Pakete, die für einen MN innerhalb einer Domäne bestimmt sind, werden an den DFA getunnelt, der DFA leitet dann die Pakete an die Multicastadresse des MN weiter. Basisstationen, die die Multicastgruppe abonnierten, empfangen die Datagramme, und nur die BS, die den MN bedient, leitet das Paket den anderen BSs weiter, zwischenspeichert sie nur.
  • Ein bedeutsamer Nachteil dieses Verfahrens ist die Verwaltung dessen, wer der Kern ist, jedesmal wenn es eine Verbindungsübergabe gibt.
  • Hierarchische Mikromobilität
  • Terminologie
  • In diesem vorgeschlagenen Mikromobilitätsschema besteht das Mobilitätsverwaltungsprotokoll aus drei Komponenten:
  • Zugriffsmobilitätsverwaltungsprotokoll (Access Mobility Management Protocol)
  • Es spezifiziert die Registrierungsprozeduren zwischen dem MN und der Domäne, mit der es verbunden ist, und ist unabhängig von den Mikro- und Makromobilitätsverwaltungsprotokollen, die in dem Kern des Netzwerks verwendet werden.
  • Mikromobilitätsverwaltungsprotokoll (Micro-mobility Management Protocol)
  • Es befaßt sich mit der lokalen Mobilität innerhalb der Domäne.
  • Makromobilitätsverwaltungsprotokoll (Macro-mobility Management Protocol)
  • Es ist das Protokoll, das sich mit der Makromobilität (interdomän) des MN befaßt; Mobile IP wird verwendet, um Makromobilität zu erreichen.
  • Prinzipien
  • Der Vorschlag basiert auf dem Einsatz von Mobilitätsunterstützungen (Mobility supports/MS). Eine MS ist ein Router oder Satz von Routern, der ein Binding pro mobilen Knoten aufrechterhält, die zur Zeit die Domäne besuchen, und ebenfalls die Aufgabe des Sendens von Bind-Updates im Auftrag des MN durchführt. Typische Funktionen einer MS umfassen:
    • • durch den MN gesendete Prozeßregistrierungsnachrichten (Process Registration Messages)
    • • Senden von Binding-Updates an den CN und den HA des MN
    • • Abfangen und Umleiten der an den MN adressierten Pakete
  • Ablauffolge: Betreten einer neuen Domäne (Interdomänbewegung)
    • • Ermittelt eine CoA (auch bezeichnet als Physikalische CoA (PcoA)) und registriert sich mit der Mobilitätsunterstützung durch Senden seiner Heimatadresse, Adresse des Heimatagenten, PcoA und der Adresse seiner vorherigen Mobilitätsunterstützung (MS_p) in der vorherigen Domäne. Die Registrierung wird durch die Mobilitätsunterstützung bestätigt.
    • • Beim Empfangen einer Registrierungsnachricht von dem MN weist die MS eine virtuelle CoA (Virtual VCoA) für den MN zu und registriert sich bei seinem HA im Auftrag des MN. Dann bestätigt sie den Empfang der Registrierungsnachricht, die durch den MN gesendet wurde, und die Bestätigung beinhaltet die VCoA.
    • • Nach den obenerwähnten Operationen bittet die MS die MS_p, alle Pakete, die an den MN adressiert sind, an sie umzuleiten. MS_p muß diese Anforderung bestätigen und die Liste der CN und die Liste der Folgenummern der neuesten gesendeten Binding-Updates senden.
    • • Legt einen Eintrag an, der das Binding zwischen der Adresse des MN, seinem HA, VcoA und der Liste der CNs und Folgenummern beinhaltet.
    • • Sendet ein Binding-Update an jeden CN.
    • • MS erzeugt dann ein Binding zwischen der PcoA und VcoA des MN, das durch die MS verwendet wird, um Pakete umzuleiten, die an ihren aktuellen Anschlußpunkt adressiert sind.
  • Ablauffolge: Intradomänenbewegung
  • Wenn sich ein MN innerhalb einer Domäne (von der Versorgung von einer BS zu einer anderen) bewegt, dann registriert der MN seinen neuen Anschlußpunkt bei der MS. Die MS aktualisiert anschließend den Binding-Eintrag für den MN durch Ersetzen der vorhandenen PCoA durch die neue PCoA. Könnte ebenfalls Binding-Updates an die lokalen CNs des MN senden.
  • Datenfluß
  • Die durch einen Correspondent Node gesendeten Datagramme werden durch den HA des MN abgefangen und an die VCoA des MN weitergeleitet. Die MS fängt diese Pakete ab und tunnelt sie an die PCoA. Die MS sendet (Heimatadresse, Grenzrouter) Bind-Update-Nachrichten an jeden der CNs. Die CNs aktualisieren beim Empfangen dieser Nachrichten den Eintrag des MN und senden die ankommenden Pakete an die aktuelle PCoA des MN.
  • Multicasting-basierte Architektur für Internet-Host-Mobilität
  • Dieser Vorschlag verwendet IP-Multicasting als einen Mechanismus, um die Mobilität zu erreichen. Jedem mobilen Knoten wird eine Multicastadresse statt einer Unicastadresse ausgegeben. Es ist keine Konzeption des Heimatagenten/Fremdagenten vorhanden. Die Multicastadresse wird zusammen mit Aufenthaltsservern (Location Servers) und Multicastroutern verwendet, um die Mobilität zu erreichen. Es ist keine Lösung des Problems der Mikromobilität. Es ist das Protokoll, das Mobile IP abfragt.
  • Terminologie
  • Aufenthaltsserver (Verteiltes Verzeichnis)
  • Diese sind Server, die das Binding zwischen der Multicastadresse von einem MN und dem Multicastrouter, der den MN bedient, speichern. Jeder MN ist für das periodische Aktualisieren seines Aufenthaltsortsservers periodisch mit Informationen über den Multicastrouter (Multicast Router/MR) verantwortlich, der ihn bedient.
  • Basisstation
  • Zusätzlich zu den normalen Fähigkeiten der Basisstation weist in diesem Schema jede Basisstation ebenfalls die Fähigkeit auf, wie ein MR zu arbeiten.
  • Prinzipien
  • Wenn ein CN Datagramme sendet, die für einen MN bestimmt sind (der eine Multicastadresse aufweist), nimmt der Multicastrouter (MR_CN) innerhalb des Netzwerks die Datagramme auf und überprüft einen Aufenthaltsserver auf Informationen bezüglich des MN. Der ausgewählte Aufenthaltsserver ist von der Multicastadresse des MN abhängig.
  • Beim Erhalten der Adresse des Multicastrouters (MR_MN), der den MN bedient, setzt sich der MR_CN mit dem MR_MN in Verbindung und schließt sich der Multicastgruppe an und leitet die Datagramme weiter.
  • Jeder MR, der die Datagramme empfängt, enttunnelt die Datagramme und leitet sie an den MN weiter.
  • Bevor sich der MN von der Versorgung von einem Multicastrouter zu einem anderen bewegt, fordert der MN den MR innerhalb des neuen Netzwerks an, sich der Multicastgruppe anzuschließen. Folglich empfängt der MN ununterbrochen Pakete.
  • Folglich empfängt der vorherige MR und der neue MR des MN die Pakete, aber der vorherige MR würde aufhören, Datagramme nach einer bestimmten Zeitdauer zu empfangen.
  • MÄNGEL IM STAND DER TECHNIK
  • Während die folgende Aufzählung nicht als Einschränkung des Anwendungsbereiches der vorliegenden Erfindung in irgendeiner Weise angesehen werden sollte, gewährt sie einen Einblick in die Mängel des Standes der Technik, die in einigen beispielhaften Ausführungsformen durch die vorliegende Erfindung korrigiert werden können:
    • • Cellular IP bedeutet, daß der mobile Knoten dieses Protokoll implementiert. Das ist ein großer Nachteil, da es ein Update jedes Knotens erfordert, um imstande zu sein, das genannte Protokoll zu nutzen. Außer diesem wichtigen Punkt kennt dieses Protokoll im Detail nicht, wie der mobile Knoten erfahren sollte, ob er ein herkömmliches Schema (d.h. mobiles IP) oder das zellulare Schema verwenden sollte.
    • • Cellular IP und HAWAII verwenden beide ein Hop-by-Hop-Routingprotokoll, was die Verwaltung von riesigen Routingtabellen beim Einsatz in einem großen Netzwerk erfordert (z.B. Zellularnetz, in dem die Benutzer in Millionen gezählt werden). Dieses spezifische Problem bedeutet ebenfalls, daß alle Knoten in der Wireless-Domäne eine spezielle Software integrieren müssen, folglich können Standardkomponenten nicht verwendet werden.
    • • HAWAII unterstützt nicht das Care-of-Adreßschema der Fremdadresse, das in mobilem IP angeboten wird. Dann wieder erfordert HAWAII die Verwendung der Co-located Care-of-Adresse. Dieses Prinzip erfordert, daß der Betreiber eine riesige Anzahl von IP-Adressen verwaltet, da er eine IP-Adresse pro Benutzer zuweisen muß. In Anbetracht des Problems, daß IPv4 bereits einen Mangel der Adresse aufweist, bedeutet dann der Vorschlag ebenfalls, daß das Netzwerk entweder ein privates Adressenschema ausführt oder IPv6 verwendet.
    • • Der in Singapur gemachte Vorschlag bedeutet, daß der mobile Knoten die Multicastadresse zusammen mit der Registrierungsanforderung an die neue Basisstation sendet. Das modifiziert das Protokoll auf jedem einzelnen mobilen Knoten.
    • • Das vereinheitlichte hierarchische Modell bedeutet, daß sich die Mobilitätsunterstützung auf dem mobilen Knoten im Namen des Heimatagenten registriert. Das Schema verursacht ein schwerwiegendes Sicherheitsproblem. Es modifiziert ebenfalls die mobile IP-Spezifikation durch Ändern der Registrierungs-PDU. Und schließlich muß der mobile Knoten die IP-Adresse der Basisstation haben, mit der er vorher verbunden war.
    • • Die obenerwähnten Lösungen unterstützen ein Schema wie zum Beispiel "make before break (unterbrechungslos)" nicht, was für Voice-over-IP-Anwendungen unentbehrlich ist.
    • • Der letzte Vorschlag weist mehrere Nachteile auf. Es ist eine Beschränkung in der Anzahl der eindeutigen Class-D-Adressen vorhanden, die jedem einzelnen MN in IPv4 zugewiesen werden können. Es erfordert, daß jeder Router in einem Subnetz mobilitätskompatibel ist. Bevor sich ein MN unter eine neue Versorgung bewegt, kann er den MR innerhalb dieses Gebiets von einer möglichen Verbindungsübergabe informieren und den MR anfordern, sich der Multicastgruppe anzuschließen. Folglich muß der MN die Adresse des benachbarten MR kennen, und ebenfalls den Overhead, der an diesem MN beteiligt ist, jedesmal wenn er eine Verbindungsübergabe durchführt. Die Skalierbarkeit der Verwendung eines Aufenthaltsservers ist etwas, was nicht sehr klar ist.
  • Ein Fachmann kann imstande sein, diese Liste zu erweitern, aber sie dient dazu, um anzugeben, daß der Stand der Technik technische Probleme aufweist, die noch durch jedes Mobile IP-Protokoll anzugehen sind.
  • Aufgaben der Erfindung
  • Entsprechend sind (unter anderen) die Aufgaben der vorliegenden Erfindung, die Mängel im Stand der Technik zu umgehen und das Folgende zu beeinflussen:
    • (1) Die Mobilität der mobilen Knoten zu erhöhen, während eine IP-Verbindung aufrechterhalten wird.
    • (2) Den Routingoverhead zu verringern, der mit den aktuellen IP-Routingprotokollen verbunden ist.
    • (3) Allgemein die Mängel von vorhandenen Makromobilitätsprotokollen zu überwinden.
  • Während diese Aufgaben nicht verstanden sollten, um die Lehren der vorliegenden Erfindung einzuschränken, werden im Allgemeinen diese Aufgaben teilweise oder ganz durch die offenbarte Erfindung erreicht, die in den folgenden Abschnitten diskutiert wird. Ein Fachmann wird zweifellos imstande sein, Aspekte der vorliegenden Erfindung auszuwählen, wie offenbart ist, um jede Kombination der oben beschriebenen Aufgaben zu beeinflussen.
  • Kurzdarstellung der Erfindung
  • Die Erfindung löst diese Aufgaben durch ein Verfahren nach Anspruch 1, durch ein Medium nach Anspruch 11 und durch ein System nach Anspruch 21.
  • Multicast-Mikromobilitäts-Protokoll (Multicast Micro-Mobility/MMM)
  • Das MMM-Protokoll nutzt IP-Multicast, um schnelle Verbindungsübergaben zu erreichen. Die Basisstationen, wie durch das Protokoll definiert, sind nicht bloß passive Bridges, sondern weisen eine aktive Teilnahme in dem Funktionieren des Protokolls auf. Effiziente Verbindungsübergaben können erreicht werden, wenn Trigger von der Sicherungsschicht verwendet werden, um Verbindungsübergaben der Vermittlungsschicht durchzuführen. Alle Router innerhalb der Wireless-Domäne sind erforderlich, um das IP-Multicastrouting zu unterstützen.
  • Der Hauptzugriffsrouter (Main Access Router/MAR) dient als der Gateway zu der Wireless-Domäne und unterstützt Mobile IP. Der MAR kann als ein Fremdagent und/oder ein Heimatagent dienen. Der MAR verarbeitet die durch einen MN gesendeten Registrierungsanforderungen und verarbeitet ebenfalls die BSR-Erweiterungen, die an die Registrierungsnachrichten angehängt werden. Der MAR ist auch erforderlich, um eine Multicastadreßerweiterung (MAE) vor dem Weiterleiten der Registrierungsantwort zuzuweisen und einzufügen. Der MAR verwendet zwei Caches, um Knoten innerhalb seiner Domäne zu verwalten. Der Binding-Cache weist Einträge für mobile Knoten auf, die jetzt durch den MAR bedient werden. Der wahrscheinliche Cache weist Einträge für MNs auf, die erwarten, für den Dienst durch den MAR genehmigt zu werden. Sobald der MN für den Dienst genehmigt worden ist, nachdem die notwendigen Kontrollen durchgeführt worden sind und nach dem Empfangen einer Registrierungsantwort von dem HA des MN, wird der MN-Eintrag aus dem wahrscheinlichen Cache zu dem Binding-Cache bewegt. Der MAR implementiert die Erweiterungen wie in der Literatur zu Mobile IP beschrieben ist.
  • Der BSR hängt die BSR-Erweiterung an jede Mobile IP-Registrierungsanforderung an und leitet die Nachrichten an den MAR weiter. Der BSR verarbeitet die Multicastadreßerweiterung, die an der Mobile IP-Registrierungsantwort angehängt ist. Die BSRs senden ebenfalls die periodische Nachricht für Nachbar-Binding-Update (neighbor binding update/NBU) an jeden BSR, der auf seiner Nachbarliste ist. Der BSR verwaltet zwei Caches; der Binding-Cache wird durch den BSR verwendet, um mobile Knoten unter seiner Versorgung zu verwalten, und der wahrscheinliche Cache wird durch den BSR verwendet, um schnelle Verbindungsübergaben für mobile Knoten durchzuführen, die unter der Versorgung von seinen benachbarten BSRs sind. Die Binding-Caches werden durch MNAE-Nachrichten aktualisiert und die wahrscheinlichen Caches werden durch die NBU-Nachricht aktualisiert. Die NBU-Nachricht wird durch die benachbarten BSRs verwendet (die Definition des "benachbarten BSR" wird durch den Netzbetreiber entweder statisch oder dynamisch bestimmt), um ihre wahrscheinlichen Caches zu verwalten. Die Basisstationsrouter (BSR) implementieren die Erweiterungen wie in der bekannten Netzwerk-Literatur beschrieben ist. Hier wird es angenommen, daß jeder BSR die IP-Adresse seiner benachbarten BSRs kennt. (Diese kann ohne weiteres von einem Netzadministrator konfiguriert werden.) Jeder BSR kennt ebenfalls die IP-Adresse seines MAR.
  • Das MMM-Protokoll erweitert das aktuelle Mobile IP-Protokoll mit einem Satz von Nachrichten, die entworfen sind, so daß:
    • • Ein BSR mit seinen benachbarten BSRs kommunizieren kann, der Liste der Informationen des mobilen Knotens, die gegenwärtig unter dem Versorgungsbereich des BSR sind, der die Nachbar-Binding-Erweiterung (Neighbor Binding Extension/NBE) verwendet. Die Nachricht für Nachbar-Binding-Update (NBU) beinhaltet die NBE.
    • • Ein BSR seinem MAR die IP-Adresse des BSR mitteilen kann, der die Mobile IP-Registrierungsanforderung unter Verwendung der BSR-Erweiterung weitergeleitet hat. Die Nachricht der Registrierungsanforderung wird mit der BSR-Erweiterung angehängt.
    • • Ein MAR dem BSR die Multicastadresse mitteilen kann, die einem speziellen MN zugewiesen wurde, nachdem ein MN den Zugang zu dem Netz unter Verwendung der Multicastadreßerweiterung (MAE) gewährt hat. Diese Erweiterung wird an die Mobile IP-Registrierungsantwort angehängt.
    • • Ein BS dem BSR die Charakteristika der Sicherungsschicht eines mobilen Knotens mitteilen kann, der seine Zelle betritt, unter Verwendung einer Mobile Node Advertisement-Erweiterung (MNAE). Die Nachricht KANN mehr als eine MNAE beinhalten.
  • Die folgende Diskussion beschreibt die verschiedenen Phasen, indem ausführlich dargelegt wird, wie diese Erweiterungen zum Erweitern von mobilem IP beitragen, um Mikromobilitätsunterstützung anzubieten. Eine Kurzbeschreibung ist über die Ablauffolge gegeben, wenn ein MN eine Fremddomäne betritt. Dieses Protokoll macht eine Annahme, daß ein einzelner Betreiber vorhanden ist, der das Fremdnetz verwaltet.
  • Protokollerweiterungen
  • Die vorliegende Erfindung erweitert die vorhandenen Mobile IP-Protokolle mit den folgenden Zusätzen:
    • • BSR-Erweiterung – angehängt nach der Registrierungsanforderung des mobilen Knotens und beinhaltet die IP-Adresse des BSR, der die Registrierungsanforderung des mobilen Knotens weiterleitet.
    • • Multicastadreßerweiterung (MAE) – angehängt nach der Registrierungsantwort des Heimatagenten und beinhaltet die Multicastadresse, die für den mobilen Knoten zugewiesen wurde.
    • • Nachbar-Update-Erweiterung (NUE) – Nachricht wird durch einen BSR an seine umliegenden BSRs gesendet, um ihnen die Liste des mobilen Knotens mitzuteilen, der sich gegenwärtig unter dem Versorgungsbereich seines BSR befindet. Die Nachricht wird periodisch gesendet.
    • • Mobile Node Advertisement-Erweiterung (MNAE) – gesendet jedesmal, wenn die Basisstation feststellt, daß ein neuer mobiler Knoten den Versorgungsbereich betreten hat.
  • Nachrichtenerweiterungen
  • Die vorliegende Erfindung erweitert die vorhandenen Mobile IP-Nachrichten mit den folgenden Zusätzen:
    • • Mobile Node Advertisement (MNA) – Eine Basisstation sendet diese Nachricht an ihren BSR jedesmal, wenn die Basisstation feststellt, daß ein neues Mobiltelefon ihren Versorgungsbereich betreten hat. Die Nachricht wird ebenfalls periodisch gesendet, um die Binding-Cache-Einträge in dem BSR aufzufrischen.
    • • Nachbar-Binding-Update (NBU) – Ein BSR, der gegenwärtig einen MN bedient, sendet periodisch NBU-Nachrichten an seine benachbarten BSRs. Die NBU-Nachrichten können NUE für alle MNs seiner Versorgung beinhalten. Wenn ein BSR das NBU von einem benachbarten BSR empfängt, frischt er dann auf oder fügt Informationen der MNs hinzu, die unter der Versorgung seines Nachbars sind. Das ist nur ein teilweises Aktualisieren, weil der BSR die NBUs von allen seinen benachbarten BSRs empfangen muß, damit alle Einträge aufgefrischt oder aktualisiert werden.
  • Mitteilungsprinzipien
  • Das offenbarte MMM-Protokoll erweitert das aktuelle Mobile IP-Protokoll mit einem Satz von Nachrichten, die entworfen sind, so daß:
    • • Ein BSR mit seinen benachbarten BSRs kommunizieren kann, der Liste der Informationen des mobilen Knotens, die gegenwärtig unter dem Versorgungsbereich des BSR sind, der die Nachbar-Update-Erweiterung (Neighbor Update Extension/NUE) verwendet. Die Nachricht für Nachbar-Binding-Update (NBU) beinhaltet die NUE.
    • • Ein BSR seinem MAR die IP-Adresse des BSR mitteilen kann, der die Mobile IP-Registrierungsanforderung unter Verwendung der BSR-Erweiterung weitergeleitet hat. Die Nachricht der Registrierungsanforderung wird mit der BSR-Erweiterung angehängt.
    • • Ein MAR dem BSR die Multicastadresse mitteilen kann, die einem speziellen MN zugewiesen wurde, nachdem ein MN den Zugang zu dem Netz unter Verwendung der Multicastadreßerweiterung (MAE) gewährt hat. Diese Erweiterung wird an die Mobile IP-Registrierungsantwort angehängt.
    • • Ein BS dem BSR die Charakteristika der Sicherungsschicht eines mobilen Knotens mitteilen kann, der seine Zelle betritt, unter Verwendung einer Mobile Node Advertisement (MNA). Die Nachricht KANN mehr als eine MNAE beinhalten.
  • Besuchen einer Fremddomäne
  • Wenn ein MN den Versorgungsbereich eines BSR (oder irgendeines anderen Routers in dieser Domäne) betritt, löst das Sicherungsschichtprotokoll an der BS, die den mobilen Knoten bedient, eine MNAE-Nachricht aus. Die BS informiert ihren BSR über das Eintreffen eines MN unter seiner Versorgung. Die Basisstationen senden periodisch MNAE-Nachrichten an den BSR mit den aufgelisteten MNs unter seiner Versorgung.
  • Der BSR unternimmt einen Schritt auf der Basis des Vorhandenseins der Sicherungsschichtinformationen des MN in seinen Caches. Wenn ein Eintrag für den MN in seinem Binding-Cache vorhanden ist, dann frischt der BSR den Eintrag auf. Wenn ein Eintrag für den MN in seinem wahrscheinlichen Cache vorhanden ist, dann schließt sich der BSR der Multicastgruppe an und überträgt den Eintrag aus dem wahrscheinlichen Cache zu dem Binding-Cache. Wenn keine Einträge in jedem seiner Caches vorhanden sind, dann sendet der BSR eine mobile IP-Agent-Advertisement-Nachricht an den mobilen Knoten.
  • Beim Empfangen des Advertisements sendet der MN eine Registrierungsanforderung an den BSR. Der BSR hängt die BSR-Erweiterung an die Registrierungsanforderung des MN an und leitet sie an seinen MAR weiter. Der MAR, nachdem er alle erforderlichen Kontrollen (AAA-Protokoll, Frage/Antwort und Schlüsselaustausch, NAI usw.) durchgeführt hat, leitet die Registrierungsanforderung ohne die BSR-Erweiterung (diese Erweiterung wird durch den MAR entfernt) an den Heimatagenten des mobilen Knotens weiter.
  • Der MAR legt einen Eintrag in dem anstehenden Cache für den MN mit seiner Heimatadresse und der Adresse des BSR an, der den mobilen Knoten bedient. Für den HA hat es den Anschein, als ob der MAR den MN bereitstellt. Der HA erteilt oder lehnt auf der Basis seiner Richtlinien die Registrierungsanforderung ab. Wenn der HA die Anforderung erteilt, dann sendet er eine Registrierungsantwort an den MAR mit den entsprechenden Flags.
  • Wenn der MN eine Registrierungsanforderung auslöst und sich in eine neue Zelle bewegt, die mit einem neuen BSR verbunden ist, wird der vorher beschriebene Mechanismus eine zweite Registrierungsanforderung auslösen. Der neue BSR verarbeitet die Registrierungsanforderung wie vorher beschrieben (der BSR hängt die BSR-Erweiterung an die Registrierungsanforderung an). Der MAR, der die Registrierung des MN empfängt, kontrolliert seinen anstehenden Cache auf Einträge. Wenn ein Eintrag vorhanden ist, wird der MAR folgern, daß sich der MN unter einen anderen Versorgungsbereich des BSR bewegt hat, während der Heimatagent des mobilen Knotens die vorherige Registrierungsanforderung verarbeitet. Der MAR leitet die neue Registrierungsanforderung nicht an den Heimatagenten des MN weiter. Der MAR aktualisiert den anstehenden Cache, um die neue BSR-Adresse widerzuspiegeln.
  • Wenn der MAR eine Registrierungsantwort von dem HA empfängt, bewegt er den Eintrag für den MN aus dem wahrscheinlichen Cache zu dem Binding-Cache und weist eine Multicastadresse dem MN zu. Die Registrierungsantwort wird dann an den BSR zusammen mit der angehängten MAE weitergeleitet. Der BSR entfernt die MAE und leitet die Registrierungsantwort an den MN weiter. Er legt ebenfalls einen Eintrag an, der das Binding der Multicastadresse mit dem MN herstellt.
  • Der aktuelle BSR des MN informiert periodisch seine benachbarten BSRs über die neu angelegten Bindings von MNs innerhalb seiner Versorgung unter Verwendung einer NBU-Nachricht. Diese Nachricht schließt die Heimatadresse des MN, seine CoA, die Adresse des HA, die Multicastadresse, Sicherungsschichtinformationen und die Lebensdauer der Registrierung für jeden MN innerhalb seiner Versorgung ein. Die NBU-Nachricht frischt teilweise die Einträge des wahrscheinlichen Caches auf. Es ist ein teilweises Auffrischen, weil der Cache gänzlich nur aufgefrischt wird, nachdem der BSR jede NBU-Nachricht von jedem seiner benachbarten BSRs empfangen hat.
  • Die Basisstationen senden periodisch die Advertisement-Nachricht des mobilen Knotens an ihre BSR (die Periodizität ist nicht definiert worden), um die Bindings aufzufrischen. Die Advertisement-Nachricht des mobilen Knotens frischt teilweise die Binding-Cache-Einträge des BSR auf. Es ist ein teilweises Auffrischen, da der Cache gänzlich nur aufgefrischt wird, nachdem der BSR die Advertisement-Nachricht des mobilen Knotens von jeder der Basisstationen unter seiner Versorgung empfangen hat.
  • Wenn sich der MN zu einer anderen BS bewegt, die mit der gleichen BSR verbunden ist, sendet die BS sofort eine Advertisement-Nachricht des mobilen Knotens mit den Sicherungsschichtinformationen des MN.
  • Wenn sich der MN zu einer Zelle bewegt, die mit einem verschiedenen BSR als den ihn bedienenden verbunden ist, dann informiert die neue BS den neuen BSR über das Vorhandensein des MN durch Senden einer Advertisement-Nachricht des mobilen Knotens. Wenn der BSR einen Eintrag in seinem wahrscheinlichen Cache aufweist, der die durch die BS gegebenen Sicherungsschichtinformationen mit denjenigen in dem wahrscheinlichen Cache gefundenen verknüpft, dann sendet er eine Verbindungsnachricht (join message) an den MAR (die anfordert, sich der Multicastgruppe anzuschließen). Inzwischen bewegt der alte BSR, der keine Advertisement-Nachricht des mobilen Knotens von mindestens einer seiner Basisstationen empfängt, die den Binding-Cache-Eintrag des MN auffrischen, dann den Binding-Eintrag für den MN zu seinem wahrscheinlichen Cache in der Annahme, daß sich der mobile Knoten zu seinem Nachbar bewegt hat.
  • Care-of-Adresse
  • Das vorgeschlagene Protokoll stellt keine spezielle Anforderung an den Typ der durch den MN verwendeten Care-of-Adresse. Diese Adresse kann entweder die Care-of-Adresse eines Fremdagenten oder eine Co-located Care-of-Adresse sein.
  • Der MAR sollte verlangen, daß alle BSRs das 'R'-Bit in den Agent-Advertisement-Nachrichten setzen, die nach dem Empfangen einer Advertisement-Nachricht des mobilen Knotens gesendet werden.
  • Wenn sich der MN mit einer Co-located Care-of-Adresse registriert, hängt der BSR die BSR-Erweiterung an die Registrierungsanforderung an. Der MAR verarbeitet die Registrierung und entfernt die BSR-Erweiterung. Der MAR weist ebenfalls eine Multicastadresse zu.
  • Der MN hängt die Multicastadreßerweiterung an die Registrierungsantwort an. Der einzige Unterschied ist in der Verkehrsverwaltung, d.h. welcher Knoten den Tunnel entfernt und das Paket an sein mobiles Ziel weiterleitet.
  • Verkehrsfluß
  • Wenn sich der Correspondent Node (CN) außerhalb der Fremd-Wireless-Domäne befindet, werden die an einen MN gesendeten Datenpakete an seine Heimatadresse adressiert (außer wenn Route 9 Optimierung verwendet wird). Der Heimatagent fängt diese Datagramme ab und tunnelt sie an die Care-of-Adresse (CoA) des MN. Die CoA ist die IP-Adresse des MAR. Der MAR prüft beim Empfangen der getunnelten Pakete, um zu sehen, ob ein gültiger Binding-Cache-Eintrag für den MN vorhanden ist. Wenn der MAR einen gültigen Eintrag für den MN aufweist, dann enttunnelt er die Pakete und erzeugt einen neuen Tunnel. Die IP-Adresse des MAR wird als die Quelladresse der getunnelten Pakete gesetzt, die Zieladresse ist die Multicastadresse, die dem MN zugewiesen wurde. Die Pakete werden dann durch diesen Tunnel gesendet. Jeder BSR, der die Multicastgruppe abonniert hat, empfängt eine Kopie und enttunnelt die Pakete und nur der BSR, der einen Binding-Cache-Eintrag für den MN aufweist, leitet die Pakete an den MN weiter. Die BSRs, die keinen Binding-Cache-Eintrag für den MN aufweisen, verwerfen die Pakete, auch wenn sie einen Eintrag für den MN in ihrem wahrscheinlichen Cache aufweisen können.
  • Bewegung innerhalb einer Fremddomäne
  • Wenn ein MN eine neue Zelle betritt (innerhalb der gleichen Fremddomäne, die er besucht), muß die BS den BSR über das Vorhandensein des MN informieren. Sie muß eine Advertisement-Nachricht des mobilen Knotens senden, die die Sicherungsschichtinformationen des MN einschließt. Zwei Szenarien können vorhergesehen werden. In dem ersten Fall bewegt sich der MN zu einer neuen BS, bleibt aber unter der Versorgung des gleichen BSR (die alte und die neue Basisstation werden durch den gleichen BSR bedient), dann ist keine Aktion erforderlich. In dem zweiten Fall bewegt sich der MN unter der Versorgung eines BSR, der von der alten BSR verschieden ist (sehr wahrscheinlich, daß ein Eintrag für den MN in dem wahrscheinlichen Cache vorhanden sein würde), dann muß der neue BSR sofort die Multicastgruppe abonnieren. Der neue BSR sendet ebenfalls ein NBU an seine benachbarten BSRs und wenn der alte BSR einer unter den benachbarten BSRs ist, dann würde er den Eintrag für den MN aus dem Binding-Cache zu dem wahrscheinlichen Cache bewegen.
  • Unterbrechungslos (Make-Before-Break)
  • Die Option Make-Before-Break (MBB) erfordert, daß die benachbarten BSRs eines bedienenden BSR die Diffusionsgruppe abonnieren, sobald sie die NBU-Nachricht empfangen. Diese Option erfordert ebenfalls, daß die benachbarten BSRs (die einen Eintrag in ihrem wahrscheinlichen Cache und keinen Eintrag in dem Binding-Cache aufweisen) alle ankommenden Multicastpakete filtern und verwerfen. Das Filtern wird angehalten, wenn ein BSR ein Advertisement des mobilen Knotens von einer seiner Basisstationen für einen speziellen MN empfängt.
  • Unter Verwendung der normalen Betriebsweise sendet der BSR eine Verbindungsnachricht nur nachdem ein MN seine Versorgung betreten hat, diese Verzögerung (abhängig davon, wie hoch der MAR in der Topologie angeordnet ist) und die Verarbeitungsverzögerung an dem MAR werden eingebracht. Unter Verwendung der Option MBB hätten sich die benachbarten BSRs der Gruppe vor dem Eintrag des mobilen Knotens innerhalb seiner Versorgung angeschlossen und folglich wird die Verzögerung nicht eingebracht. Die Option Make-Before-Break (MBB) ist bestimmt, um die Latenzzeit zu eliminieren, die während des Verbindungsvorganges eingebracht wurde.
  • Make-Before-Break innerhalb einer Fremddomäne ist allgemein in 6 erläutert (0600).
  • Beispielhafte Vorteile
  • Während die folgende Aufzählung nicht als Einschränkung des Anwendungsbereiches der vorliegenden Erfindung in irgendeiner Weise angesehen werden sollte, gewährt sie einen Einblick in einige Merkmale und Vorteile der vorliegende Erfindung, die sie in einigen beispielhaften Ausführungsformen von dem Stand der Technik unterscheiden können:
    • • Der Hauptvorteil des Protokolls ist die niedrige Latenzzeit, die in das Aufbauen einer Vermittlungsschichtverbindung eingebracht wird, dies wird durch Nutzen der durch die Sicherungsschicht angebotenen Trigger erreicht, wenn eine Verbindungsübergabe vorkommt.
    • • Der andere Vorteil ist die Reibungslosigkeit der Verbindungsübergabe, die dieses Protokoll bietet. Die problemlose Verbindungsübergabe erfolgt infolge des durch das Protokoll angebotenen Make-Before-Break und das wird durch Nutzen der Multicastingverfahren erreicht. Das hierin beschriebene Protokoll der vorliegenden Erfindung bietet eine neue Lösung für das schwierige Problem der Mikromobilität an. Es sind mehrere Vorteile vorhanden, die dieses Protokoll im Vergleich zu anderen vorher erwähnten Lösungen bietet.
    • • Das Protokoll der vorliegenden Erfindung ist völlig transparent zu dem mobilen Knoten, der die Wireless-Domäne nicht merkt und den BSR wie einen "Pseudo"-Fremdagenten sieht. Die Verwendung von Multicast ermöglicht den Einsatz eines "Make-Before-Break"-Merkmals, das die Vorteile im Fall von "Echtzeit"-Verkehr wie zum Beispiel Voice-over-IP präsentiert, obgleich es wichtig ist zu beachten, daß der Vorteil seine eigenen Nachteile aufweist. Der Nachteil ist der "nutzlose" Verkehr, der an die BSRs erzeugt wird, die keinen MN bedienen.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Für ein vollständiges Verstehen der durch die Erfindung bereitgestellten Vorteile sollte auf die folgende detaillierte Beschreibung zusammen mit den beigefügten Zeichnungen verwiesen werden, in denen darstellen:
  • 1 – vorhandene Heimat-/Fremdknoten-IP-Vernetzung des Standes der Technik;
  • 2 bis 8 – eine typische Topologie, wie das System und Verfahren der vorliegenden Erfindung auf vorhandene Heimat-/Fremd-IP-Netzroutingtopologien angewandt werden;
  • 9 bis 12 – beispielhafte Datenstrukturen, die innerhalb einiger bevorzugter Ausführungsformen der vorliegenden Erfindung verwendet werden;
  • 13 bis 14 – beispielhafte Systemkomponenten und Netztopologien, die innerhalb einiger bevorzugter Ausführungsformen der vorliegenden Erfindung verwendet werden;
  • 15 – das grundsätzliche Verfahren, das in einigen bevorzugten Ausführungsformen der vorliegenden Erfindung verwendet wird;
  • 16 – die grundsätzlichen Szenarien der Netztopologie, die in einigen bevorzugten Ausführungsformen der vorliegenden Erfindung verwendet werden;
  • 17 bis 36 – beispielhafte Systemprozeßfließbilder, die innerhalb einiger bevorzugter Ausführungsformen der vorliegenden Erfindung verwendet werden;
  • 37 – ein verallgemeinertes Systemblockdiagramm der vorliegenden Erfindung;
  • 38 – eine verallgemeinerte Struktur der Software, die in einigen bevorzugten Ausführungsformen der vorliegenden Erfindung implementiert ist;
  • 39 – ein verallgemeinertes Signalflußdiagramm für die Signalstruktur, die in einigen bevorzugten Ausführungsformen der vorliegenden Erfindung implementiert ist;
  • 40 – die verallgemeinerten Signalkomponenten wie durch die Protokollerweiterungen verkörpert, die in einigen bevorzugten Ausführungsformen der vorliegenden Erfindung verwendet werden.
  • BESCHREIBUNG DER GEGENWÄRTIG BEVORZUGTEN BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
  • Während diese Erfindung die Ausführungsform in vielen verschiedenen Formen zuläßt, ist in den Zeichnungen gezeigt und wird hierin in detaillierter bevorzugter Ausführungsform der Erfindung mit dem Verständnis beschrieben, daß die vorliegende Offenbarung als eine Erläuterung der Prinzipien der Erfindung durch Beispiele anzusehen ist und nicht beabsichtigt ist, die Erfindung auf die dargestellte Ausführungsform zu beschränken.
  • Die zahlreichen innovativen Lehren der vorliegenden Patentanmeldung werden mit speziellem Verweis auf die gegenwärtig bevorzugte Ausführungsform beschrieben, worin diese innovativen Lehren vorteilhaft auf die speziellen Probleme eines SYSTEMS UND VERFAHRENS ZUM MIKROMOBILITÄTSBASIERTEN NETZ-ROUTING angewendet werden. Jedoch sollte es verstanden werden, daß diese Ausführungsform nur ein Beispiel der vielen vorteilhaften Anwendungen der innovativen Lehren hierin ist. Im Allgemeinen beschränken die in der Patentbeschreibung der vorliegenden Patentanmeldung gemachten Darlegungen nicht notwendigerweise irgendeine der verschiedenen beantragten Erfindungen. Außerdem können einige Darlegungen auf einige erfinderische Merkmale anwendbar sein, aber nicht auf andere.
  • Definitionen
  • Überall in der Diskussion in diesem Dokument werden die folgenden Definitionen verwendet:
  • Systemblöcke/Prozedurschritte nicht beschränkend
  • Die vorliegende Erfindung kann entsprechend in Form von beispielhaften Systemblockdiagrammen und Prozedurablaufdiagrammen beschrieben werden. Während diese Punkte ausreichend sind, einem Fachmann die Lehren der vorliegenden Erfindung mitzuteilen, sollten sie nicht ausschließlich als den Anwendungsbereich der vorliegenden Erfindung begrenzend ausgelegt werden. Ein Fachmann wird erkennen, daß die Systemblockdiagramme kombiniert und umgeordnet werden können ohne Verlust der Allgemeingültigkeit, und Prozedurschritte addiert oder subtrahiert und umgeordnet werden können, um den gleichen Effekt mit keinem Verlust der Allgemeingültigkeit der Lehren zu erreichen. Folglich sollte es verstanden werden, daß die vorliegende Erfindung, wie in den beigefügten beispielhaften Systemblockdiagrammen und Prozedurablaufdiagrammen dargestellt, nur für Zwecke der Lehren ist und durch einen Fachmann in Abhängigkeit von der beabsichtigten Zielanwendung umgearbeitet werden kann.
  • Personalcomputer nicht beschränkend
  • Überall in der Diskussion hierin werden Beispiele bereitgestellt, die Personalcomputer-(PC-)Technologien verwenden, um die Lehren der vorliegenden Erfindung zu erläutern. Dem Begriff 'Personalcomputer' sollte eine weitreichende Bedeutung in dieser Hinsicht gegeben werden, wie im Allgemeinen jede Recheneinrichtung verwendet werden kann, um die Lehren der vorliegenden Erfindung zu implementieren, und der Anwendungsbereich der Erfindung ist nicht nur auf Personalcomputeranwendungen beschränkt.
  • Internet/Intranet nicht beschränkend
  • Überall in der Diskussion hierin werden die Begriffe Internet und Intranet im Allgemeinen verwendet, um irgendein Netzkommunikationssystem oder -umgebung zu bezeichnen. Im Allgemeinen wird der Begriff Intranet die Kommunikation bezeichnen, die lokal zu einem gegebenen System oder Benutzer ist, und Internet wird die Kommunikation in einem entfernteren Ort beschreiben. Ein Fachmann wird erkennen, daß diese Begriffe innerhalb der Kontexte von modernen Kommunikationsnetzen willkürlich sind und keinesfalls den Anwendungsbereich der vorliegenden Erfindung beschränken.
  • Die vorliegende Erfindung antizipiert speziell, daß in einigen Implementierungen der GUI-Entwicklungsrahmen (und/oder seine Laufzeitkomponente) mit den Daten kommuniziert, die verwendet werden, um die GUI über das Internet zu steuern. Folglich kann die Anwendung, die die Benutzeroberfläche steuert, auf einem Computersystem gespeichert sein und die Daten, die für die Darstellung und Steuerung verwendet werden, können irgendwo anders auf einem anderen Computersystem enthalten sein und über jede Anzahl von Netzwerkprotokollen zugegriffen werden.
  • Anwenderprogrammierschnittstelle (Application Programming Interface/API) nicht beschränkend
  • Während die vorliegende Erfindung zum Teil unter Verwendung der Standard-Anwenderprogrammierschnittstellen (APIs) wie zum Beispiel Software Development Kits (SDKs) und dergleichen implementiert werden kann, ist keine Anforderung vorhanden, daß die vorliegende Erfindung unter Verwendung dieser Tools zu implementieren ist. Zu beachten ist auch, daß der Rahmen der vorliegenden Erfindung in Standard-Toolkits und dergleichen eingebaut werden kann, die in einen API-Rahmen zur Verwendung in Standard-Softwareentwicklungsrahmen integriert sein können oder nicht.
  • Betriebssystem nicht beschränkend
  • Zusätzlich, während die vorliegende Erfindung implementiert werden kann, um die Verwendung einer Vielzahl von Microsoft®-Betriebssystemen (einschließlich einer Vielzahl von WindowsTM-Varianten) zu begünstigen, sollte nichts ausgelegt werden, um den Anwendungsbereich der Erfindung auf diese speziellen Softwarekomponenten zu beschränken. Insbesondere das System und Verfahren, wie hierin gezeigt, wird breit in einer Vielzahl von Systemen implementiert, einige von denen eine graphische Benutzeroberfläche einschließen können. Einige Beispiele schließen unter anderen HP-UXTM, LINUXTM, SOLARIS und UNIXTM (und ihre Varianten) ein.
  • Datenstrukturen nicht beschränkend
  • Die vorliegende Erfindung kann in einer Vielzahl von Datenstrukturen in einigen bevorzugten Ausführungsformen verkörpert sein. Jedoch ist die Form solcher Datenstrukturen, wie hierin beschrieben, nur beispielhaft. Ein Fachmann würde schnell begreifen, daß eine breite Vielzahl von anderen Datenstrukturen gleichwertig in dieser Patentanmeldung verwendet werden könnte. Folglich sollte keine Datenstruktur, die hierin beinhaltet ist, als den Anwendungsbereich der vorliegenden Erfindung beschränkend interpretiert werden.
  • Kommunikationsmedien nicht beschränkend
  • Die vorliegende Erfindung kann verkörpert werden, um den Transport von Netzprotokollinformationen über eine Vielzahl von Kommunikationsmedien zu beeinflussen. Jedoch das verwendete Signalformat, um solche Übertragungen zu übermitteln, wie hierin beschrieben, ist nur beispielhaft. Ein Fachmann würde schnell begreifen, daß eine breite Vielzahl von anderen Kommunikationsmedien gleichwertig in dieser Patentanmeldung verwendet werden könnte. Folglich sollten keine Kommunikationsmedien, die hierin beinhaltet sind, als den Anwendungsbereich der vorliegenden Erfindung beschränkend angesehen werden.
  • Akronyme
  • Die folgenden Akronyme werden überall in der Diskussion der vorliegenden Erfindung und in Diskussionen verwendet, die sie mit dem Stand der Technik vergleichen:
  • Wireless-Domäne (Wireless Domain/WD)
  • Die Domäne, über die der Benutzer Zugang zu dem Internet erhält. Die Domäne muß durch eine einzelne Entität aus Gründen der Sicherheit und Autorisierung verwaltet werden.
  • Hauptzugriffsrouter (Main Access Router/MAR)
  • Der Router, der mit der Wireless-Domäne und mit dem Internet verbunden ist. Dieser Router muß mobiles IP unterstützen.
  • Basisstationsrouter (Base Station Router/(BSR)
  • Dieser Begriff bezeichnet den Router, der mit einem Satz von Bridges der Basisstationen verbunden ist.
  • Versorgungsbereich des BSR
  • Der Versorgungsbereich des BSR setzt sich aus jedem Versorgungsbereich jeder mit dem BSR verbundenen Basisstation zusammen.
  • Bedienender BSR
  • Dieser Begriff bezeichnet den BSR, der zur Zeit das an einen mobilen Knoten gesendete Multicastpaket verarbeitet. Der BSR enttunnelt den äußeren Header und leitet das innere Paket an den mobilen Knoten weiter.
  • Basisstation (BS)
  • Das ist der Endpunkt des leitungsgebundenen Netzes. Sie weist eine Luftschnittstelle auf. Mehrere Basisstationen können mit dem gleichen BSR verbunden sein.
  • Versorgungsbereich der BS
  • Das durch eine einzelne Basisstation versorgte Gebiet.
  • Aktiver Cache des BSR
  • Dieser Cache beinhaltet Informationen, die jeden mobilen Knoten betreffen, der sich unter dem Versorgungsbereich des BSR befindet.
  • Wahrscheinlicher Chache des BSR
  • Dieser Cache beinhaltet Informationen, die durch umliegende BSRs gesendet wurden, die darauf hinweisen, daß ein mobiler Knoten autorisiert worden ist, um die drahtlose Infrastruktur zu verwenden.
  • Zelle
  • Das ist das durch eine Basisstation (BS) versorgte Gebiet.
  • Übersicht
  • In einer Welt, wo die Funkvernetzung eine vorherrschende Lösung wird, um den Zugang zu dem Kunden von überall her anzubieten, ist es wichtig, ein Design zu haben, das eine problemlose Mobilität ermöglicht. Der Benutzer muß imstande sein, sich entlang seinem Weg zu bewegen, ohne unter Konnektivitätunterbrechungen zu leiden. Mobile IP definiert ein Protokoll, mit dem der mobile Knoten seine Heimatadresse behält, ungeachtet des Netzwerks, mit dem er verbunden ist. Dieses Protokoll weist einen großen Nachteil auf, wenn Verbindungsübergaben zu häufig werden. Der Prozeß des Registrierens über einen Fremdagenten mit dem Heimatagenten erzeugt einen Overhead, der sich drastisch auf abgehende Verbindungen auswirken wird.
  • Innerhalb des Kontextes der vorliegenden Erfindung wird es angenommen, daß Basisstationen nicht bloß passive Bridges sind. Eine zusätzliche Annahme ist, daß mehrere Basisstationen mit dem gleichen Basisstationsrouter (BSR) verbunden sind.
  • Das für das Protokoll der vorliegenden Erfindung beibehaltene Prinzip ist, das Sicherungsschichtprotokoll zu verwenden, um das Senden der Agent-Advertisement-Nachricht auszulösen. Jede Basisstation ist dafür verantwortlich, den BSR zu informieren, wenn ein mobiler Knoten seine Zelle betritt. Die Basisstationen sind mit einem Basisstationsrouter (BSR) verbunden, der mit dem Netzwerk der Fremddomäne verbunden ist. Wir wollen das Sicherungsschichtprotokoll nutzen, um den Basisstationsrouter über das Eintreten des mobilen Knotens in eine der Zellen des Versorgungsbereiches des BSR zu informieren. Auf der Basis der Informationen in seinem Besitz handelt der BSR entsprechend (sendet ein Agent-Advertisement oder schließt sich einem Diffusionsbaum an).
  • Das Netzwerk der Wireless-Domäne kann entweder mit einer Baumstruktur oder einer anderen aufgebaut sein. Die Baumstruktur wird für die Beschreibung des Protokolls beibehalten. Der wichtige Punkt ist, daß dem Netzbetreiber die genaue Topologie des Netzes wohlbekannt ist. Das bedeutet, daß ungeachtet der durch den Benutzer genommenen Bewegungsrichtung der nächste BSR voraussagbar ist. Innerhalb des Netzwerks der Wireless-Domäne ist ein Hauptzugriffsrouter (Main Access Router/MAR) vorhanden, der die Wireless-Domäne mit dem Internet verbindet. Dieser Router spielt die Rolle des Fremd- und Heimatagenten wie in mobilem IP definiert ist. Die übrigen Netzrouter sind herkömmliche IP-Router mit einer spezifischen Anforderung, um Multicastrouting zu unterstützen.
  • Der MAR verwaltet einen Binding-Cache für jeden mobilen Knoten, dessen Zugang erteilt worden ist. Dieser Cache beinhaltet Informationen wie zum Beispiel die Heimatadresse des mobilen Knotens, die Adresse des Heimatagenten, die Multicastadresse und die Lebensdauer. Er verwaltet ebenfalls einen Cache für alle anstehenden Registrierungsanforderungen. Dieser Cache beinhaltet Informationen, die in der Registrierungsanforderung und der IP-Adresse des BSR gefunden wurden.
  • Der BSR verwaltet zwei Caches. Ein Cache beinhaltet Informationen über jede Binding-Zuordnung. Die Binding-Zuordnung beinhaltet die Adresse des mobilen Knotens, die Multicastadresse, die Lebensdauer usw. Der zweite Cache des BSR beinhaltet Informationen über den wahrscheinlichen mobilen Knoten. Diese Informationen werden durch die umliegenden BSRs gegeben, wenn der Zugang eines mobilen Knotens erteilt worden ist.
  • Beim Einschalten MÜSSEN sich der MAR und die BSRs synchronisieren. Während dieses Vorganges erwirbt jeder BSR Kenntnis von der FA-Fähigkeit des MAR. Diese Informationen werden durch jeden BSR verwendet, um eine lokale Agent-Advertisement-Nachricht zu erzeugen.
  • Die BS löst das Aussenden der Agent-Advertisement-Nachricht durch Senden der Advertisement-Nachricht des mobilen Knotens aus; der mobile Knoten empfängt sie und sendet eine Registrierungsanforderung. Der BSR fügt seine IP-Adresse an dem Ende Registrierungsanforderung des mobilen Knotens ein (die BSR-Erweiterung) und leitet die ganze Nachricht an den MAR weiter. Der MAR prüft die Registrierung und unternimmt den entsprechenden Schritt, der mit jeder in der Nachricht vorhandenen Erweiterung (AAA-Erweiterung, Frage- und Antwort-Erweiterung, Erweiterung der Netzzugangskennung usw.) verbunden ist. Der MAR entfernt die BSR-Erweiterung und legt einen Eintrag in dem anstehenden Cache an, der den BSR mit der Registrierungsanforderung des mobilen Knotens verbindet. Dann wird die Registrierungsanforderung an den Heimatagenten weitergeleitet. Sobald die Registrierungsantwort von dem Heimatagenten durch den MAR empfangen wird, weist er eine Multicastadresse zu, die mit dem Binding des mobilen Knotens verbunden ist. Der Eintrag in dem anstehenden Cache wird zu dem Binding-Cache bewegt und wird aktualisiert, um die Multicastadresse zu integrieren. Die Multicastadreßerweiterung wird zusammen mit der Mobile IP-Registrierungsantwort an den BSR gesendet, der die Registrierungsanforderung des mobilen Knotens weitergeleitet hat. Der BSR entfernt die Multicastadreßerweiterung und leitet die Mobile IP-Registrierungsantwort weiter. Der BSR MUß sich der Diffusionsgruppe anschließen, deren Adresse in der Multicasterweiterung gegeben ist. Der BSR übermittelt an die umliegenden BSRs die Informationen, die den mobilen Knoten betreffen, zu dem der Zugang gerade erteilt worden ist. Die Nachricht schließt Sicherungsschichtinformationen wie zum Beispiel ISMI oder MAC-Adresse und die Multicastadresse ein, die verwendet werden, um das Paket des mobilen Knotens zu tunneln.
  • Wenn sich der mobile Knoten unter den Versorgungsbereich einer neuen Basisstation bewegt, informiert diese Basisstation den BSR über den neu angekommenen mobilen Knoten durch Senden der Sicherungsschichtinformationen des mobilen Knotens. Wenn der BSR einen Cache-Eintrag für den mobilen Knoten aufweist, aktualisiert er den Cache. Wenn der BSR keinen Cache-Eintrag für den mobilen Knoten aufweist, aber einen Eintrag in seinem wahrscheinlichen Cache aufweist, sendet der BSR eine Verbindungsnachricht an den MAR. Er kann dann die an den mobilen Knoten gesendeten Pakete empfangen und enttunneln.
  • Die folgenden Abschnitte stellen im Detail das vorgeschlagene Protokoll dar.
  • Neue Mobile IP-Erweiterungen
  • Dieser Abschnitt kennzeichnet die neuen Erweiterungen auf Mobile IP, die notwendig sind, um das vorgeschlagene Protokoll innerhalb des Kontextes der vorliegenden Erfindung zu implementieren.
  • Advertisement des mobilen Knotens (Mobile Node Advertisement) (0900)
  • Die Erweiterung der Protokollstruktur für Advertisement des mobilen Knotens ist in 9 (0900) erklärt und umfaßt in der Regel die folgenden Felder:
    • • Typ (0911): ein Typkennungsfeld.
    • • Subtyp (0912): neuer mobiler Knoten (n) oder Sicherungsschicht-Tabellenaktualisierung (u). Die Nachricht des Typs des neuen mobilen Knotens wird jedesmal gesendet, wenn die Basisstation feststellt, daß ein neuer mobiler Knoten den Versorgungsbereich betreten hat. Die Sicherungsschicht-Tabellenaktualisierung wird periodisch durch die Basisstation gesendet, um die Binding-Einträge an dem BSR aufzufrischen.
    • • Länge (0913): N, wo N die Anzahl der gesendeten Sicherungsschichtinformationen ist. Die gesendeten Informationen können die Adresse der MAC-Schicht zum Beispiel sein, wenn die drahtlose Verbindung 802.11-konform ist.
    • • Länge eines Elementes (0920): M, wo M gleich der Länge einer einzelnen sicherungsschichtspezifischen Information ist.
  • BSR-Erweiterung (1000)
  • Die Erweiterung der Protokollstruktur der BSR-Erweiterung ist in 10 (1000) erklärt und umfaßt in der Regel die folgenden Felder:
    • • Typ (1011): ein Typkennungsfeld.
    • • IP-Adresse des BSR (1012, 1020): die IP-Adresse des BSR. Die IP-Adresse gibt an, welcher BSR den mobilen Knoten bedient. Diese Adresse wird verwendet, um die mobile IP-Registrierungsantwort an den BSR weiterzuleiten, der den mobilen Knoten bedient. Die BSR-Erweiterung MUß an dem Ende der Mobile IP-Registrierungsanforderung angehängt werden.
  • Multicastadreßerweiterung (1100)
  • Die Erweiterung der Protokollstruktur der Multicastadresse ist in 11 (1100) erklärt und umfaßt in der Regel die folgenden Felder:
    • • Typ (1111): ein Typkennungsfeld.
    • • Multicastadresse (1112, 1120): die Multicastadresse, die für den mobilen Knoten zugewiesen wurde. Die Informationen, die das Mobiltelefon betreffen, sind in der mobilen IP-Registrierungsantwort eingeschlossen. Die Multicastadreßerweiterung MUß an dem Ende der mobilen IP-Registrierungsantwort angehängt werden.
  • Nachbar-Update-Erweiterung (1200)
  • Die Erweiterung der Protokollstruktur der Multicastadresse ist in 12 (1200) erklärt und umfaßt in der Regel die folgenden Felder:
    • • Typ (1211): ein Typkennungsfeld.
    • • Länge (1213): N, wo N der Wert der in der Nachricht vorhandenen Dreiergruppe (Heimatadresse des mobilen Knotens, Multicastadresse und sicherungsschichtspezifische Informationen) ist. Kann eventuell Null sein, um die Einträge in den umliegenden Caches zu löschen.
    • • Heimatadresse des mobilen Knotens (1230, 1270): die IP-Adresse des mobilen Knotens.
    • • Multicastadresse (1240, 1280): die Multicastadresse, die durch den MAR für diesen speziellen mobilen Knoten zugewiesen wurde.
    • • Sicherungsschichtspezifische Informationen des mobilen Knotens (1250, 1290): beinhalten die sicherungsschichtspezifischen Informationen für den mobilen Knoten (z.B. die MAC-Adresse, wenn die Bitübertragungsschicht des Netzwerks 802.11 ist).
  • Protokollübersicht (1300–1600)
  • Dieser Abschnitt beschreibt das Verhalten der verschiedenen mobilen Knoten in zwei Situationen:
    • 1 Das erste Szenario beschreibt das Protokoll, wenn der mobile Knoten die Fremddomäne betritt und sich innerhalb ihres Versorgungsbereiches bewegt.
    • 2 Das zweite Szenario beschreibt die Evolution des mobilen Knotens während er sich innerhalb des Versorgungsbereiches des Heimatnetzes bewegt.
  • In beiden Fällen basiert die Diskussion auf den Netzelementen, die in 13 (1310, 1320, 1330) dargestellt sind, und der Topologie, die in 14 (1400) dargestellt ist.
  • Komponenten der Netzelemente (1300)
  • Innerhalb des Kontextes der in dieser Diskussion verwendeten Netzelemente, wie in 13 (1300) dargestellt ist, gelten die folgenden Einschränkungen:
    • • Der Hauptzugriffsrouter (MAR) (1310) MUß mobiles IP unterstützen, das sowohl Fremd- als auch Heimatagent-Funktionalität implementiert. Der MAR MUß ebenfalls einen Teil der in diesem Dokument beschriebenen Protokollerweiterungen unterstützen. Der MAR MUß die BSR-Erweiterung verarbeiten, die nach jeder Registrierungsanforderung folgt. Der MAR MUß die Multicastadreßerweiterung vor dem Weiterleiten der Registrierungsantwort zuweisen und einfügen.
    • • Die Router (1320) innerhalb der Wireless-Domäne MÜSSEN das IP-Multicastrouting unterstützen.
    • • Die Basisstationsrouter (1330) MÜSSEN die in diesem Dokument beschriebenen Erweiterungen implementieren. Der BSR MUß die BSR-Erweiterung nach jeder Mobile IP-Registrierungsanforderung einfügen. Der BSR MUß die Multicastadreßerweiterung im Anschluß an die mobile Registrierungsantwort verarbeiten. Der BSR MUß periodisch ein Nachbar-Binding-Update an jeden ihn umgebenden BSR senden. Diese Nachricht wird durch die benachbarten BSRs verwendet, um den wahrscheinlichen Cache zu verwalten. Dieser Cache beinhaltet die Informationen der mobilen Knoten, die sich innerhalb der Umgebung des BSR befinden.
  • Wie vorher erwähnt, ist die Topologie weithin bekannt, und kennt jeder Basisstationsrouter die IP-Adresse der anderen Basisstationsrouter, die sich in seiner Nachbarschaft befinden. Zum Beispiel kennt BSR 4 die IP-Adressen von BSR 3 und BSR 5, da diese BSRs seine Nachbarn sind. Jeder Basisstationsrouter kennt die IP-Adresse des Hauptzugriffsrouters.
  • Nachrichten der Protokollerweiterung (1500)
  • Wie in 15 (1500) dargestellt, erweitert das Protokoll der vorliegenden Erfindung das aktuelle Mobile IP-Protokoll mit einem Satz von Nachrichten, die dafür bestimmt sind:
    • • die nächsten wahrscheinlichen Basisstationsrouter zu informieren, die Informationen bezüglich des mobilen Knotens gegeben, der gerade Zugang zu dem Netzwerk erhalten hat (d.h. der mobile Knoten hat gerade den Versorgungsbereich der Wireless-Domäne betreten). Diese Nachricht wird als die Erweiterung für Nachbar-Binding-Update bezeichnet (d.h. das Mobiltelefon bewegt sich von einem BSR zu einem anderen). Diese Nachricht wird von BSR an BSR gesendet. (1510)
    • • den MAR zu informieren, der die IP-Adresse des BSR gibt, der die mobile IP-Registrierungsanforderung weitergeleitet hat. Diese Nachricht wird als die BSR-Erweiterung bezeichnet. Diese Nachricht wird an die mobile IP-Registrierungsanforderung angehängt. (1520)
    • • den BSR über die Multicastadresse zu informieren, die diesem speziellen mobilen Knoten zugewiesen wurde, wenn der Zugang zu dem Netzwerk erteilt wird. Diese Nachricht wird als die Multicastadreßerweiterung bezeichnet. Diese Nachricht wird an die mobile IP-Registrierungsantwort angehängt. (1530)
    • • den BSR mit den Schicht-2-Charakteristika über einen mobilen Knoten zu informieren, der eine der Zellen betritt. Diese Nachricht wird als die Advertisement-Erweiterung des mobilen Knotens bezeichnet. Die Nachricht KANN mehr als eine Information des mobilen Knotens beinhalten. (1540)
  • Diese erweiterten Protokollnachrichten werden innerhalb des Kontextes der zwei Mobilitätsszenarien verwendet, die unten beschrieben und in 16 (1600) dargestellt sind.
  • Verallgemeinerte Mobilitätsszenarien (1600)
  • Die vorliegende Erfindung implementiert ein verallgemeinertes Mobilitätsprotokoll und Messagingsystem innerhalb des Kontextes der verallgemeinerten Mobilitätsszenarien, die in 16 (1600) dargestellt sind. Die folgende Diskussion beschreibt die verschiedenen Phasen, indem ausführlich dargelegt wird, wie die Erweiterungen zum Erweitern von mobilem IP beitragen, um Mikromobilitätsunterstützung anzubieten.
  • Das erste dargestellt Szenario (1610) ist, wenn sich der mobile Knoten unter dem Versorgungsbereich einer Fremddomäne (1611) bewegt.
  • Das zweite Szenario (1620) ist, wenn sich der mobile Knoten innerhalb seiner Heimatdomäne (1621) bewegt. In diesem Szenario beschreibt die folgende Diskussion, wie es dem Mobiltelefon gelingt, zu seinem Heimatagenten (1622) zurückzukehren. Dieses Protokoll nimmt an, daß ein einzelner Betreiber das Fremdnetz verwaltet, aber die vorliegende Erfindung ist nicht auf diese Annahme beschränkt.
  • Betreten der Fremddomäne (1700–3200)
  • Bezug nehmend auf das erste in 16 (1610) dargestellte Mobilitätsszenario, ist das verallgemeinerte Protokoll, das mit dem Betreten der Fremddomäne verbunden ist, in 17 bis 24 (1700, 1800, 1900, 2000, 2100, 2200, 2300, 2400) dargestellt und wird nun im Detail diskutiert.
  • Wenn der mobile Knoten den Versorgungsbereich des Basisstationsrouters 1 betritt (der erste BSR oder jeder andere Router in dieser Domäne) (1701), löst das Sicherungsschichtprotokoll an der Basisstation das Aussenden der Advertisement-Nachricht des mobilen Knotens (1702) aus. Die BS informiert den BSR über das Eintreten eines mobilen Knotens in die Zelle (1703). Die Basisstation MUß periodisch die Advertisement-Nachricht des mobilen Knotens an den BSR mit der Liste des mobilen Knotens senden, der sich in der Basisstationszelle befindet (1704).
  • Der BSR wird seine Entscheidung auf dem Vorhandensein der Sicherungsschicht des mobilen Knotens in seinen Caches basieren. Bei einem Treffer des Binding-Caches (1705) MUß der BSR den Eintrag auffrischen (1706). Bei einem Treffer des wahrscheinlichen Caches (1707), MUß sich der BSR dem Diffusionsbaum anschließen und den Eintrag aus dem wahrscheinlichen Cache zu dem Binding-Cache übertragen (1708).
  • Der BSR MUß periodisch ein Nachbar-Binding-Update an die umliegenden BSRs mit der Liste der Sicherungsschichtinformationen von allen den mobilen Knoten senden, die sich in dem Versorgungsbereich des BSR befinden (1809).
  • Wenn in keinem der Chaches ein Treffer ist (1810), MUß der BSR eine mobile IP-Agent-Advertisement-Nachricht senden (1811).
  • Der mobile Knoten sendet die Registrierung an den Basisstationsrouter (BSR) (1812). Der BSR (der zum Beispiel der erste BSR sein kann) MUß seine IP-Adresse (d.h. BSR-Erweiterung) zu der Registrierungsanforderung des mobilen Knotens hinzufügen und sie an den MAR weiterleiten (1813). Der MAR, nachdem er alle erforderlichen Kontrollen durchgeführt hat, die zum Erteilen der Registrierungsanforderung (AAA-Protokoll, Frage/Antwort und Schlüsselaustausch, NAI usw.) notwendig sind (1814), leitet die Registrierungsanforderung allein an den Heimatagenten weiter (1815).
  • Der MAR legt einen Eintrag in dem anstehenden Cache für die Anforderung des mobilen Knotens an, einschließlich der IP-Adresse des BSR, der den mobilen Knoten bedient (1916). Für den Heimatagenten beherbergt der MAR anscheinend den mobilen Knoten (1917). Der Heimatagent auf der Basis seiner eigenen Richtlinien erteilt oder verweigert die Registrierungsanforderung (1918). Unter Berücksichtigung, daß der Heimatagent die Anforderung erteilt (1919), sendet er seine Antwort an den Fremdagenten (d.h. den MAR) (1920).
  • Wenn der mobile Knoten die erste Registrierungsanforderung (2021) auslöst und sich zu einer neuen Zelle bewegt, die mit einem neuen BSR verbunden ist (2022), wird der vorher beschriebene Mechanismus eine zweite Registrierungsanforderung auslösen (2023). Der neue BSR verarbeitet die Registrierungsanforderung wie in dem vorherigen Absatz beschrieben ist (d.h. der BSR hängt die BSR-Erweiterung an die Registrierungsanforderung an) (2024). Der MAR, der die mobile Registrierung empfängt, MUß den anstehenden Cache prüfen (2025). Bei einem Treffer im Cache (2026), wird der MAR folgern, daß sich der mobile Knoten zu einer anderen Zelle bewegt hat, während der Heimatagent die Registrierungsanforderung verarbeitet (2027). Der MAR MUß den anstehenden Cache aktualisieren, um die Adresse des neuen BSR widerzuspiegeln (2028).
  • Wenn der MAR die Registrierungsantwort empfängt (2129), aktualisiert er den Cache, um das Ergebnis der Anforderung widerzuspiegeln (z.B. den Eintrag in dem anstehenden Cache zu entfernen und legt einen Eintrag in dem Binding-Cache an) und eine Multicastadresse zuzuweisen (2130). Die Registrierungsantwort wird an den Basisstationsrouter weitergeleitet, der der Multicastadreßerweiterung vorausgeht (2131). Der erste BSR entfernt die Multicastadreßerweiterung und leitet die Registrierungsantwort an den mobilen Knoten weiter (2132). Er legt ebenfalls einen Binding-Eintrag an, der die Multicastadresse mit dem mobilen Knoten verbindet (2133).
  • Der erste BSR informiert periodisch den zweiten BSR über das neu erzeugte Binding (2234). Die Nachricht schließt für jeden in dem Binding-Cache gefundenen mobilen Knoten die Adresse des mobilen Knotens, die Care-of-Adresse, die Adresse des Heimatagenten, die Multicastadresse, die Sicherungsschichtinformationen und die Lebensdauer der Registrierung ein. Die Nachricht für Nachbar-Binding-Update frischt teilweise die Einträge des wahrscheinlichen Caches auf (2235). Das ist ein teilweises Auffrischen, da der Cache gänzlich aufgefrischt wird, nachdem er jede Nachricht für Nachbar-Binding-Update von jedem benachbarten BSR empfangen hat.
  • Wenn der mobile Knoten unter dem Versorgungsbereich bleibt, der mit der gleichen Basisstation verbunden ist (2336), MUß diese Basisstation periodisch die Auffrischnachricht (Advertisement des mobilen Knotens) an den ersten BSR senden (muß Periodizität auf der Basis des Anwendungskontextes definiert werden) (2337). Die Advertisement-Nachricht des mobilen Knotens frischt teilweise die Binding-Cache-Einträge auf (2338). Das ist ein teilweises Auffrischen, da der Cache gänzlich aufgefrischt wird, nachdem er jede Advertisement-Nachricht des mobilen Knotens von jeder Basisstation empfangen hat.
  • Wenn sich der mobile Knoten zu einer anderen Basisstation bewegt, die mit dem gleichen BSR verbunden ist (2339), MUß die Basisstation sofort eine Advertisement-Nachricht des mobilen Knotens mit den Sicherungsschichtinformationen des mobilen Knotens senden, der das Ereignis erzeugt hat (2340).
  • Wenn sich der mobile Knoten zu der Zelle bewegt, die mit dem zweiten BSR verbunden ist (2441), informiert einer der BSs den zweiten BSR über das Vorhandensein des mobilen Knotens durch Senden einer Advertisement-Nachricht des mobilen Knotens an den zweiten BSR (2442). Wenn der zweite BSR einen Eintrag in seinem wahrscheinlichen Cache aufweist, der die durch den ersten BSR gesendeten Informationen beinhaltet (2443), verbindet der zweite BSR die durch die BS gegebenen Sicherungsschichtinformationen mit den in dem wahrscheinlichen Cache gefundenen und sendet eine Nachricht, um sich der Multicastgruppe anzuschließen, um die Pakete des mobilen Knotens zu empfangen (2444).
  • Inzwischen empfängt der erste BSR keine den Binding-Cache auffrischende Advertisement-Nachricht des mobilen Knotens, folglich wird der Eintrag in den wahrscheinlichen Cache bewegt (2445). Wenn der mobile Knoten über verschiedene Basisstationen empfangen und senden kann, wird der mobile Knoten die Nachricht von beiden verschiedenen Basisstationen empfangen (2446).
  • Tabelle 1 stellt die Binding-Cache-Einträge an dem MAR für die Szenarien dar, die zum Experimentieren des MMM-Protokolls verwendet worden sind. Ein Eintrag für einen MN wird in dem Binding-Cache erst angelegt, nachdem eine Registrierungsantwort von dem HA des MN empfangen wird. MN1 ist unter der Versorgung von BSR1 und HA1 ist der Heimatagent von MN1. MN1 verwendet eine Care-of-Adresse (entweder eine Colocated-Adresse oder die Adresse des MAR), die von der besuchten Domäne erworben worden ist.
  • Tabelle 1: Binding-Tabelleneinträge
    Figure 00570001
  • Care-of-Adresse (COA) (2500)
  • Das vorgeschlagene Protokoll stellt keine spezielle Anforderung an die durch den mobilen Knoten verwendete Typ-Care-of-Adresse. Diese Adresse kann entweder die Care-of-Adresse eines Fremdagenten oder eine Co-located Care-of-Adresse sein.
  • Der MAR hat am Anfang alle BSRs angefordert, das 'R'-Bit in der Agent-Advertisement-Nachricht zu setzen, die sie nach dem Empfangen einer Advertisement-Nachricht des mobilen Knotens senden (2501). Wie der mobile Knoten die Co-located Care-of-Adresse erwirbt, ist außerhalb des Anwendungsbereiches des Dokumentes, aber ihre Implementierung wird einem Fachmann weithin bekannt sein.
  • Außer diesem Punkt bleibt das Prinzip identisch. Wenn sich der mobile Knoten mit einer Co-located Care-of-Adresse registriert (2502), hängt der BSR die BSR-Erweiterung nach der Registrierungsanforderung an (2503). Der MAR verarbeitet die Registrierung und entfernt die BSR-Erweiterung (2504). Der MAR weist eine Multicastadresse für den mobilen Knoten zu und hängt sie in der Multicastadreßerweiterung nach der Registrierungsantwort an (2505). Der einzige Unterschied liegt in der Verkehrsverwaltung, d.h. welcher Knoten den Tunnel entfernt und das Paket an sein mobiles Ziel weiterleitet (2506). Der nächste Abschnitt beschreibt, wie der Verkehr verwaltet wird, wenn der mobile Knoten eine Co-located Care-of-Adresse verwendet.
  • Verkehrsfluß
  • Die generische Verkehrsfluß-Paketvermittlung ist in 7 (0700) erläutert und wird nun im Detail beschrieben.
  • Care-of-Adresse des Fremdagenten (2600, 2700)
  • Der verallgemeinerte Verkehrsfluß der Care-of-Adresse des Fremdagenten ist in 26 (2600) und 27 (2700) erläutert. Wenn sich der Correspondent Node außerhalb der Wireless-Domäne (2601) befindet, werden die Pakete an das Heimatnetz adressiert (2602). Der Heimatagent fängt diese Pakete ein und tunnelt sie an die in seinem Binding-Cache gefundene Care-of-Adresse (2603). Diese Adresse entspricht der IP-Adresse des Hauptzugriffsrouters. Der MAR empfängt die getunnelten Pakete (2604). Wenn der MAR einen gültigen Binding-Cache für den mobilen Knoten aufweist (2605), enttunnelt er das Paket und erzeugt einen neuen Tunnel (2606).
  • Bezug nehmend auf 27 (2700) wird die Quell-IP-Adresse mit der IP-Adresse des MAR (2707) eingestellt und die Ziel-IP-Adresse wird mit der Multicastadresse eingestellt, die für den mobilen Knoten zugewiesen ist (2708). Die Pakete werden dann an die Diffusionsgruppe gesendet (2709). Jeder BSR, der die Multicastgruppe abonniert hat, empfängt eine Kopie (2710) und enttunnelt das Paket (2711) und leitet die Pakete an den mobilen Knoten weiter (2712).
  • Co-located Care-of-Adresse (2800)
  • Der verallgemeinerte Verkehrsfluß der Co-located Care-of-Adresse des Fremdagenten ist in 28 (2800) erläutert. Wenn der mobile Knoten eine Co-located Care-of-Adresse verwendet (2801), fängt der MAR das Datagramm ein (2802) und tunnelt diese mit der Zieladresse, die auf die Multicastadresse eingestellt ist (2803). Jeder BSR, der die Gruppe abonniert hat, empfängt die Pakete (2804) und enttunnelt es (2805) und sendet das Paket an den mobilen Knoten (2806). Der mobile Knoten enttunnelt das Paket wie im mobilen IP spezifiziert ist (2807).
  • Correspondent Node innerhalb der Wireless-Domäne (2900)
  • Die verallgemeinerte Foreign Agent Correspondence innerhalb der Wireless-Domäne ist in 29 (2900) erläutert. Wenn sich der Correspondent Node in der Fremddomäne befindet (2901), wird der Verkehr an die Heimatadresse des mobilen Knotens gesendet (2902). Der MAR durchsucht seinen Binding-Cache auf einen gültigen Eintrag, der die Heimatadresse des mobilen Knotens beinhaltet (2903). Bei einem Treffer im Cache (2904) tunnelt der MAR das Paket direkt an die Multicastgruppe (2905). Dieser Mechanismus verbessert die Leistungsfähigkeit des gesamten Netzes, wenn Wegoptimierung nicht verwendet wird.
  • Bewegung innerhalb der Fremddomäne (3000)
  • Der Hauptvorteil des Protokolls ist die geringe Latenzzeit, die vor dem Empfangen der Pakete auf abgehenden Verbindungen erforderlich ist. Das Protokoll, da es auf dem Sicherungsschichtprotokoll aufbaut, ermöglicht solche Leistungsfähigkeit und ist im Allgemeinen in 30 (3000) erläutert.
  • Wenn der mobile Knoten eine neue Zelle betritt (3001), MUß die Basisstation den BSR über das Vorhandensein des mobilen Knotens informieren (3002). Sie MUß eine Advertisement-Nachricht des mobilen Knotens senden, einschließlich der Sicherungsschichtinformationen des mobilen Knotens (3003). Zwei Szenarien können vorhergesehen werden. Wenn sich der mobile Knoten zu einer anderen Basisstation bewegt hat, aber unter der Versorgung des gleichen BSR bleibt (d.h. der mobile Knoten durch eine BS bedient wird, die mit dem gleichen BSR verbunden ist) (3004), dann ist keine Aktion erforderlich (3008).
  • Wenn der mobile Knoten nicht unter denen ist, die durch den BSR bedient sind (d.h. der BSR weist kein Binding-Cache auf), aber der BSR weist einen Eintrag in dem wahrscheinlichen Cache auf (3005), MUß der BSR sofort die Multicastgruppe abonnieren (3006).
  • Beim nächsten Ablaufen des Timers, der das Aussenden der Nachricht für Nachbar-Binding-Update auslöst, informiert der BSR alle BSRs in seiner Nachbarschaft, einschließlich der Liste der Informationen des mobilen Knotens (3007).
  • Option Make-Before-Break (unterbrechungslos) (3100)
  • Verallgemeinert ist die optionale Funktionalität "Make-Before-Break" in 31 erläutert (3100). Die Option "Make-Before-Break" erfordert, daß die umliegenden BSRs eines bedienenden BSR die Diffusionsgruppe abonnieren (3102), sobald sie die Nachbar-Update-Nachricht empfangen (3101). Die Option erfordert ebenfalls, daß alle BSRs, die gegenwärtig den mobilen Knoten nicht bedienen (d.h. der Eintrag des mobilen Knotens ist in dem wahrscheinlichen Cache), alle ankommenden Multicastpakete filtern und verwerfen (3103). Die Filterung wird entfernt (3105), wenn der BSR von einer seiner Basisstationen eine Advertisement-Nachricht des mobilen Knotens, einschließlich der Sicherungsschichtinformationen des mobilen Knoten empfing (3104).
  • Diese Option ist bestimmt, um die Latenzzeit der Verarbeitung der Verbindungsnachricht der Diffusionsgruppe zu verringern, da der BSR bereits die an das Mobiltelefon gesendeten Pakete empfängt. Die Verarbeitung ist dann auf das Entfernen des Filterungsmerkmals beschränkt, das mit dieser speziellen Multicastadresse verbunden ist.
  • Auffrischen der Registrierung (3200)
  • Die verallgemeinerte Funktionalität des Auffrischens der Registrierung ist in 32 (3200) erläutert. Wenn der mobile Knoten ermittelt, daß die vorherige Registrierung nahe am Ablaufen ist (3201), MUß er eine neue mobile IP-Registrierungsanforderung an seinen Heimatagenten senden (3202). Der BSR, der gegenwärtig den mobilen Knoten bedient, MUß die BSR-Erweiterung (3203) anhängen. Der MAR MUß den Binding-Cache aktualisieren, um die neue Lebensdauer des Bindings widerzuspiegeln (3204). Die Multicastadresse bleibt unverändert (3205).
  • Bewegung innerhalb der Heimatdomäne
  • Die Datenflüsse der Protokollsequenz zuhause sind im Allgemeinen in 8 (0800) erläutert und werden nun im Detail diskutiert.
  • Virtuelles Heimatnetz (Virtual Home Network) (3300, 3400)
  • Verallgemeinert ist die Funktionalität des virtuellen Heimatnetzes in 33 (3300) erläutert. Wenn sich der mobile Knoten innerhalb der Heimat-Wireless-Domäne bewegt (3301), bleiben die für die Fremddomäne beschriebenen Prinzipien erhalten. Die Heimatdomäne des mobilen Knotens ist administrativ mit dem MAR verbunden (3302). Folglich dient der MAR als ein Heimatagent für den mobilen Knoten (3303).
  • Wie in dem Abschnitt Übersicht oben erwähnt ist, erfordert das Protokoll eine Initialisierungsphase, während der die BSRs Informationen über die Fähigkeit des mobilen Agenten des MAR empfingen (3304). Die BSRs verwenden diese Informationen, um das Agent-Advertisement zu erzeugen.
  • Der mobile Knoten, der einen Punkt innerhalb der Heimat-Wireless-Domäne betritt, wird eine mobile IP-Registrierung senden, die jede vorherige Binding-Nachricht durch den Heimatagenten löschen wird, während der mobile Knoten eine Fremd-Wireless-Domäne besuchte (3305). Es kann ebenso eine neue Registrierungsanforderung sein, da die mobilen Geräte gerade eingeschaltet worden sind. Der den mobilen Knoten bedienende BSR MUß die BSR-Erweiterung anhängen, die durch den MAR verwendet werden wird, um die Registrierungsantwort weiterzuleiten (3306).
  • Bezug nehmend auf 34 (3400), weist der Heimatagent des MAR eine Multicastadresse zu (3407) und erzeugt ein Binding-Cache für den mobilen Knoten (3408). Die Multicastadresse wird an den BSR mit der Multicastadreßerweiterung gesendet (3409). Der BSR entfernt die Multicastadreßerweiterung (3410) und leitet die Registrierungsantwort an den mobilen Knoten weiter (3411). Der BSR sendet eine Nachricht für Nachbar-Binding-Update an die umliegenden BSRs (3412).
  • Während sich der mobile Knoten in der Heimatdomäne bewegt, sind die für die Fremddomäne beschriebenen Prinzipien völlig identisch (siehe den vorherigen Abschnitt Bewegung innerhalb der Fremddomäne).
  • Verkehrsfluß (3500)
  • Die verallgemeinerte Funktionalität des Verkehrsflusses ist in 35 (3500) und 36 erläutert (3600). Wenn sich der Correspondent Node innerhalb der Domäne befindet (3501), werden die Pakete an die Heimatadresse des mobilen Knotens gesendet, die durch den MAR abgefangen werden (3502). Der MAR erzeugt den Tunnel, um die Pakete weiterzuleiten (3503). Die Zieladresse wird auf die Multicast-IP-Adresse eingestellt (3504) und die Quelladresse wird auf die Adresse des MAR eingestellt (3505). Alle BSRs, die die Diffusionsgruppe abonniert haben, werden das getunnelte Paket empfangen (3506). Die BSRs MÜSSEN den äußeren IP-Header entfernen und das innere Paket an den mobilen Knoten weiterleiten (3507).
  • Bezug nehmend auf 36 (3600), wenn der Correspondent Node außerhalb der Domäne ist (3608), werden die Pakete gezwungen, über den MAR zu gehen (3609), der das gleiche Prinzip anwendet, wie in dem vorherigen Absatz beschrieben ist. Der MAR erzeugt einen Tunnel (3610) mit der Zieladresse, die auf die Multicastadresse eingestellt ist (3611), und mit der Quelladresse, die auf die IP-Adresse des MAR eingestellt ist (3612). Dieses Paket wird durch jeden BSR enttunnelt, der die Gruppe abonniert hat (3613). Das durch den Correspondent gesendete Paket wird an den mobilen Knoten weitergeleitet (3614).
  • Änderung im vorhandenen Protokollverhalten
  • Die vorliegende Erfindung modifiziert die vorhandenen Mobile IP-Protokolle etwas. Das Protokoll der vorliegenden Erfindung bedeutet, daß sich der mobile Knoten jedesmal registrieren MUß, wenn er eine Wireless-Domäne betritt, auch wenn die Wireless-Domäne die Heimatdomäne des mobilen Knotens ist. Diese Erweiterung ist obligatorisch, um das Aufbauen des Multicast-Verteilungsbaums zu ermöglichen.
  • Das Protokoll der vorliegenden Erfindung fordert den BSR, der als der Fremdagent dient, nicht auf, periodisch die Agent-Advertisement-Nachricht zu senden. Die Nachricht wird nur gesendet, wenn der BSR ermittelt, daß der mobile Knoten neu in dem Versorgungsbereich des BSR ist.
  • Betrachtungen des mobilen Knotens
  • Das Protokoll der vorliegenden Erfindung schließt keine spezifische Anforderung für den mobilen Knoten ein, außer daß der mobile Knoten das mobile IP implementieren MUß, wie in RFC 2002 definiert ist.
  • Die einzige innerhalb der vorliegenden Erfindung gemachte Anforderung ist, daß der mobile Knoten, wenn er eine Wireless-Domäne betritt, eine mobile IP-Registrierungsanforderung senden MUß. Das ist erforderlich, um den Multicasttunnel innerhalb der Wireless-Domäne einzurichten. Diese Registrierung entfernt ebenfalls das anstehende Binding, wenn der mobile Knoten in seine Heimatdomäne zurückkehrt. Der mobile Knoten MUß dann die Lebensdauer auf Null einstellen, wie im mobilen IP spezifiziert ist.
  • Der mobile Knoten MUß die Übersicht über die anstehenden Registrierungsanforderungen behalten, da diese Nachrichten verlorengehen können. In solchem Fall MUß der mobile Knoten einen Timer einstellen, dessen Ablauf eine neue mobile IP-Registrierungsnachricht auslösen wird. Die Anzahl der gesendeten mobilen IP-Registrierungsnachrichten sollte im Allgemeinen begrenzt sein.
  • Betrachtungen der Basisstation
  • Die Basisstation MUß einen Cache aufrechterhalten, einschließlich der sicherungsschichtspezifischen Informationen von jedem mobilen Knoten, der sich innerhalb ihres Versorgungsbereiches befindet.
  • Die Basisstation MUß periodisch das Advertisement-Update des mobilen Knotens senden (siehe vorherigen Abschnitt Advertisement des mobilen Knotens), das alle sicherungsschichtspezifischen Informationen von allen mobilen Knoten beinhaltet, die sich unter ihrem Versorgungsbereich befinden. Die Periodizität dieser Nachricht bleibt noch zu definieren. Es ist wahrscheinlicher, daß die Periodizität mit der Anzahl der Basisstationen verknüpft wird, die an dem BSR angeschlossen sind, und der Anzahl der Benutzer, die der BSR verwalten kann. Die Anzahl der gesendeten Nachrichten sollte abgestimmt sein, so daß der Signalisierungsteil des Protokolls keinen großen Overhead erzeugt.
  • Die Basisstation MUß sofort eine Advertisement-Nachricht des mobilen Knotens mit dem Subtypsatz an die "neue" senden (siehe vorherigen Abschnitt Advertisement des mobilen Knotens), indem die sicherungsschichtspezifischen Informationen des mobilen Knotens gegeben werden, wenn sie erkennt, daß ein mobiler Knoten ihren Versorgungsbereich betreten hat. Dieser Ablauf ist allgemein in 3 (0300) erläutert.
  • Betrachtungen des Basisstationsrouters
  • Der BSR MUß die durch den MAR gesendete Agent-Advertisement-Nachricht verarbeiten. Der BSR MUß die gegebenen Informationen speichern, da sie verwendet werden, um die lokale Agent-Advertisement-Nachricht an einen mobilen Knoten zu senden. Der BSR detektiert einen MAR-Ausfall, wenn er eine Agent-Advertisement-Nachricht mit einer Folgenummer gleich Null empfängt. Wenn der BSR eine Agent-Advertisement-Nachricht mit einer Folgenummer anders als Null gleich nach seiner eigenen Einschaltphase empfängt, weist dies darauf hin, daß der BSR neu gebootet hat. Dieser Fall erfordert, daß sich alle mobilen Knoten mit ihrem Heimatagenten registrieren. Dieses Szenario ist allgemein in 2 (0200) erläutert.
  • Der Basisstationsrouter MUß zwei Caches verwalten: der Binding-Cache hält die Informationen von allen mobilen Knoten, die unter einem Versorgungsbereich von einer der Basisstationen gegenwärtig sind oder waren. In der Tat kann ein mobiler Knoten in die letzte Advertisement-Nachricht des mobilen Knotens eingeschlossen worden sein, die den Binding-Cache-Eintrag aufgefrischt haben wird und sich unter einen anderen Versorgungsbereich bewegt haben, der durch einen anderen Basisstationsrouter verwaltet ist. Der wahrscheinliche Cache hält die Informationen der mobilen Knoten, die in der Nachbarschaft sind. Diese mobilen Knoten können bald erscheinen und die Informationen sind bestimmt, um dem Vorgang der Verbindungsübergabe zu helfen.
  • Die Basisstation MUß die Advertisement-Nachricht des mobilen Knotens verarbeiten. Es sind zwei verschiedene Szenarien in Abhängigkeit von dem Wert des Subtypfeldes vorhanden:
    • 1. Das Subtypfeld gibt an, daß der mobile Knoten gerade den Versorgungsbereich einer Basisstation betreten hat. Für den Basisstationsrouter bedeutet diese Nachricht entweder, daß das Mobiltelefon neu in dem Versorgungsbereich des BSR ist oder sich der mobile Knoten unter einen Bereich bewegt hat, der durch eine andere BS abgedeckt ist. Der BSR ermittelt den ersten Fall durch die Tatsache, daß sowohl der Binding-Cache als auch der wahrscheinliche Cache keinen Eintrag beinhaltet, der den Sicherungsschichtinformationen entspricht, die in der Advertisement-Nachricht des mobilen Knotens eingeschlossen sind. In solchem Fall MUß der BSR eine Mobile IP-Agent-Advertisement-Nachricht an den mobilen Knoten senden. Wenn der BSR einen Eintrag in dem Binding-Cache aufweist, bedeutet es, daß sich der mobile Knoten in eine neue Zelle bewegt hat und keine Aktion erforderlich ist. Wenn der BSR ermittelt, daß sich der mobile Knoten gerade in seinen Versorgungsbereich des BSR bewegt hat, weil er einen Eintrag in dem wahrscheinlichen Cache aufweist, MUß der BSR eine Verbindungsnachricht des IGMP (wenn dies das verwendete Protokoll ist) in Richtung des MAR senden. Der BSR muß ebenfalls den Eintrag aus dem wahrscheinlichen Cache zu dem Binding-Cache bewegen.
    • 3. Wenn das Subtypfeld eine Aktualisierungsnachricht anzeigt, MUß der BSR die Nachricht verarbeiten, die in dem Auffrischen des Eintrags in dem Binding-Cache jedes mobilen Knotens besteht, der in der Liste eingeschlossen ist. Eine einzelne Nachricht (d.h. Advertisement-Update des mobilen Knotens) widerspiegelt nur einen Teil des mobilen Knotens, der sich gegenwärtig in dem Versorgungsbereich des BSR befindet. Der BSR muß warten, bis er die Advertisement-Nachricht des mobilen Knotens jeder Basisstation empfangen hat, bevor die Einträge in dem Binding-Cache entfernt werden. Wenn einige Einträge des Binding-Cache abgelaufen sind, sollten diese Einträge aus dem Binding-Cache in den wahrscheinlichen Cache entfernt werden. Der BSR MUß eine IGMP-Erlaubnisnachricht in Richtung des MAR senden, wenn der BSR die Option "Unterbrechungslos (Make-Before-Break)" nicht implementiert. Die Lebensdauer eines Binding-Eintrags ist gleich der doppelten Zeit eingestellt, die für den BSR nötig ist, um die Advertisement-Update-Nachricht des mobilen Knotens aller BSR zu empfangen.
  • Der BSR MUß periodisch eine Nachbar-Update-Nachricht mit der Liste des mobilen Knotens senden, der sich unter seinem Versorgungsbereich des BSR befindet. Diese Liste wird an alle BSRs in der Nachbarschaft gesendet. Wie der BSR die Liste der BSRs in der Nachbarschaft erfährt, ist außerhalb des Anwendungsbereiches des Dokumentes (z.B. die Informationen könnten an den BSR über das Netzmanagementprotokoll SNMP gegeben werden).
  • Der BSR muß jede empfangene Nachbar-Update-Nachricht verarbeiten. Jede dieser Nachrichten schließt die Liste des mobilen Knotens ein, der gegenwärtig durch einen benachbarten BSR bedient wird. Für jeden mobilen Knoten, der in der Liste eingeschlossen ist, MUß der BSR entweder einen Eintrag anlegen oder einen vorhandenen auffrischen. Wenn die Implementierung die Option "Unterbrechungslos (Make-Before-Break)" unterstützen will, MUß der BSR eine IGMP-Verbindungsnachricht in Richtung des MAR senden. Wenn der Eintrag in dem wahrscheinlichen Cache abläuft, MUß der Eintrag gelöscht werden und der BSR MUß eine Erlaubnisnachricht in Richtung des MAR senden. Die Lebensdauer des Eintrags des wahrscheinlichen Caches wird auf die doppelte Senderate der Nachbar-Update-Nachrichten eingestellt.
  • Für jede Multicast-Diffusionsgruppe, die einem Eintrag in dem Binding-Cache entspricht und für die der BSR abonniert hat, MUß der BSR alle empfangenen Pakete enttunneln und sie an die Basisstationen weiterleiten. Wenn der BSR das Make-Before-Break-Merkmal implementiert, MUß der BSR imstande sein, die Multicast-Diffusionsgruppe zu filtern, die keine Paketverarbeitung verlangt (d.h. weil der mobile Knoten den Versorgungsbereich des BSR noch nicht betreten hat). Der BSR erfährt die Liste der mobilen Knotens, die solche Verarbeitung erfordern, durch Konsultieren des wahrscheinlichen Caches.
  • Wenn ein Eintrag des wahrscheinlichen Caches nicht aufgefrischt wird, wenn der BSR die Option Make-Before-Break nicht implementiert, MUß der BSR eine IGMP-Erlaubnisnachricht in Richtung des MAR senden. Der Eintrag MUß dann aus dem Cache entfernt werden.
  • Betrachtungen des Hauptzugriffsrouters
  • Der MAR ist der einzige in der Wireless-Domäne verfügbare Fremdagent. Der MAR MUß nach dem anfänglichen Boot (oder einem Reboot) eine Agent-Advertisement-Nachricht an alle BSRs der Wireless-Domäne senden. Diese Nachricht MUß periodisch gesendet werden, um einen BSR-Ausfall abzudecken. Die erste nach der anfänglichen Einschaltphase gesendete Nachricht MUß die Folgenummer gleich Null aufweisen.
  • Sie MUß alle Registrierungsanforderungen verarbeiten wie in Mobile IP definiert ist und SOLLTE alle Erweiterungen der Registrierungsanforderung verarbeiten (z.B. NAI-Erweiterung, AAA-Erweiterung, Erweiterung des Rücktunnelns (reverse tunneling) usw.). Der MAR MUß das Vorhandensein der BSR-Erweiterung prüfen. Die Registrierungsanforderung MUß durch den MAR zurückgewiesen werden, wenn die BSR-Erweiterung nicht eingeschlossen ist. Der MAR muß imstande sein, die zwei folgenden Fälle zu ermitteln:
    • 2. Das Mobiltelefon registriert sich zum ersten Mal (d.h. der Binding-Cache weist keinen Eintrag für diesen mobilen Knoten auf).
    • 4. Das Mobiltelefon sendet eine Registrierungsanforderung, um ein aktuelles Binding aufzufrischen (d.h. der Binding-Cache weist einen Eintrag für diesen mobilen Knoten auf).
  • In dem ersten Fall sollte der MAR einen Eintrag in einem anstehenden Cache anlegen, der die in der Registrierungsanforderung eingeschlossenen Informationen beinhaltet.
  • Wenn der MAR eine zweite Registrierungsanforderung für den gleichen mobilen Knoten empfängt, während die Registrierungsanforderung zur Zeit verarbeitet wird (d.h. der anstehende Cache weist einen Eintrag für diesen mobilen Knoten auf), MUß der MAR den Inhalt der BSR-Erweiterung prüfen, da sich der mobile Knoten zu einem anderen Versorgungsbereich des BSR bewegt haben kann. Der MAR sollte den Eintrag in dem anstehenden Cache aktualisieren. Wenn die Registrierungsanforderung identisch ist, sollte der MAR die Registrierung verarbeiten und sie an den Heimatagenten weiterleiten.
  • Der MAR MUß die ganze in der Registrierung eingeschlossene Erweiterung verarbeiten, was bedeutet, daß der MAR mit einem lokalen AAA-Server zusammengeschaltet sein SOLLTE, um den Zugang des mobilen Knotens zu erteilen.
  • Wenn der Heimatagent die Registrierungsanforderung erteilt, MUß der MAR eine Multicastadresse zuweisen und mit dem mobilen Knoten verbunden sein. Der Mechanismus, durch welchen der MAR die Multicast herausfindet, ist außerhalb des Anwendungsbereiches dieses Dokumentes. Der MAR MUß die Multicastadreßerweiterung an dem Ende der Registrierungsantwort anhängen und die Nachricht an den BSR weiterleiten, der die Registrierungsanforderung weitergeleitet hat. Der MAR MUß einen Binding-Eintrag anlegen, der die Informationen der Zuordnung hält (Binding und Multicastadresse).
  • Wenn der MAR feststellt, daß die Registrierungsanforderung des Mobiltelefons gesendet wurde, um sein aktuelles Binding aufzufrischen, MUß der MAR die Registrierung an den Heimatagenten weiterleiten. Der MAR MUß die Multicastadreßerweiterung an dem Ende der von dem Heimatagenten empfangenen Registrierungsantwort anhängen. Diese Erweiterung MUß die gleiche Multicastadresse einschließen, die während der Verarbeitung der anfänglichen Registrierungsanforderung zugewiesen wurde.
  • Registrierungsanforderungen sind allgemein in 4 erläutert (0400) mit Registrierungsantwortflüssen, die in 5 erläutert sind (0500).
  • Beispielhafte Systemverbesserungen
  • Lastverteilung
  • Um das Auftreten eines Engpasses in dem Netzwerk zu vermeiden, ist es möglich, MARs miteinander zu verbinden. Das Prinzip ist, mehrere MAR zu haben, die die Wireless-Domäne bedienen, um die Last zu verringern, da jeder MAR nur einen Teil der mobilen Benutzer unterstützen wird, die sich gegenwärtig in der Domäne bewegen. Die MARs werden miteinander verbunden und das Prinzip ist, daß sich der mobile Knoten zu einem Teil der Domäne, die durch einen anderen MAR gesteuert wird, einfach bewegen kann, indem der BSR, der den mobilen Knoten bedient, eine Verbindungsnachricht bis zu dem vorherigen MAR sendet. Diese Lösung kann ein Latenzzeitproblem bezüglich der Verbindungsübergabeleistung hervorrufen, aber sie könnte ein Kompromiß zwischen der Engpaßsituation und dem Vorhandensein einer verteilten Umgebung sein. Der zweite Vorteil ist, verschiedene Zugangspunkte zu dem Wireless-Netz bereitzustellen, was Schutz im Fall des MAR-Ausfalles bereitstellt.
  • Wenn das Prinzip beibehalten wird, weist es die Konsequenz auf, daß der MAR ein Multicastrouter sein soll, da sich an einem Punkt oder einem anderen der mobile Knoten unter einen Bereich bewegen wird, der durch einen anderen MAR gesteuert wird. Der BSR wird die IGMP-Nachricht an den MAR senden, der die Anforderung an den MAR weiterleiten wird, der ursprünglich den mobilen Knoten bedient hat.
  • Gruppieren von BSR in Cluster
  • Die Idee ist, den MAR, der die mobile IP-Registrierungsantwort sendet, in einer vorgegebenen Gruppe von BSRs zu haben. Zum Beispiel könnten wir einen Cluster nehmen, der aus BSR 1, 2 und 3 aufgebaut ist. Ein BSR gehört zu einem einzelnen Cluster. Diese drei BSRs werden zu einer gleichen Gruppe gehören und werden die Registrierungsanforderungen durch Mithören der dedizierten Multicastadresse empfangen. Der BSR, der die ursprüngliche Registrierungsanforderung weitergeleitet hat, MUß imstande sein, die Übersicht über die gesendeten Registrierungsanforderungen zu behalten. In der Tat MUß der BSR das entsprechende Enttunneln der Pakete des mobilen Knotens einrichten. Der andere BSR MUß die entsprechende Filterung einstellen, so daß die Pakete des mobilen Knotens verworfen werden.
  • Das Prinzip bedeutet, daß der BSR, der sich am Rand des Clusters befindet, die Multicastadresse des in der Nähe befindlichen Clusters kennen MUß. Wenn also ein mobiler Knoten den Versorgungsbereich des BSR eines Rand-BSR betritt, MUß dieser BSR den bekannten Cluster informieren. Wenn wir dieses Schema auf die klassische Honigwabe anwenden, die verwendet wird, um das Zellularnetz darzustellen, können wir sehen, daß die Clusterbildung die Signalisierungspakete des Protokolls verringert. Der Nachteil ist, daß sich alle BSRs in einem Cluster der Gruppe anschließen werden, was eine größere Kapazität des Netzes erfordern wird, da mehr Datenverkehr unterstützt werden wird. Eine Simulation sollte einschätzen, ob einige Vorteile vorhanden sind, um solche Verfahren zu verwenden.
  • BEVORZUGTER SYSTEMKONTEXT DER VORLIEGENDEN ERFINDUNG
  • Übersicht (3700)
  • Die am meisten verallgemeinerte Systemimplementierung der vorliegenden Erfindung ist in 37 (3700) erläutert, in welcher die vorliegende Erfindung, als ein mikromobilitätsbasiertes Netz-Routing-Protokollmittel (3710) verkörpert, innerhalb eines Internet-IP-Netzes (3720) vereinigt ist, um die Kommunikation zwischen einem Heimatagentmittel (3730) (das ein ortsfestes Computersystem oder ein wandernder Netzknoten sein kann) und einem Wireless-Remote-Gerätemittel zu erlauben (3740). Die hierin beschriebenen Protokolle und Verfahren erlauben die IP-Konnektivität zwischen dem Heimatagentmittel (3730) und dem Wireless-Remote-Gerätemittel (3740) mit minimalem Overhead innerhalb des Internet-IP-Netzmittels (3720). Die Wireless-Remote-Gerätemittel (3740) können eine breite Vielzahl von Implementierungen aufweisen, einschließlich aber nicht begrenzt auf Telefone, Wireless-PDAs und andere Formen von Wireless-Funksendeempfängern, Sendern, Empfänger und dergleichen.
  • Wie vorher beschrieben, können die Internet-IP-Netzmittel (3720) jede Anzahl von Hauptzugriffsroutern, Routern und/oder Basisstationsroutern vereinigen, um die in diesem Szenario erforderliche Hardwarefunktionalität zu implementieren. Die Software, um die beschriebenen Protokolle zu implementieren, kann zwischen jeder oder allen Schichten innerhalb dieser Hardwarestruktur geschichtet sein.
  • Während die vorliegende Erfindung in einer Vielzahl von Formen verkörpert und in einer Vielzahl von Systemkontexten implementiert sein kann, sind einige bemerkenswerte Systemkontexte vorhanden, die bevorzugt werden. In diesem Abschnitt führen wir die Konzeption Small Group Multicast (SGM) oder Explicit Multicast (XCAST) ein und entwickeln dann ein Implementierungsverfahren für MMM unter Verwendung von XCAST.
  • SGM/XCAST
  • Um sich einer speziellen Multicastgruppe anzuschließen, sendet ein Knoten in der Regel eine IGMP-Verbindungsnachricht an eine Quelle oder an einen zentralen Knoten abhängig von dem Typ des verwendeten Multicastverfahrens. Herkömmliches IP-Multicast verwendet eine Multicastadresse, um Datagramme an die Mitglieder einer speziellen Gruppe weiterzuleiten. Die Multicastrouter von der Quelle zu den Gruppenmitgliedern aktualisieren ihre Tabelle, die die Anwesenheit von Gruppenmitgliedern netzabwärts widerspiegelt. Jeder Multicastrouter leitet die Datagramme weiter, bis sie die Knoten erreichen, die die eine Gruppe abonniert hatten. Dieser Mechanismus funktioniert gut, wenn die Gruppen sehr groß sind und die Anzahl der Gruppen zahlenmäßig klein ist. Es sind verschiedene Multicastschemata vorhanden, die sich an das Problem des Dense- und Sparse-Mode-Multicast (PIM Sparse-Mode und Dense-Mode) richten, aber die Schemata sind für eine große Anzahl von kleinen Multicastgruppen nicht gut geeignet.
  • Anders als herkömmliches IP-Multicast kann XCAST effektiv eine große Anzahl von kleinen Multicastgruppen unterstützen. Herkömmliches IP-Multicast stützt sich auf Multicastroutern, um die Informationen der Multicastgruppe aufrechtzuerhalten und ist folglich sehr geeignet für eine kleine Anzahl von großen Multicastgruppen. Eine große Anzahl von Multicastgruppen könnte Skalierbarkeitsprobleme verursachen, weil jeder Multicastrouter viele Einträge (für jede Gruppe) halten müßte und ebenfalls die inbegriffene Verarbeitungszeit beim Nachschlagen. XCAST richtet sich an dieses Problem durch Beseitigen der Notwendigkeit, die Informationen (Gruppeninformationen) an jedem Multicastrouter zu speichern, statt dessen trägt jedes Datenpaket die Unicastadresse der Knoten, die Mitglieder dieser Multicastgruppe sind. Die Pakete werden repliziert, wo auch immer notwendig, damit alle Gruppenmitglieder die Datagramme empfangen. Die Quelle der Pakete verwaltet in der Regel die Gruppenmitgliedschaft, deshalb sendet jeder Knoten, der wünscht ein Mitglied der Gruppe zu sein, eine Nachricht, die anfordert, sich einer XCAST-Sitzung anzuschließen.
  • Wenn ein Router ein XCAST-Paket empfängt, führt er das Folgende durch:
    • • Schlägt in der XCAST-Tabelle nach, um den nächsten Hop für jedes innerhalb des Datagrammes aufgelistete Ziel zu ermitteln.
    • • Wenn ein Eintrag für den nächsten Hop für ein spezielles Ziel vorhanden ist, dann wird das Paket repliziert und an die Unicastadresse des Ziels gesendet.
    • • Wenn ein Eintrag für den nächsten Hop eines speziellen Ziels vorhanden ist, dann wird die Liste auf der Basis des nächsten Hops unterteilt.
    • • Die Datagramme werden für jeden eindeutigen nächsten Hop repliziert.
    • • Die Ziele innerhalb des XCAST-Headers werden modifiziert, um nur diejenigen Ziele widerzuspiegeln, die durch einen speziellen nächsten Hop erreichbar sind.
    • • Leitet die Datagramme durch die entsprechende Schnittstelle an den nächsten Hop weiter.
  • Implementierung unter Verwendung von XCAST
  • Eine Multicast-Herangehensweise an die Mobilität ermöglicht uns, schnelle Verbindungsübergaben bereitzustellen. Beim Durchführen einer Verbindungsübergabe würden der alte BSR und der neue BSR Teil der gleichen Multicast-Sitzung sein, es sei denn, daß der Eintrag für den MN an dem alten BSR abläuft, wenn gerade eine Verbindungsübergabe durchgeführt wird. Überwiegend während einer Verbindungsübergabe würden nur zwei BSRs Mitglieder der gleichen Multicast-Sitzung sein. Wenn ein MN Verbindungsübergaben häufig durchführt oder wenn die Lebensdauer des Eintrags in den Tabelle länger ist, dann könnten mehr als zwei BSRs Teil der gleichen Multicast-Sitzung sein. In der normalen Betriebsweise nehmen wir an, daß die Lebensdauern der Soft-State-Einträge dynamisch berechnet werden, um die Häufigkeit der Verbindungsübergaben in Betracht zu ziehen. In solch einem Szenario würde es höchstens nur zwei BSRs geben, die Mitglieder der gleichen Multicastgruppe sind.
  • Eine Domäne kann aus einigen Hundert Basisstationen bestehen, die tausende von MNs bedienen. Der MAR weist eine Multicastadresse für jeden MN innerhalb seiner Domäne zu. Der MAR muß folglich einen Eintrag halten und die Gruppenmitgliedschaft für alle MNs innerhalb seiner Domäne. Die BSRs weisen ebenfalls hunderte von Multicastroutingeinträgen für mobile Knoten unter ihrer Versorgung auf. Das erzeugt nicht nur eine unhandliche Routingtabelle, sondern erhöht auch die Nachschlagezeit für jeden MN. Wenn Multicastrouter zwischen dem MAR und den BSRs vorhanden sind, dann würden sie ebenfalls Multicasteinträge für jeden MN aufweisen müssen. Die Vorteile, die Multicastrouting bietet, werden wegen des Skalierbarkeitsproblems aufgehoben, das es hier aufwirft. Dieses Problem besteht auch mit Protokollen, die hostbasierte Routingverfahren verwenden.
  • Tabelle 2 zeigt die Einträge in einem Multicastrouter. Wenn eine Anzahl N von MNs unter der Versorgung eines BSR vorhanden ist, dann muß der BSR einen Eintrag für jeden einzelnen von ihnen aufrechterhalten und so macht es jeder Multicastrouter innerhalb der Domäne. BSR1 ist ein Mitglied einer Multicastgruppe, die durch eine eindeutige Multicastadresse adressiert wird, die MN1 zugewiesen ist. BSR2 und BSR3 sind Mitglieder der Multicastgruppe, die durch eine Multicastadresse adressiert ist, die MN2 zugewiesen ist. Jeder Eintrag weist eine mit ihm verbundene Lebensdauer auf. Die Einträge werden gelöscht, wenn die mit einem Eintrag verbundene Lebensdauer abläuft.
  • Tabelle 2: MCAST-Tabelleneinträge
    Figure 00780001
  • Dieses Problem ist komplizierter, wenn die Option Make-Before-Break (MBB) eingeschlossen ist. Tabelle 3 zeigt die Einträge in einem Multicastrouter, der die Option Make-Before-Break verwendet. BSR1, BSR2, BSR3 und BSR4 sind alle Mitglieder der Multicastgruppe, die MN1 bedient. BSRs, die den MN nicht bedienen, empfangen ebenfalls Pakete, da sie entschieden haben, die Multicastgruppe zu abonnieren, die die Option MBB verwendet. Die BSRs, die den MN1 nicht bedienen (wenn die BSRs keinen Eintrag für den MN1 innerhalb ihres Binding-Caches aufweisen), müssen die Pakete verwerfen, sobald er sie von dem MAR empfängt. Nur diejenigen BSRs, die einen Eintrag für MN1 in ihrem Binding-Cache aufweisen, können die Pakete an den MN1 weiterleiten.
  • Tabelle 3: MCAST-Tabelleneinträge unter Verwendung von Make-Before-Break
    Figure 00780002
  • Figure 00790001
  • Um die Nachteile von IP-Multicast zu überwinden, schlagen wir vor, XCAST anstelle des herkömmlichen Multicasts als ein Mittel zu verwenden, um die Mikromobilität zu erreichen. Die BSRs sind erforderlich, um sich kleinen Multicastgruppen anzuschließen, um schnelle Handover zu erreichen. Die Verbindungsnachrichten sind nicht die gleichen IGMP-Verbindungsnachrichten, aber sind in ihrer Funktionalität ähnlich. Die Definitionen der Nachrichten werden hier nicht diskutiert und sind implementierungsspezifisch. Der MAR verwaltet eine Liste von XCAST-Gruppen und die Unicast-Routingadressen der BSRs, die zu jeder Gruppe gehören. Der MAR hält ein Binding zwischen der Heimatadresse des MN, der CoA des MN, der Unicastadresse jedes BSR, der sich dieser virtuellen Gruppe angeschlossen hat und einer Lebensdauer, die mit dem Eintrag verbunden ist, aufrecht. Die an einen MN adressierten Datenpakete, der eine Fremddomäne besucht, werden durch den MAR empfangen, er tunnelt dann die Pakete an die BSRs unter Verwendung des XCAST-Mechanismus. An jedem Zwischenrouter werden die Datagramme entweder repliziert, bevor sie netzabwärts gesendet werden, in Abhängigkeit von den in dem XCAST-Header aufgeführten Adressen, oder unbeeinflußt an den Nachbar netzwabwärts gesendet. Die BSRs entkapseln die Datagramme und leiten sie dann an den entsprechenden MN weiter.
  • Erzeugung der XCAST-Sitzung
  • Wenn der MAR eine Registrierungsantwort von dem HA als Antwort auf die durch einen MN gesendete Registrierungsanforderung empfängt, legt der MAR dann einen Eintrag in der XCAST-Tabelle 4 an, die die Heimatadresse des MN, die CoA des MN und einen Eintrag für den BSR (BSRs, die ihre BSR-Erweiterung hinzufügten) beinhaltet, der die Registrierungsanforderung von dem MN an den MAR weitergeleitet hat. Der Eintrag weist die Unicastadresse des BSR auf, der den MN bedient. Dieser Eintrag muß periodisch aufgefrischt werden, der er ein Soft-State-Eintrag ist. Jeder Eintrag weist eine Lebensdauer auf, für die sie gültig sind, und Einträge, die nicht periodisch durch Verbindungsnachrichten aufgefrischt werden, werden entleert. Die BSRs, die die Einträge gültig behalten wollen, müssen Verbindungsnachrichten mit ihren BSR-Erweiterungen an den MAR senden.
  • Tabelle 4: XCAST-Tabelleneinträge
    Figure 00800001
  • Tabelle 4 stellt die Einträge dar, wenn XCAST anstelle von IP-Multicast verwendet wird. Die XCAST-Tabelle befindet sich nur auf dem MAR. Die Router von dem MAR zu den BSRs beinhalten keine XCAST-Tabelleneinträge, weder beinhalten sie irgendwelche Informationen über einen speziellen MN, ausgenommen das normale IP-Routing. Die Zwischenrouter müssen folglich keine großen Multicasttabellen verwalten. Die Zwischenrouter können die Replikation von Datagrammen in Abhängigkeit davon durchführen müssen, welcher Router der direkte Vorgänger der BSRs ist. Überwiegend würden nur diejenigen Router, die direkter Vorgänger der BSRs sind, die Replikation durchzuführen und den XCAST-Header zu ändern haben.
  • In Tabelle 4 weist MN1 eine mit ihm verbundene Multicast-Sitzung auf und der BSR1 ist ein Mitglied der Multicast- Sitzung. Das bedeutet, das MN1 unter der Versorgung von BSR1 ist und daß BSR1 die Registrierungsantwort von dem MN1 an den MAR weitergeleitet hat.
  • Der MAR legt dann entweder einen neuen Eintrag an oder kodifiziert/frischt einen vorhandenen Eintrag für den MN unter Verwendung der Registrierungsanforderung mit der BSR-Erweiterung auf. MN2 wird von BSR2 an BSR3 übergeben und weist folglich zwei BSR-Einträge auf, weil die Lebensdauer für die Einträge in der Regel länger als die Latenzzeit der Verbindungsübergabe ist.
  • Unterbrechungslos (Make-Before-Break)
  • Die Option Make-Before-Break hilft, Verbindungsübergaben zu erreichen, die erforderlich sind, damit die strengen Anforderungen der Latenzzeit des Echtzeitverkehrs erfüllt sind. MNs müssen die entsprechenden Flags während der Registrierung einstellen, um den MAR über seine Anforderung für die MBB-Option zu benachrichtigen. Der MAR kann in Abhängigkeit von der Last des Netzwerkes und der Verfügbarkeit von Ressourcen innerhalb der Domäne die Anforderung für MBB erteilen oder zurückweisen. Wenn der MAR der Anforderung für MBB zustimmt, dann ist es erforderlich, daß alle BSRs, die bedienen oder Nachbarn des BSR sind, der einen MN bedient, die MBB-Option implementieren. Wenn der MAR die Anforderung zurückweist, dann arbeiten die BSRs in der normalen Betriebsart.
  • BSRs, die Nachbar-Update-Nachrichten von ihren benachbarten BSRs empfangen, sind erforderlich, um einen Eintrag für den MN anzulegen, der die Sicherungsschichtinformationen des MN, seine CoA, Heimatadresse des MN und eine Lebensdauer, die mit dem Eintrag in ihrem wahrscheinlichen Cache verbunden ist, beinhaltet. Die BSRs schließen sich dann der Multicast-Sitzung für diesen speziellen MN an. Der MAR legt beim Empfangen der Verbindungsnachrichten von den BSRs einen Eintrag für den MN an, der die Heimatadresse des MN den BSRs zuordnet, die Verbindungsnachrichten an die Multicast-Sitzung des MN gesendet haben, auch wenn nur einer unter den mehreren BSRs den MN unter seiner Versorgung aufweist.
  • Tabelle 5 widerspiegelt die Einträge in der XCAST-Sitzungstabelle an dem MAR, wenn die MBB-Option verwendet wird. BSR1, BSR2, BSR3 und BSR4 sind alle Mitglieder der Multicast-Sitzung für MN1 (die Unicastadresse des MN wird als die Sitzungskennung verwendet), folglich würden alle von ihnen Datagramme empfangen, die für MN1 bestimmt sind. Aus dem Binding-Cache-Eintrag für den MN1 von Tabelle 1 ist es klar, daß MN1 durch BSR1 bedient wird. Folglich müssen BSR2, BSR3 und BSR4 die für MN1 bestimmten Datagramme verwerfen, wenn sie erst einmal die Datenpakete von dem MAR empfangen. Entsprechend würden BSR2, BSRS, BSR4 und BSR4 die für MN2 bestimmten Datagramme empfangen. Nur BSR2 sendet die Datagramme an MN2 und die anderen müssen die Datagramme verwerfen.
  • Tabelle 5: XCAST-Tabelleneinträge
    Figure 00820001
  • Figure 00830001
  • COMPUTERSOFTWAREMEDIEN (3800)
  • Die vorliegende Erfindung, wie in 13 erläutert ist (1310, 1320, 1330), antizipiert speziell, daß die hierin beschriebenen Protokolle und Verfahren in Computermedien integriert sein können, die durch ein oder mehr Computersysteme lesbar sind, ob sie Hauptzugriffsrouter (1310), Router (1320) und/oder Basisstationsrouter (1330) seien. Dieses maschinenlesbare Medium kann eine breite Vielzahl von Formen aufweisen, die weithin bekannt sind oder von einem Fachmann antizipiert sind.
  • Wie allgemein in 38 erläutert ist (3800), antizipiert die vorliegende Erfindung die verteilte Natur der Software wie in einer Vielzahl von maschinenlesbaren Medien verkörpert ist, ob sie in einem oder mehr Heimatagenten (3811) oder anderen Netzeinrichtungen seien, die durch das Internet (3821) über eine Reihe von Softwareprotokollen mit einer oder mehr Softwarekomponenten des Hauptzugriffsrouters (3831), Routers (3841) und/oder Softwarekomponenten des Basisstationsrouters (3851) mit einem oder mehr zusammenwirkenden Wireless-Geräten (3861) kommunizieren, die unter einem koordinierten Softwareprotokoll arbeiten, das in einem maschinenlesbaren Medium verkörpert ist.
  • SIGNALCODIERUNG (3900, 4000)
  • Für einen Fachmann wird klar sein, daß die Protokolle und Verfahren, wie durch die vorliegende Erfindung gelehrt, in einer breiten Vielzahl von Arten und Weisen codiert werden können und daß die resultierenden Signale, die diese Protokolle umfassen, in einer breiten Vielzahl von Netwerkkontexten gesendet werden können. Die vorliegende Erfindung antizipiert speziell, daß die hierin beschriebenen Protokolle und zugeordneten Verfahren auf die Netzsignalisierungs-Methodologien angewendet werden, um eindeutige Signalströme zu erzeugen, die verwendet werden können, um die mikromobilitätsbasierte Netzportabilität für verallgemeinerte IP-Signalisierung zu beeinflussen.
  • Innerhalb dieses Kontextes ist das allgemeine Signalflußdiagramm von 39 (3900) anwendbar. Hier kommuniziert ein Heimatagent (3910) oder andere Netzeinrichtung durch das Internet (3920) über eine Reihe von einem oder mehr Hauptzugriffsroutern (3930), Routern (3940) und/oder Basisstationsroutern (3950) mit einem oder mehr Wireless-Geräten (3960).
  • Wie in 40 erläutert ist (4000), entspricht die Signalisierung in diesem Kontext dem Protokoll der vorliegenden Erfindung, wie vorher beschrieben ist, und vereinigt im Allgemeinen Strukturen der Mobile Node Advertisement Extension (MNAE) (4001), Strukturen der Base Station Router (BSR) Extension (4002), Strukturen der Multicast Address Extension (MAE) (4003) und/oder Strukturen der Neighbor Update Extension (NUE) (4004).
  • SCHLUßFOLGERUNG
  • Ein mikromobilitätsbasiertes Netz-Routingsystem und Verfahren, das ein Protokoll implementiert, das die Makromobilitätsunterstützung von Mobile IP erweitert, um die Mikromobilität zu unterstützen, ist offenbart worden, was ein effizienteres und leichter implementiertes Internet-Routingprotokoll für zu beeinflussende Netzeinrichtungen ermöglicht. Das Makromobilitätsmerkmal hierin bezieht sich auf die Idee, in welcher der mobile Knoten Zugriff auf das Internet erlangt, während die gleiche IP-Adresse beibehalten wird. Diese Konzeption wird nur einmal verwendet, wenn der mobile Knoten den Versorgungsbereich einer Fremddomäne betritt (eventuell seine Heimatdomäne). Die Konzeption der Mikromobilität innerhalb dieses Kontextes erleichtert das Routing der Pakete an den mobilen Knoten, während er sich innerhalb des Fremdnetzes bewegt. Die vorliegende Erfindung implementiert diese neuen Merkmale über die Verwendung der Nachrichtenzusammensetzungen und Protokollerweiterungen, die die Mobile IP-Protokolle des Standes der Technik erweitern.
  • Der Hauptvorteil des Protokolls der vorliegenden Erfindung ist die geringe Latenzzeit, die in das Aufbauen einer Vermittlungsschichtverbindung zwischen dem MN und dem Fremdnetz eingebracht wird. Dies wird durch Nutzen der durch die Sicherungsschicht angebotenen Trigger erreicht, wenn eine Verbindungsübergabe vorkommt. Der andere Vorteil ist die Reibungslosigkeit der Verbindungsübergabe, die dieses Protokoll bietet. Die problemlose Verbindungsübergabe erfolgt infolge der Option Make-Before-Break und das wird durch Nutzen der Multicastingverfahren erreicht.
  • Das Protokoll der vorliegenden Erfindung bietet eine neue Lösung für das schwierige Problem der Mikromobilität an. Es sind mehrere andere Vorteile vorhanden, die dieses Protokoll im Vergleich zu den vorher erwähnten Lösungen bietet. Dieses Protokoll ist völlig transparent zu dem MN, der die Wireless-Domäne nicht merkt und den BSR wie einen "Pseudo"-Fremdagenten sieht. Die Verwendung von Multicast ermöglicht den Einsatz von MBB, das Vorteile im Fall von Echtzeitverkehr wie zum Beispiel Voice-over-IP präsentiert, obgleich es wichtig ist zu beachten, daß der Vorteil seine eigenen Nachteile aufweist. Der Hauptnachteil ist der nutzlose Verkehr, der an die BSRs erzeugt wird, die den MN nicht bedienen.
  • Ein Fachmann könnte angesichts der Lehren der vorliegenden Erfindung ohne weiteres eine Simulationsplattform aufbauen, um die Konzeption zu bestätigen und die Leistung des Protokolls zu messen. Es würde dann möglich sein sicherzustellen, daß die Latenzzeit der Verbindungsübergabe ausreichend klein ist, um eine effiziente Dienstgüte für den Endbenutzer anzubieten. Ein Fachmann könnte angesichts der Lehren der vorliegenden Erfindung ohne weiteres die Probleme ermitteln, die sich auf das Multicastrouting beziehen. Da jedoch das Kommunikationsprofil ein strenges Eins-zu-Wenige ist, kann das Protokoll der vorliegenden Erfindung das Multicast-Protokoll (XCAST) der kleinen Gruppe nutzen. Ein Fachmann könnte angesichts der Lehren der vorliegenden Erfindung ohne weiteres Optimierungen zu dem Basisprotokoll mit zusätzlichen Untersuchungsverfahren machen, die im Stand der Technik bekannt sind. Pagingerweiterungen auf der Basis von MMM werden als Teil dieser Verfahren antizipiert.
  • Patentansprüche
  • Obgleich eine bevorzugte Ausführungsform der vorliegenden Erfindung in den beigefügten Zeichnungen erläutert und in der vorhergehenden detaillierten Beschreibung beschrieben worden ist, wird es verstanden werden, daß die Erfindung nicht auf die offenbarten Ausführungsformen beschränkt ist, sondern imstande ist zu zahlreichen Neuanordnungen, Modifikationen und Substitutionen ohne von der Erfindung abzuweichen, wie durch die folgenden Patentansprüche dargelegt und definiert ist.
  • Figure 00870001
  • Figure 00880001
  • Figure 00890001
  • Figure 00900001
  • Figure 00910001
  • Figure 00920001
  • Figure 00930001
  • Figure 00940001
  • Figure 00950001
  • Figure 00960001
  • Figure 00970001
  • Figure 00980001
  • Figure 00990001
  • Figure 01000001
  • Figure 01010001
  • Figure 01020001
  • Figure 01030001
  • Figure 01040001
  • Figure 01050001

Claims (21)

  1. Ein mikromobilitätsbasiertes Netz-Routingverfahren, umfassend: Mitteilen von einer Basisstation, BS, an einen Basisstationsrouter, BSR, daß ein mobiler Knoten, MN, den Versorgungsbereich einer Wireless-Domäne, WD, betreten hat; Mitteilen der Charakteristika des MN von der BS an den BSR; Mitteilen der IP-Adresse des MN von dem BSR an einen Hauptzugriffsrouter, MAR; wobei das mikromobilitätsbasierte Netz-Routingverfahren eine Kommunikation zwischen einem Heimatagentmittel und einem Wireless-Gerätemittel überwacht, die über ein Internet-IP-Mittel erfolgt, gekennzeichnet durch: Mitteilen einer Multicastadresse, die dem MN von dem MAR zugeordnet wurde, an den BSR; Erzeugen eines Binding der Multicastadresse an den MN innerhalb des BSR; und Weiterleiten der Multicastadresse von dem BSR an einen benachbarten BSR des BSR; wobei der MAR die Pakete an die Multicastadresse tunnelt; jeder BSR, der sich der Multicastadresse angeschlossen hat, die Pakete empfängt; und nur der BSR, der ein Binding der Gruppenadresse an den MN aufweist, die Pakete an den MN weiterleitet.
  2. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei das Protokollmittel des mikromobilitätsbasierten Netz-Routings außerdem umfaßt: (a) Strukturen der Mobile Node Advertisement Extension (MNAE); (b) Strukturen der Base Station Router (BSR) Extension; (c) Strukturen der Multicast Address Extension (MAE); (d) Strukturen der Neighbor Update Extension (NUE); wobei die Strukturen die Mobil-IP-Kommunikationsprotokolle vergrößern, um die mikromobilitätsbasierte Netz-Routingfunktionalität und die IP-Konnektivität zwischen dem Heimatagentmittel und dem Wireless-Gerätemittel zu beeinflussen.
  3. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei das Heimatagentmittel ebenfalls ein Wireless-Gerätemittel ist.
  4. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei das Protokollmittel des mikromobilitätsbasierten Netz-Routings in der Software verteilt ist, die auf Hauptzugriffsroutern, Routern und Basisstationsroutern läuft.
  5. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei das Protokollmittel des mikromobilitätsbasierten Netz-Routings ein Folgeumschalt-Routingprotokoll implementiert.
  6. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei die Kommunikation über das Internet erfolgt.
  7. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei ein oder mehr Schritte des Verfahrens auf einem Personalcomputer (PC) implementiert sind.
  8. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei ein oder mehr Schritte des Verfahrens auf einem Wireless-Funksendeempfänger implementiert sind.
  9. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei das Wireless-Gerät innerhalb einer Fremdnetzdomäne arbeitet.
  10. Das mikromobilitätsbasierte Netz-Routingverfahren nach Anspruch 1, wobei das Wireless-Gerät innerhalb einer Heimatnetzdomäne arbeitet.
  11. Ein computernutzbares Medium, das computerlesbare Programmcodemittel aufweist, die mikromobilitätsbasierte Netz-Routingfunktionalität bereitstellen, wobei die computerlesbaren Programmcodemittel umfassen: Computerprogrammcodemittel zum Mitteilen von einer Basisstation, BS, an einen Basisstationsrouter, BSR, daß ein mobiler Knoten, MN, den Versorgungsbereich einer Wireless-Domäne, WD, betreten hat; Computerprogrammcodemittel zum Mitteilen von der BS an den BSR der Charakteristika des MN; Computerprogrammcodemittel zum Mitteilen einer IP-Adresse des MN von dem BSR an einen Hauptzugriffsrouter, MAR; wobei das mikromobilitätsbasierte Netz-Routingverfahren eine Kommunikation zwischen einem Heimatagentmittel und einem Wireless-Gerätemittel überwacht, die über ein Internet-IP-Mittel erfolgt, gekennzeichnet durch: Computerprogrammcodemittel zum Mitteilen einer Multicastadresse, die dem MN zugeordnet wurde, von dem MAR an den BSR; Computerprogrammcodemittel zum Erzeugen eines Binding der Multicastadresse an den MN innerhalb des BSR; und Computerprogrammcodemittel zum Weiterleiten der Multicastadresse von dem BSR an einen benachbarten BSR des BSR; wobei der MAR die Pakete an die Multicastadresse tunnelt; jeder BSR, der sich der Multicastadresse angeschlossen hat, die Pakete empfängt; und nur der BSR, der ein Binding der Multicastadresse an den MN aufweist, die Pakete an den MN weiterleitet.
  12. Das computernutzbare Medium nach Anspruch 11, wobei das Protokollmittel des mikromobilitätsbasierten Netz-Routings umfaßt: (a) Strukturen der Mobile Node Advertisement Extension (MNAE); (b) Strukturen der Base Station Router (BSR) Extension; (c) Strukturen der Multicast Address Extension (MAE); (d) Strukturen der Neighbor Update Extension (NUE); wobei die Strukturen die Mobil-IP-Kommunikationsprotokolle vergrößern, um die mikromobilitätsbasierte Netz-Routingfunktionalität und die IP-Konnektivität zwischen dem Heimatagentmittel und dem Wireless-Gerätemittel zu beeinflussen.
  13. Das computernutzbare Medium nach Anspruch 11, wobei das Heimatagentmittel ebenfalls ein Wireless-Gerätemittel ist.
  14. Das computernutzbare Medium nach Anspruch 11, wobei das Protokollmittel des mikromobilitätsbasierten Netz-Routings in der Software verteilt ist, die auf Hauptzugriffsroutern, Routern und Basisstationsroutern läuft.
  15. Das computernutzbare Medium nach Anspruch 11, wobei das Protokollmittel des mikromobilitätsbasierten Netz-Routings ein Folgeumschalt-Routingprotokoll implementiert.
  16. Das computernutzbare Medium nach Anspruch 11, wobei die Kommunikation über das Internet erfolgt.
  17. Das computernutzbare Medium nach Anspruch 11, wobei das Medium mit einem Personalcomputer (PC) kompatibel ist.
  18. Das computernutzbare Medium nach Anspruch 11, wobei das Medium mit einem Wireless-Funksendeempfänger kompatibel ist.
  19. Das computernutzbare Medium nach Anspruch 11, wobei das Wireless-Gerät innerhalb einer Fremdnetzdomäne arbeitet.
  20. Das computernutzbare Medium nach Anspruch 11, wobei das Wireless-Gerät innerhalb einer Heimatnetzdomäne arbeitet.
  21. Ein mikromobilitätsbasiertes Netz-Routingsystem, umfassend: (a) Heimatagentmittel; (b) Internet-IP-Mittel; (c) Protokollmittel des mikromobilitätsbasierten Netz-Routings; (d) Wireless-Gerätemittel; wobei das Heimatagentmittel mit dem Wireless-Gerätemittel über Internet-IP-Mittel unter der Kontrolle des Protokollmittels des mikromobilitätsbasierten Netz-Routings kommuniziert; und das Internet-IP-Mittel außerdem einen oder mehr Hauptzugriffsrouter, Router und/oder Basisstationsrouter umfaßt; und wobei das mikromobilitätsbasierte Netz-Routingsystem ein computernutzbares Medium umfaßt, das computerlesbare Programmcodemittel nach Anspruch 11 aufweist.
DE60216862T 2001-08-29 2002-08-05 System und Verfahren zum mikromobilitätsbasierten Netz-Routing Expired - Lifetime DE60216862T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US31684901P 2001-08-29 2001-08-29
US316849P 2001-08-29
US68525 2002-02-04
US10/068,525 US7339928B2 (en) 2001-08-29 2002-02-04 Micro-mobility network routing system and method

Publications (2)

Publication Number Publication Date
DE60216862D1 DE60216862D1 (de) 2007-02-01
DE60216862T2 true DE60216862T2 (de) 2007-10-18

Family

ID=26749058

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60216862T Expired - Lifetime DE60216862T2 (de) 2001-08-29 2002-08-05 System und Verfahren zum mikromobilitätsbasierten Netz-Routing

Country Status (5)

Country Link
US (1) US7339928B2 (de)
EP (1) EP1289223B1 (de)
CN (1) CN1298148C (de)
AT (1) ATE349128T1 (de)
DE (1) DE60216862T2 (de)

Families Citing this family (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7065576B2 (en) * 2001-09-27 2006-06-20 Matsushita Electric Industrial Co., Ltd. Dynamic multicast grouping for vehicles and other mobile objects
US8068832B2 (en) * 2001-11-19 2011-11-29 Nokia Corporation Multicast session handover
US7471661B1 (en) * 2002-02-20 2008-12-30 Cisco Technology, Inc. Methods and apparatus for supporting proxy mobile IP registration in a wireless local area network
US7478167B2 (en) * 2002-03-18 2009-01-13 Nortel Networks Limited Resource allocation using an auto-discovery mechanism for provider-provisioned layer-2 and layer-3 virtual private networks
US7346053B1 (en) * 2002-05-07 2008-03-18 Cisco Technology, Inc. Methods and apparatus for supporting IP multicast for a mobile router
JP4000933B2 (ja) * 2002-07-19 2007-10-31 ソニー株式会社 無線情報伝送システム及び無線通信方法、無線端末装置
DE60239016D1 (de) * 2002-08-21 2011-03-03 Spyder Navigations Llc Paket-weiterleitung an ein verbindungsorientiertes netzwerk
US7487199B2 (en) * 2002-09-24 2009-02-03 Motorola, Inc. Method and apparatus for maintaining SIP contact addresses
EP1408666A1 (de) * 2002-10-09 2004-04-14 Motorola, Inc. Rutierung in einem Datenkommunikationsnetz
US7599323B2 (en) * 2002-10-17 2009-10-06 Alcatel-Lucent Usa Inc. Multi-interface mobility client
US7499401B2 (en) * 2002-10-21 2009-03-03 Alcatel-Lucent Usa Inc. Integrated web cache
US20070208864A1 (en) * 2002-10-21 2007-09-06 Flynn Lori A Mobility access gateway
US7562393B2 (en) * 2002-10-21 2009-07-14 Alcatel-Lucent Usa Inc. Mobility access gateway
US7515561B2 (en) * 2002-11-12 2009-04-07 Nokia Corporation System and method for discovering network interface capabilities
GB2395629B (en) * 2002-11-20 2006-06-21 Motorola Inc Wireless communications systems and methods
US7505432B2 (en) * 2003-04-28 2009-03-17 Cisco Technology, Inc. Methods and apparatus for securing proxy Mobile IP
US7460855B2 (en) 2003-06-03 2008-12-02 Microsoft Corporation Selective pre-authentication to anticipated primary wireless access points
JP4076482B2 (ja) * 2003-07-02 2008-04-16 株式会社エヌ・ティ・ティ・ドコモ 移動ノード、移動通信システム及び通信制御方法
KR100561470B1 (ko) * 2003-10-18 2006-03-16 삼성전자주식회사 네트워크를 이용한 동보 인쇄방법 및 장치
US8655755B2 (en) * 2003-10-22 2014-02-18 Scottrade, Inc. System and method for the automated brokerage of financial instruments
DE60335748D1 (de) * 2003-11-19 2011-02-24 Nat Inst Inf & Comm Tech Funkkommunikationssystem
FR2863798A1 (fr) * 2003-12-12 2005-06-17 France Telecom Procede et systeme de diffusion multicast vers un terminal nomade en fonction de la localisation.
US20050159149A1 (en) * 2003-12-27 2005-07-21 Wen Kuei-Ann Network mobile communication device
FR2866498A1 (fr) * 2004-02-17 2005-08-19 Thomson Licensing Sa Methode de transmission d'un flux multipoint dans un reseau local et dispositif de connexion implementant la methode
US7545782B2 (en) * 2004-02-19 2009-06-09 Belair Networks, Inc. Mobile station traffic routing
EP1578059A1 (de) * 2004-03-19 2005-09-21 Swisscom Mobile AG WLAN Weiterreichung
US7924771B2 (en) * 2004-04-13 2011-04-12 Qualcomm, Incorporated Multimedia communication using co-located care of address for bearer traffic
WO2005122438A1 (en) * 2004-06-11 2005-12-22 Samsung Electronics Co., Ltd. System and method for fast network re-entry in a broadband wireless access communication system
JP3950874B2 (ja) * 2004-07-01 2007-08-01 株式会社東芝 ネットワーク接続装置、経路情報配布プログラム及び経路情報配布方法
WO2006016406A1 (ja) * 2004-08-12 2006-02-16 Fujitsu Limited 移動通信ネットワークシステム
US7940764B2 (en) * 2004-08-12 2011-05-10 Intel Corporation Method and system for processing multicast packets
KR100636318B1 (ko) * 2004-09-07 2006-10-18 삼성전자주식회사 ＣｏＡ 바인딩 프로토콜을 이용한 어드레스 오너쉽인증방법 및 그 시스템
US7676223B2 (en) * 2004-09-13 2010-03-09 Alcatel-Lucent Usa Inc. Method for controlling a flow of information between secondary agents and a mobile device in a wireless communications system
DE102004047692A1 (de) * 2004-09-30 2006-04-13 Siemens Ag Kommunikationssystem und Verfahren zur Bereitstellung eines mobilen Kommunikationsdienstes
DE102004057311B4 (de) * 2004-11-26 2007-12-20 T-Mobile International Ag & Co. Kg Verfahren und System zur Unterstützung von Dienstekontinuität für mobile Kommunikation über unterschiedliche Zugangsnetzwerke
GB2422072B (en) * 2005-01-10 2008-06-04 Motorola Inc A network node a communication node and a method of operation therefor
KR100597423B1 (ko) * 2005-01-25 2006-07-05 삼성전자주식회사 이동 아이피(Ｍｏｂｉｌｅ ＩＰ) 환경에 있어서,이동국(Ｍｏｂｉｌｅ Ｎｏｄｅ)의 등록 방법 및 상기방법에 의한 이동 아이피 네트워크 시스템
US20060227745A1 (en) * 2005-03-11 2006-10-12 Interdigital Technology Corporation Method and system for station location based neighbor determination and handover probability estimation
CN101199169A (zh) * 2005-04-28 2008-06-11 松下电器产业株式会社 交叉节点检测方法及利用计算机执行该方法用的交叉节点检测用的程序
JP4558577B2 (ja) * 2005-05-12 2010-10-06 パナソニック株式会社 パケット中継方法およびホームエージェント
KR100677591B1 (ko) * 2005-05-27 2007-02-02 삼성전자주식회사 Ｓｃｔｐ 기반의 핸드오버 기능을 구비한 단말장치 및핸드오버 방법
JPWO2007015539A1 (ja) * 2005-08-03 2009-02-19 パナソニック株式会社 クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末
US7965633B2 (en) 2005-12-12 2011-06-21 Alcatel-Lucent Usa Inc. Method of downlink rate control
US7899456B2 (en) * 2005-12-16 2011-03-01 International Business Machines Corporation Method for faster mobility handoff of a mobile node
US7969945B2 (en) * 2006-01-11 2011-06-28 Starent Networks Llc Systems and methods for mobility management on wireless networks
KR101185570B1 (ko) * 2006-03-04 2012-09-24 삼성전자주식회사 이동망 환경에서의 다중 인터페이스를 이용한 자원예약방법
US20070257354A1 (en) 2006-03-31 2007-11-08 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Code installation decisions for improving aggregate functionality
US8477683B2 (en) * 2006-04-13 2013-07-02 Qualcomm Incorporated Configuring a host device by way of MMP
US20070254677A1 (en) * 2006-05-01 2007-11-01 Motorola, Inc. Method and system to enable paging for mobile ip nodes
GB2438454B (en) * 2006-05-26 2008-08-06 Motorola Inc Method and system for communication
KR100734884B1 (ko) * 2006-07-11 2007-07-03 한국전자통신연구원 Ｉｅｅｅ ８０２．１６／와이브로 망상의 네이버 탐색프로토콜 메시지 전송 방법
US20080025256A1 (en) * 2006-07-26 2008-01-31 Boris Ginzburg Multicasting techniques in wireless networks
CN100596101C (zh) * 2006-08-31 2010-03-24 华为技术有限公司 一种本地移动性管理网络的报文路由方法和系统
US20080077491A1 (en) * 2006-09-21 2008-03-27 Geraldine Robinson Advertisement system and method
US8547891B2 (en) * 2006-10-10 2013-10-01 Qualcomm Incorporated Systems and methods for improving multicasting over a forward link
RU2474069C2 (ru) 2007-07-13 2013-01-27 Телефонактиеболагет Лм Эрикссон (Пабл) Способ сокращения сигнализации управления в ситуациях передачи обслуживания
GB2455978A (en) * 2007-12-24 2009-07-01 King S College London Packet-switched access networks
KR101030353B1 (ko) * 2008-12-23 2011-04-20 삼성전자주식회사 근거리 통신 환경에서 이동단말기의 경로를 탐색하는 장치 및 방법
US8385332B2 (en) * 2009-01-12 2013-02-26 Juniper Networks, Inc. Network-based macro mobility in cellular networks using an extended routing protocol
US8509815B1 (en) * 2009-05-21 2013-08-13 Sprint Communications Company L.P. Dynamically updating a home agent with location-based information
US20100309878A1 (en) * 2009-06-08 2010-12-09 Aleksandr Stolyar Mobility access gateway
US10039032B2 (en) * 2010-09-17 2018-07-31 Xieon Networks S.A.R.L. Method and device for processing data in a communication network
CN103916905A (zh) 2013-01-06 2014-07-09 中兴通讯股份有限公司 组播源的注册、组播路径的建立方法及装置
US9973986B2 (en) * 2013-01-17 2018-05-15 Intel IP Corporation Systems and methods for mobility optimization in a heterogeneous network
US9742798B2 (en) 2015-03-16 2017-08-22 Cisco Technology, Inc. Mitigating neighbor discovery-based denial of service attacks
US9363784B1 (en) * 2015-04-30 2016-06-07 Mist Systems Inc. Methods and apparatus relating to the use of real and/or virtual beacons
US10219166B2 (en) 2015-04-30 2019-02-26 Mist Systems, Inc. Methods and apparatus for generating, transmitting and/or using beacons
US10433153B2 (en) 2015-06-18 2019-10-01 Sony Corporation System, method, and terminal device
CN106658479B (zh) * 2016-11-16 2020-12-11 广东新岸线科技有限公司 一种无线网络融合的实现方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5325362A (en) 1993-09-29 1994-06-28 Sun Microsystems, Inc. Scalable and efficient intra-domain tunneling mobile-IP scheme
US5636220A (en) 1994-03-01 1997-06-03 Motorola, Inc. Packet delivery method for use in a wireless local area network (LAN)
CA2129197C (en) 1994-07-29 1999-11-09 Roger Y.M. Cheung Method and apparatus for connecting a wireless lan to a wired lan
JP2842524B2 (ja) 1996-06-06 1999-01-06 日本電気株式会社 マルチキャストグループ構成方法及びマルチキャスト通信ネットワーク
JP3090194B2 (ja) 1997-02-24 2000-09-18 日本電気株式会社 移動ホストのマルチキャスト通信方法
US6434134B1 (en) * 1998-12-11 2002-08-13 Lucent Technologies, Inc. Dynamic address assignment for wireless devices accessing packet-based wired networks
US6578085B1 (en) 1999-01-27 2003-06-10 Nortel Networks Limited System and method for route optimization in a wireless internet protocol network
WO2000054475A1 (en) 1999-03-09 2000-09-14 Telefonaktiebolaget Lm Ericsson (Publ) Multicast handover for mobile internet protocol
EP1204250A4 (de) 1999-07-22 2009-04-01 Hitachi Ltd Auf mobilen ip basierdes netsystem und verfahren zur vermittlung von verbindungen
AU7565000A (en) 1999-09-21 2001-04-24 Telefonaktiebolaget Lm Ericsson (Publ) System and method for call routing in an integrated telecommunications network having a packet-switched network portion and a circuit-switched network portion
JP4060021B2 (ja) * 2000-02-21 2008-03-12 富士通株式会社 移動通信サービス提供システム、および移動通信サービス提供方法
US20020075866A1 (en) * 2000-09-14 2002-06-20 Troxel Gregory Donald Delivering messages to a node at a foreign network
US6816912B1 (en) * 2000-12-01 2004-11-09 Utstarcom, Inc. Method and system for tunnel optimized call setup for mobile nodes

Also Published As

Publication number Publication date
DE60216862D1 (de) 2007-02-01
US7339928B2 (en) 2008-03-04
ATE349128T1 (de) 2007-01-15
EP1289223A2 (de) 2003-03-05
EP1289223B1 (de) 2006-12-20
CN1298148C (zh) 2007-01-31
EP1289223A3 (de) 2004-05-26
CN1407772A (zh) 2003-04-02
US20050213545A1 (en) 2005-09-29

Similar Documents

Publication Publication Date Title
DE60216862T2 (de) System und Verfahren zum mikromobilitätsbasierten Netz-Routing
DE10085302B3 (de) Mobile-IP für Mobil-Ad-Hoc-Netze
DE60310593T2 (de) Routing in einem datenkommunikationsnetz
DE60113735T2 (de) Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten
DE60211657T2 (de) System und verfahren für ein mobilitätsverwaltungsprotokoll mit geringem zusatzaufwand in einer internet protokollschicht
DE60020563T2 (de) Telekommunikationsvermittlung
DE102006015033B4 (de) Mobile Station als Gateway für mobile Endgeräte zu einem Zugangsnetz sowie Verfahren zur Netzanmeldung der mobilen Station und der mobilen Endgeräte
EP1391081B1 (de) Heterogenes mobilfunksystem
DE60034557T2 (de) Ip-routing-optimierung in einem zugriffsnetz
DE60317774T2 (de) Verfahren und vorrichtung zur clusterbildung von mobile ip home agents
US6804221B1 (en) Micromobility using multicast
DE60103942T2 (de) Lastausgleich in einem Telekommunikationssystem das Mobil IP unterstützt
DE602004008692T2 (de) Drahtloses lokales Netzwerksystem mit der Möglichkeit zur Unterstützung von mobilen Hosts und ein entsprechendes Betriebsverfahren
DE60205748T2 (de) Mehrfachsendung in punkt-zu-punkt-paketdatennetzwerken
DE60027566T2 (de) Leitweglenkung für Telekommunikation
DE69813743T2 (de) Protokoll für mobiles Internet
DE60218144T2 (de) Verfahren und Vorrichtung zur Routenoptimierung in geschachtelten mobilen Netzwerken
DE10297190B4 (de) Anordnungen und Verfahren in mobilen Internetkommunikationssystemen
DE60319071T2 (de) Vefahren zum datentransfer in mobil- und festtelekommunikationssystemen
DE602004003016T2 (de) Gerät in einem Netzwerk und Verfahren für einen stabilen Handoff in einem IP-basierten ad-hoc-Mobilfunknetzwerk
US7672288B1 (en) Arrangement for secure communication and key distribution in a telecommunication system
DE602004006918T2 (de) Methode zur Vorabreservierung einer neuen "Care-of"-Adresse für ein schnelles Handover in einer mobilen IPv6 Umgebung
DE112006003520T5 (de) Ein Verfahren zum Ändern der Verwendung eines Zugangspunkts (Access Point - AP) in einem drahtlosen Kommunikationsnetz
EP1271896A2 (de) Verfahren und System für mobile IP-Nodes in heterogenen Netzwerken
DE60133641T2 (de) Kommunikationssystem und verfahren 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