-
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
-
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
-
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
-
-
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
-
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
-
-
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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-