DE60113735T2 - Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten - Google Patents

Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten Download PDF

Info

Publication number
DE60113735T2
DE60113735T2 DE60113735T DE60113735T DE60113735T2 DE 60113735 T2 DE60113735 T2 DE 60113735T2 DE 60113735 T DE60113735 T DE 60113735T DE 60113735 T DE60113735 T DE 60113735T DE 60113735 T2 DE60113735 T2 DE 60113735T2
Authority
DE
Germany
Prior art keywords
node
mobile
nodes
access routing
partner
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60113735T
Other languages
English (en)
Other versions
DE60113735D1 (de
Inventor
Sandro Grech
Jaakko Rajaniemi
Pedro Serna
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Application granted granted Critical
Publication of DE60113735D1 publication Critical patent/DE60113735D1/de
Publication of DE60113735T2 publication Critical patent/DE60113735T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/34Modification of an existing route
    • H04W40/36Modification of an existing route due to handover
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/24Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248Connectivity information update
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/24Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/28Connectivity information management, e.g. connectivity discovery or connectivity update for reactive routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/087Mobility data transfer for preserving data network PoA address despite hand-offs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/14Mobility data transfer between corresponding nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/005Data network PoA devices

Description

  • GEBIET UND HINTERGRUND DER ERFINDUNG
  • Die Erfindung bezieht sich im Allgemeinen auf Mobile-IP (Internet-Protokoll) und insbesondere auf einen Mechanismus zum Überwinden von Problemen, die bei häufiger Änderung einer Zustelladresse durch den Mobilknoten (MN) mit Mobile-IP in Zusammenhang stehen.
  • Mobile-IP bzw. Mobiles IP ist eine Technologie, die es einem Mobilknoten (MN) wie etwa einem tragbaren Computer, einem Mobilfunktelefon oder einem Minicomputer bzw. „Personal Digital Assistant" ermöglicht, sich zu bewegen, während er dennoch seine Internet-Protokoll- (IP-) Adresse beibehält. Befindet sich der Mobilknoten in fremden Netzwerken, erhält der Korrespondenzknoten (CN) die momentane Adresse (CoA) vom Heimatagenten (HA). Der Korrespondenzknoten ist jeder beliebige Knoten (ein anderer Mobilknoten, ein fester Internetknoten oder irgendein Netzwerkelement), der ein Paket an den Mobilknoten sendet oder von diesem empfängt.
  • Da Mobile-IPv6 (MIPv6) die aktuelle Version von Mobile-IP ist, wird diese verwendet, um die Erfindung zu beschreiben. Es ist zu beachten, dass anstelle von Mobile-IPv6 ebenso Mobile-IPv4 verwendet werden kann.
  • MIPv6 ist über ein Ende-zu-Ende-Signalisierungsparadigma ausgelegt, bei dem sich nur der Heimatagent (HA) und die Korrespondenzknoten (CNs) an die Schicht 3- (L3-) Bewegung eines Mobilknotens (MN) anpassen. Aufgrund dessen ist Mobile-IPv6 mit verschiedenen Verwaltungsdaten bzw. Overheads konfrontiert, falls die Bewegung des MN zu häufig erfolgt. Im Fall häufiger Weiterreichungen zwischen drahtlosen Sendeempfängern, die kleine geografische Bereiche abdecken, können Verbindungsschichtmechanismen zur Verbindungserhaltung (d.h. Verbindungsschichtübergabe) eine schnellere Konvergenz und weniger Verwaltungsdaten bzw. Overheads als Mobile-IP bieten.
  • Angesichts des momentanen Trends, IP näher an die drahtlose Schnittstelle voran zu treiben, um eine vollständige IP-Infrastruktur zu entfalten, werden gerade mehrere Lösungen für dieses Problem basierend auf IP-Protokollen untersucht. Eine kurze Übersicht dieser Entwurfsvorschläge ist nachstehend aufgeführt.
  • Das Mobile-IPv6-Protokoll stützt sich auf Bindungsnachrichten (Bindungsaktualisierungen, Bindungsbestätigungen und Bindungsanforderungen), die zwischen dem MN und dem HA sowie dem CN versendet werden. Dies ermöglicht, eine Erreichbarkeit von MNs beizuhalten, während sie sich von Subnetz zu Subnetz bewegen und daher eine Zustelladresse (in eine, deren Präfix in diesem bestimmten Subnetz bekannt gemacht wird) ändern. Bindungsaktualisierungen (BUs) werden verwendet, um HAs und den CN bezüglich der momentanen Adresse des MN zu informieren. BUs verursachen an der Funkschnittstelle einen Signalisierungsoverhead und am Heimatagenten sowie am Korrespondenzknoten einen Verarbeitungsoverhead.
  • Lokale Mobilitätsverwaltungs- (LMM-) Protokolle sind für Umgebungen ausgelegt, bei denen mobile Hosts bzw. Leitrechner ihren Anschlusspunkt am Netzwerk (und folglich eine Zustelladresse) so häufig ändern, dass bei einem Netzwerk, das nur auf Basis-Mobile-IPv6 läuft, die folgenden unerwünschten Auswirkungen auftreten würden:
    Signalisierungsoverhead, Netzwerksignalisierungsoverhead, Verarbeitungsoverhead an den Partnerknoten, Signalisierungsoverhead über die Luft, Signalisierungsverzögerung und Paketverlust.
  • Im Hinblick auf einen Signalisierungsoverhead (Netzwerksignalisierungsoverhead, Signalisierungsoverhead über die Luft und Verarbeitungsoverhead an Partnerknoten) kann der Netzwerksignalisierungsoverhead in den meisten Fällen durch Synchronisation von Bindungsnachrichten mit Nutzlasten höherer Schichten (d.h. IP-Signalisierung zu bestehender Nutzlast huckepack nehmen) minimiert werden.
  • Infolge mehrerer BUs (Bindungsaktualisierungsnachrichten) über die Luftschnittstelle hinweg, wenn mehrere offene Sitzungen mit CNs bestehen, ist auch an der Luftschnittstelle ein Signalisierungsoverhead zu erkennen. Um eine dreieckige Leitweglenkung zu vermeiden, sollten Mobile-IPv6-MNs BUs an jeden dieser CNs senden. Eine dreieckige Leitweglenkung ist ein wohl bekanntes Problem, das auftritt, während sich der MN weit von seinem Heimatnetzwerk entfernt befindet und gerade mit einem CN kommuniziert, der sich nahe dem fremden Ort befindet. Jedes vom CN zum MN gesendete Datagramm verläuft zu einem HA, der das Paket dann an den MN weiterleitet. Daher verlaufen die Pakete über einen langen Weg anstatt über den kürzesten Pfad.
  • Ein Verarbeitungsoverhead an Partnerknoten kann an dem Heimatagenten oder an den Korrespondenzknoten insbesondere dann auftreten, wenn der Korrespondenzknoten eine große Anzahl von Mobilknoten bedient (z.B. ein Streaming-Server). Da der HA speziell dazu in das Netzwerk eingeführt ist, um eine Abbildungs- und Tunnelungsfunktionalität durchzuführen, die die Grundlage von Mobile-IPv6 bildet, sollte der HA zum Abwickeln großer Signalisierungsmengen ausgelegt sein. CNs könnten jedoch nicht gewillt sein, viel Verarbeitungsoverhead aufzuwenden, der durch Mobilität von MNs verursacht wird. Es wäre daher wünschenswert, die Mobilität eines MN so transparent wie möglich für CNs zu machen, ohne von diesem möglicherweise schwierige Verarbeitungsanforderungen zu verlangen (und ohne zu einer dreieckigen Leitweglenkung zurückzukehren).
  • Eine Signalisierungsverzögerung kann über lange Pfade hinweg auftreten, die zwischen dem Mobilknoten und dem Heimatagenten und allen Korrespondenzknoten bestehen. Bei Basis-Mobile-IPv6 müsste der Mobilknoten seinen Heimatagenten und alle Korrespondenzknoten, mit denen er aktive Bindungen hat, verständigen. Mit der Einführung eines lokalisierten Mobilitätsverwaltungs- (LMM-) Protokolls wird diese Verzögerung reduziert.
  • Die Einführung von LMM in jeglicher zukünftiger Architektur kann als ein Overhead angesehen werden, besonders wenn das Protokoll komplex ist. Die vorliegenden Lösungen (hierarchisches Mobile-IPv6 (HMIPv6), Mobile-IPv6 mit regionalen Registrierungen (MIPv6RR)) erschweren den Betrieb von Mobile-IPv6 auf die folgenden Arten:
    • – Einführung des Erfordernisses von Erweiterungen bei Bekanntmachungen,
    • – Einführung neuer oder modifizierter Bindungsnachrichten,
    • – Zusätzliche Knotenfunktionalität (Gateway-Mobilitätsagent (GMA)/Mobilitätsankerpunkt (MAP), usw.),
    • – Erfordernis von Konfigurationen (von denen einige manuelle Konfigurationen sind, z.B. muss bei MIPv6RR jeder bereichsbewusste Leitweglenkungsknoten manuell mit der IP-Adresse der unmittelbaren Nachfolger-Leitweglenkungsknoten konfiguriert werden),
    • – Erfordernis von Sicherheitsverknüpfungen unter diesen Knoten,
    • – Erhöhte Funktionalität im Mobilknoten, usw.
  • Es hat auch zunehmende Bedenken gegeben bezüglich der Größe von Bindungscachespeichern innerhalb von GMA/MAP (die als die Funktion des SGSN bei GPRS nachahmend angesehen werden können). Dies führt auch einzelne Störungsstellen in die Hierarchie ein, die natürlich unerwünscht sind. Fällt ein hierarchischer Agent aus, ist das gesamte Randnetzwerk beeinträchtigt. Während dieses Problem durch Wiederholungsmechanismen angegangen werden kann, führen diese Mechanismen eine zusätzliche Komplexität ein.
  • Die hierarchischen LMMs tendieren dazu, sogar noch mehr Signalisierung über die Luft zu benötigen, was betrifft:
    • – Erweiterungen bei Leitweglenkungsknoten-Bekanntmachungen (zusätzliche 28 Bytes für jeden MAP im Fall von HMIPv6 oder zusätzliche 24 Bytes für jede bekannt gemachte regionale Zustelladresse bei MIPv6RR);
    • – Erweiterungen bei Bindungsaktualisierungen, um einen regionalen Bindungsaktualisierungsbetrieb durchzuführen (20 Bytes für die Unteroption „vorheriger Zugangsleitweglenkungsknoten" bei MIPv6RR; dies ist erforderlich, um zu bestimmen, welcher Leitweglenkungsknoten der Übergangs-Leitweglenkungsknoten ist);
    • – Tunnelungsoverhead (zusätzliche 40 Bytes für den Tunnelungs-IPv6-Nachrichtenkopf für jedes Datenpaket, das bei HMIPv6 über die Luft versendet wird; ein Tunnelungsoverhead wird bei MIPv6RR durch den Adressenwechsel bzw. -austausch bei dem regionalen Weiterleitungsmechanismus überwunden).
  • Es sollte beachtet werden, dass Schemata bzw. Maßnahmen wie etwa eine Nachrichtenkopfkomprimierung die ersten beiden vorstehend genannten Overheads nicht überwinden. Jedes Mal, wenn eine Bewegung stattfindet, muss infolge einer sich ändernden Zustelladresse jeder Kontext wiederhergestellt werden und ist mindestens ein Paket pro Sitzung unkomprimiert. Sogar für einen CN kann es mehrere Komprimierungssitzungen geben (VoIP über RTP über UDP, Video über RTP über UDP sind zwei unterschiedliche Kontexte). Ein Transferieren oder Neustarten vieler Kontexte verursacht auch einen Verwaltungsoverhead. Experimente zeigen, dass der Neustartoverhead in der Größenordnung von 6 Paketen liegen kann.
  • Die Luftschnittstellenausnutzung kann sowohl durch HMIPv6 als auch durch damit einhergehendes MIPv6RR reduziert werden, da im Gegensatz zu dem Fall von Basis-Mobile-IP, bei dem mehrere Bindungsaktualisierungen gesendet werden müssen – eine zum Heimatagenten und eine zu jedem Korrespondenzknoten, nur eine (regionale) Bindungsaktualisierung an den MAP/GMA oder den Übergangs-Leitweglenkungsknoten gesendet werden muss.
  • Eine lokalisierte Mobilitätsverwaltung begrenzt eine Signalisierung auf kurze Pfade und reduziert daher die Wahrscheinlichkeit eines Paketverlusts.
  • Das Signalisierungsverzögerungs- und das Paketverlustproblem können durch das Protokoll schneller Weiterreichungen (oder einen ähnlichen Mechanismus) bewältigt werden.
  • Angesichts der vorstehend umrissenen Probleme wurden vor allem in der MobileIP-Arbeitsgruppe (WG) bei IETF mehrere Lösungen basierend auf unterschiedlichen Prinzipien vorgeschlagen. Im Allgemeinen versuchen LMMs (ehemals bekannt als Mikromobilitätsprotokolle) die mit dem Basis-Mobile-IPv6-Protokoll in Zusammenhang stehenden vorstehend genannten Overheads zu überwinden, wenn Mobilknoten ihre Zustelladresse (CoA: „care-of-address") häufig ändern. Aktuelle LMM-Entwurfsvorschläge innerhalb von IETF können allgemein wie folgt klassifiziert werden:
    • 1) LMMs, die auf einer Hierarchie wie gemäß 1 gezeigt basieren. Diese Hierarchie-LMMs basieren auf Erweiterungen von Mobile-IP und bestehen momentan aus „Hierarchisches Mobile-IPv6" (HMIPv6) und „Mobile-IPv6 mit Regionalen Registrierungen" (MIPv6RR). Diese LMMs erzeugen eine virtuelle Flaute bei der schnellen Bewegung von MNs aus Sicht von Partnerknoten außerhalb der besuchten Domäne. Dies wird durch Verwendung von zwei Zustelladressen erreicht; eine regionale und eine lokale, von denen sich nur die letztere bei jeder AR-Änderung ändert. Der Bereich, in dem ein MN die gleiche regionale Zustelladresse beibehalten darf, basiert auf Erweiterungen von über die Luft gesendeten Mobile-IPv6-Leitweglenkungsknoten-Bekanntmachungen, die Domänen abgrenzen, in denen unterschiedliche regionale Zustelladressen verwendet werden können.
    • 2) LMMs basierend auf Host-Leitwegen. Ein typisches Beispiel dieser Klasse von LMMs ist Zellular-IP. Diese LMMs ermöglichen es auch, dass Mobile-IPv6 als das „Makromobilitäts"-Protokoll tätig ist, aber sie basieren nicht auf Erweiterungen von Mobile-IPv6. Ein MN behält die gleiche (topologisch unrichtige) IP-Adresse bei, während er sich über Ars hinweg bewegt, die zu der gleichen Domäne gehören. Die Erreichbarkeit des MN wird durch Erzeugung von Host-Leitwegen innerhalb der Domäne aufrecht erhalten. Der Hauptnachteil bei diesen Vorschlägen ist die Skalierbarkeit, wenn Leitweglenkungstabellen eine große Anzahl von sich schnell ändernden Host-Leitwegen enthalten (Leitweglenkungstabelleneinträge mit Subnetzmaske/128).
    • 3) LMMs basierend auf Tunnelung über den Rand des Netzwerks hinweg. Momentan gibt es bei IETF keine auf diesem Modell basierenden Vorschläge. Ein Mechanismus, der Weiterleitungspfade zwischen Zustelladressen eines MN erzeugt, kann die Reibungslosigkeit einer Übergabe bei Mobile-IPv6 verbessern.
  • Im Allgemeinen führt Mobile-IPv6 mit regionalen Registrierungen eine regionale und eine primäre (Strecken-) CoA ein. Die regionale CoA ist die CoA, wie sie von außerhalb der besuchten Domäne gesehen wird, und bleibt gleich, während der MN innerhalb einer besuchten Domäne (GMA) bleibt. Die primäre CoA ermöglicht, die regionalen Bewegungen des MN zu verfolgen, aber ihre Änderung ist über den Gateway-Mobilitätsagenten (GMA) hinaus transparent.
  • Hierarchisches Mobile-IPv6 reduziert eine Mobilitätssignalisierung mit externen Netzwerken durch Einsatz einer lokalen hierarchischen Struktur, die auf der Einführung eines neuen Agenten basiert, der Mobilitätsankerpunkt (MAP) genannt wird. Dieser Agent ist im Wesentlichen als ein lokaler HA für einen MN tätig, den er bedient. Die Domänegrenzen eines MAP sind durch die ARs definiert, die die MAP-Informationen an die angeschlossenen MNs bekannt machen. Ein MAP kann zwei unterschiedliche Betriebsarten aufweisen. In einer „Grundbetriebsart" bildet ein MN eine Regional-CoA (RCoA) auf dem Subnetz des MAP und eine Strecken-CoA (LCoA). Die Paketlieferung an den MN wird durch Abfangen und Einkapseln am MAP erreicht. In einer „erweiterten Betriebsart" kann ein MN eine Adresse des MAP als Ausweich-CoA verwenden. Die Paketlieferung wird durch Eitkapselung und durch Neueinkapselung der Pakete am MAP erreicht.
  • Ein GMA (der bei Mobile-IPv6 mit regionalen Registrierungen verwendet wird) und ein MAP (der bei hierarchischem Mobile-IPv6 verwendet wird) sind Knoten, die die Abbildung zwischen der regionalen Zustelladresse und der lokalen Zustelladresse enthalten und die Tunnelung oder Weiterleitung zwischen diesen Adressen erledigen. Ein MAP kann durch einen Leitweglenkungsknoten bzw. Router in einem besuchten Netzwerk implementiert werden, und ein GMA durch ein Softwaremodul in den Leitweglenkungsknoten bzw. Router.
  • Das Basis-Mobile-IPv6 verwendet die vorhergehende Leitweglenkungsknoten-Benachrichtung, die die neue Zustelladresse mit der vorhergehenden Zustelladresse am alten Zugangsleitweglenkungsknoten bindet, als ob die letztere eine Heimatadresse wäre. Dies verursacht eine Einkapselung von Verkehr, der für die alte Zustelladresse bestimmt ist, an die neue Zustelladresse als die äußere Einkapselungszieladresse. Dieser Weiterleitungstunnel wird normalerweise erst aufgebaut, nachdem der MN an der neuen Verbindung ankommt (wobei dieser Mechanismus bei schnellen Weiterreichungen für Mobile-IPv6 weiter optimiert ist). Dies löst jedoch nicht den Ende-zu-Ende- Signalisierungsoverhead auf, der im vorherigen Abschnitt beschrieben wurde, sondern löst lediglich das Verzögerungs- und das Paketverlustproblem (d.h. der Mobilteilnehmer wird mit dem Dienst zufrieden sein, aber der Netzwerkbetreiber wird immer noch mit Netzwerkoverhead infolge häufiger Ende-zu-Ende-Signalisierung konfrontiert sein).
  • Zellular-IPv6 und HAWAII schlagen Mechanismen vor, die auf Host-Leitwegeinträgen (/128 Bit-Netzmaske) in Leitweglenkungstabellen basieren. Es wurde weitgehend akzeptiert, dass diese Vorschläge mit schwerwiegenden Skalierbarkeitsproblemen infolge der Instabilität konfrontiert sind, die durch eine große Anzahl sich schnell ändernder Leitweglenkungstabelleneinträge verursacht wird. Es sollte auch beachtet werden, dass HAWAII auf Mobile-IPv4 zugeschnitten ist.
  • In „Threshold-Based Registration (TBR) in Mobile IPv6" (L. Yang et al., „Threshold-Based Registration in Mobile IPv6", IFIP-TC/6 European Commission NETWORKING 2000 International Workshop, MWCN 2000, Paris, Frankreich, Mai 2000) richtet der MN Weiterleitungspfade von seiner unmittelbar vorhergehenden Zustelladresse ein. Erst nach einer festen Anzahl unmittelbarer Weiterleitungsschritte richtet der MN direkte Weiterleitungspfade von der primären Zustelladresse (an dem Ankerheimatagenten) ein, und erst nach einer Anzahl direkter Weiterleitungsschritte von seiner primären Zustelladresse wird der MN eine neue primäre Zustelladresse an seinem HA registrieren. Das Ziel dieses Mechanismus besteht darin, die Reibungslosigkeit einer Übergabe bei Mobile-IPv6 zu verbessern.
  • Unabhängig von den vorstehend aufgelisteten lokalen Mobilitätsmechanismen ermöglichen schnelle Weiterreichungen für Mobile-IPv6 einem Mobilknoten, eine neue Zustelladresse zu konfigurieren, bevor er sich zu einem neuen Zugangsleitweglenkungsknoten bewegt, so dass er diese neue Zustelladresse unmittelbar nach einer Verbindung mit dem neuen Zugangsleitweglenkungsknoten verwenden kann. Schnelle Weiterreichungen ermöglichen zusätzlich den Aufbau eines temporären Weiterleitungspfads zwischen dem alten Zugangsleitweglenkungsknoten und dem neuen Zugangsleitweglenkungsknoten. Daher können schnelle Weiterreichungen die vorstehend beschriebenen Verzögerungs- und damit einhergehenden Paketverlustprobleme lindern. Schnelle Weiterreichungen zielen nicht darauf ab, das Signalisierungsoverheadproblem zu überwinden.
  • Die Druckschrift „draft-ietf-mobileip-fast-mipv6-03.txt" beschreibt Mobile-IPv6, das einem Mobilknoten MN ermöglicht, seine Verbindungsfähigkeit bzw. Konnektivität zum Internet beizubehalten, während er sich von einem Zugangsleitweglenkungsknoten AR zu einem anderen bewegt. Dieser Prozess wird als Weiterreichung bezeichnet. Gemäß dieser Druckschrift sollte der MN, wann immer er kann, eine neue Zustelladresse CoA erhalten und Bindungsaktualisierungen zum Aktualisieren der Bindungsinformationen mit neuen CoA-Informationen an Korrespondenzknoten und den Heimatagenten wie bei Mobile-IPv6 spezifiziert senden. Ist der MN (aus verschiedenerlei Gründen, wobei einer der Gründe darin besteht, dass er nicht in der Lage ist, eine neue CoA zu erhalten) unfähig, Bindungsaktualisierungen an die Korrespondenzknoten bzw. den Heimatagenten zu senden, und muss der MN eine Übergabe durchführen, sind bei dieser Weiterreichung drei Seiten bzw. Parteien beteiligt (wobei diese Übergabe als dreiseitige bzw. Dreiparteienübergabe bezeichnet wird). Die Unfähigkeit, eine MIP-Registrierung durchzuführen, kann sich entweder aus einer speziellen Entscheidung durch den MN infolge eines anhaltenden Echtzeit-Medienstroms ergeben oder kann sich aus einer schnellen Bewegung zwischen altem AR oAR und neuem AR nAR ergeben, die nicht ausreichend Zeit gewährt, um die Registrierung abzuschließen. Ein anderes Verfahren erfordert einen L2-Auslöser am oAR vor einem L2-Weiterreichungsbeginn oder einen L2-Auslöser vor einem L2-Weiterreichungsabschluss am nAR, sowie einen L2-Auslöser am oAR, nAR und MN unverzüglich bei Abschluss einer L2-Weiterreichung.
  • Der durch die Erfindung vorgelegte Mechanismus erweitert den Betrieb derart, dass er unter anderem das Overheadproblem löst oder zumindest verringert.
  • Die Erfindung stellt ein Verfahren gemäß Anspruch 1 oder einem der abhängigen Ansprüche 2 bis 11 bereit. Die Erfindung stellt ferner ein System gemäß Anspruch 12 oder einem der abhängigen Ansprüche 13 bis 20 bereit.
  • Die Entscheidung darüber, ob der erste Zugangsleitweglenkungsknoten (AR1) als Anker-Zugangsleitweglenkungsknoten tätig sein soll, kann von dem Mobilknoten, vom Netzwerk oder von einer Instanz im Zugangsnetzwerk getroffen werden. Die Instanz im Zugangsnetzwerk ist vorzugsweise ein Zugangsleitweglenkungsknoten. Eine funktionalität eines Zugangsleitweglenkungsknotens kann zum Beispiel in der Basisstation oder einem GPRS-Unterstützungsknoten implementiert sein. Der Zugangsleitweglenkungsknoten kann ebenfalls eine separate Instanz sein.
  • Die maximale Anzahl von Weiterreichungen, für die der gleiche Anker-Zugangsleitweglenkungsknoten beibehalten wird, ist vorzugsweise auf einen vordefinierten oberen Grenzwert beschränkt.
  • Einige Beispiele der in Ansprüchen 2, 13 genannten Kriterien: Die Verkehrsaktivität zwischen dem Knoten (CN1, CN2, ..., CNn) und dem Mobilknoten (MN) will sagen, dass die Entscheidung getroffen wird, um unnötige Signalisierung oder unnötigen Verkehr zwischen dem MN und Partnerknoten zu vermeiden. Sie kann auch bedeuten, dass eine Kostenfunktion zwischen der Signalisierung zwischen Partnerknoten und Zugangsleitweglenkungsknoten sowie der Signalisierung zwischen unterschiedlichen Zugangsleitweglenkungsknoten vorliegt.
  • Protokollschichten 1 und 2 meinen die Protokollschichten unterhalb einer IP-Schicht, zum Beispiel Luftschnittstellenprotokolle (einschließlich Funkressourcensteuerung) und physikalische Schicht. Allgemeiner gesagt können die Schichten beliebige „unterliegende Schichten" sein, was nicht nur „Protokollschichten 1 und 2" meint (zum Beispiel GSM/CDMA einschließlich Funkressourcensteuerung und physikalischer Schicht). Die „unterliegenden Schichten" meinen grundsätzlich alles unterhalb der IP-Schicht. Es kann sich um ein Funkressourcensteuerprotokoll und um L1 handeln, aber im Vergleich zu GSM/WCDMA können sie auch ein Protokoll wie etwa SM, GMM, usw. umfassen.
  • Beispiele von Funkzugangsnetzwerken sind CDMA- oder TDMA-basierte Funkzugangsnetzwerktechnologien.
  • Die vorstehende Funktionalität kann, sogar nachdem sich der MN zu ARn bewegt hat, durch zwei optionale Mechanismen erweitert werden, wobei beim ersten dieser eine Kette von Tunnels zwischen dem Anker-Zugangsleitweglenkungsknoten und dem aktuellen Zugangsleitweglenkungsknoten erzeugt wird und bei der zweiten Option ein einziger Tunnel zwischen dem Anker-Zugangsleitweglenkungsknoten und dem aktuellen Zugangsleitweglenkungsknoten erzeugt wird. Die Entscheidung darüber, ob BUs zu senden sind, basiert vorzugsweise immer auf den in Ansprüchen 1, 2 beschriebenen Kriterien und darauf getroffen, wie oft die CoA geändert wurde, ohne den HA und die CNs zu benachrichtigen (um übermäßig lange Weiterleitungspfade zu vermeiden).
  • Ein nachfolgend als Anker-Zugangsrouter bezeichneter Anker-Zugangsleitweglenkungsknoten (AAR) ist der Router, der für die Zustelladresse (CoA) des Mobilknotens (MN) verantwortlich ist, die für den Heimatagenten (HA) und die Korrespondenzknoten (CN) sichtbar ist, während der MN an einem anderen Zugangsrouter (AR) außer dem AAR auf einer Funkschicht (und auf einer IP-Schicht über eine zweite CoA, die für den HA und die CNs nicht sichtbar ist) angeschlossen ist. Es können viele HAs ebenso wie CNs bereitgestellt sein, die anhaltende Sitzungen mit dem MN haben.
  • Genauer gesagt kann, wenn sich der Mobilknoten bewegt hat und einen neuen Zugangsrouter als Anker-Zugangsrouter ausgewählt hat, eine Bindungsaktualisierungsnachricht immer an den vorhergehenden Zugangsrouter gesendet werden, wobei die Entscheidung darüber, ob Bindungsaktualisierungsnachrichten zu senden sind, immer auf den in Ansprüchen 1, 2 genannten Kriterien und/oder darauf basiert, wie oft eine Zustelladresse (CoA) geändert wurde, ohne einen Partnerknoten zu benachrichtigen. Wahlweise kann eine Bindungsaktualisierungsnachricht, wenn sich der Mobilknoten bewegt hat und einen neuen Zugangsrouter als Anker-Zugangsrouter ausgewählt hat, immer an den Anker-Zugangsrouter gesendet werden, wobei die Entscheidung wiederum auf den eben erwähnten Kriterien basiert.
  • Die Erfindung verringert die Menge von mit Mobile-IP in Beziehung stehender Signalisierung zwischen (sich möglicherweise schnell bewegenden) Mobilknoten (MNs) und ihren Partneragenten (HA, CNs).
  • Zusätzlich zu der Verringerung von Signalisierung zwischen Zugangsroutern und den Partnerknoten verringert die Erfindung gemäß einem Aspekt auch die Signalisierung auf der Luftschnittstelle, während sich der MN im Ruhezustand befindet. (Weil der MN die BUs über die Luft nicht versenden muss, ist es ausreichend, dass die RRA-(RAN-Registrierungsbereich, wobei dieser ähnlich einem UTRAN-Registrierungsbereich ist) Aktualisierungen versendet werden.)
  • Bei einem typischen Funkzugangsnetzwerk ist ein Registrierungsbereich (RRA) eine Menge von Zugangsroutern (und IP-BTS, falls AR und IP-BTS kombiniert sind), die zu dem gleichen RRA gehören. Ein RRA ist ein Konzept eines L2-Bereichs und ist auf der IP-Ebene nicht zu sehen. Benachbarte RRAs können gegenseitig überlappen.
  • Gemäß einer bevorzugter Implementierungen der Erfindung sind ein Verfahren und ein Mechanismus bereitgestellt zum Verringern der Anzahl von Bindungsaktualisierungen, die von einem sich schnell bewegenden MN an seinen HA und seine CNs gesendet werden, auf eine garantierte Höchstfrequenz. Der Verarbeitungsoverhead an dem HA sowie den CNs und der Signalisierungsoverhead über die Luft werden so minimiert. Es wird auch ein Rahmen für einen Funkrufmechanismus zum Reduzieren eines Signalisierungsoverheads vorgelegt, der von Mobile-IP verursacht wird, um in Ruhe befindliche MNs zu verfolgen. Die Signalisierungsverzögerung und der Paketverlust können ebenfalls reduziert werden. Die Minimierung von Signalisierungsverzögerung und Paketverlust kann auch dem Mechanismus schneller Weiterreichungen für Mobile-IPv6 überlassen werden, wie er z.B. in dem entsprechenden Internet-Draft von IETF („Internet Engineering Task Force") spezifiziert ist.
  • Die Erfindung führt ein Verfahren und einen Mechanismus ein, die auf einer Zugangsrouter- (AR-) Verankerung basieren, die auf Erweiterungen des Mechanismus schneller Weiterreichungen aufbaut. Es werden unterschiedliche Heuristiken vorgelegt, mittels derer der Anker-Zugangsrouter (AAR) verlegt werden könnte. Es werden zwei Optionen beschrieben, die zum Vermeiden mehrerer Ebenen erneuter Einkapselung verwendet werden können, was möglicherweise durch eine mehrfache Weiterleitung verursacht werden kann.
  • Gemäß einem weiteren Aspekt der Erfindung sind ein zugehöriges Verfahren und ein zugehöriger Mechanismus bereitgestellt, um einen Funkruf zu unterstützen, wenn sich ein MN im Ruhemodus befindet, wodurch ein unnötiger Netzwerkoverhead begrenzt wird, der zum Verfolgen in Ruhe befindlicher MNs verwendet wird, und auch die Batterielebensdauer der MN erhöht wird.
  • Da das Verfahren und der Mechanismus gemäß einer bevorzugten Implementierung der Erfindung auf der IP-Schicht arbeiten, sind sie auch für eine lokalisierte Mobilitätsverwaltung über homogene Medien hinweg ebenso wie für Mobilität über heterogene Medien hinweg geeignet (z.B. von einem AR mit WCDMA-basiertem/n Zugangspunkt/en zu einem AR mit WLAN-basiertem/n Zugangspunkt/en).
  • Vorteile der Struktur und des Verfahrens gemäß der Erfindung gegenüber hierarchischen LMMs sind die folgenden:
    • – Kein Erfordernis von Konfigurationen (Bei den momentanen Entwürfen hierarchischer LMM, z.B. bei MIPv6RR, muss jeder bereichsbewusste Router in der Hierarchie mit den Adressen der direkten Nachfolger konfiguriert werden.);
    • – Kein Erfordernis von Erweiterungen bei Router-Bekanntmachungen, die Funkressourcen einnehmen;
    • – Kein Erfordernis zusätzlicher Bindungsaktualisierungen (oder Erweiterungen bei Bindungsaktualisierungen) über die Luft (zusätzlich zu denjenigen, die von Mobile-IPv6 und schnellen Weiterreichungen benötigt werden);
    • – Die ganze Funktionalität, die zum Begrenzen der Ausbreitung von BUs aus Partnerknoten notwendig ist, kann in den Zugangsroutern bereitgestellt werden. Der Mechanismus ist für den Rest des Internets transparent, wodurch alle Router im Netzwerk standardmäßige IP-Router sein können;
    • – Es gibt keinen einzelnen Wurzel- bzw. Stammknoten in oberster Ebene der Hierarchie, der als der GMA/MAP tätig ist. Der Tunnelendpunkt im Fall flacher LMM ist für unterschiedliche MNs über unterschiedliche Ars hinweg verteilt. Dies führt zu einer besseren Skalierbarkeit;
    • – Kein Erfordernis zum Aufbauen einer zweiten Zustelladresse (regionale CoA-Zustelladresse) (Bei HMIPv6 ist dies explizit – ein MN hat eine eindeutige regionale CoA mit der ganzen zugehörigen Signalisierung aufzubauen. Bei MIPv6RR ist dies kein solches Problem, da alle MNS unter dem gleichen GMA die gleiche regionale CoA verwenden.);
    • – Die von der Erfindung bereitgestellte flache lokalisierte Mobilitätsverwaltung erfordert nur sehr geringfügige Änderungen an Mobile-IPv6 und schnellen Weiterreichungen für Mobile-IPv6 (kein Erfordernis eines vollständig neuen Protokolls);
    • – Die von der Erfindung bereitgestellte flache lokalisierte Mobilitätsverwaltung ist nicht abhängig von Domänen, die durch Erweiterungen bei Mobile-IPv6-Router-Bekanntmachungen bekannt gemacht werden, sondern von Zeitgebern, die die Frequenz begrenzen, mit der ein MN BUs an seinen HA und seine CNs senden darf. Dieses Merkmal kann verwendet werden, um zu gewährleisten, dass BUs an dem HA und den CNs nicht mit einer Frequenz empfangen werden, die höher ist als ein bestimmter Schwellenwert. Dieser Vorteil ist mit hierarchischen LMMs basierend auf Domäne-Bekanntmachungen nicht möglich;
    • – Vereinfachte Sicherheitsverknüpfungen zwischen Netzwerkelementen und Mobilknoten. Der MN kann entweder wie bei Basis-Mobile-IPv6 arbeiten oder kann BUs an vorhergehende Zugangsrouter senden, mit denen er bereits vorher kommuniziert hat. Daher besteht kein Erfordernis, komplexe Schlüsselverteilungsmechanismen einzuführen und sich auf diese zu stützen;
    • – Bei den lokalen Mobilitätsagenten sind weniger Zustände erforderlich, da Zustände nur für sich schnell bewegende MNs benötigt werden. Zustände für sich langsam bewegende MNs werden nur an den HA und/oder den CNs beibehalten.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 veranschaulicht einen grundlegenden Aufbau eines Kommunikationssystems und skizziert den grundlegenden Betrieb von LMMs basierend auf einer Hierarchie,
  • 2 zeigt einen Betrieb eines hypothetischen Netzwerks unter Verwendung von Basis-Mobile-IP und schnellen Weiterreichungen (ohne LMM),
  • 3 zeigt das Funktionsprinzip eines Ausführungsbeispiels gemäß der Erfindung für ein Verfahren und System, die den vorgeschlagenen flachen LMM-Mechanismus berücksichtigen (Option 2),
  • 4 und 5 zeigen Signalisierungsdiagramme für den flachen LMM-Mechanismus von Ausführungsbeispielen für Option 1 und Option 2 gemäß der Erfindung,
  • 6 bezieht sich auf einen IP-Abschluss am Zugangsrouter (d.h. IP-BTS), wobei 2 Ebenen auf L2 und IP verfolgt werden,
  • 7 veranschaulicht ein bevorzugtes Ausführungsbeispiel der Erfindung und zeigt das Gesamtprinzip einer Trennung von L2 von der L3,
  • 8 veranschaulicht die Trennung von Schicht L2 von Schicht L3 in einer ausführlicheren Darstellung,
  • 9 zeigt die Arbeitsweise eines Ausführungsbeispiels und veranschaulicht die Signalisierung für eine RRA-Aktualisierung, falls der Teilnehmer die RRA-Grenze überquert,
  • 10 zeigt die Arbeitsweise eines Ausführungsbeispiels und veranschaulicht die Signalisierung für eine anschließende RRA-Aktualisierung, und
  • 11, 12 zeigen die IP- und die L2-Verfolgung auf 2 Ebenen, die gemäß Ausführungsbeispielen der Erfindung implementiert ist.
  • AUSFÜHRLICHE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN DER ERFINDUNG
  • Im Allgemeinen betrachtet die Erfindung einen Mechanismus zum Überwinden der mit Mobile-IP in Zusammenhang stehenden Probleme bei häufiger Änderung einer Zustelladresse durch den Mobilknoten (MN). Bei den nachstehenden Beispielen wird Mobile-IPv6 verwendet, aber es sollte beachtet werden, dass die Erfindung ebenso mit anderen Protokollen wie etwa Mobile-IPv4 implementiert werden kann. Aspekte der Erfindung sind in Kürze: Während der MN eine Zelle wechselt, erzeugt er die neue Zustelladresse (CoA) wie bei Standard-Mobile-IPv6, aber er sendet die Bindungsaktualisierungen (BU) nicht an Heimatagent (HA) oder an Korrespondenzknoten (CN). Stattdessen sendet er eine BU an den alten Zugangsrouter (AR) oder sendet er überhaupt keine BU (zusätzlich zu der schnellen BU zwischen dem neuen und dem alten AR) im Fall schneller Weiterreichungen (Internet-Draft). Die Erfindung führt einen auf einer Zugangsrouter- (AR-) Verankerung basierenden Mechanismus ein, der auf Erweiterungen am Mechanismus schneller Weiterreichungen (Internet-Draft) aufbaut. Es werden unterschiedliche Heuristiken vorgelegt, mittels derer der Anker-Zugangsrouter (AAR) verlegt werden könnte. Es werden zwei Optionen beschrieben, die verwendet werden könnten, um mehrere Ebenen erneuter Einkapselung zu vermeiden, was durch eine mehrfache Weiterleitung verursacht werden kann.
  • Diese Erfindung führt auch einen zugehörigen Mechanismus zum Unterstützen eines Funkrufs ein, wenn sich ein MN in Ruhebetriebsart befindet, wodurch ein unnötiger Netzwerkoverhead begrenzt wird, der zum Verfolgen in Ruhe befindlicher MNs verwendet wird, und auch die Lebensdauer von Batterien des MN erhöht wird. Ein „A"-Flag bzw. -Kennzeichen in der Mobile-Ipv6-Router-Bekanntmachung könnte in den momentan unspezifizierten Bits hinzugefügt werden, um die Mobilknoten zu benachrichtigen, dass dieser spezielle Zugangsrouter eine Verankerung unterstützt. Dann kann der MN entscheiden, die BUs an den Anker-AR zu senden, während er die Zugangsrouter wechselt. Zum Beispiel basierend auf Schicht 2- (L2-) Aufenthaltsbereichen (z.B. URA (Registrierungsbereich beim Universal-Mobiltelekommunikationssystem (UMTS))) oder basierend auf der Anzahl von Zugangsrouterhops bzw. -abschnitten oder abhängig von dem Zeitraum seit der letzten Änderung einer Zustelladresse kann der MN entscheiden, seinen Anker-Zugangsrouter zu verlegen.
  • Die beschriebenen Ausführungsbeispiele der Erfindung basieren auf einem Mechanismus zum Erzeugen von Weiterleitungspfaden zwischen Zustelladressen des MN und somit zum Verbessern der Reibungslosigkeit einer Übergabe bei Mobile-IPv6 und stellen eine Lösung für das Problem zum Begrenzen der BUs bereit, die sich zu dem HA und den CNs ausbreiten müssen. Probleme schneller und reibungsloser Übergabe können gemäß der von IETF vorgeschlagenen Lösung, d.h. „Fast Handovers for Mobile IPv6", gehandhabt werden.
  • Mit dem gemäß den Ausführungsbeispielen bereitgestellten flachen LMM-Konzept gibt es keinen Knoten an der Wurzel bzw. am Stamm der Hierarchie, der als ein GMA/MAP tätig ist. Der Betrieb des Anker-Zugangsrouters (AAR) bei der flachen LMM ist sehr einfach und kann daher in allen Zugangsroutern implementiert werden. Der Betrieb des AAR ist einfach der gleiche grundlegende Betrieb eines standardmäßigen ARs mit einem zusätzlichen eingebetteten MIPv6-Bindungscachspeicher, der es dem AAR ermöglicht, BUs vom MN zu empfangen und Pakete an den MN weiterzuleiten, auch während der MN nicht mehr in dem von diesem AR gebildeten Subnetz ist.
  • Ist das Konzept zur Verwendung einer regionalen Weiterleitung implementiert, um mehrere Ebenen erneuter Einkapselung zu verhindern, müssen auch die ARs eine regionale Weiterleitung implementieren. Es sollte beachtet werden, dass der Mechanismus regionaler Weiterleitung nicht erforderlich ist, falls jeder Zugangsrouter die getunnelten Pakete entkapselt, bevor er sie erneut einkapselt.
  • 1 skizziert den grundlegenden Betrieb von auf einer Hierarchie basierenden LMMs. Es ist zu beachten, dass der MN, während der MN innerhalb der gleichen hierarchischen Domäne (mit dem gleichen LMGW als Wurzel bzw. Stamm) umherwandert, nur regionale Bindungsaktualisierungen versendet. Wechselt der MN die Domäne, sendet er BUs an seinen HA und seine CNs. Gemäß der Figur ist der lokale Mobilitätsgateway (LMGW) ein Knoten, der die häufige Änderung einer Zustelladresse von sich schnell bewegenden Mobilknoten für Knoten transparent macht, die sich topologisch weiter von dem Mobilknoten entfernt befinden (s.a. der Heimatagent). Um Signalisierungslatenzzeiten zu minimieren, sollte ein LMGW topologisch so nahe wie möglich an dem Mobilknoten sein. Bei den Ausführungsbeispielen der Erfindung befindet sich der LMGW im AAR und wird dynamisch von Fall zu Fall zugeordnet (d.h. sich langsam bewegende MNs verwenden keinen LMGW). Bei hierarchischem Mobile-IPv6 ist der LMGW äquivalent zu dem MAP und bei Mobile-IPv6 mit regionalen Registrierungen ist der LMGW äquivalent zu dem GMA.
  • Bei allen Zeichnungen ist der gleiche MN mehrere Male gezeigt, jeweils zu anderen aufeinander folgenden Zeitpunkten t1 bis t4, wie es gemäß 1 bis 3 auch durch einen Pfeil „ZEIT" angedeutet ist. 4, 5 stellen die Zeitachse von t = t0 bis t = t4 in einer Abwärtsrichtung dar.
  • 2 zeigt den Betrieb eines hypothetischen Netzwerks unter Verwendung von Basis-Mobile-IP und schnellen Weiterreichungen (ohne LMM). Es ist zu beachten, dass der MN bei jedem AR-Wechsel eine MIPv6-Signalisierung mit dem HA und dem CN veranlassen muss.
  • 3 zeigt das Funktionsprinzip bevorzugter Ausführungsbeispiele der Erfindung, die den vorgeschlagenen flachen LMM-Mechanismus umfassen (Option 2, d.h. BUs, aber keine regionale Weiterleitung). Eine ausführliche Beschreibung des Mechanismus ist nachstehend angegeben. Es ist zu beachten, dass der MN nur dann gefordert ist, eine Mobile-IPv6-Signalisierung auszulösen, wenn der Anker-Zugangsrouter verlegt wird.
  • 4 und 5 zeigen das Signalisierungsdiagramm für den nachstehend beschriebenen flachen LMM-Mechanismus für Option 1 und Option 2.
  • Wie vorstehend erörtert lindern schnelle Weiterreichungen für Mobile-IPv6 vorstehend dargelegte Verzögerungs- und Paketverlustprobleme, aber gehen momentan nicht das Signalisierungsoverheadproblem an. Dies kann gemäß 2 ersehen werden. Eine Ende-zu-Ende-Mobile-IPv6-Signalisierung hat bei jedem Wechsel eines Zugangsrouters stattzufinden. Obwohl der mit dieser Signalisierung in Zusammenhang stehende Overhead in den meisten Fällen durch Synchronisation der Bindungsnachrichten mit Nutzlasten höherer Schicht reduziert werden kann, ist dies in einigen Fällen nicht machbar. Selbst wenn alle Bindungsnachrichten mit Nutzlast höherer Schicht synchronisiert werden können, würde immer noch irgendein Mechanismus erforderlich sein, um den Verarbeitungsoverhead an Korrespondenzknoten zu begrenzen. Daher ist es weiter wünschenswert, diese Ende-zu-Ende-Signalisierung zu begrenzen, insbesondere wenn der MN Zugangsrouter sehr häufig wechselt.
  • Die Erfindung schlägt daher gemäß einem Aspekt einen Mechanismus zum Begrenzen der Ende-zu-Ende-Signalisierung basierend auf einer Verankerung von Zugangsroutern vor (siehe 3). Ein MN ist zunächst an AR1 angeschlossen (Zeit = t0). Anschließend (Zeit = t1) wird er zu einer neuen Zelle weitergereicht, die von einem neuen Zugangsrouter (AR2) gesteuert wird. Der MN fährt fort, indem er seine neue Zustelladresse wie bei Standard-Mobile-IPv6 bildet. Der MN trifft jedoch eine Entscheidung darüber, dass er statt BUs an seine Partnerknoten (HA, CNs) zu senden eine BU an seinen vorhergehenden Zugangsrouter oder im Fall schneller Weiterreichungen überhaupt keine BU (zusätzlich zu der schnellen BU) senden wird. Im letztgenannten Fall wird der alte Zugangsrouter die neue Zustelladresse des MN über eine im IETF-Vorschlag spezifizierte schnelle BU erfahren. Der einzige Unterschied, der durch die Erfindung vorgeschlagen wird, besteht darin, dass der MN anschließend keine BU an seine Partnerknoten (HA, CNs) senden wird. Ein „A"-Flag bzw. -Kennzeichen in der Mobile-IPv6-Routerbekanntmachung könnte in den momentan unspezifizierten Bits hinzugefügt werden, um die Mobilknoten zu benachrichtigen, dass dieser spezielle Zugangsrouter eine Verankerung unterstützt.
  • Der MN kann zum Beispiel basierend auf L2-Aufenthaltsbereichen (z.B. URA) oder basierend auf der Anzahl von Zugangsrouterhops bzw. -abschnitten oder abhängig von dem Zeitraum seit der letzten Änderung seiner Zustelladresse entscheiden, seinen Anker-Zugangsrouter zu verlegen. Dies wird nachstehend ausführlicher erörtert.
  • Eines der Ziele des flachen LMM-Konzepts besteht darin, die Ausbreitung von BUs zu HA und CNs zu minimieren. Die nachstehend skizzierten grundlegenden Algorithmen sind ausreichend, um diesem Zweck zu dienen. Das Problem einer Minimierung von Latenzzeit und Paketverlust kann von dem Mechanismus schneller Weiterreichungen gehandhabt werden.
  • Im Folgenden werden Einzelheiten zum Begrenzen der Frequenz von zu HA und CNs gesendeten BUs erörtert. Die folgenden grundlegenden Algorithmen können als eine Grundlage für die Entscheidung darüber verwendet werden, wann eine Zugangsrouter-Verankerung zu verwenden ist und wann zu normalen schnellen Weiterreichungen + Mobile-IPv6-Betrieb zurückzukehren ist (d.h. Senden von BUs an HA und CNs):
    • – Beibehalten eines Zeitgebers (t) zum Messen des Zeitraums seit der letzten Lieferung einer BU an HA/CN falls t > Schwelle normale schnelle Weiterreichung + MIPv6-Betrieb sonst normale schnelle Weiterreichung + MIPv6-Betrieb, aber ohne Versendung von BU (oder Versendung von BU an AAR, abhängig davon, welche Option (siehe unten) ausgewählt ist) Ende UND/ODER
    • – Beibehalten eines Zählers (c) im MN, um die Anzahl von L3-Weiterreichungen zu verfolgen, für die der gleiche AAR beibehalten wird. Falls der AAR (im Hinblick auf eine Anzahl von L3-Weiterreichungen) zu weit entfernt ist, Verlegung des AAR; UND/ODER
    • – der MN kann auch die Anzahl von CNs in Betracht ziehen, mit denen er anhaltende Sitzungen hat, wenn er die Entscheidung darüber trifft, ob der AAR zu verwenden ist oder nicht. Ist die Anzahl von CNs über einem bestimmten Schwellwert (n), wird der MN, (hauptsächlich) um Luftschnittstellenressourcen zu sparen, entscheiden, den AAR zu verwenden, wobei in diesem Fall nur eine BU versendet wird.
  • In der Praxis wird eine Kombination der vorstehenden Verfahren/Algorithmen noch bessere Ergebnisse liefern. Eine Auswahl der Schwellenwerte und ihrer entsprechenden Gewichtungen, die zu den optimalsten Ergebnissen führen, kann durch Implementierungen und/oder Simulationen empirisch herausgefunden werden.
  • In einem bestimmten Stadium, z.B. wenn ein Schwellenwert erreicht wird, der für den ausgewählten Algorithmus oder mehrere der vorstehend genannten Algorithmen eingestellt ist, kann der MN entscheiden, dass es Zeit ist, seinen Zugangsrouter zu verlegen. In diesem Fall wird er einem standardmäßigen Mobile-IPv6-Vorgang schneller Weiterreichung folgen und wird eine Bindungsaktualisierung an seine Partnerknoten (HA und CNs) senden.
  • Im Folgenden werden Optionen zum Begrenzen mehrerer Ebenen erneuter Einkapselung erörtert, die optionale Merkmale der Erfindung darstellen (wobei dieses Problem auch gelöst werden könnte, falls die Zugangsrouter die getunnelten Pakete entkapseln, bevor sie sie erneut einkapseln).
  • Es sind zwei alternative Mechanismen vorgeschlagen, um dieses Problem zu vermeiden, d.h. mehrere Ebenen erneuter Einkapselung zu begrenzen.
  • Die erste Option besteht darin, einen Adressenwechsel bzw. -austausch anzuwenden, wie er z.B. bei Mobile-IP mit regionaler Weiterleitung (J.T. Malinen, C.E. Perkins, „Mobile IP Regional Forwarding", Internet-Draft) verwendet wird.
  • Die zweite Alternative besteht darin, dass der MN Aufzeichnungen bezüglich der Adresse des Anker-Zugangsrouters macht und diese Adresse als primären Anker-Zugangsrouter verwendet (d.h., dass der MN seine Bewegung immer an diesen Zugangsrouter signalisiert). Bei Zeit = t2 wird der MN zu einer von AR3 gesteuerten Zelle weitergereicht. Der MN wählt weiterhin, AR1 als seinen Ankerpunkt zu verwenden. Daher sendet er während des schnellen Übergabemechanismus seine schnelle BU an AR1 anstatt an AR2. Auf diese Art und Weise ist (ähnlich wie bei HMIPv6) nur ein zusätzlicher Tunnelungs-Nachrichtenkopf erforderlich. Wird ein Adressenwechselmechanismus verwendet, wie etwa der in J.T. Malinen, C.E. Perkins, „Mobile IP Regional Forwarding", Internet-Draft, vorgeschlagene, wird kein zusätzlicher Tunnelungsoverhead auftreten.
  • 4 veranschaulicht die Funktionsweise eines Ausführungsbeispiels, das eine Funktion gemäß Option 1 berücksichtigt. Der Signalisierungs- und Nachrichtenfluss (Datenfluss) ebenso wie die Bedeutung der gemäß 4 gezeigten Aktionen ist aus den in 4 verwendeten Pfeilen und Beschriftungen selbsterklärend. 4 stellt daher eine vollständige Offenbarung der Einzelheiten dieses Ausführungsbeispiels der Erfindung dar.
  • Die Funktionsweise entspricht dem grundlegenden Betrieb schneller Weiterreichung + MIPv6, mit den folgenden Modifikationen:
    • – ARs machen die Unterstützung einer flachen LMM mit einem „A"-Flag bekannt, das eines der momentan ungenutzten Bits in der MIPv6-Routerbekanntmachung ersetzt;
    • – ARs implementieren eine regionale Weiterleitung, um mehrere Ebenen erneuter Einkapselung zu vermeiden;
    • – MN implementiert einen heuristischen Algorithmus (z.B. wie vorstehend angegeben), um zu bestimmen, wann BUs an HA und CNs zu senden sind (wobei dies bei dem beispielhaften Ausführungsbeispiel gemäß 4 passiert, wenn sich MN zu AR5 bewegt).
  • 5 veranschaulicht die Funktionsweise eines Ausführungsbeispiels, das eine Funktion gemäß Option 2 berücksichtigt. Der Signalisierungs- und Nachrichtenfluss (Datenfluss) ebenso wie die Bedeutung der gemäß 5 gezeigten Aktionen ist aus den in 5 verwendeten Pfeilen und Beschreibungen selbsterklärend. 5 stellt daher eine vollständige Offenbarung der Einzelheiten dieses Ausführungsbeispiels der Erfindung dar.
  • Die Funktionsweise des Ausführungsbeispiels gemäß 5 entspricht dem grundlegenden Betrieb schnellerer Weiterreichung + MIPv6, mit den folgenden Modifikationen:
    • – ARs machen die Unterstützung einer flachen LMM mit einem „A"-Flag bekannt, das eines der momentan ungenutzten Bits in der MIPv6-Routerbekanntmachung ersetzt;
    • – MN zeichnet die Adresse des AAR auf und sendet seine BUs im Gegensatz zu HA/CNs an diese Adresse;
    • – In diesem Fall erfolgt nur 1 zusätzliche Einkapselung (am AAR). Ist dies ein Problem, können die ARs den bei regionaler Weiterleitung verwendeten Adressenwechselmechanismus implementieren (ohne ein Erfordernis einer vollständigen Implementierung einer regionalen Weiterleitung, da kein Bedarf für den Mechanismus besteht, der den Bindungscachespeicher bei RegFwd (hop- bwz. abschnittsweise) aufbaut (oder aktualisiert));
    • – In diesem Fall kann der AAR verweigern, als ein Anker-AR tätig zu sein, indem er eine negative Rücksendung mit einer neuen Fehlernachricht sendet (z.B. „AR nicht gewillt, als Anker zu dienen"). In diesem Fall wird der MN zu einem Standardbetrieb schneller Weiterreichung + MIPv6 zurückkehren, d.h. eine BU an HA/CNs senden.
  • Bei dem Ausführungsbeispiel gemäß 5, das „Option 2" implementiert, sind keine vielfachen Ebenen eines Adressenwechsels notwendig. Bei MIPv6RR sind vielfache Ebenen eines Adressenwechsels die einzige Option.
  • Als Nächstes wird der Betrieb in Ruhebetriebsart beschrieben. Der Signalisierungsoverhead zur Unterstützung der Mobile-IPv6-Mobilitätsverwaltung wird linear mit der Anzahl von MNs in Netzwerk steigen. Die überwiegende Mehrheit drahtloser IP-Teilnehmer wird zum größten Teil der Zeit nicht gerade aktiv kommunizieren. Vielmehr werden MNs in einem (Energie sparenden) Ruhezustand sein, d.h. passiv mit dem Netzwerk verbunden. Als Folge hiervon wird es für das Netzwerk ausreichend sein, den ungefähren Standort in Ruhe befindlicher MNs zu kennen. Der exakte Standort der MNs wird nur wichtig, wenn Daten zu diesen weitergeleitet werden müssen, wobei die Netzwerkprotokolle in diesem Fall in der Lage sein müssen, diese Teilnehmer auf eine skalierbare und rechtzeitige Art und Weise effizient zu suchen und zu finden. Dieser Prozess ist bei zellularen Netzwerken nicht neu und wird als Funkruf bezeichnet.
  • Die Erfindung schlägt vor, die vorstehend dargelegte grundlegende Struktur zu erweitern, um einen Funkrufmechanismus einzubinden, der gewährleistet, dass die vorstehend genannten Vorteile erreicht werden. An Zugangsroutern angeschlossene L2-Zugangspunkte sind in Registrierungsbereichen (RAs) organisiert, die ähnlich zu UTRAN-Registrierungsbereichen (URA) bei UTRAN und GERAN-Registrierungsbereichen (GRA) bei GERAN sind. Die Kennung des RRA wird über einen Rundsendungskanal von jedem Zugangspunkt bekannt gemacht. Um Funktechnologien in diesen Mechanismus zu integrieren, die keinen Gebrauch von derartigen L2-Bereichen machen (z.B. WLAN), können diese Registrierungsbereiche IP-basiert sein (aber weiterhin über Rundsendungskanäle versendet werden, so dass der MN diese im Ruhemodus abhören kann). Befindet sich der MN im Ruhezustand, ist er nicht gefordert, irgendwelche Bindungsaktualisierungen (entweder an die Partnerknoten oder an den AAR) zu senden, solange er innerhalb des gleichen RA wie sein AAR bleibt. Hat der MN keinen AAR verwendet, bevor er in den Ruhemodus gegangen ist, übernimmt der letzte AR seine Rolle, bei dem der MN zuletzt aktiv gesehen wurde. Wechselt ein in Ruhe befindlicher MN RAs, versendet er BUs wie bei Standard-MIPv6, d.h. zu seinem HA. Der HA kennt daher immer den Standort des MN mit der Genauigkeit des RA.
  • Leitet ein neuer CN eine neue Sitzung zu dem MN ein, wird der Verkehr zuerst den HA erreichen, wo er in Richtung der zuletzt registrierten Zustelladresse umgeleitet wird, die auf einen Zugangsrouter im aktuellen RA des MN zeigen sollte. Empfängt der AR ein solches Paket bzw. solche Pakete, nachdem bestimmt wurde, dass der MN an keinem der an diesem angeschlossenen Zugangspunkte einen Funkträger aufweist, wird der AR einen Funkruf über den gesamten RA hinweg einleiten. Bei zellularen Systemen, die ohnehin Funkruf unterstützen (WCDMA, EDLE, usw.), könnte dies eine L2-Funkrufnachricht sein. Bei anderen Technologien, die momentan keinen Funkruf auf L2 unterstützen, kann eine beliebige IP-Funkrufnachricht definiert werden. Bei Empfang einer derartigen Funkrufnachricht, leitet der MN eine Funkträgereinrichtung ein und sendet eine BU an den AAR, so dass Pakete an den aktuellen AR des MN weitergeleitet werden können. Daraufhin sendet der MN vorzugsweise BUs an den HA und die CNs, um optimale Leitweglenkungspfade einzurichten.
  • Die Erfindung hat Einflüsse bzw. Auswirkungen auf die Architekturen, die für vollständige IP-Architekturen basierend auf Mobile-IP (IPv4 oder IPv6) ausgewählt werden. Bei den beschriebenen Ausführungsbeispielen befindet sich die ganze erforderliche Funktionalität in den Zugangsroutern. Es besteht kein Bedarf für irgendwelche spezialisierten Knoten (GMA/MAP, usw.) in der Architektur.
  • Da der bei diesen Ausführungsbeispielen dargelegte Mechanismus auf der IP-Schicht arbeitet, ist er ebenso geeignet für eine lokalisierte Mobilitätsverwaltung über homogene Medien hinweg, wie für Mobilität über heterogene Medien hinweg (z.B. von einem AR mit WCDMA-basiertem/n Zugangspunkt/en zu einem AR mit WLAN-basiertem/n Zugangspunkt/en).
  • Die in dem MN benötigte Intelligenz ist nicht viel komplizierter als ein einfacher Vorgang zum Implementieren der vorstehenden Zeitgeber- oder Zählerfunktion.
  • Der flache LMM-Mechanismus basiert nicht auf Host-Leitwegen. Er basiert stattdessen auf Bindungscachespeichern. Der Unterschied gegenüber dem Vorgenannten besteht darin, dass Bindungscachespeichereinträge nicht durch Leitweglenkungsprotokolle verbreitet werden. Daher gibt es keine Instabilitätsprobleme. Bezüglich der Anzahl von Einträgen in jedem Bindungscachespeicher gibt es im Vergleich zu hierarchischen LMMs bei dem Fall flacher LMM weniger Einträge pro Cache, da kein Wurzel- bzw. Stammknoten in oberster Ebene der Hierarchie vorhanden ist, der alle Adressabbildungen für die MNs in dieser Domäne beibehält. Die Bindungscachespeicher sind über die ARs hinweg verteilt und daher skalierbarer.
  • Die Ausführungsbeispiele der Erfindung, die in den Zeichnungen gezeigt und vorstehend ebenso wie im Folgenden beschrieben sind, beziehen sich auf einen Bereich, bei dem der Mobilfunknetzwerkentwurf auf den IP-Mobilitätsmechanismen basiert, z.B. Mobile-IPv6. Die Hauptzugangstechnologien (Schicht 2-Protokolle), die im folgenden Text betrachtet werden, sind GSM und WCDMA.
  • Das Teilnehmer-IP schließt auf der Netzwerkseite (im Gegensatz zum momentanen GPRS, bei dem das Teilnehmer-IP am GGSN abschließt) am Zugangsrouter ab (wobei der Text den Ausdruck IP-BTS verwendet, der eine Kombination der AR- und der BTS-Funktionalität ist). Dies bedeutet, dass IP-Pakete zum Teilnehmer immer an den Zugangsrouter geleitet werden. In einigen Fällen existieren bereits L2-Ressourcen (d.h. Funkressourcen für Funkträger) zum Senden der Daten über die Luft. Ein typisches Beispiel dafür ist eine aktive Datenübertragung.
  • Es ist zu beachten, dass der Zugangsrouter und die Basisstation (BTS) in unterschiedlichen Netzwerkinstanzen sein können.
  • In einigen Fällen können jedoch keine L2-Ressourcen verfügbar sein und kann es auch sein, dass der Endgerätestandort nur in einer L2-Standortverwaltungsfunktion bekannt ist. Eine L2-Standortverwaltung kann auf einer Aktualisierung der Standortinformationen am Netzwerk basieren, wo der berichtete Bereich RRA ist (RAN-Registrierungsbereich, der ähnlich dem UTRAN-Registrierungsbereich bei WCDMA ist). Daher muss die IP-BTS den Teilnehmer vorher rufen, um den Teilnehmer zu lokalisieren, woraufhin die IP-BTS Ressourcen für den Teilnehmer zuweisen kann, damit die Daten über die Luft an den Teilnehmer gesendet werden können.
  • 6 bezieht sich auf ein am Zugangsrouter (d.h. IP-BTS) abgeschlossenes IP, 2-Ebenen-Verfolgung in L2 und IP, und zeigt einen Fall, bei dem der Teilnehmer anfängt, IP-Pakete vom Netzwerk zu empfangen. Die Zustandsinformationen (z.B. Paketdatenkonvergenzprotokoll (PDCP), Funkstreckensteuerung/Medienzugangssteuerung (RLC/MAC), Sicherheit und Standort) des Teilnehmers (MN) werden in der IP-BTS 1 beibehalten, während sich der Teilnehmer bei IP-BTS 2 befindet. Bei diesem Beispiel wird auch die Funkressourcensteuerung (RRC) in IP-BTS 1 beibehalten. Das Fragezeichen in der 6 zeigt, dass die IP-BTS 1 bei diesem Beispiel den physikalischen Standort (L1-Information) des MN nicht kennt. Der Teilnehmer muss von dem RRA gerufen werden, und wenn der MN des Teilnehmers auf den Funkruf antwortet, muss die Weiterreichung zu der IP-BTS 2 ausgeführt werden.
  • Tritt das Endgerät in einen neuen RRA-Bereich ein, aktualisiert es seinen Standort am Netzwerk (RRA-Aktualisierung), d.h. die Standortdatenbank „Standort-DB" in der IP-BTS 1. Die IP-BTS kann die Standortinformationen des bestimmten Bereichs enthalten, d.h. die bestimmten RRAs. Der Teilnehmer kann in Regionalberiche eintreten, für die die Standortinformationen in einer anderen Datenbank in einer anderen IP-BTS als derjenigen gespeichert sind, wo die Standortinformationen des Teilnehmers gespeichert waren, bevor der Teilnehmer in den neuen Regionalbereich eingetreten ist.
  • In diesem Fall werden die (L2-) Informationen bezüglich des Teilnehmers wie gemäß 7 gezeigt an die neue IP- BTS verschoben. Auf der IP-Ebene bedeutet die Änderung der IP-BTS typischerweise die Änderung der CoA des Teilnehmers. Daher muss der Teilnehmer zusätzlich zu der RRA-Aktualisierung die BUs an alle CNs senden.
  • Da das Versenden von BUs an CNs die Signalisierungslast über die Luft erhöht, ist es in einigen Fällen nützlich, eine Trennung von L2 von L3 zu ermöglichen. Dies bedeutet, dass der L2-Kontext des Teilnehmers an die neue IP-BTS verschoben wird, während der Teilnehmer auf der L3-Schicht weiterhin bei der alten IP-BTS ist. Um die IP-Pakete korrekt an den Teilnehmer zu leiten, aktualisiert die alte IP-BTS die neue Weiterleitungs-IP-Adresse, wohin die IP-Pakete weiterzuleiten sind, die an der CoA in der alten IP-BTS ankommen („L3-Weiterleitung" gemäß 7).
  • 7 veranschaulicht die Trennung der L2 von L3 und zeigt das Gesamtprinzip, was mit der Trennung von L2 von der L3 gemeint ist. Dieses Ausführungsbeispiel gemäß 7 ist ein bevorzugtes Ausführungsbeispiel der Erfindung.
  • Die vertikale Linie gemäß 7 symbolisiert die Grenze zwischen RRA1 und RRA2.
  • 8 veranschaulicht die Trennung von Schicht L2 von Schicht L3 in einer ausführlicheren Darstellung. In diesem Fall ist der Teilnehmer MN an IP-BTS 3 angeschlossen und empfängt IP-Pakete über IP-BTS 1 und IP-BTS 2. Der Bindungscachespeicher von BTS 1 umfasst die Information „Nächster Hop = IP-BTS 2".
  • 9 zeigt die Signalisierung für eine RRA-Aktualisierung, falls der Teilnehmer die RRA-Grenze überquert. Der Teilnehmer aktualisiert seinen neuen RRA-Standort am Netzwerk einschließlich der temporären Funknetzwerkkennung (RNTI, wobei dies eine L2-Kennung ist, die für den Teilnehmer verwendet wird) und altem RRA-Standort (Nachricht „1. RRA-Aktualisierung [RNTI, alter RRA]", die vom Teilnehmer an IP-BTS neu/AR neu gesendet wird). Die neue IP-BTS weist eine IP-Adresse zu, an der sie bereit ist, weitergeleitete IP-Pakete zu empfangen, die von der alten IP-BTS getunnelt werden. Die neue IP-BTS sendet eine Nachricht „2. RRA-Aktualisierung [RNTI, Weiterleitungs-IP-Adresse]" an BTS alt/AR alt. Es ist zu beachten, dass die IP-Adresse später von der neuen IP-BTS bzw. AR neu zugewiesen werden kann, indem ein zusätzlicher Umlauf zwischen der alten und der neuen IP-BTS/AR durchgeführt wird.
  • Die alte IP-BTS führt eine Bindung von der CoA mit der neuen Weiterleitungsadresse durch („3. Einrichten von Bindungsinfo CoA → Weiterleitungs-IP"). Empfängt die alte IP-BTS Pakete, die an den Teilnehmer gesendet werden, an der CoA, tunnelt sie die Pakete an die neue Weiterleitungs-IP-Adresse.
  • Empfängt die alte IP-BTS die RRA-Aktualisierung, sendet sie die L2-Informationen, z.B. Funkträger (RLC/MAC), Endgerätefähigkeit, Sicherheitsparameter und Nachrichtenkopfkomprimierungsinfo, an die neue IP-BTS („4. RRA-Aktualisierungsbest. [L2-Info]").
  • Es ist eine Möglichkeit, dass an dieser Stelle keine L3-Informationen an die neue IP-BTS weitergeleitet werden. Es ist ebenfalls möglich, einige L3-Ebenen-Informationen weiterzuleiten, z.B. QoS-Informationen (Differenzierte-Dienste-Codepunkt, DSCP) und Sicherheitsinformationen.
  • Die neue IP-BTS bestätigt dem Teilnehmer die RRA-Aktualisierung („5. RRA-Aktualisierungsbest. [neuer RRA]").
  • Aus Sicht von L2 befindet sich der Teilnehmer nun im neuen RRA, während der Teilnehmer auf der L3 in der alten IP-BTS immer noch die alte CoA hat.
  • 10 zeigt den Fall einer anschließenden RRA-Aktualisierung, der auftritt, wenn der Teilnehmer einen RRA wechselt, während L3 und L2 bereits bei der vorhergehenden RRA-Aktualisierung getrennt wurden (siehe 9).
  • Der Teilnehmer aktualisiert seinen neuen RRA-Standort am Netzwerk durch Senden einer RRA-Aktualisierungsnachricht 1, die die temporäre Funknetzwerkkennung (RNTI) und den alten RRA-Standort enthält. Die neue IP-BTS weist eine IP-Adresse zu, an der sie bereit ist, weitergeleitete IP-Pakete zu empfangen, die von der alten IP-BTS getunnelt werden, und sendet eine RRA-Aktualisierungsnachricht 2 an die alte IP-BTS, die RNTI und Weiterleitungs-IP-Adresse bezeichnet. Es ist zu beachten, dass die IP-Adresse später von der neuen IP-BTS/AR neu zugewiesen werden kann, indem ein zusätzlicher Umlauf zwischen der alten und der neuen IP-BTS/AR durchgeführt wird.
  • Die alte IP-BTS aktualisiert die alte Weiterleitungs-IP-Adresse in die neue Weiterleitungs-IP-Adresse und sendet eine RRA-Aktualisierungsnachricht 3 an die andere alte IP-BTS, die die IP-Pakete für den Teilnehmer weiterleitet. Die letztgenannte IP-BTS führt eine Bindung von der CoA mit der neuen Weiterleitungsadresse durch (Ereignis 4). Empfängt die weiterleitende IP-BTS Pakete, die an den Teilnehmer gesendet werden, an der CoA, tunnelt sie die Pakete an die neue Weiterleitungs-IP-Adresse.
  • Empfängt die alte IP-BTS die RRA-Aktualisierungsbest. (Nachricht 5), sendet sie die L2-Informationen, d.h. Funkträger (RLC/MAC), Endgerätefähigkeit, Sicherheitsparameter und Nachrichtenkopfkomprimierungsinfo, an die neue IP-BTS (Nachricht 6). Es ist möglich, dass an dieser Stelle irgendwelche L3-Informationen an die neue IP-BTS weitergeleitet werden. Es ist ferner möglich und vorteilhaft, z.B. Qo5-Informationen (DSCPs) und Sicherheitsinformationen weiterzuleiten.
  • Die neue IP-BTS bestätigt dem Teilnehmer die RRA-Aktualisierung (Nachricht 7).
  • Aus Sicht der L2 befindet sich der Teilnehmer nun im neuen RRA, während der Teilnehmer auf der L3 immer noch in der weiterleitenden IP-BTS die alte CoA hat.
  • Alternativ zu dem gemäß 10 dargelegten Mechanismus ist es, dass die neue IP-BTS, wenn sie eine IP-Adresse zuweist, an der sie bereit ist, weitergeleitete IP-Pakete zu empfangen, die von der alten IP-BTS getunnelt werden, eine RRA-Aktualisierungsnachricht 2 an die alte IP-BTS sendet, die RNTI und Weiterleitungs-IP-Adresse bezeichnet. Die alte IP-BTS speichert die neue Weiterleitungs-IP-Adresse und sendet eine RRA-Aktualisierungsbest.-Nachricht zurück an die neue IP-BTS. Auf diese Weise wird das IP-Paket über zwei alte IP-BTS/AR an die neue IP-BTS/AR geleitet.
  • Die Erfindung stellt eine neue Netzwerkarchitektur-Auslegung bereit.
  • Die vorgeschlagene Lösung kombiniert momentane GSM- und WCDMA-Funkkonzepte mit dem MIPv6-Konzept.
  • 11 zeigt eine Tabelle, die die IP- und die L2-Ebene (IP- und L2-Standortverfolgung auf 2 Ebenen) kombiniert und jeden der möglichen Kombinationszustände beschreibt. Die Spalten gemäß 11 stellen L2/IP; L2 freigegeben; Zelle; und RRA dar. Die Hinweise in der Tabelle sind selbsterklärend und müssen hier daher nicht wiederholt werden; die Offenbarungsinhalt dieser Tabelle ist ebenso wie alle anderen zugehörigen Figuren vollständig in die Offenbarung der Erfindung eingebunden.
  • 12 zeigt die Inhalte der Tabelle gemäß 11, d.h. IP- und L2-Verfolgung auf 2 Ebenen, in einem Zustandsdiagrammformat.
  • Es ist zu beachten, dass gemäß 12 der Ausdruck Weiterreichung für einen Fall verwendet wird, bei dem die Zelle und/oder der Zugangsrouter (d.h. IP-BTS) gewechselt wird, während eine aktive Datenübertragung besteht. Auch in dem Fall, dass keine Datenübertragung besteht (d.h. L2-RRA-Zustand), wird der Weiterreichungsausdruck verwendet, aber er unterscheidet sich von der ursprünglichen Idee der Weiterreichung und kann z.B. auch als „eine Änderung der Zelle und/oder des Zugangsrouters" oder „Lagerung zu neuer/m Zelle/Zugangsrouter" bezeichnet werden.
  • Ein Fachmann weiß, dass die Erfindung auch bei anderen Mobilfunknetzwerken (einschließlich Netzwerken basierend auf WLAN, IP-RAN, UTRAN, GERAN, EDLE, usw.) verwendet werden kann.

Claims (20)

  1. Verfahren zum Verwalten von Datenflüssen zwischen Mobilknoten (MNs), Zugangsleitweglenkungsknoten (AR) und Partnerknoten (HA, CNs), mit dem Schritt, dass, wenn ein Mobilknoten eine Weiterreichung von einem ersten Zugangsleitweglenkungsknoten (AR1) zu einem anderen Zugangsleitweglenkungsknoten (AR2, AR3, ..., ARn) durchführt, eine Entscheidung darüber getroffen wird, ob der erste Zugangsleitweglenkungsknoten (AR1) als ein Anker-Zugangsleitweglenkungsknoten tätig sein und Daten von den Partnerknoten (HA, CNs) über den neuen Zugangsleitweglenkungsknoten (AR2, AR3, ..., ARn) an den Mobilknoten weiterleiten soll, oder ob eine Aktualisierung der neuen Position des Mobilknotens an einen Partnerknoten (HA, CN) zu senden ist, wobei die Entscheidung basierend auf der Zeit getroffen wird, die seit einer vorhergehenden Aktualisierung verstrichen ist, die an die Partnerknoten (HA, CNs) gesendet wurde.
  2. Verfahren gemäß Anspruch 1, bei dem die Entscheidung basierend auf zumindest einem der folgenden Kriterien getroffen wird: – die Anzahl von Partnerknoten (HA, CN1, CN2, ..., CNn), mit denen er laufende Sitzungen hat, – die Verkehrsaktivität zwischen dem/den Partnerknoten (HA, CN1, CN2, ..., CNn) und dem Mobilknoten (MN), – Verkehrslast oder Signalisierungslast zwischen Mobilknoten und Zugangsleitweglenkungsknoten und/oder Partnerknoten, – der Zustand zugrunde liegender Schichten, z.B. Protokollschichten 1 und/oder 2, – der Zustand des Mobilknotens, – die Frequenz von Weiterreichungen.
  3. Verfahren gemäß Anspruch 1 oder 2, bei dem die Entscheidung von dem Mobilknoten getroffen wird.
  4. Verfahren gemäß Anspruch 1 oder 2, bei dem die Entscheidung von dem Netzwerk getroffen wird.
  5. Verfahren gemäß Anspruch 1 oder 2, bei dem die Entscheidung von einer Instanz im Zugangsnetzwerk getroffen wird.
  6. Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem die maximale Anzahl von Weiterreichungen, für die der gleiche Anker-Zugangsleitweglenkungsknoten beibehalten wird, auf einen vordefinierten oberen Grenzwert beschränkt ist.
  7. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Kommunikation zwischen dem/den Mobilknoten, den Zugangsleitweglenkungsknoten (AR) und den Partnerknoten (HA, CNs) basierend auf Mobile-IP ausgeführt wird.
  8. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem, wenn sich der Mobilknoten bewegt und einen neuen Zugangsleitweglenkungsknoten als Anker-Zugangsleitweglenkungsknoten ausgewählt hat, immer eine Bindungsaktualisierungsnachricht an den vorhergehenden Zugangsleitweglenkungsknoten gesendet wird, wobei die Entscheidung darüber, ob Bindungsaktualisierungsnachrichten zu senden sind, immer auf den in Anspruch 1 oder 2 genannten Kriterien und/oder auf der Anzahl von Malen basiert, die sich eine Zustelladresse (CoA) ohne Benachrichtigung eines Partnerknotens geändert hat.
  9. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem, wenn sich der Mobilknoten bewegt und einen neuen Zugangsleitweglenkungsknoten als Anker-Zugangsleitweglenkungsknoten ausgewählt hat, immer eine Bindungsaktualisierungsnachricht an den Anker-Zugangsleitweglenkungsknoten gesendet wird, wobei die Entscheidung darüber, ob Bindungsaktualisierungsnachrichten zu senden sind, immer auf den in Anspruch 1 oder 2 genannten Kriterien und/oder auf der Anzahl von Malen basiert, die sich eine Zustelladresse (CoA) ohne Benachrichtigung eines Partnerknotens geändert hat.
  10. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Weiterreichung des Mobilknotens von dem ersten zu dem zweiten Zugangsleitweglenkungsknoten durchgeführt wird, wie es bei Mobile-IP oder für schnelle Weiterreichungen für Mobile-IPv6 definiert ist.
  11. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Partnerknoten einen Heimatagenten (HA) und/oder einen Korrespondenzknoten (CN) umfassen.
  12. System zum Verwalten von Datenflüssen zwischen Mobilknoten (MNs), Zugangsleitweglenkungsknoten (AR) und Partnerknoten (HA, CNs), mit einer Entscheidungseinrichtung zum Entscheiden, wenn ein Mobilknoten eine Weiterreichung von einem ersten Zugangsleitweglenkungsknoten (AR1) zu einem anderen Zugangsleitweglenkungsknoten (AR2, AR3 ..., ARn) durchführt, ob der erste Zugangsleitweglenkungsknoten (AR1) als ein Anker-Zugangsleitweglenkungsknoten tätig wird und Daten von den Partnerknoten (HA, CNs) über den anderen Zugangsleitweglenkungsknoten (AR2, AR3, ..., ARn) an den Mobilknoten weiterleitet, oder ob eine Aktualisierung der neuen Position des Mobilknotens an einen Partnerknoten (HA, CN) zu senden ist, wobei die Entscheidung basierend auf der Zeit getroffen wird, die seit einer vorhergehenden Aktualisierung verstrichen ist, die an die Partnerknoten (HA, CNs) gesendet wurde.
  13. System gemäß Anspruch 12, bei dem die Entscheidung basierend auf zumindest einem der folgenden Kriterien getroffen wird: – die Anzahl von Partnerknoten (HA, CN1, CN2, ... CNn), mit denen er laufende Sitzungen hat, – die Verkehrsaktivität zwischen dem/den Partnerknoten (HA, CN1, CN2, ...CNn) und dem Mobilknoten (MN), – Verkehrslast oder Signalisierungslast zwischen Mobilknoten und Zugangsleitweglenkungsknoten und/oder Partnerknoten, – der Zustand der zugrunde liegenden Schichten, – der Zustand des Mobilknotens, – die Frequenz von Weiterreichungen.
  14. System gemäß Anspruch 12 oder 13, bei dem die Entscheidungseinrichtung im Mobilknoten (MN) bereitgestellt ist.
  15. System gemäß Anspruch 12 oder 13, bei dem die Entscheidungseinrichtung im Netzwerk enthalten ist.
  16. System gemäß Anspruch 12 oder 13, bei dem die Entscheidungseinrichtung in einer Instanz im Zugangsnetzwerk enthalten ist.
  17. System gemäß einem der Ansprüche 12 bis 16, bei dem die maximale Anzahl von Weiterreichungen, für die der gleiche Anker-Zugangsleitweglenkungsknoten beibehalten wird, auf einen vordefinierten oberen Grenzwert beschränkt ist.
  18. System gemäß einem der Ansprüche 12 bis 17, bei dem der Zugangsleitweglenkungsknoten (AR) eine Basisstation ist.
  19. System gemäß einem der vorhergehenden Systemansprüche, wobei das System angepasst ist, eine Weiterreichung des Mobilknotens von einem Zugangsleitweglenkungsknoten zu einem anderen Zugangsleitweglenkungsknoten durchzuführen, wie es bei Mobile-IP oder für schnelle Weiterreichungen für Mobile-IPv6 definiert ist.
  20. System gemäß einem der vorhergehenden Systemansprüche, bei dem die Partnerknoten einen Heimatagenten (HA) und/oder einen Korrespondenzknoten (CN) umfassen.
DE60113735T 2001-10-11 2001-10-11 Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten Expired - Lifetime DE60113735T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2001/011787 WO2003034683A1 (en) 2001-10-11 2001-10-11 Method and system for managing data flow between mobile nodes, access routers and peer nodes

Publications (2)

Publication Number Publication Date
DE60113735D1 DE60113735D1 (de) 2006-02-09
DE60113735T2 true DE60113735T2 (de) 2006-06-29

Family

ID=8164622

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60113735T Expired - Lifetime DE60113735T2 (de) 2001-10-11 2001-10-11 Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten

Country Status (5)

Country Link
US (1) US20040213181A1 (de)
EP (1) EP1436962B1 (de)
AT (1) ATE305696T1 (de)
DE (1) DE60113735T2 (de)
WO (1) WO2003034683A1 (de)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7283496B2 (en) * 2001-10-17 2007-10-16 Alcatel Lucent Network paging system and method
US20030104814A1 (en) * 2001-11-30 2003-06-05 Docomo Communications Laboratories Usa Low latency mobile initiated tunneling handoff
WO2003067439A1 (en) * 2002-02-04 2003-08-14 Flarion Technologies, Inc. A method for extending mobile ip and aaa to enable integrated support for local access and roaming access connectivity
US20030193952A1 (en) * 2002-02-04 2003-10-16 O'neill Alan Mobile node handoff methods and apparatus
US8649352B2 (en) 2002-02-04 2014-02-11 Qualcomm Incorporated Packet forwarding methods for use in handoffs
US7290064B2 (en) * 2002-06-24 2007-10-30 Cisco Technology, Inc. Adaptive feedback technique implemented in mobile IP networks
US20040137905A1 (en) * 2003-01-09 2004-07-15 Docomo Communications Laboratories Usa, Inc. System and method for channel scanning in wireless networks
US7146130B2 (en) * 2003-02-24 2006-12-05 Qualcomm Incorporated Wireless local access network system detection and selection
US20040165563A1 (en) * 2003-02-24 2004-08-26 Hsu Raymond T. Wireless local access network system detection and selection
US7590708B2 (en) * 2003-02-24 2009-09-15 Qualcomm, Incorporated Wireless local access network system detection and selection
JP4102692B2 (ja) * 2003-03-25 2008-06-18 富士通株式会社 無線基地局装置および基地局制御装置
KR100568152B1 (ko) * 2003-10-20 2006-04-07 삼성전자주식회사 이동망 환경에서의 크로스오버 라우터 탐색방법,자원예약방법 및 이를 이용하는 자원 예약 시스템
JP3965382B2 (ja) 2003-11-28 2007-08-29 松下電器産業株式会社 通信システム及び通信方法
KR20050081240A (ko) * 2004-02-12 2005-08-18 삼성전자주식회사 버전 6의 모바일 아이피 시스템에서 가상 아이피 존 할당방법
EP1578059A1 (de) 2004-03-19 2005-09-21 Swisscom Mobile AG WLAN Weiterreichung
US7120136B2 (en) * 2004-04-26 2006-10-10 Motorola, Inc. Mobile station mobility in a wireless LAN
WO2005122504A1 (ja) * 2004-06-11 2005-12-22 Matsushita Electric Industrial Co., Ltd. 通信ハンドオーバ方法及び通信メッセージ処理方法
US7873012B2 (en) * 2004-07-26 2011-01-18 Avaya Communication Israel Ltd. Roaming wireless client communication
US7676223B2 (en) * 2004-09-13 2010-03-09 Alcatel-Lucent Usa Inc. Method for controlling a flow of information between secondary agents and a mobile device in a wireless communications system
US7843871B2 (en) 2004-12-21 2010-11-30 International Business Machines Corporation Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
US7529207B2 (en) 2004-12-21 2009-05-05 International Business Machines Corporation Method of reestablishing communication by a mobile node upon recovery from an abrupt shut down
CN101204064A (zh) * 2005-05-31 2008-06-18 松下电器产业株式会社 用于控制分组转发的方法和设备
US9031047B2 (en) * 2005-06-21 2015-05-12 Google Technology Holdings LLC Method and apparatus for facilitate communications using surrogate and care-of-internet protocol addresses
WO2007001950A1 (en) * 2005-06-21 2007-01-04 Motorola, Inc. System and method for paging and location update in a network
US9357586B2 (en) * 2005-06-21 2016-05-31 Google Technology Holdings LLC Method and apparatus to facilitate mobile station communications using internet protocol-based communications
CN101204099B (zh) * 2005-06-21 2011-09-07 摩托罗拉移动公司 基于地址解析协议的无线接入点
US8144687B2 (en) * 2005-06-21 2012-03-27 Motorola Mobility, Inc. Method, apparatus and system for establishing a direct route between agents of a sender node and a receiver node
GB2440100B (en) * 2005-06-21 2009-09-30 Motorola Inc Method and apparatus for reducing latency during wireless connectivity changes
WO2007001951A2 (en) * 2005-06-21 2007-01-04 Motorola, Inc. System and method for providing a distributed virtual mobility agent
KR100882187B1 (ko) * 2005-07-14 2009-02-06 삼성전자주식회사 아이피 멀티미디어 서브시스템 기반의 음성패킷서비스제공을 위한 장치 및 방법
KR101238993B1 (ko) * 2005-08-25 2013-03-04 엘지전자 주식회사 이동통신 시스템에서의 트래픽 전송경로 재설정 방법
US8711698B2 (en) * 2005-10-17 2014-04-29 The Invention Science Fund I, Llc Signal routing dependent on a loading indicator of a mobile node
US9148907B2 (en) 2005-09-07 2015-09-29 The Invention Science Fund I, Llc Heading-dependent routing
WO2007038947A1 (en) * 2005-09-27 2007-04-12 Telefonaktiebolaget L M Ericsson (Publ) A network architecture and a method relating to access of user stations
US8125896B2 (en) * 2005-10-17 2012-02-28 The Invention Science Fund I, Llc Individualizing a connectivity-indicative mapping
US8495239B2 (en) * 2005-10-17 2013-07-23 The Invention Science Fund I, Llc Using a signal route dependent on a node speed change prediction
US20070087695A1 (en) * 2005-10-17 2007-04-19 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Mobile directional antenna
US20070115885A1 (en) * 2005-11-22 2007-05-24 Singh Ajoy K Method and system for fast IP handoff of a mobile node
US8059581B2 (en) 2006-01-05 2011-11-15 Qualcomm Incorporated Method and apparatus for seamless and efficient wireless handoffs
JP4702110B2 (ja) 2006-03-03 2011-06-15 日本電気株式会社 無線通信システム、無線基地局、無線通信制御装置、プログラム、および経路制御方法
KR101185570B1 (ko) * 2006-03-04 2012-09-24 삼성전자주식회사 이동망 환경에서의 다중 인터페이스를 이용한 자원예약방법
KR100790135B1 (ko) * 2006-08-17 2008-01-02 삼성전자주식회사 브리지 기반 무선 기지국 기간망에서의 핸드오버 처리 방법
KR101301188B1 (ko) * 2007-01-02 2013-08-29 삼성전자주식회사 모바일 IPv6 네트워크 시스템 및 그 시스템의 패킷포워딩 방법
US8238314B2 (en) * 2007-09-27 2012-08-07 Alcatel Lucent Method and apparatus for providing a distributed forwarding plane for a mobility home agent
US8625582B2 (en) 2008-08-14 2014-01-07 Motorola Solutions, Inc. Method and apparatus for routing a bearer path in an internet protocol multimedia subsystem based communication system
JP5688016B2 (ja) 2009-06-17 2015-03-25 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカPanasonic Intellectual Property Corporation of America 通信システム、移動端末、ネットワークノード並びに基地局装置
US8538439B2 (en) 2011-02-11 2013-09-17 Blackberry Limited Communications system configured to correct an association mismatch and related methods
US8942193B2 (en) * 2011-04-08 2015-01-27 Blackberry Limited Routing different subsets of an internet protocol flow over different points of attachment
US9380486B2 (en) * 2012-02-08 2016-06-28 Brocade Communications Systems, Inc. Method and system for signaling reduction on radio access networks using targeted intelligence for communication devices
US9055465B1 (en) * 2013-04-26 2015-06-09 Sprint Spectrum L.P. Managing wireless communication link resources
CN108347723B (zh) * 2017-01-25 2021-01-29 华为技术有限公司 一种切换方法和装置
US11240730B2 (en) * 2020-02-28 2022-02-01 At&T Intellectual Property I, L.P. Selectively sending routing information to routing devices in a fifth generation (5G) or other next generation network
US11863348B2 (en) * 2021-07-06 2024-01-02 Cisco Technology, Inc. Message handling between domains

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6172986B1 (en) * 1997-05-13 2001-01-09 Hitachi, Ltd. Mobile node, mobile agent and network system
US6195705B1 (en) * 1998-06-30 2001-02-27 Cisco Technology, Inc. Mobile IP mobility agent standby protocol
US6160804A (en) * 1998-11-13 2000-12-12 Lucent Technologies Inc. Mobility management for a multimedia mobile network
US6760444B1 (en) * 1999-01-08 2004-07-06 Cisco Technology, Inc. Mobile IP authentication
SG92686A1 (en) * 2000-03-09 2002-11-19 Kent Ridge Digital Labs An atm handoff process
US6992994B2 (en) * 2000-04-17 2006-01-31 Telcordia Technologies, Inc. Methods and systems for a generalized mobility solution using a dynamic tunneling agent
US6721297B2 (en) * 2001-11-19 2004-04-13 Motorola, Inc. Method and apparatus for providing IP mobility for mobile networks

Also Published As

Publication number Publication date
ATE305696T1 (de) 2005-10-15
EP1436962B1 (de) 2005-09-28
US20040213181A1 (en) 2004-10-28
EP1436962A1 (de) 2004-07-14
WO2003034683A1 (en) 2003-04-24
DE60113735D1 (de) 2006-02-09

Similar Documents

Publication Publication Date Title
DE60113735T2 (de) Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten
DE60216862T2 (de) System und Verfahren zum mikromobilitätsbasierten Netz-Routing
DE60034557T2 (de) Ip-routing-optimierung in einem zugriffsnetz
DE60030452T2 (de) Weiterbereichsnetz (wan) mobilität für ip-basierte netze
DE10085302B3 (de) Mobile-IP für Mobil-Ad-Hoc-Netze
DE60022881T2 (de) Routing in einem paketvermittlungsnetz mit mobilendstationen
DE60123186T2 (de) Verbessertes Betriebsverfahren für ein Telekommunikationsnetz zum Versorgen von Routenoptimierung und Dienstequalität
DE60218144T2 (de) Verfahren und Vorrichtung zur Routenoptimierung in geschachtelten mobilen Netzwerken
DE60211657T2 (de) System und verfahren für ein mobilitätsverwaltungsprotokoll mit geringem zusatzaufwand in einer internet protokollschicht
DE60122652T2 (de) Weiterreichungsverfahren für eine Mobilstation mit einer mobilen IP Addresse in einem Mobilkommunikationssystem
DE60020563T2 (de) Telekommunikationsvermittlung
DE60221231T2 (de) Verwaltungssystem für mobiles endgerät, mobiles endgerät, agent und programm
EP1391081B1 (de) Heterogenes mobilfunksystem
Lo et al. Architecture for mobility and QoS support in all-IP wireless networks
DE60310417T2 (de) Anschluss/aktualisierung einer mobilen einheit an ein zellulares kommunikationsnetz
EP1405540B1 (de) Verfahren zum durchführen eines qos-orientierten handoffs zwischen einem ersten und einem zweiten ip-basierten, insbesondere mobilen ipv6-basierten kommunikationspfad zwischen einem mobile node (mn) und einem correspondent node (cn)
DE602005000413T2 (de) Verfahren zur Zuordnung einer virtuellen IP-Zone in einem mobilen IPv6 System
DE602004003016T2 (de) Gerät in einem Netzwerk und Verfahren für einen stabilen Handoff in einem IP-basierten ad-hoc-Mobilfunknetzwerk
DE602004011628T2 (de) Verfahren und system für nahtlose weiterreichung zwischen wlan und wwan
DE60130112T2 (de) Weiterreichung in einem drahtlosen mobil-ip-netzwerk
DE60129545T2 (de) Architektur und paketweglenkung in einem netzwerk des mehrträgertyps
DE69932229T2 (de) Aktualisierung des leitweglenkungsgebietes in einem paketfunknetz
CN101465811A (zh) 基于分层移动IPv6协议资源预留方法
Islam et al. Design and implementation of a multihoming-based scheme to support mobility management in NEMO
WO2006056184A1 (de) Verfahren und system zur unterstützung von dienstekontinuität für mobile kommunikation über unterschiedliche zugangsnetzwerke

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
R082 Change of representative

Ref document number: 1436962

Country of ref document: EP