DE60131914T2

DE60131914T2 - Mobilitätsunterstützung für einen korrespondierenden Knoten in einem mobilen IP Netzwerk

Info

Publication number: DE60131914T2
Application number: DE60131914T
Authority: DE
Inventors: Yoichiro Nakahara-ku Kawasaki-shi Igarashi; Mitsuaki Nakahara-ku Kawasaki-shi Kakemizu; Shinya Sawara-ku Fukuoka-shi Yamamura; Kazunori Sawara-ku Fukuoka-shi Murata; Masaaki Nakahara-ku Kawasaki-shi Wakamoto
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-02-09
Filing date: 2001-02-07
Publication date: 2008-12-18
Anticipated expiration: 2021-02-08
Also published as: DE60131914D1; US20010012777A1; EP1124396B1; EP1124396A2; JP2001224070A; EP1124396A3

Description

Technisches Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein Mobilkommunikationssystem und insbesondere ein Netzwerk, das ein Mobilendgerät (einen Mobilknoten, wie z. B. ein tragbarer PC, etc.) unterbringt, das sich zwischen Unternetzwerken bewegt.
2. Stand der Technik
In letzter Zeit hat das Volumen des IP-Paketverkehrs stark zugenommen mit der schnellen Ausbreitung des Internets. Ferner wurde mit der Popularisierung von Zellulartelefonen, IMT-2000 (International Mobile Telecommunications 2000) standardisiert, so dass eine Hochgeschwindigkeits-IP-Kommunikation in einer Mobilumgebung populär zu werden erscheint. Trotz solch schneller technischer Innovation scheint eine Verbesserung der IP-Kommunikation, d. h. eine Technik zum Implementieren eines Dienstes mit zusätzlichem Wert, wie z. B. QoS (Dienstqualität bzw. Quality of Service) für jedes Endgerät oder Lastverteilung von WWW (World Wide Web)-Verkehr über mehrere Server auf einem gesamten Netzwerk nicht vollständig ausgereifter zu werden, obwohl es potentiell nachgefragt wird.
US Händler, wie z. B. Cisco, 3com, etc. haben die Initiative ergriffen, beim Vorschlagen des Konzepts des PBN (Policy-Based Networking bzw. Regelbasiertes Netzwerk) als einen Rahmen zum Steuern eines IP-Netzwerks. Mit dem PBN setzt ein Regelserver Betriebsregeln eines Netzwerks (Daten, die verwendet werden zum Bereitstellen eines Dienstes für einen Benutzer) in einer Netzwerkgerätegruppe, die Dienste implementiert, wie z. B. QoS, etc. durch Bezug nehmen auf die Regeln. Jedoch muss, sobald ein Setzen einer Regel für jedes Mobilendgerät (Setzen eines bereitzustellenden Dienstes an jedes Mobilendgerät) angepasst wird und wenn eine Regel hinzugefügt/geändert wird, eine Regeleinstellung aktualisiert werden in allen der Netzwerkgeräte, was möglicherweise ein Mobilendgerät unterbringen kann, was zu einer Erhöhung in der Regelsetzprozessmenge in dem gesamten Netzwerk führt. Ferner muss, zum Anwenden der Information, die benachrichtigt wird durch das PBN an einen fundamentalen Dienst, vereinbart durch ein individuelles Mobil-IP-Endgerät, etc. die Information als eine Spezifizierung gemacht werden und überprüft werden, ob passend für jeden Dienst, in der Situation der Implementierung.
25 zeigt beispielhaft eine Qualitätskontrolle in einem Netzwerk mit einer Regel gemäß einer herkömmlichen Technik.
Beispielhaft gezeigt wird hier ein Verfahren wie PBN (Policy Base Nework), mit dem ein Policy-Server bzw. Regelserver & NMS (Netware Management System) eine Dienstsverhandlung mit einem Benutzer durchführt, und eine Zulassungskontrolle für jeden Benutzer wird bereitgestellt in einem festen Netzwerk. Bei dem PBN verteilt ein Policy-Server bzw. Regelserver Netzwerkbetriebsregeln (Kontrollparameter) an eine Netzwerkgerätegruppe (einschließlich einem Router, etc.) und setzt diese in die Gruppe. Die Netzwerkgerätegruppe implementiert Dienste, wie z. B. QoS (Dienstsqualität: Dienstsqualitätskontrolle), etc. durch Bezugnehmen auf die oben beschriebenen Regeln, wenn Pakete gesteuert werden.
Jedoch kann ein Problem auftreten, falls ein Versuch gemacht wird, eine Regel zu setzen, die für jedes Mobilendgerät bestimmt ist. Das heißt, dass wenn eine Regel hinzugefügt/geändert wird, wird ein Regelsetzen benötigt durchgeführt zu werden in allen von den Netzwerkgeräten, die in der Lage sind, Pakete weiterzuleiten, die übertragen/empfangen werden von einem Mobilendgerät. Dies führt zu einer starken Erhöhung in der Menge von Regelsetzprozessen in einem gesamten Netzwerk. In anderen Worten müssen Netzwerkgeräte, wie z. B. ein Router, etc. eine riesige Anzahl von Stücken von Regeldaten für entsprechende Endgeräte erhalten. Dies ist unpraktisch als ein Dienststeuerverfahren für jedes Endgerät.
In einem IP-Netzwerk, in dem Sprach- und Daten-Kommunikationen integriert sind, und mit dem verschiedene Arten von Endgeräten verbunden sind, wird ein Verfahren, wie z. B. Int-Serv (RSVP: siehe RFC 2205 der Internet Engineering Task Force, Network Workig Group) oder Diff-Serv (siehe RFC 2475 der Internet Engineering Task Force, Network Working Group) vorgeschlagen als ein Mittel zum Implementieren von QoS, um Verkehr zu schützen, der empfindlich ist hinsichtlich einer Verzögerung oder Verkehr, dem eine höhere Business-Priorität zugewiesen ist. Das Diff-Serv-Verfahren mit einem kleinen Overhead wird betrachtet als am effektivsten für ein Trägernetzwerk oder ein Backbone-Netzwerk (ein Hauptnetzwerk, das das Netzwerk des Internets verbindet). Jedoch benötigt dieses Verfahren ein Regelaufstellen in Netzwerkgeräten auf einem Pfad. Zusätzlich wird bei diesem Verfahren allein ein Netzwerk-Management problematisch.
Deshalb wurde das Konzept des PBN (Policy-Base Netzworking) vorgeschlagen, bei dem ein Server, genannt ein Policy-Server bzw. Regelserver, kollektiv Regeln in Netzwerkgeräten aufstellt. Jedoch werden in einem übergangslosen globalen Netzwerk, zusammengesetzt aus verschiedenen Anbietern und Trägern, die Mobilendgeräte unterstützen, alle lokalen Netzwerke benötigt zum Bestimmen einer Regel für jeden Benutzer, der möglicherweise eine Verbindung durchführen kann, und zum Setzen von Information in Netzwerkgeräte. Der einzige Weg zum Implementieren dieser Bestimmung und Einstellen mit den PBN ist ein lokales halten der Regelinformation von allen Benutzern oder Voreinstellen der Information in potentiellen Netzwerkgeräten.
Es ist extrem ineffizient und unpraktisch, diese Vorgänge für Benutzer auszuführen, deren Gesamtzahl bis zu Hunderten von Millionen geht. Ferner benötigt ein kontinuierliches Halten der Regelinformation von allen Benutzern in Netzwerkgeräten eine Erhöhung in den Speichermengen der Netzwerkgeräte, so dass die Last zum Verarbeiten dieser riesigen Mengen an Information schwerer wird, was zu einer Degradierung im Durchsatz führt.
Umgekehrt wird, falls ein Verarbeitungsverfahren zum Durchführen einer Anfrage an einem Regelserver in allen Fällen adoptiert wird, der Overhead eines Durchführens einer Anfrage an einem Regelserver aufgenommen, und die Möglichkeit, dass die SLA (Service Level Agreement bzw. Dienstniveau-Vereinbarung) nicht eingehalten werden kann, kann sich erhöhen.
EP 0 924 913 stellt eine Anordnung bereit, die eine persönliche Mobilität in dem Internet unterstützt. Für einen Teilnehmer wird eine Dienstbereitschaft eines Endgeräts, das nicht verbunden ist mit dem Heimnetzwerk des Teilnehmers, bereitgestellt, dadurch dass mit der Hilfe der Identifizierung des Teilnehmers, die eingegeben wird über das Endgerät, eine IP-Adresse für den Teilnehmer abgefragt wird bei einem Server-Agent in dem Heimnetzwerk des Teilnehmers, und die abgefragte IP-Adresse wird transferiert an eine Proxyknotenkomponente des Endgeräts.
Eine Aufgabe der vorliegenden Erfindung ist es, ein Kommunikationssystem eines Netzwerks bereitzustellen, das ein Mobilendgerät extensiv unterstützt.
Zusammenfassung der Erfindung
Gemäß der vorliegenden Erfindung wird ein Mobilkommunikationssystem gemäß dem anhängenden unabhängigen Anspruch 1 bereitgestellt, sowie ein Mobilkommunikationsverfahren gemäß dem anhängenden unabhängigen Anspruch 11. Bevorzugte Ausführungsformen sind in den abhängigen Ansprüchen definiert.
Kurze Beschreibung der Zeichnungen
1 erklärt Mobil-IP;
2A und 2B stellen schematisch Kommunikationspfade dar, die gezeigt sind in und extrahiert von 1;
3 zeigt ein Beispiel einer Netzwerkkonfiguration gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
4 zeigt beispielhaft ein Dienstprofil;
5 zeigt den Prozess für ein Registrieren eines CN (Korrespondenzknoten) bei einem Proxy-CN.
6 zeigt beispielhaft eine Sequenz, die die fundamentale Prozedur für ein Registrieren des CN bei dem Proxy-CN zeigt;
7 zeigt beispielhaft eine Sequenz, die das Verfahren zum Verwalten individueller Dienststeuerdaten innerhalb des Proxy-CNs zeigt;
8 zeigt beispielhaft eine Sequenz, die eine bevorzugte Ausführungsform des Verfahrens zum Verwalten eines Besuchszustands des CN (Nr. 1) zeigt;
9 zeigt beispielhaft eine Sequenz, die die bevorzugte Ausführungsform des Verfahrens zum Verwalten des Besuchszustands des CN (Nr. 2) zeigt;
10 zeigt beispielhaft eine Sequenz, die eine andere bevorzugte Ausführungsform des Verfahrens zum Verwalten des Besuchszustands des CN (Nr. 1) zeigt;
11 zeigt beispielhaft eine Sequenz, die eine andere bevorzugte Ausführungsform des Verfahrens zum Verwalten des Besuchszustands des CN (Nr. 2) zeigt;
12 zeigt beispielhaft eine Sequenz, die eine andere bevorzugte Ausführungsform des Verfahrens zum Verwalten des Besuchszustands des CN (Nr. 3) zeigt;
13 zeigt eine erste bevorzugte Ausführungsform des Verfahrens zum Anordnen einer Proxy-CN-Funktionalgruppe;
14 zeigt eine zweite bevorzugte Ausführungsform des Verfahrens zum Anordnen der Proxy-CN-Funktionalgruppe;
15 zeigt eine dritte bevorzugte Ausführungsform des Verfahrens zum Anordnen einer Proxy-CN-Funktionalgruppe;
16 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in einer bevorzugten Ausführungsform erklärt, die in 13 gezeigt ist (Nr. 1);
17 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform erklärt, die in 13 gezeigt ist (Nr. 2);
18 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform erklärt, die in 14 gezeigt ist (Nr. 1);
19 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform erklärt, die in 14 gezeigt ist (Nr. 2);
20 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform zeigt, die in 14 gezeigt ist (Nr. 3);
21 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform zeigt, die in 14 gezeigt ist (Nr. 4);
22 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform zeigt, der in 15 gezeigt ist (Nr. 1);
23 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform zeigt, die in 15 gezeigt ist (Nr. 2);
24 zeigt beispielhaft ein Flussdiagramm, das den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform zeigt, die in 15 gezeigt ist (Nr. 3); und
25 zeigt beispielhaft die herkömmliche Qualitätskontrolle unter Verwendung von Regeln in einem Netzwerk.
Detaillierte Beschreibung
Die vorliegende Erfindung nimmt die Technik als gegeben an, die in der US-Patentanmeldung Nr. 09/672,866 (die japanische Patentanmeldung Nr. 2001-169341 ) gegeben ist. Hier im Folgenden werden die Inhalte dieser Anmeldung kurz beschrieben. Für weitere Details sei auf die Beschreibung verwiesen, die in der Anmeldung enthalten ist.
Ein Mobilkommunikationssystem ermöglicht einem Mobilendgerät, verbunden mit einem Netzwerk, zusammengesetzt aus einer Vielzahl von Unternetzwerken, mit Kommunikation versorgt zu werden ähnlich zu der bereitgestellt in einem ersten Unternetzwerk, wenn verbunden in einem zweiten Unternetzwerk, selbst nach einem Bewegen von dem ersten zu dem zweiten Unternetzwerk. Dieses System umfasst ein Korrespondenzendgerät, das eine Kommunikation mit dem Mobilendgerät durchführt; eine Authentifizierungseinheit, die das Korrespondenzendgerät authentifiziert; eine Einstelleinheit, die Kommunikationsparameter einstellt, die das Korrespondenzendgerät benötigt zum Durchführen einer Kommunikation mit dem Mobilendgerät, wenn das Mobilendgerät sich bewegt von dem ersten an das zweite Unternetzwerk; und eine Kommunikationseinheit, wobei eine Kommunikation durchführt zwischen netzwerksteuernden Geräten, so dass die Kommunikationsparameter gesetzt bzw. eingestellt werden.
Ein Mobilkommunikationsverfahren zur Verwendung in einem Netzwerk einschließlich einem Korrespondenzendgerät, das eine Kommunikation mit einem Mobilendgerät durchführt, was einem Mobilendgerät ermöglicht, verbunden mit einem Netzwerk, zusammengesetzt aus einer Vielzahl von Unternetzwerken, versorgt zu werden mit Kommunikation ähnlich zu der in einem ersten Unternetzwerk wenn verbunden in einem zweiten Unternetzwerk, selbst nach einem Bewegen von dem ersten zu dem zweiten Unternetzwerk. Dieses Verfahren umfasst die Schritte von: (a) Authentifizieren des Korrespondenzendgeräts; (b) Einstellen von Kommunikationsparametern, die das Korrespondenzendgerät benötigt zum Durchführen einer Kommunikation mit dem Mobilendgerät, wenn das Mobilendgerät sich von dem ersten zu dem zweiten Unternetzwerk bewegt; und (c) Durchführen einer Kommunikation zwischen Netzwerksteuergeräten, so dass die Kommunikationsparameter eingestellt bzw. gesetzt werden.
Ein Router unterstützt ein Endgerät, das eine Kommunikation mit einem Mobilendgerät durchführt, verfolgt Binde-Information über das Mobilendgerät, die transferiert wird von dem Heimagent des Mobilendgeräts an das Endgerät, und verarbeitet Datenpakete von dem Endgerät an das Mobilendgerät, basierend auf der Binde-Information.
Geräte, die innerhalb eines Netzwerks angeordnet sind, führen eine Kommunikation durch zum Verwalten oder Einstellen von Kommunikationsparametern, die benötigt werden wenn ein Mobilendgerät, das sich zwischen den Unternetzwerken bewegt, mit einem Korrespondenzendgerät kommuniziert, während einem Durchkreuzen der Unternetzwerke, und das Korrespondenzendgerät kommuniziert mit dem Mobilendgerät über diese Geräte. Demgemäß muss das Korrespondenzendgerät nicht eine bestimmte Fähigkeit aufweisen zum Empfangen eines Kommunikationsdienstes mit dem Mobilendgerät, so dass eine schwere Verarbeitungslast nie dem Korrespondenzendgerät auferlegt wird. Deshalb werden verschiedene Endgeräte, die von Benutzern besessen werden, verfügbar als ein Korrespondenzendgerät, und die Benutzer können leicht eine Kommunikation mit einem Mobilendgerät empfangen.
Diese Patentanmeldung stellt einen Rahmen einer Dienststeuerung bzw. Dienstkontrolle bereit, die basiert auf einer Mobil-IP-Architektur, implementiert durch Kombinieren von Mobil-IP, das vereinbart ist durch RFC 2002 und einem AAA (Authentication, Authorization und Accounting)-System, das gegenwärtig untersucht wird von IETF (Internet Engineering Task Force: a leading standardization organization fort he Internet; Internet Engineering Task Force, Network Working Group RVD 2002: IP Mobility Support, Oktober 1996), für ein effektives Einstellen von notwendiger Information (Regeln) in einem globalen Netzwerk, bereitstellend Anbietern ein Benutzerprofil, das auf eine zentralisierte Art und Weise verwaltet wird.
Mit der in dieser Anmeldung beschriebenen Technik wird eine Datenbank zum Speichern von Information, eingesetzt in einem Netzwerkgerät, in Benutzereinheiten angeordnet in dem AAA-System, Multifunktion zum Extrahieren der Information von dem Identifizierer (NAI: Network access Identifier bzw. Netzwerkzugangsidentifizierer) von einem Benutzer, wenn eine Authentifizierungsanforderung durchgeführt wird und zum Auswählen und Berichten der Information, benötigt durch die funktionalen Elemente, festgelegt durch RFC 2002, FA (Foreign Agent bzw. Fremdagent, dessen Details später beschrieben werden) und einem HA (Heimagent bzw. Home Agent, dessen Details später auch beschrieben werden). Ferner wird das für eine Kommunikation zwischen funktionalen Elementen verwendete Protokoll erweitert, so dass die Information, die benötigt wird, durch jedes Element benachrichtigt werden kann, der HA und der FA werden ausgestattet mit der Funktion zum Zwischenspeichern der Information, benachrichtigt von dem AAA-System, und eine Funktion zum Steuern der Informationseinstellung in einem Netzwerkgerät und Paketeditieren wird hinzugefügt. Diese Funktionen werden integriert mit der Registrierungsprozedur des Mobil-IP, Handoff (Handover bzw. Übergabe) während einer Bewegung oder der Prozedur zum Optimieren eines Weges, so dass es möglich wird, gültige Regelinformation einzustellen, während ein Benutzer auf ein Netzwerk zugreift.
Demgemäß wird die vorliegende Erfindung erklärt durch Annehmen von Mobil-IP. Für Details über Mobil-IP wird auf die folgenden Referenzen verwiesen.

"Mobile IP: The Internet Unplugged", geschrieben von James D. Solomon, überwacht und übersetzt durch F. Teraoka und J. Inoue und veröffentlicht durch Pierson Education, Co.

Akronyme, die in der Erklärung der bevorzugten Ausführungsformen auftreten, werden unten erklärt.
- MIP (Mobil-IP)
Mobil-IP-Protokoll, festgelegt durch RFC 2002 und seinen zukünftigen Erweiterungen.
- AAA protocol
Protokoll, das verwendet wird durch ein AAA-System. Die vorliegende Erfindung bestimmt nicht ein zu verwendendes Protokoll. Jedoch nehmen die bevorzugten Ausführungsformen die Verwendung eines DIAMETER-Protokolls an, (das gegenwärtig untersucht wird von IETF, und erhalten wird durch Erweitern des RADIUS-Protokolls zur Authentifizierung und Buchführung, was am häufigsten verwendet wird von Internet Dienstanbietern). Das AAA-Protokoll ist verfügbar wie jedes Protokoll, das die Information übertragen kann über Authentifizierung, Autorisierung, Buchhaltung und Regeln.
- Datenbank Rückholprotokoll
Protokolle zum Holen einer Dienstsprofildatenbank. Ein zu verwendendes Protokoll hängt ab von einem Datenbankprodukt, das verwendet wird als eine Dienstsprofil-Datenbank. LDAP (Lightweight Directory Access Protocol: festgelegt durch X.500, was der Standard von ISO (International Standard Organization) und ITU (International Telecommunication Union) ist), wird normal verwendet. Die vorliegende Erfindung bezieht sich nicht auf Vorgänge eines Rückholprotokolls in einer Datenbank.
- MN (Mobilknoten)
Ein Mobilendgerät mit einer Mobil IP-Protokollfunktion
- CN (Korrespondenzknoten)
Ein Kommunikationsknoten, mit dem ein Mobilendgerät kommuniziert.
- AAA
Ein Akronym, das verwendet wird von IETF für eine Servergruppe, die eine Authentifizierung, Autorisierung und eine Buchhaltung ausführt. Die AAA-Servergruppe umfasst eine Funktion zum entsprechenden Mitteilen eines Dienstprofils einem HA oder einem FA (Fremdagent) durch Verwenden einer HA-Registrierungsanforderungsnachricht oder einer Authentifizierungsbestätigungsnachricht über ein AAAF.
Zusätzlich zu den oben beschriebenen Funktionen umfasst die AAA-Servergruppe gemäß der vorliegenden Erfindung eine Dienstsverwaltungsfunktion bzw. Dienstmanagementfunktion zum Extrahieren eines Dienstprofils eines Benutzers, der eine Authentifizierungsanforderung von einer Dienststeuerdatenbank durchführt und zum Erzeugen eines Dienstprofils mit einem Format eines allgemeinen Zwecks, in dem Paketsteuerinformation eingestellt werden kann. Ein AAAH ist ein AAA-Server in einem Netzwerk, der die Teilnehmerdaten des Benutzers hält, der die Authentifizierungsanforderung durchführt, wobei ein AAAF einen AAA-Server in einem Netzwerk ist, der nicht die Teilnehmerdaten des Benutzers hält. Der AAAF identifiziert den AAAH, basierend auf dem NAI (Netzwerkzugangsidentifizierer) des Benutzers und überträgt direkt eine Nachricht an den HA als Proxy.
- FA (Fremdagent)
Ein funktionales Element, definiert durch RVC 2002. Ein Agent, der keine Heimadresse zu einem Mobilendgerät zugeordnet hat. Entkapseln eines Pakets, das eingekapselt ist und übertragen an eine care-of-address, die die Adresse des eigenen Knotens ist und Weiterleiten des Pakets an eine Verbindungsschichtadresse entsprechend der Heimadresse. Diese Adressentsprechung wird verwaltet durch eine Tabelle, die Besucherliste genannt wird. Zur selben Zeit ist der FA ein Zugangsrouter eines Mobilendgeräts und ein AAA-Protokollclient. Der FA hat eine Session-Transaktionsfunktion zum Verwalten einer DIAMETER-Session.
- HA (Heimagent)
Ein funktionales Element, definiert durch RFC 2002. Ein Agent, der eine Heimadresse einem Mobilendgerät zugeordnet hat. Das Paket, das adressiert wird an die Heimadresse des Mobilendgeräts und weitergeleitet durch den HA, wird eingekapselt und übertragen an die care-of-address des FA, was der Heimadresse entspricht. Hier ist eine "care-of-address" etwas Ähnliches wie ein Postkasten in einem normalen Postsystem. Diese Adressentsprechung wird verwaltet durch eine Tabelle, genannt ein (mobiler) Binde-Cache bzw. Binde-Zwischenspeicher. Der HA ist ein AAA-Protokollclient zur gleichen Zeit. Der HA hat eine Session-Transaktionsfunktion zum Verwalten einer DIAMETER-Session.
Ferner betrifft die vorliegende Erfindung eine Wegoptimierung in dem Mobil-IP und die Technik, die in der japanischen Patentanmeldung Nr. 2001-169341 erwähnt wird.
1 erklärt das Mobil-IP.
Es sei angenommen, dass ein Netzwerk zusammengesetzt ist aus Unternetzwerken 1 und 2. Auch sei angenommen, dass ein Mobilknoten (MN) 12 zuerst in einem Unternetzwerk 2 ist und eine Kommunikation durchführt mit einem CN 13 über einen HA 11. Der MN 12 kann getragen werden wie ein tragbarer PC und kann verbunden werden mit einem unterschiedlichen Netzwerk.
Hier sei angenommen, dass der MN 12 sich von dem Unternetzwerk 2 zu dem Unternetzwerk 1 bewegt. Nachdem der MN 12 sich zu dem Unternetzwerk 1 bewegt, versucht er eine Kommunikation mit dem CN 13 zu starten, der verbunden ist mit dem Unternetzwerk 2. Anfangs gibt der MN 12 eine Registrierungsanforderung an einen FA 10 aus, so dass der FA 10 eine Registrierung durchführt, so dass der MN 12 selbst in das Netzwerk 1 kommt. Ferner benachrichtigt der FA 10 den HA 11 in den Unternetzwerk 2, dass der MN 12 gegenwärtig gesteuert wird durch den FA 10. Der HA 11 gibt an den CN 13 eine Instruktion zum Aktualisieren der Netzwerk-Binde-Information aus zum Kommunizieren mit dem MN 12, basierend auf der Benachrichtigung von dem FA 10. Bei Beendigung der Registrierung für den MN 12 gibt der HA 11 seine Bestätigung an den FA 10 zurück. Nachdem der FA 10 eine Registrierung durchführt, so dass der MN 12 gegenwärtig von ihm gesteuert wird, gibt er eine Bestätigungsnachricht an den MN 12 zurück als eine Benachrichtigung, die kennzeichnet, dass eine Kommunikation durchgeführt werden kann. Wenn eine Nachricht an den MN 12 übertragen wird, basierend auf einer Aktualisierungsinstruktion, überträgt der CN 13 ein Signal an den FA 10 (durch Tunneln) und bringt den FA 10 dazu, die Nachricht zu transferieren. Als Ergebnis kann eine Kommunikation mit dem MN 12 ermöglicht werden.
Indessen überträgt in einer Kommunikation von dem MN 12 zu dem CN 13 der MN 12 zuerst die Nachricht, die der MN 12 an den CN 13 adressiert, an den FA 10. Der FA 10 überträgt die Nachricht, die empfangen wird von dem MN 12 direkt an den CN 13. Auf diese Art und Weise kann der MN 12 weiter die Kommunikation mit dem CN 13 durchführen, selbst nach einem Bewegen zu dem Unternetzwerk 1.
2A und 2B stellen schematisch Kommunikationspfade dar, die gezeigt sind in und extrahiert von 1. 2A zeigt den Fall, wo eine Pfadoptimierung nicht durchgeführt wird, wobei 2B den Fall zeigt, wo eine Pfadoptimierung durchgeführt wird.
Wie in 2A gezeigt, wird in dem Fall, wo eine Pfadoptimierung nicht durchgeführt wird, die von dem MN übertragene Nachricht, an den FA übertragen, und dann von dem FA an den CN übertragen, während die Nachricht von dem CN einmal übertragen wird an den HA und übertragen an den FA. Die Nachricht wird dann übertragen an den MN. Da die Nachricht von dem CN an den MN durch den HA durchgehen muss, wie oben beschrieben, wird die Funktion des HA, der die Netzwerk-Ressource ist, verwendet für jede Kommunikation, was zu einer Verschwendung an Netzwerk-Ressourcen führt.
2B zeigt den Fall, wo eine Pfadoptimierung durchgeführt wird. Der CN mit einer Pfadoptimierungsfunktion überträgt die Nachricht, die adressiert wird an den MN nicht an den HA aber direkt an den FA, der die Nachricht an den MN überträgt. Der Fluss der Nachricht von dem MN an den CN ist ähnlich zu dem, der in 2A gezeigt ist. Auf diese Art und Weise wird es unnötig, bei jeder Kommunikation durch den HA zu gehen, wodurch verhindert wird, dass Netzwerk-Ressourcen verschwendet werden.
Mit der Funktion (1) die Pfadoptimierung darstellend (draftietf-mobileip-optim-08.txt) in dem Mobil-IP, wird jeder CN ausgestattet mit einer Binde-Cache-Verwaltungsfunktion und einer Tunnelpaketerzeugungsfunktion, die dem HA gehören, so dass ein individueller CN ein Tunnelpaket erzeugt und überträgt, adressiert an die care-of-address des MN. Deshalb wird das Paket von jedem CN, der mit dem MN Kommuniziert, direkt an die care-of-Adresse des MN übertragen mittels eines Tunnelns und nicht über den HA. In diesem Fall muss jeder CN Protokollmanipulationen verwalten, die für die Pfadoptimierung benötigt werden und Daten, die in CN-Einheiten zu halten sind.
Mit der Funktion (2), die Technik darstellend, die in der japanischen Patentanmeldung Nr.2001-169341 erwähnt wird, wird ein "Dienstprofil" verteilt an jeden CN, so dass eine individuelle Dienststeuerung für jeden CN ausgeführt wird. Speziell wird ein Dienstprofil hinzugefügt zu der Binde-Aktualisierungsnachricht, die verwendet wird in der Pfadoptimierung, und die Nachricht mit dem Profil hinzugefügt wird übertragen an einen CN. Ähnlich erzeugt in dem Fall des oben beschriebenen Binde-Caches der CN einen Eintrag aufs Neue für einen empfangenen Binde-Cache, falls der Eintrag nicht innerhalb des CN selbst existiert. Falls der Eintrag schon existiert, aktualisiert der CN das Dienstprofil.
Wie oben beschrieben, wird eine Funktionsaddition benötigt für jeden CN als Voraussetzung, so dass eine individuelle Dienststeuerung ausgeführt wird. Zum Empfangen der individuellen Dienststeuerung, die in der japanischen Patentanmeldung Nr. 2001-169341 erwähnt ist, muss der CN die oben beschriebenen Funktion (2) umfassen.
Ferner muss als eine Voraussetzung des CN in der japanischen offengelegten Patentanmeldung Nr.2001-169341 ein Mobilendgerät, das die individuelle Dienststeuerung gemäß dieser Anmeldung empfangen kann, die Verarbeitungsfähigkeit des Mobil-IP umfassen.
Mit dieser Fähigkeit können jedoch einige Verbindungsschichten bzw. Link Layer nicht unterstützt werden, beispielsweise eine Dial-up-Verbindung in PPP (Point-to-Point Protocol), das ein Hauptprotokoll zum Zugreifen auf ein ISP (Internet Dienstanbieter) in einem Mobilendgerät ist oder Ähnlichem. Aus diesem Grund kann ein tragbarer CN (Mobilendgerät) nicht die individuelle Dienststeuerung empfangen, die offenbart ist in der japanischen Patentanmeldung Nr. 2001-169341 . Zum Erlauben, dass die individuelle Dienststeuerung empfangen wird, müssen die folgenden Voraussetzungen erfüllt sein.

(1) Funktionen müssen an ein CN hinzugefügt werden, der als Dienstziel gemäß der japanischen Patentanmeldung Nr. 2001-169341 zu erkennen ist. Hinzufügen von Funktionen an ein Gerät mit einem geringen Durchsatz erhöht eine Last auf dem Durchsatz. Dies wird kein Problem in einer stationären Arbeitsstation (workstation) oder PC innerhalb des maximalen Durchsatzes. Jedoch kann dies möglicherweise ein ernstes Problem werden in manchen Fällen in einem tragbaren Mobilgerät einer kleinen Größe.
(2) Ähnlich ist es in der Technik gemäß der japanischen Patentanmeldung Nr. 2001-169341 essentiell, Funktionen zu einem CN hinzuzufügen zum Empfangen der individuellen Dienststeuerung, die bereitgestellt wird durch diese Technik. Dies wird ein Hindernis beim Populärmachen des Dienstes dieser Architektur. Zum Bereitstellen von jedem CN mit dem gleichen Dienst, muss keine individuelle Voraussetzung einem Endgerät abverlangt werden.
(3) Auch muss in einem Mobilendgerät, das das Mobil-IP nicht verwenden kann aufgrund einer funktionalen Beschränkung abhängig von einem Verbindungsschichten-Typ, wenn ein CN einen ISP verbindet, die individuelle Dienststeuerung bereitgestellt werden durch die Ausführung der Funktion bei einem Netzwerk-Edge als Proxy. Speziell verwendet ein CN, der eine Bewegung zwischen Netzwerken annimmt, häufig ein Dial-up PPP und kann nicht Mobil-IP verwenden. Dies kann möglicherweise ein Problem beim Populärmachen des Dienstes auf eine gleiche Art und Weise sein wie in (2).

Demgemäß kann, falls der CN gemäß der japanischen Patentanmeldung Nr. 2001-169341 versucht wird mit den oben beschriebenen Funktionen ausgestattet zu werden, ein ernsteres Problem auftreten, speziell bei einem tragbaren CN, und die Funktion, die dieser Architektur spezifisch ist, wird benötigt, hinzugefügt zu werden. Die folgenden zwei Voraussetzungen müssen erfüllt werden, um den Dienst einer größeren Vielzahl von Endgerät und Benutzertypen bereitzustellen durch Unterstützen der Funktionen des CN auf einer Netzwerkseite.

(1) Freigeben jedes CN von einem Hinzufügen von Funktionen.
(2) Auch einem Mobilendgerät in einer Nicht-Mobil-IP-Umgebung erlauben, die individuelle Dienststeuerung zu empfangen.

3 zeigt die Konfigurierung eines Netzwerks gemäß einer bevorzugten Ausführungsform der der vorliegenden Erfindung.
In der bevorzugten Ausführungsform gemäß der vorliegenden Erfindung wird ein Proxy-CN, der für einen CN agiert, angeordnet in einem Netzwerk, nicht hinzufügend viele Funktionen zu dem CN wie oben beschrieben. Das gesamte Netzwerk ist konfiguriert als lein Mobil-IP-Netzwerk, wo die oben beschriebenen MN, Greifabschnitt, AAAF, AAAH und HA angeordnet werden. Die Greifabschnitt, HA, AAAF und AAAH können Nachrichten austauschen über ein IP-Transfer-Netzwerk 21. Der Proxy-CN kann als Software oder Hardware beispielsweise in einem Router implementiert werden.
Wenn der MN wünscht mit dem CN zu kommunizieren, unterstützt durch den HA, wird nämlich eine Registrierungsanforderung an den FA durchgeführt. Diese Anforderung wird benachrichtigt an den AAAH über den AAAF. Der AAAH verifiziert den Inhalt eines zu bereitstellenden Dienstes durch Bezugnahme auf eine Dienstprofildatenbank 22 und benachrichtigt den HA. In der oben beschriebenen Erklärung wird der CN direkt verbunden mit dem HA und kommuniziert mit dem MN. Bei diesem Verfahren erhöht sich jedoch die Anzahl der Funktionen, die hinzugefügt werden an den CN, so dass eine Verarbeitungsverzögerung auftreten kann aufgrund eines Verlustes einer Prozessorverarbeitungsfähigkeit, falls der CN auch ein tragbarer PC ist ähnlich zu dem MN.
Demgemäß wird ein Proxy-CN 24 angeordnet zwischen dem CN 25 und dem HA 26. Der Proxy-CN 24 umfasst eine funktionale Gruppe einschließlich CMF, TCF, MHF, CD und MAF, die später beschrieben werden. Der CN 25 greift auf den Proxy-CN 24 zu, um mit dem MN zu kommunizieren. Der Proxy-CN 24 fragt einen Verbindungsschicht-Authentifizierungsserver 23, ob oder ob nicht ein Zugang des CN 25 zu authentifizieren ist. Der Verbindungsschicht-Authentifizierungsserver 23 erhält notwendige Parameter durch Bezugnehmen auf eine Dienstprofildatenbank 27 gemäß dem NAI des CN 25, verifiziert den Inhalt des bereitzustellenden Dienstes an den CN 25 und benachrichtigt den Proxy-CN 24, dass die Kommunikation autorisiert ist. Der Proxy-CN 24 gibt eine Kommunikations-Autorisierung an den CN 25 aus. Der CN 25, der die Kommunikationsautorisierung empfängt, überträgt die Nachricht von dem CN 25 an den MN über den Proxy-CN 24 und den HA 26. Die an den HA 26 übertragene Nachricht wird dann an den MN übertragen, wie oben beschrieben.
Durch Anordnen der Funktionen, dass sie angeordnet sind in dem CN 25 in dem Proxy-CN 24, wie oben beschrieben, gibt es keinen Bedarf zum Hinzufügen von Funktionen zu einem individuellen CN. Als Ergebnis kann ein CN von irgendeinem Typ einen Dienst eines entsprechenden Netzwerks empfangen.
Ferner wird, falls ein dem CN 25 bereitgestellter Dienst ein Tunneln enthält, die Nachricht, die von dem CN 25 zu dem Proxy-CN 24 geht, direkt übertragen an den FA.
Eine Dienstprofildatenbank 27, die in 3 gezeigt ist, ist zusammengesetzt aus Dienstprofilen für entsprechende Benutzeridentifizierer (NAIs). Eine Auswahl von Diensten einschließlich einem Sicherheitsdienst, einem Multicast-Dienst, etc. kann registriert werden und implementiert werden.
Ein Dienstprofil ist zusammengesetzt aus NAI zum Identifizieren eines Benutzers und einem Dienstblock mit einer Konfiguration, die sich unterscheidet abhängig von einem Diensttyp. Der Dienstblock ist zusammengesetzt aus einem Diensttyp, Regel und Information spezifisch für einen Dienst. Die Information spezifisch für einen Dienst einer Paketfilterung enthält eine Regulierungsadresse und eine Anwendungsbedingung. Die Information spezifisch für einen Dienst der Diff-Serv-Übertragung, angewandt auf ein Übertragungspaket eines Mobilendgeräts, enthält eine Empfangsortsadresse, einen Empfangsortsport und einen TOS (Diensttyp) Wert. Die Information spezifisch für einen Dienst des Diff-Serv-Empfangs, angewandt auf ein Empfangspaket eines Mobilendgeräts, enthält eine Übertragungsquellenadresse, eine Übertragungsquellenport und einen TOS-Wert.
Hier wird ein Beispiel eines Dienstprofils in 4 gezeigt.
Das Dienstprofil ist ein "Informationssatz", der eine Paketsteuereinrichtung beschreibt, die benötigt wird zum Ausführen der IP-Dienststeuerung, die bereitgestellt wird durch die vorliegende Erfindung.
Die folgenden zusammensetzenden Elemente sind enthalten als spezifische Elemente.

(1) Steuerzielpaketinformation Information zum Identifizieren eines Typs eines zu steuernden Pakets.
(2) Routing/Paket Editierinformation Information über den Typ und Mittel einer Paketsteuerung (ex. Übertragungsbestimmungsortsadresse, etc.)
(3) Spezifische Steuerinformation Information über ein Dienststeuermittel spezifisch für ein physikalisches Gerät. Ein FA und ein HA sind zusammengesetzt aus einer Router-Steuereinheit und einer Dienststeuereinheit.

Die Router-Steuereinheit umfasst eine Router-Tabelle, ein Binde-Cache, der eine temporäre Routing-Tabelle ist, und ein Dienststeuerfilter zum Identifizieren eines Dienststeuerzielpakets. Diese Einheit hat die Funktionen zum Extrahieren eines Empfangs-IP-Headers und zum Editieren von Header-Information.
Die Dienst-Steuereinheit umfasst eine Dienststeuertransaktionsfunktion, mit der eine Dienststeuertransaktion eingestellt wird, zurückgeholt wird, aktualisiert oder gelöscht wird gemäß der Anforderung von der Router-Steuereinheit. Die Dienst-Steuereinheit umfasst ein MIP und eine DIAMETER-Protokollfunktion und auch eine allgemeine Protokollverarbeitungsfunktion, die einen Nachrichtenempfang und Übertragungspuffer verwendet.
Die Proxy-CN-Funktionalgruppe ist ein Satz von funktionalen Elementen, die benötigt werden, wenn die Funktionen, die von jedem CN umfasst werden müssen, getrennt werden von den CN und angeordnet auf einer Netzwerkseite.
Spezifisch ausgedrückt wird diese Gruppe zusammengesetzt aus Funktionen, die unten aufgelistet und definiert werden.

(1) CMF (Cache-Managementfunktion): Eine Funktion, die ein Binde-Cache speichert und verwaltet (care-of-address, etc. eines Mobilknotens (hier im Folgenden abgekürzt mit MN), was ein Kommunikationspartner ist) für Pfadoptimierung in dem Mobil-IP. Speziell Detektieren des Binde-Caches, Übertragen von einem HA, Neuerzeugen eines Eintrags, falls der Eintrag für diesen Cache nicht existiert und Aktualisieren des Eintrags mit der empfangenen Information des Binde-Caches, falls der Cache schon existiert.
(2) TCF (Tunneling Capability Function bzw. Tunnelfähigkeitsfunktion): Eine Funktion, die ein Tunnelpaket an eine care-of-address des MN erzeugt, der Pfadoptimierung bezüglich des oben beschriebenen (1) implementiert. Falls diese Funktion umfasst wird, wenn ein Paket versucht wird zu übertragen an die care-of-address des MN, der die Pfadoptimierung implementiert, wird das Paket eingekapselt (beispielsweise eingekapselt als ein IP-in-IP-Paket), basierend auf der in dem Binde-Cache gespeicherten Information.
(3) MHF (Nachrichten-Handhabungsfunktion): Falls eine spezifische Nachrichtenschnittstelle definiert wird in der vorliegenden Erfindung, überträgt/empfängt die MHF diese Nachricht. Falls die Proxy-CN-Funktionalgruppe angeordnet ist in verteilten physikalischen Elementen, und falls sie hin und her spezifische Information austauschen müssen, erzeugt diese Funktion eine Nachricht auf einer Übertragungsseite oder detektiert eine Nachricht auf einer Empfangsseite.
(4) MAF (Mobil-Agent-Funktion): eine Mobil-Agent-Funktion in dem Mobil-IP. Diese Funktion wird verwendet zum dynamischen Registrieren/Entfernen eines CN, der Mobil-IP verwenden kann an/von einem Proxy-CN.
(5) CD (Cache-Daten): Inhalte der Datenbank, die ursprünglich zu einem CN gehört in der bevorzugten Ausführungsform gemäß der vorliegenden Erfindung. Einen Speicher zum Speichern dieser Inhalte, etc. aufweisen. Speziell wird die CD zusammengestellt aus einer Besucherliste und einem Binde-Cache.

Datentypen, die ein Proxy-CN benötigt zum Registrieren und Verwalten eines individuellen CN werden unten aufgelistet.

(1) Besucherliste: Eine Liste mit der fundamentalen Besucherinformation, und der Information über die Besuchszustands-Flag von jedem CN und die Information (pointer) zum Durchführen einer Assoziierung mit Cache-Daten, die später zu beschreiben sind.
(2) Binde-Cache: Ein Binde-Cache, der kontinuierlich zu halten ist von einem CN in einer Pfadoptimierung in dem Mobil-IP. Der Binde-Cache ist enthalten in einer Binde-Aktualisiernachricht.
(3) Dienstprofil: Profildaten, die vorbereitet werden für jeden NAI und zum Implementieren der individualen Dienststeuerung in der japanischen Patentanmeldung Nr. 2001- 169341 . Das Dienstprofil ist oder kann enthalten sein in der Binde-Aktualisiernachricht.

Da die Anordnung der oben beschriebenen funktionalen Elemente und Daten, die dem Proxy-CN konfigurieren, sich unterscheiden können in einem Netzwerk abhängig von einem Implementierungsverfahren, gibt es kein festes Abbilden für die physikalischen Elemente. In anderen Worten gibt es keinen Bedarf zum Ausstatten des Proxy-CN mit allen von den Funktionen. Ein CN oder ein HA kann ausgestattet sein mit einigen dieser Funktionen.
5 zeigt den Prozess zum Registrieren eines CN (ohne Mobil-IP-Funktionalität) bei einem Proxy-CN.
Falls ein CN, der sich zwischen Netzwerken bewegen kann (hier im Folgenden bezeichnet als ein Mobil-CN) registriert wird bei einem Proxy-CN, verwaltet durch den ISP, mit dem der CN verbunden ist, wird PPP (Point-to-Point-Protokoll) verwendet als ein allgemeines Zugangsverfahren. Wenn eine Verbindung durchgeführt wird mit dem ISP durch eine Telefonleitung, wird dieses Protokoll in den meisten Fällen verwendet.
Jedoch kann, falls der durch den ISP bereitgestellte Proxy-CN versucht wird, über PPP verwendet zu werden, das Mobil-IP nicht erkannt werden. Dies rührt hauptsächlich daher, weil der Mobilknoten (Mobil-CN) des Mobil-IP eine Registrierungsanforderung mit einer spezifizierten Heimadresse ausgibt. Jedoch kann ein dial-up-Server von dem PPP nicht solch eine Adresse autorisieren (eine Adresse, deren Präfix unterschiedlich ist von dem eines stehenden Netzwerks).
In solch einem Fall wird ein Mittel zum Verwenden eines Proxy-CN ohne Verwendung des Mobil-IP bereitgestellt.
Für die Authentifizierung des CN über PPP ist ein AAA Server in einen Mobil-IP-Netzwerk nicht verfügbar. Deshalb wird ein Verbindungsschicht-Authentifizierungsserver vorbereitet als ein Proxy des CN, der die PPP-Verbindung verwendet, und eine Verbindung mit dem Netzwerk wird autorisiert, falls eine Authentifizierung gemacht wird durch den Authentifizierungsserver.
Ferner wird, als ein Verfahren zum Verteilen des Dienstprofils für den CN entsprechend diesem Fall, die Dienstprofildatenbank (Dienstprofil DB) verbunden mit dem oben beschriebenen Verbindungsschicht-Authentifizierungsserver vorbereitet, nicht dem AAA-Server, und die Originaldaten des Dienstprofils für den entsprechenden CN werden in der Datenbank gespeichert. Nachdem der Verbindungsschicht-Authentifizierungsserver eine Verbindungsanforderung von dem CN (1)) von 5) empfängt und verifiziert, dass dieser CN ein legaler CN ist, liest er die Profildaten von dem Dienstprofil DB ((2) von 5) und benachrichtigt den Proxy-CN ((3) von 5). Der Verbindungsschicht-Authentifizierungsserver gibt dann eine Zugangsautorisierung an den CN aus ((4) von 5).
Auf diese Art und Weise wird das Verfahren zum Registrieren eines CN bei einem Proxy-CN, wo ein CN, der nicht das Mobil-IP verwenden kann, wie z. B. ein CN, der PPP verwendet, bereitgestellt, wobei eine individuelle Dienststeuerung ermöglicht wird.
Oder falls ein CN das Mobil-IP verwenden kann, dann kann das Mobil-IP-Verfahren verwendet und implementiert werden als Mittel zum Registrieren des CN bei dem Proxy-CN, wobei das Mittel der fundamentale Mechanismus des Mobil-IP ist, mit dem ein MN (Mobilknoten) eine Registrierung bei einem FA (Fremd Agent) durchführt. Da der Proxy-CN eine MAF (Mobil Agenten Funktion) umfasst, wird der CN bei dem Proxy-CN mit der Registrierungsprozedur des Mobil-IPs registriert. Das Dienstprofil für den CN wird verteilt von dem AAA-Server an den Proxy-CN über den HA, und das Pfad wird gespeichert in dem Dienstprofil-Cache für den entsprechenden CN, den der Proxy-CN verwaltet innerhalb des Proxy-CNs.
6 zeigt die Sequenz der fundamentalen Prozedur zum Registrieren eines CN bei einem Proxy-CN.
Die in 6 gezeigte Sequenz ist fundamental die gleiche, wie die zum Übertragen/Empfangen einer Nachricht mit dem Mobil-IP, wenn der MN eine Registrierung bei dem FA durchführt, außer dass Gebiete von dem Binde-Cache und dem Dienstprofil-Cache eines registrierten CN erzeugt werden als ein Prozess innerhalb des Proxy-CN.

(1) Der Proxy-CN dient auch als ein FA (Fremd Agent) der Mobil-IP. Demgemäß sendet der Proxy-CN eine Agentenwerbenachricht aus, dass der FA zu dem Unternetzwerk gehört, zu dem der Proxy-CN selbst gehört. Diese Aussendenachricht wird empfangen von allen Knoten innerhalb des Unternetzwerks. Der Proxy-CN macht den Knoten, der versucht zu registrieren bei dem Proxy-CN selbst, empfängt die Aussendenachricht und benachrichtigt den Knoten über die Existenz des Proxy-CN.
(2) Der CN, der sich zu dem Proxy-CN bewegt hat und gegenwärtig unter seiner Kontrolle steht, sucht nach der Agentenwerbenachricht, die übertragen wird von dem Proxy-CN. Der CN, der diese Nachricht empfängt, erzeugt eine Registrierungsanforderungsnachricht mit der Information des CN selbst, um von dem Proxy-CN zu verlangen den CN zu registrieren.
(3) Der CN überträgt die Registrierungsanforderungsnachricht, die erzeugt wird in (2). Sein Bestimmungsort ist der Proxy-CN.
(4) Der Proxy-CN authentifiziert die Legalität des CN, der die Registrierungsanforderungsnachricht überträgt. Ein Authentifizierungsverfahren hängt ab von einer Implementierung bei dieser bevorzugten Ausführungsform. Verfahrensbeispiele enthalten ein Verfahren zum Anfordern von einem AAA-Server, eine Authentifizierung auszuführen, ein Verfahren, bei dem der Heim-Agent eines CNs eine Authentifizierung ausführt, etc.. Wenn die Legalität des CN authentifiziert wird, führt der Proxy-CN den nächsten Schritt aus.
(5) Als ein den Proxy-CN spezifischer Betrieb werden Dienstprofil-Cache und eine Binde-Cache erzeugt für ein CN, der zu registrieren ist.
(6) Wenn die oben beschriebenen Schritte richtig beendet sind, überträgt der Proxy-CN eine Registrierungsbestätigungsnachricht des Mobil-IP an den CN. Der CN, der die Bestätigungsnachricht empfängt, lernt, dass die Registrierungsanforderung, die der CN selbst übertragen hat, richtig akzeptiert wird.

7 zeigt das Verfahren zum Verwalten individueller Dienststeuerdaten innerhalb eines Proxy-CN.
Hier wird ein Mittel zum Halten von Cache-Daten bezüglich einem CN, der zu verwalten ist, beschrieben. Der Proxy-CN führt eine Assoziierung zwischen der Besucherliste durch, die der Mobil-Agent-Funktion des Mobil-IP gehört und Cache-Daten. Die Besucherliste enthält die Information für individuelle CNs, die in dem Bereich des Proxy-CN sind. Ein spezifisches Assoziierungsverfahren ist wie folgt. Erweiterte Information ist hinzuzufügen an jeden Besucherlisteneintrag und ein Indexpointer, der auf die Orte eines Binde-Caches zeigt, und ein Dienstprofil-Cache werden gespeichert in dem erweiterten Teil. Handhaben von dem Binde-Cache und dem Dienstprofil-Cache, die gehalten werden durch den Proxy-CN, können zusammen ausgeführt werden mit der Verwaltung der Besucherliste durch eine MAF (Mobil Agenten Funktion), so dass Prozesse, wie z. B. Cache-Erzeugung, Entfernung, etc. erleichtert werden können.
Hier speichert der Binde-Cache die care-of-address von dem FA, auf den zugegriffen wird durch den MN, der auch einen Zugang durchführt auf den CN, der ein Teilnehmer ist und die Heimadresse des MN durch Durchführen einer Assoziierung zwischen diesen.
8 und 9 zeigen die Sequenzen, die eine bevorzugte Ausführungsform des Verfahrens zum Verwalten des Besuchszustands eines CN repräsentieren.
Ein Mobil-CN wird dynamisch registriert bei einem Proxy-CN. Zum Detektieren, dass der Mobil-CN sich zu einem unterschiedlichen Netzwerk bewegt, ist es notwendig, zyklisch zu verifizieren, dass jeder CN gegenwärtig gesteuert wird durch den Proxy-CN.
Verifizierungsmittel gemäß dieser bevorzugten Ausführungsform ist das eine, adoptiert in dem Fall, wo der CN registriert wird an dem Proxy-CN unter Verwendung des Mobil-IP.
Der CN wird registriert bei dem Proxy-CN unter Verwendung der Registrierungsprozedur des Mobil-IP als ein Registrierungsverfahren. Wenn die Mobil-IP-Registrierung durchgeführt wird, muss seine Lebenszeit bestimmt werden, und der CN muss neu registriert werden bevor die Lebenszeit abläuft. Falls der CN das Mobil-IP verwenden kann, wird die oben beschriebene zyklische Neuregistrierungsprozedur des Mobil-IP auch verwendet als Besucherzustandsverifizierung.
9 zeigt den Prozess für einen bestimmten Teilnehmer als Flussdiagramm.
In 9 startet die Lebenszeit einer Registrierung überwacht zu werden in Schritt S1. In Schritt S2 wird die oben beschriebene Tabelle durchsucht. In Schritt S3 wird detektiert, ob oder nicht ein Zeitstempel neu geschrieben wird durch die Neuregistrierung des Teilnehmers. Falls der Zeitstempel als neu geschrieben detektiert wird, geht der Prozess zurück zu Schritt S1, wo das Überwachen wieder startet. Falls der Zeitstempel nicht neu geschrieben wird, wird die Registrierung des entsprechenden Teilnehmers gelöscht in Schritt S4.
10 bis 12 zeigen das Verfahren zum Verwalten des Besuchszustands eines CN gemäß einer anderen bevorzugten Ausführungsform.
Falls ein CN nicht das Mobil-IP in der bevorzugten Ausführungsform verwenden kann, die in 8 und 9 gezeigt ist, existieren die zyklischen und Explizit-Registrierungsverfahren wie das Mobil-IP dann nicht, ein Bleibe/außerhalb des Bereichs-Zustand kann nicht explizit verifiziert werden abhängig von der Anwesenheit/Abwesenheit einer Registrierungsnachricht. In diesem Fall gibt es kein allgemeines Mittel für ein zyklisches Verifizieren des Besuchszustands. Jedoch kann es bestimmt werden, dass der CN den Bereich verlässt (bewegt sich zum unterschiedlichen Netzwerk oder ISP), falls es keine Aktivität des CN (Paketübertragung) für eine vorbestimmte Zeitperiode gibt. Die folgenden zwei Typen sind verfügbar als ein Verifizierungsmittel.
10 zeigt ein Flussdiagramm, das ein erstes Besuchszustandsverwaltungsverfahren in dem Fall zeigt, wo ein CN das Mobil-IP nicht verwenden kann.
Da Daten eine Basis sind, hält ein Proxy-CN die Daten, die den Besuchszustand von jedem CN kennzeichnen. Hier werden diese Daten bezeichnet als ein Besuchszustands-Flag.
Normal überwacht der Proxy-CN Pakete (Schritt S10). Das Besuchszustands-Flag wird gesetzt auf einen "Bleibe"-Zustand bei dem Beginn der Registrierung eines CN oder während der CN verifiziert wird, dass er Pakete überträgt (häufig).
Falls der Proxy-CN detektiert, dass die Pakete von dem CN nicht für eine vorbestimmte Zeitperiode fließen (Schritt S11), betrachtet er, dass der CN möglicherweise den Bereich verlassen hat und ändert das Besuchszustands-Flag auf einen Übergangszustand bzw. Anhängigzustand.
Der Proxy-CN startet einen Bestimmungszeitgeber zur gleichen Zeit, bei der er das Besuchszustands-Flag auf den Übergangszustand ändert (Schritt S12). Da jetzt keine Pakete des CN fließen bevor der Zeitgeber abläuft (Schritt S16), wird der Zustand des CN als "außerhalb des Bereichs" bestimmt. Das Besuchszustands-Flag zu dieser Zeit wird gesetzt auf einen "Außerhalb des Bereichs"-Zustand (Schritt S17). Sobald der "Außerhalb des Bereichs"-Zustand bestimmt wird, entfernt der Proxy-CN die Registrierung von diesen CN auf eine ähnliche Art und Weise wie in dem oben beschriebenen Fall, wo das Mobil-IP verfügbar ist und die zyklische Neuregistrierungsnachricht nicht empfangen wird (Schritt S18). Auch zu dieser Zeit wird der entsprechende Dateneintrag entfernt. Falls die Pakete des CN in Schritt S14 detektiert werden, wird der Zustand des CN geändert zu dem Bleibe-Zustand in Schritt S15. Der Prozess geht dann zurück zu Schritt S10, wo der Proxy-CN neu startet, die Pakete zu überwachen.
12 zeigt den Zustandsübergang des Besuchszustands-Flag in dem Verfahren, das in 10 gezeigt ist.
Das Besuchszustands-Flag, das anfangs auf den Bleibe-Zustand gesetzt wird, führt einen Übergang zu dem Übergangszustand aus, wenn keine Pakete, die fließen, detektiert werden. Hier wird, falls Pakete wieder zu fließen detektiert werden, das Besuchszustands-Flag wieder aufgestellt auf den Bleibe-Zustand. Jedoch wird, falls keine Pakete wieder zu fließen detektiert werden in dem Übergangszustand, der CN bestimmt wird, außerhalb des Bereichs von dem Proxy-CN zu sein. Deshalb wird das Besuchszustands-Flag geändert auf den Außerhalb-des-Bereichs-Zustand. Das Besuchszustands-Flag wird geändert auf den Außerhalb des Bereichs-Zustand. Das Besuchszustands-Flag von einem neu registrierten CN wird zuerst eingestellt auf den Bleibe-Zustand, nachdem sein Dateneintrag erzeugt wird. Danach wird der oben beschriebene Übergang wiederholt, bis der CN außerhalb des Bereichs geht.
11 zeigt ein Flussdiagramm, das ein zweites Besuchszustands-Verwaltungsverfahren in dem Fall zeigt, wo ein CN das Mobil-IP nicht verwenden kann.
Für jeden CN, den ein Proxy-CN verwaltet, wird ein "vorhergehende Besuchszustandsverfizierungszeit" (hier im Folgenden bezeichnet als ein Verifizierungszeitstempel) hinzugefügt als expandierte Daten eines Besucherlisteneintrags. Ferner wird eine einzelne zyklische Überwachungsaufgabe (hier im Folgenden bezeichnet als eine Überwachungsaufgabe) in dem gesamten Proxy gestartet.
Diese Überwachungsaufgabe referenziert die Verifizierungszeitstempel von allen der bleibenden CNs in einen vorbestimmten Zyklus. Ein Verifizierungszeitstempel ist eine Zeit, bei der das Paket, übertragen von dem CN, detektiert wird in dem vorhergehenden Zyklus.
Falls der Unterschied zwischen der gegenwärtigen Zeit und dem Verifizierungszeitstempel größer ist als der Wert innerhalb des Proxy-CN, d. h., falls keine Pakete von dem CN zu fließen detektiert werden für eine vorbestimmte Zeitperiode oder länger, wird die Registrierung des CN gelöscht. Falls der Unterschied kleiner ist als der festgelegte Wert, wird bestimmt, dass der CN bleibt, und der Proxy-CN fährt fort, den registrierten Zustand zu halten.
Das bedeutet, dass in 11 die Besuchszustandsverifizierung gestartet wird in Schritt S20, und die Überwachungsaufgabe den Prozess startet. Zuerst wird in Schritt S21 ein n-ter CN-Eintrag gesucht. In Schritt S22 wird der Vergleich durchgeführt zwischen der gegenwärtigen Zeit und der vorhergehenden Paketdetektionszeit des CN. Zu dieser Zeit wird die Detektionszeit erhalten durch Lesen des Verifizierungszeitstempels. Dann wird in Schritt S23 bestimmt, ob oder nicht der Zeitunterschied, erhalten als Ergebnis des Vergleichs, kleiner ist als ein festgelegter Wert. Falls der Zeitunterschied kleiner ist als der festgelegte bzw. festgesetzte Wert, wird versucht, das neueste Paket zu detektieren in Schritt S24. Falls das Paket detektiert wird, wird seine Zeit registriert als ein Verifizierungszeitstempel. Falls der Zeitunterschied größer ist als der festgesetzte Wert in Schritt S23, wird die Registrierung des CN gelöscht. Die Überwachungsaufgabe führt die Schritte S21 bis S25 für alle CN-Einträge aus. Wenn die Beendigung des Überwachungszyklus verifiziert wird in Schritt S26, geht der Prozess zu Schritt S20, wo der Besuchszustandsverifizierungsprozess neu gestartet wird.
Ferner kann als ein anderes Verfahren zum Verwalten des Besuchszustands eines CN, das folgende Verfahren betrachtet werden.
Manchmal kann ein CN, der nicht das Mobil-IP verwenden kann, eine Verbindung mit einem Proxy-CN trennen durch explizites Trennen einer Telefonleitung, etc.. Diese Trennung kann detektiert werden als eine Leitungstrennung einer Verbindungsschicht auf einer Proxy-CN-Seite (Netzwerkseite). Der Proxy-CN überwacht die Information über diese Verbindungsschichttrennung. Wenn der Proxy-CN die Trennung detektiert, wird bestimmt, dass der CN den Bereich verlassen hat und den Prozess ausführt eines Löschens der Registrierung des CN.
Ein spezifisches Verfahren zum Detektieren der Trennung zwischen dem Proxy-CN und dem CN als Leitungstrennung einer Verbindungsschicht kann leicht verstanden werden durch einen Fachmann. Demgemäß werden die Bestimmung, ob oder nicht der CN einen Bereich verlässt und der Registrierungslöschungsprozess, basierend auf dieser Bestimmung, betrachtet als leicht implementierbar zu sein durch den Fachmann.
13 zeigt eine erste bevorzugte Ausführungsform des Verfahrens zum Anordnen der Proxy-CN-Funktionalgruppe.
Hinsichtlich des Verfahrens zum Anordnen der Proxy-CN-Funktionalgruppe wird eine Binde-Aktualisiernachricht, übertragen von einem HA an einen CN erkannt durch einen Proxy-CN, der einen tatsächlichen Nachrichtenprozess als Proxy eines CN ausführt.
Mit diesem Anordnungsverfahren werden alle die funktionalen Elemente, wie z. B. CMF, TCF, MHF, MAF und CD unterstützt in einem benachbarten Router (Proxy-CN: gesetzt als ein Standard-Router, auf den normal von dem CN zugegriffen wird). Deshalb ist eine bestimmte externe Schnittstelle zum Verbinden der Funktionen nicht benötigt, wenn ausgestattet. Die Binde-Aktualisiernachricht, übertragen an den CN, geht durch den Proxy-CN, der auch als ein Standard-Router dient. Jedoch hat die MHF (Nachrichtenhandhabfunktion bzw. Message Handling Function) innerhalb der Proxy-CN-Funktionalgruppe eine Funktion zum Suchen nach der Header-Information von allen Paketen und überwacht eine Mobil-IP-Steuernachricht.
Eine detektierte Binde-Aktualisiernachricht wird an die CMF (Codec-Verwaltungsfunktion bzw. Cache Management Function) des Proxy-CN gegeben und reflektiert auf die CD (Cache-Daten) des CN.
Die Mobil-IP-Steuernachricht wird wie folgt detektiert. Auf das "Protokoll"-Feld eines IP-Headers wird Bezug genommen, und das Paket, das die folgenden zwei Bedingungen (1) und (2) erfüllt, wird bestimmt als eine "Mobil-IP-Steuernachricht": (1) Das "Protokoll"-Feld kennzeichnet TOP (Transmission Control Protocol bzw. Übertragungssteuerprotokoll) oder das UDP (user Datagram Protocol bzw. Benutzer-Datagramm-Protokoll); und (2) auf das "Portnummer"-Feld in dem TCP/UDP-Header wird Bezug genommen, und dieses Feld kennzeichnet eine Mobil-IP-Steuernachricht. Ein Paket, das nicht diese Bedingungen erfüllt, ist ein Datenpaket. Als Nächstes wird bestimmt, ob oder nicht das Paket, das die obigen Bedingungen erfüllt, eine Binde-Cache-Verwaltungsnachricht ist. Speziell wird auf das "Typ"-Feld des Mobil-IP-Headers Bezug genommen (beispielsweise Typ: Binde-Aktualisiernachricht). Falls das Paket bestimmt wird, die Binde-Cache-Verwaltungsnachricht zu sein, identifiziert der Proxy-CN den CN als den (ursprünglichen) Bestimmungsort dieser Nachricht von dem "Bestimmungsorts"-Feld des Impuls-Headers. Unter Verwendung der Information zum Identifizieren des CN in der obigen Bedingung als ein Schlüssel, betreibt der Proxy-CN den Binde-Cache-Eintrag (aktualisiert den Binde-Cache) des CN.
14 zeigt eine zweite bevorzugte Ausführungsform des Verfahrens zum Anordnen der Proxy-CN-Funktionalgruppe.
Falls der Prozess zum Detektieren einer Binde-Aktualisiernachricht eine hohe Last auf den Proxy-CN auferlegt als das Verfahren zum Anordnen der Proxy-CN-Funktionalgruppe, wird ein Teil der Funktion der MHF angeordnet in dem HA. Das bedeutet, dass die Funktion zum Neuschreiben des Bestimmungsorts der Binde-Aktualisiernachricht von einem Standard-CN zu einem Proxy-CN in dem HA, der die Übertragungsquelle der Binde-Aktualisiernachricht ist, angeordnet wird.
Die erste Binde-Aktualisiernachricht wird nämlich transferiert an den Proxy-CN unverändert. Der Proxy-CN beendet die erste Binde-Aktualisiernachricht, die ursprünglich an den CN adressiert ist und aktualisiert den Binde-Cache. Als Nächstes überträgt der Proxy-CN eine Binde-Bestätigungsnachricht an den HA. Mit dieser Nachricht wird der HA aufgefordert, den Bestimmungsort der Binde-Aktualisiernachricht, der übertragen wird, neu zu schreiben und zu transferieren an einen Proxy-CN, was hervorgerufen wird durch die Bewegung eines MN. Der HA überträgt die zweite und die nachfolgenden Binde-Aktualisiernachrichten an den Proxy-CN wie angefordert.
Als Ergebnis braucht der Proxy-CN nicht länger den Nachrichten-Detektionsprozess auszuführen für die zweite und nachfolgende Binde-Aktualisiernachrichten, wodurch die Last bei dem Proxy-CN verringert wird.
15 zeigt eine dritte bevorzugte Ausführungsform des Verfahrens zum Anordnen der Proxy-CN-Funktionalgruppe.
Bei diesem Verfahren zum Anordnen der Proxy-CN-Funktionalgruppe wird die MHF angeordnet in einem CN, und die anderen Funktionen zusätzlich zu der MHF werden angeordnet innerhalb eines Proxy-CN. Eine Binde-Aktualisiernachricht wird einmal übertragen an den CN auf eine ähnliche Art und Weise wie in der Technik, die offenbart ist durch die Anmeldung, die vorher von diesem Anmelder eingereicht wurde. Hier umfasst der CN die Funktion zum Detektieren der Binde-Aktualisiernachricht und Transferieren der Nachricht an den Proxy-CN, bei dem der CN registriert ist.
Als Ergebnis werden nur Binde-Aktualisiernachrichten übertragen von dem CN an den Proxy-CN. Deshalb braucht der Proxy-CN nicht länger alle Nachrichten überprüfen, die durch den Proxy-CN selbst gehen und bestimmen, ob oder nicht jeder der durchgehenden Nachrichten eine aktualisierte Binde-Nachricht ist, wodurch auch die Nachrichtenprozesslast auf den Proxy-CN selbst verringert wird.
Datenpakete, die unterschiedlich sind zu einem Mobil-IP-Nachrichtenpaket, die übertragen werden von dem CN, werden empfangen durch den Proxy-CN, der auch als Standard-Router dient, und der Proxy-CN führt alternativ die Vorgänge des CN aus. Der Proxy-CN bestimmt nämlich, ob oder nicht eine Pfadoptimierung angewandt werden kann auf den CN, der die Übertragungsquelle der Pakete ist, führt die Dienststeuerung aus entsprechend dem CN, falls der CN ein Endgerät ist, an das die Pfadoptimierung angewendet werden kann, erzeugt ein Tunnelpaket mit der TCF und überträgt das erzeugte Paket.
Die Prozeduren zum Registrieren eines CN bei einem Proxy-CN werden unten zusammengefasst.
- Registrierung des CN, der die Mobil-IP verwenden kann.

(1) Der Proxy-CN sendet die oben beschriebene Agenten-Werbung des Mobil-IP an das gesamte Netzwerk, zu dem der Proxy-CN gehört.
(2) Der CN, ausgestattet mit der Mobil-IP-Funktion, empfängt die oben beschriebene Werbung des Proxy-CN und überträgt eine Mobil-IP-Registrierungsanforderungsnachricht an den Proxy-CN.
(3) Der Proxy-CN verifiziert die Legalität des CN gemäß der Authentifizierung, die durchgeführt wird durch einen AAA-Server.
(4) Bei Beendigung der Authentifizierung erzeugt der Proxy-CN einen Eintrag der Cache-Daten (ein Binde-Cache und ein Dienstprofil) für den CN.
(5) Wenn der Registrierungsprozess innerhalb des Proxy-CN normal endet, wird eine Registrierungsbestätigung zurückgegeben an den CN unter Verwendung einer Mobil-IP-Registrierungsantwortnachricht.

- Registrierung des CN, der nicht das Mobil-IP verwendet

(1) Der CN, der nicht das Mobil-IP verwendet, versucht eine Verbindung vorzunehmen mit einem ISP mit dem dial-up PPP.
(2) Der dial-up-Server, der die Verbindungsanforderung empfängt von dem CN, fordert den Authentifizierungsserver, der zu dem dial-up-Server gehört, auf, die Legalität des CN zu authentifizieren. Für das Authentifizierungsverfahren, das eine PPP-Verbindung verwendet, wird ein PAP (Passwort-Authentifizierungsprotokoll) oder CHAP (Challenge-Handshake-Authentifizierungsprotokoll) verwendet.
(3) Der Authentifizierungs-Server, der die Authentifizierungsanforderung empfängt, liest das Dienstprofil des CN von der Dienstprofil DB (Datenbank), die das Dienstprofil des CN speichert, wenn die Legalität des CN verifiziert wird.
(4) Der Authentifizierungs-Server überträgt das Dienstprofil des CN, das erhalten wird in dem oben beschriebenen Schritt (3), an den Proxy-CN, bei dem von dem CN gefordert wird, sich zu registrieren.
(5) Der Proxy-CN erzeugt einen Besucherlisteneintrag für den CN, basierend auf dem Pfad, übertragen in dem Schritt (4), und erzeugt auch einen Eintrag zum Speichern dieses Eintrags, den Binde-Cache sich beziehend auf Pfadoptimierung und das Dienstprofil, das benachrichtigt wird von dem Authentifizierungs-Server.
(6) Der Authentifizierungs-Server gibt die Registrierungsbestätigung an den CN zurück, der die Registrierungsanforderung ausgibt.

Die Prozeduren zum Verifizieren des Besuchszustands eines CN werden unten zusammengefasst.
- Verifizierung des Besuchszustands des CN, der das Mobil-IP verwenden kann.

(1) Ein Mobil-CN muss wiederholt eine Neuregistrierung in einem Zyklus durchführen, der kürzer ist als die Registrierungs-Lebenszeit, auf die sich der Proxy-CN und der Mobil-CN selbst einigen als die Funktion des Mobil-IP und überträgt die Mobil-IP-Registrierungsanforderungsnachricht an den Proxy-CN, bei dem der Mobil-CN gegenwärtig registriert wird.
(2) Der Proxy-CN bestimmt, dass dieser Mobil-CN in seinem Bereich bleibt beim Empfangen der oben beschriebenen Neuregistrierungsanforderung.
(3) Falls der Proxy-CN nicht die Neuregistrierungsanforderung empfängt bevor die Registrierungs-Lebenszeit abläuft, wird die Registrierung des CN gelöscht mit der Mobil-IP-Prozedur. Speziell wird der Besucherlisteneintrag für diesen CN gelöscht innerhalb des Bereichs der Mobil-IP-Funktion. Zur gleichen Zeit werden der Binde-Cache und das Dienstprofil, die zugehörig sind zu diesem Besucherlisteneintrag, gelöscht. Die Daten bezüglich der Proxy-CN-Funktion werden nämlich simultan gelöscht mit der Registrierungslöschungsprozedur des Mobil-IP.

- Verifizierung des Besuchszustands des CN, der nicht das Mobil-IP verwenden kann
Verfahren 1

(1) Der Proxy-CN überwacht den Fluss der Pakete, die übertragen werden von dem CN. Der Proxy-CN verwendet Teile eines Besucherlisteneintrags und registriert den Besuchszustand für jeden CN. Wenn der CN Pakete überträgt während der Registrierung, wird sein Zustand als Bleibe-Zustand erkannt.
(2) Falls keine Pakete, übertragen von dem CN, detektiert werden, bei einer vorbestimmten Zeitperiode zu fließen, während des oben beschriebenen Überwachungsbetriebs, betrachtet der Proxy-CN, dass der CN möglicherweise den Bereich verlassen hat und setzt den Besuchszustand des CN auf einen Anhängigzustand bzw. Übergangszustand.
(3) Falls keine Pakete von dem CN zu übertragen detektiert werden für eine andere vorbestimmte Zeitperiode in dem oben beschriebenen Übergangszustand, bestimmt der Proxy-CN, dass der CN außerhalb des Bereichs ging.
(4) Falls die Pakete von dem CN detektiert werden, während der Paketüberwachungszeitperiode in dem oben beschriebenen Schritt (3), wird der Besuchszustand wiederhergestellt auf den Bleibe-Zustand.

Verfahren 2

(1) Die Zyklusüberwachungsaufgabe, die innerhalb des Proxy-CN läuft, sucht nach der vorhergehenden Paketübertragungsverifizierungszeit (Verifizierungszeitstempel) für alle CNs, die von ihm verwaltet werden.
(2) Die Zyklusüberwachungsaufgabe erhält für jeden CN den Unterschied zwischen dem Verifizierungszeitstempel und der gegenwärtigen Zeit. Falls dieser Zeitunterschied größer ist als der Wert, der festgelegt wird innerhalb des Proxy-CN, wird bestimmt, dass der CN keine übertragenen Pakete für eine vorbestimmte Zeitperiode oder länger hat und seine Registrierung wird gelöscht.
(3) Falls der Zeitunterschied kleiner ist als der festgelegte Wert, wird bestimmt, dass der CN in dem Bereich bleibt, und seine Pakete werden zu detektieren versucht. Falls die Pakete detektiert werden als Ergebnis davon, wird der Verifizierungszeitstempel aktualisiert auf die neueste Paketdetektionszeit. Falls die Pakete nicht detektiert werden, wird der Verifizierungszeitstempel nicht aktualisiert.
(4) Diese Schritte (1) bis (4) werden wiederholt in dem Zyklus, festgelegt durch das Proxy-CN-System, so dass die Zyklus-Besuchszustandsverifizierung implementiert werden kann.

- Leitungstrennung einer Verbindungsschicht, falls das Mobil-IP nicht verfügbar ist

(1) Von einem CN wird angenommen, dass er verbunden ist mit einem Zugangsserver mit PPP.
(2) Bei Beendigung der Kommunikation durch den CN, wird die Leitungstrennungsnachricht der Verbindungsschicht übertragen an einen Zugangsserver.
(3) Der Zugangsserver, der die Leitungstrennungsnachricht detektiert, benachrichtigt die MHF der Proxy-CN-Funktionalgruppe über die Leitungstrennung durch den CN.
(4) Die MHF der Proxy-CN-Funktionalgruppe überträgt die Nachricht, die kennzeichnet, dass der CN den Bereich zu der MAF verlassen hat.
(5) Die MAF löscht den Besucherlisteneintrag für den CN, und zur selben Zeit fordert sie die CMF auf, den Binde-Cache und das Dienstprofil für diesen CN zu löschen. Hier wird die Registrierungslöschung des CN beendet.

16 und 17 zeigen Flussdiagramme, die den IP-Dienststeuernachrichtprozess in der bevorzugten Ausführungsform erklären, die in 13 gezeigt ist. 16 zeigt den Fall, wo ein Cache-Bereich erzeugt wird bei Beendigung der Registrierung eines CN an ein Proxy-CN, wobei 17 den Fall zeigt, wo ein Cache-Bereich erzeugt wird, wenn die erste Binde-Aktualisiernachricht des CN den Proxy-CN erreicht.
In 16 wird, falls es einen Cache des Endgeräts (CN) als Dienstprofil zu planen gibt, das hinzugefügt wird an eine Binde-Aktualisiernachricht, der Cache nur aktualisiert. Jedoch falls kein Cache-Bereich existiert aufgrund irgendeines Grunds oder anderen Dingen (einem Mangel an Ressourcen, etc.), wird eine abnormale Sequenz adoptiert. In diesem Fall kann der Proxy-CN den HA benachrichtigen, der die Übertragungsquelle ist, dass der empfangene Cache nicht richtig verarbeitet war. Eine "Binde-Bestätigungs"-Nachricht, die definiert wird durch das Mobil-IP-Erweiterungsprotokoll (Pfadoptimierung), wird verwendet als diese Benachrichtigung.
Deshalb erzeugt, falls ein Cache nicht erzeugt werden kann, der Proxy-CN die Binde-Bestätigungsnachricht, speichert den Wert, der kennzeichnet, dass der Cache nicht richtig verarbeitet wurde durch den Proxy-CN selbst, der der Empfangsbestimmungsort ist und überträgt die Nachricht an den HA.
In 16 überträgt der HA zuerst die Binde-Aktualisiernachricht (einschließlich einem Profil-Cache) an den CN, der zu Pfad-optimieren ist. Die Binde-Aktualisiernachricht erreicht den Proxy-CN, der auch als ein Standard-Router für den Bestimmungsort CN dient. Der Proxy-CN wartet auf ein Paket in Schritt S30 und detektiert den Empfang des Pakets in Schritt S31, sucht nach jedem Header von allen empfangenen Paketen (unabhängig von ihren Daten und Mobil-IP-Steuernachricht) und bestimmt, ob oder ob nicht jedes Paket eine Binde-Aktualisiernachricht ist, die adressiert ist an den CN (Schritt S32). Ein Verfahren zum Bestimmen ob oder ob nicht ein Paket eine Binde-Aktualisiernachricht ist, ist wie folgt. Das Paket, das die folgenden zwei Bedingungen erfüllt, wird nämlich bestimmt, eine Mobil-IP-Steuernachricht zu sein durch Bezug nehmen auf das "Protokollfeld" eines IP-Headers: (1) das "Protokoll"-Feld kennzeichnet entweder TCP oder UDP; und (2) das "Portnummer"-Feld innerhalb des TCP/UDP-Headers kennzeichnet eine Mobil-IP-Steuernachricht^. Falls ein empfangenes Paket ein Datenpaket ist, wird ein unterschiedlicher Paketprozess ausgeführt in Schritt S33, und eine Steuerung wird dann zurückgegeben zu Schritt S30.
Falls das Paket bestimmt wird, eine Binde-Aktualisiernachricht in Schritt S32 zu sein, wird es ferner bestimmt, ob oder nicht das Binde-Aktualisiernachrichtpaket eine Binde-Cache-Verwaltungsnachricht ist für eine Pfadoptimierung durch Überprüfen des entsprechenden Paketfelds. Speziell wird auf das "Typ"-Feld in dem Mobil-IP-Header Bezug genommen (beispielsweise "Typ" ist eine Binde-Aktualisiernachricht). Falls das Paket bestimmt wird, eine Binde-Cache-Verwaltungsnachricht zu sein, identifiziert der Proxy-CN den CN, der der (ursprüngliche) Bestimmungsort dieser Nachricht ist von dem "Bestimmungsort"-Feld in dem IP-Header. Für das Paket, das bestimmt wird, die Binde-Aktualisiernachricht zu sein, wird bestimmt, ob oder ob nicht der Cache entsprechend dem Bestimmungsort CN in Schritt S34 existiert. Falls der entsprechende Cache existiert, wird es gespeichert in dem Binde-Cache und dem Dienstprofil-Cache, die von dem Proxy-Cache gehalten werden, und es wird auch betrieben durch die Proxy-CN-Funktionalgruppe. Der Proxy-CN führt dann die Betriebe und Funktionen aus, die angefordert werden von dem CN, der der ursprüngliche Bestimmungsort ist. Falls kein entsprechender Cache existiert in Schritt S34, wird eine Binde-Bestätigungsnachricht, kennzeichnend "nicht ein Dienststeuerziel" erzeugt in Schritt S36. Die erzeugte Nachricht wird dann übertragen in Schritt S37, und eine Steuerung wird zurückgegeben an Schritt S30.
17 zeigt ein Flussdiagramm, das den Paketprozess zeigt, der ausgeführt wird in dem Fall, wo ein Cachebereich erzeugt wird in dem Proxy-CN, wenn die erste Binde-Aktualisiernachricht von einem CN den Proxy-CN erreicht.
In diesem Fluss ist der Prozess, der ausgeführt wird, wenn kein entsprechender Cache existiert, unterschiedlich. Bei Empfang der ersten Binde-Aktualisiernachricht (plus dem Dienstprofil-Cache) für den CN wird nämlich ein Cache-Bereich neu erzeugt, und die Daten dem Dienstprofil-Cache werden in diesen Bereich gespeichert.
Zuerst wartet in Schritt S40 der Proxy-CN auf ein Paket. Dann detektiert der Proxy-CN den Empfang des Pakets in Schritt S41 und bestimmt, ob oder ob nicht das empfangene Paket eine Binde-Aktualisiernachricht ist in Schritt S42. Falls das Paket bestimmt wird, keine Binde-Aktualisiernachricht zu sein, führt der Proxy-CN den unterschiedlichen Prozess in Schritt S43 aus. Falls das Paket bestimmt wird, die Binde-Aktualisiernachricht zu sein, geht der Prozess zu Schritt S44.
Der Proxy-CN bestimmt, ob oder ob nicht der Binde-Cache (oder nur Cache) entsprechend dem CN, der der Nachrichtenbestimmungsort ist, in Schritt S44 existiert. Falls der entsprechende Binde-Cache existiert, aktualisiert der Proxy-CN den Cache. Falls der entsprechende Cache nicht existiert, erzeugt der Proxy-CN einen Cache. Der Prozess geht dann zu Schritt S40.
18 bis 21 sind Flussdiagramme, die den IP-Dienststeuernachrichtenprozess in der bevorzugten Ausführungsform zeigen, die in 14 gezeigt ist. 18 zeigt den Fall, wo ein Cache-Bereich erzeugt wird bei Beendigung der Registrierung eines CN an einem Proxy-CN, wobei 19 den Fall zeigt, wo ein Cache-Bereich erzeugt wird, wenn die erste Binde-Aktualisiernachricht des CN den Proxy-CN erreicht. 20 fasst den Paketprozess zusammen, der ausgeführt wird durch jedes Funktionalelement, und zeigt den Empfangsbestimmungsprozess durch den HA. 21 fasst den Paketprozess zusammen, der ausgeführt wird durch jedes funktionale Element bzw. Funktionalelement und zeigt die Übertragungsprozessbestimmung, die durchgeführt wird durch den HA.
Zuerst überträgt der HA die erste Binde-Aktualisiernachricht an den HA als Bestimmungsort. Der Proxy-CN wartet auf ein Paket in Schritt S50 und detektiert den Empfang eines Pakets in Schritt S51. Der Proxy-CN bestimmt dann, ob oder ob nicht das empfangene Paket eine Binde-Aktualisiernachricht im Schritt S52 ist. Falls das Paket eine Binde-Aktualisiernachricht ist, führt der Proxy-CN einen unterschiedlichen Paketprozess in Schritt S52 aus, und die Steuerung wird zurückgegeben an Schritt S50. Falls das empfangene Paket als die Binde-Aktualisiernachricht bestimmt wird in Schritt S52, überprüft der Proxy-CN, der der Standard-Router CN ist, den Bestimmungsort der Binde-Aktualisiernachricht. Falls der Bestimmungsort der Proxy-CN ist, bestimmt der Proxy-CN, ob oder ob nicht ein Ziel-Cache existiert in Schritt S58. Falls der Ziel-Cache existiert, aktualisiert der Proxy-CN den Cache in Schritt S59. Falls der Ziel-Cache nicht existiert, erzeugt der Proxy-CN eine Binde-Bestätigungsnachricht in Schritt S60 und überträgt diese Nachricht in Schritt S61. Dann wird eine Steuerung zurückgegeben an Schritt S50.
Falls der Bestimmungsort der Binde-Aktualisiernachricht der CN in Schritt S54 ist, erzeugt und hält der Proxy-CN den Binde-Cache und den Dienstprofil-Cache (Schritt S55), der enthalten ist in der Nachricht, ohne Übertragen dieser Binde-Aktualisiernachricht an den CN, der der ursprüngliche Bestimmungsort ist. Dann gibt die MHF innerhalb des Proxy-CN die Binde-Aktualisierbestätigungsnachricht an den HA, der die Übertragungsquelle der Binde-Aktualisiernachricht als spezifische Nachricht ist (Schritte S56 und S57). Diese Nachricht gibt an, dass der Proxy-CN Binde- Aktualisiernachrichten verarbeitet, die übertragen werden danach als Proxy des CN.
Falls der Standard-Router nicht die Proxy-CN-Funktionen umfasst, wird die Binde-Aktualisiernachricht übertragen an den CN, und der CN selbst verarbeitet die Binde-Aktualisiernachricht.
Der HA, der die Binde-Aktualisierbestätigungsnachricht empfängt, ordnet den Proxy-CN, der die Übertragungsquelle ist, der Information des CN zu, der der ursprüngliche Bestimmungsort ist und wird gesteuert von dem Proxy-CN, ändert für den Proxy-CN den Bestimmungsort der zweiten und der nachfolgenden Binde-Aktualisiernachricht, übertragen an den CN und überträgt die Nachrichten. Demgemäß empfängt und verarbeitet der Proxy-CN die zweite und nachfolgende Binde-Aktualisiernachricht, die sich auf den CN bezieht.
19 zeigt den Prozess, der ausgeführt wird durch ein Proxy-CN in dem Fall, wo ein Cache-Bereich erzeugt wird, wenn die erste Binde-Aktualisiernachricht eines CN den Proxy-CN erreicht.
Zuerst wartet in Schritt S70 der Proxy-CN auf ein Paket. In Schritt S71 detektiert der Proxy-CN den Empfang des Pakets. Der Proxy-CN bestimmt dann, ob oder ob nicht das empfangene Paket eine Binde-Aktualisiernachricht ist in Schritt S72. Falls das empfangene Paket keine Binde-Aktualisiernachricht ist, führt der Proxy-CN einen unterschiedlichen Paketprozess in Schritt S73 aus. Steuerung wird dann zurückgegeben an den Schritt S70.
Falls das empfangene Paket bestimmt wird, die Binde-Aktualisiernachricht in Schritt S72 zu sein, überprüft der Proxy-CN den Bestimmungsort dieser Nachricht. Falls der Bestimmungsort der Proxy-CN ist, bestimmt der Proxy-CN weiter, ob oder ob nicht ein Cache, der zu aktualisieren ist, existiert in Schritt S78. Falls der zu aktualisierende Cache existiert, aktualisiert der Proxy-CN den Cache in Schritt S79.
Falls der entsprechende Cache nicht existiert, erzeugt der Proxy-CN ein Cache.
Falls der Bestimmungsort der Binde-Aktualisiernachricht der CN ist in Schritt S74, erzeugt der Proxy-CN einen Cache-Bereich, ferner erzeugt er eine Binde-Aktualisierbestätigungsnachricht und überträgt die erzeugte Nachricht an den HA (Schritte S76 und S77).
20 fasst den Paketprozess zusammen, der ausgeführt wird durch jedes Funktionalelement in der bevorzugten Ausführungsform, die in 14 gezeigt ist und ist ein Flussdiagramm, das die Empfangsprozessbestimmung zeigt, die durch ein HA gemacht wird.
Der HA wartet auf ein Paket in Schritt S85. Wenn das Paket übertragen wird, detektiert der HA den Empfang des Pakets in Schritt S86. In Schritt S87 bestimmt der HA, ob oder ob nicht das empfangene Paket eine Binde-Aktualisierbestätigungsnachricht ist. Falls das empfangene Paket keine Binde-Aktualisierbestätigungsnachricht ist, wird eine Steuerung zurückgegeben an Schritt S85, wo der HA auf das nächste Paket warten wird. Falls das empfangene Paket bestimmt wird, die Binde-Aktualisierbestätigungsnachricht in Schritt S87 zu sein, ändert der HA den Bestimmungsort der Binde-Aktualisiernachricht innerhalb des Informationselements für den entsprechenden CN. Die Steuerung wird dann zurückgegeben an Schritt S85, wo der HA auf das nachfolgende Paket warten wird.
21 fasst den Paketprozess zusammen, der ausgeführt wird durch jedes funktionale Element in der bevorzugten Ausführungsform, die in 14 gezeigt ist und ist ein Flussdiagramm, das die Übertragungsprozessbestimmung durch den HA zeigt.
Zuerst stellt der HA in Schritt S90 die Vorbereitung für eine Paketübertragung fertig. Der HA analysiert den Pakettyp in Schritt S91 und bestimmt, ob oder ob nicht ein empfangenes Paket eine Binde-Aktualisiernachricht ist in Schritt S92. Falls das empfangene Paket nicht die Binde-Aktualisiernachricht ist, führt der HA den Paketübertragungsprozess in Schritt S96 aus (der Prozess zum Übertragen eines Pakets an seinen Bestimmungsort). Die Steuerung wird dann zurückgegeben an Schritt S90. Falls das empfangene Paket bestimmt wird, die Binde-Aktualisiernachricht in Schritt S92 zu sein, überprüft der HA, ob oder ob nicht der Bestimmungsort des Übertragungspakets verändert wird gemäß der Binde-Aktualisierbestätigung (Schritt S93) und bestimmt, ob oder ob nicht der Bestimmungsort der Binde-Aktualisiernachricht verändert werden muss in Schritt S94. Falls der HA bestimmt, dass es keinen Bedarf zum Ändern des Bestimmungsorts in Schritt S94 gibt, überträgt der HA das Paket an den Bestimmungsort des empfangenen Pakets in Schritt S96. Falls der HA bestimmt, dass der Bestimmungsort verändert werden muss in Schritt S94, ändert er den Bestimmungsort des Pakets in Schritt S95 und überträgt das Paket an den geänderten Bestimmungsort (Proxy-CN) in Schritt S96. Bei Beendigung des Paketübertragungsprozesses wird die Steuerung zurückgegeben an Schritt S90 und dieser Prozess wird wiederholt.
22 bis 24 zeigen Flussdiagramme, die den IP-Dienststeuernachrichtenprozess in der bevorzugten Ausführungsform zeigen, die in 15 gezeigt ist. 22 zeigt den Fall, wo ein Cache-Bereich erzeugt wird bei Beendigung der Registrierung eines CN bei einem Proxy-CN, wobei 23 den Fall zeigt, wo ein Cache-Bereich erzeugt wird, wenn die erste Binde-Aktualisiernachricht des CN den Proxy-CN erreicht. 24 zeigt ein Flussdiagramm, das den Bestimmungsprozess zeigt, der ausgeführt wird durch den CN unter den zusammengefassten Paketprozessen der entsprechenden funktionalen Elemente.
In 22 überträgt der HA zuerst eine Binde-Aktualisiernachricht an den CN als ein Bestimmungsort. Der Proxy-CN, der der Standard-Router des CN ist, empfängt diese Nachricht (Schritt S101), während er in einem Paketwartezustand ist (Schritt S100). Der HA bestimmt dann, ob oder ob nicht die empfangene Nachricht eine Binde-Aktualisiernachricht ist, und ob oder ob nicht diese Nachricht an den CN zu transferieren ist (Schritt S102). Falls diese Nachricht bestimmt wird, eine zu transferierende Nachricht zu sein, transferiert der Proxy-CN die Nachricht an den CN ähnlich zu einem normalen Router. Die Steuerung wird dann zurückgegeben an Schritt S100.
Falls der Proxy-CN bestimmt, dass die Nachricht die Binde-Aktualisiertransfernachricht ist, das ist die Nachricht, adressiert an den Proxy-CN selbst, in Schritt S102, wird es weiterhin bestimmt, ob oder ob nicht der Cache entsprechend im CN existiert in Schritt S103. Falls der entsprechende Cache existiert, wird der Cache-Eintrag aktualisiert in Schritt S104. Die Steuerung wird dann zurückgegeben an Schritt S100. Falls der entsprechende Cache bestimmt wird, nicht in Schritt S103 zu existieren, wird eine Binde-Bestätigungsnachricht erzeugt in Schritt S105. In Schritt S106 detektiert der CN, dass das Paket, das übertragen und empfangen wird von dem Proxy-CN, die Binde-Aktualisiernachricht ist. Der CN, der die Binde-Aktualisiernachrichtenstruktur einer Binde-Aktualisiertransfernachricht als spezifische Nachricht detektiert und überträgt die strukturierte Nachricht an den Proxy-CN, bei dem der CN selbst registriert ist. Diese Nachricht enthält die Information, dass der Proxy-CN erkennen kann, dass es sich um eine Binde-Aktualisiernachricht handelt, als Header-Information und Binde-Cache-Daten und Dienstprofildaten, die enthalten sind in der Binde-Aktualisiernachricht, als Nutzlastinformation. Der Proxy-CN, der die Binde-Aktualisiertransfernachricht empfängt, die übertragen wird von dem CN unter seiner Kontrolle bzw. Steuerung, verifiziert, dass diese Nachricht eine Binde-Aktualisiertransfernachricht ist, basierend auf der Header-Information. Der Proxy-CN registriert die Daten für diesen CN, die enthalten sind in der verifizierten Nachricht.
23 zeigt ein Flussdiagramm, das den Prozess zeigt, der ausgeführt wird durch ein Proxy-CN in dem Fall, wo ein Cache- Bereich erzeugt wird, wenn die erste Binde-Aktualisiernachricht den Proxy-CN erreicht.
Zuerst wartet in Schritt S110 der Proxy-CN auf ein Paket. Wenn der Proxy-CN den Empfang des Pakets in Schritt S111 detektiert, bestimmt er, ob oder ob nicht das empfangene Paket eine Binde-Aktualisiernachricht ist und ob oder ob nicht die Nachricht an den CN zu transferieren ist in Schritt S112. Falls die Nachricht bestimmt wird, dass sie nicht an den CN zu transferieren ist, wird die Steuerung zurückgegeben zu Schritt S110. Dann wird dieser Prozess wiederholt.
Falls das empfangene Paket bestimmt wird, eine Binde-Aktualisiertransfernachricht zu sein in Schritt S112, bestimmt der Proxy-CN ferner, ob oder ob nicht diese Nachricht die erste Binde-Aktualisiertransfernachricht ist an den CN in Schritt S113. Falls die Nachricht die erste Binde-Aktualisiertransfernachricht ist, erzeugt der Proxy-CN einen Lache-Eintrag in Schritt S115. Die Steuerung wird dann zurückgegeben an Schritt S110. Falls die Nachricht nicht die erste Binde-Aktualisiertransferna^chricht ist in Schritt S113, aktualisiert der Proxy-CN den entsprechenden Lache-Eintrag in Schritt S114. Dann wird die Steuerung zurückgegeben an Schritt S110.
24 zeigt ein Flussdiagramm, das den Bestimmungsprozess zeigt, der ausgeführt wird durch den CN.
Zuerst wartet in Schritt S120 der CN auf ein Paket in Schritt S120. Beim Empfangen des Pakets in Schritt S121 bestimmt der CN, ob oder ob nicht das empfangene Paket eine Binde-Aktualisiernachricht ist in Schritt S122. Falls das Paket nicht die Binde-Aktualisiernachricht ist, wird eine Steuerung zurückgegeben an Schritt S120, wo der CN wieder auf ein Paket wartet. Falls das empfangene Paket bestimmt wird, die Binde-Aktualisiernachricht zu sein in Schritt S122, erzeugt der CN eine Binde-Aktualisiertransfernac^hricht in Schritt S123 und überträgt die erzeugte Nachricht an den Proxy-CN in Schritt S124. Die Steuerung wird dann zurückgegeben an Schritt S120.
Der Prozess für ein Datenpaket, das nicht eine Binde-Aktualisiernachricht ist, wird unten erklärt.

(1) Ein CN unter der Steuerung bzw. Kontrolle von einem Proxy-CN überträgt das Datenpaket an einen bestimmten MN.
(2) Das oben beschriebene Datenpaket erreicht den Proxy-CN, der auch als Standard-Router dient.
(3) Der Proxy-CN identifiziert die Übertragungsquelle von diesem Datenpaket und sucht in einer Besucherliste nach dem entsprechenden Eintrag.
(4) Ob oder ob nicht der CN ein Pfadoptimierungsziel ist, wird durchgeführt gemäß dem Besucherlisteneintrag von dem CN, der die Übertragungsquelle ist.
(5) Falls das Paket, übertragen von dem CN, bestimmt wird, ein Pfadoptimierungsziel zu sein, gibt der Proxy-CN eine Steuerung an die TCF (Tunnelfähigkeitsfunktion bzw. Tunneling Capability Function) und fordert die TCF auf, ein Tunnelpaket zu erzeugen.
(6) Die TCP erzeugt ein Tunnelpaket, gibt die Daten und Steuerung des Pakets an eine Router-Funktionseinheit innerhalb des Proxy-CN und fordert die Einheit auf, dieses Paket zu übertragen.
(7) Die Router-Funktionseinheit innerhalb des Proxy-CN überträgt das erzeugte Tunnelpaket.

Wie oben beschrieben, wurde die vorliegende Erfindung erklärt, basierend auf der bestimmten bevorzugten Ausführungsform. Jedoch ist die vorliegende Erfindung nicht begrenzt auf die obige beschriebene bevorzugte Ausführungsform und deckt verschiedene Modifizierungen ab, die durchgeführt werden von einem Fachmann.
Speziell ist die Anordnung der oben beschriebenen Funktionen, wie z. B. CMF, TCF, MHF, CD und MAF nicht begrenzt auf die oben beschriebenen bevorzugte Ausführungsform. Die Funktionen können ausreichen, angeordnet zu werden an irgendwelchen Orten auf einer Netzwerkseite, mit der ein CN verbunden ist.
Gemäß der vorliegenden Erfindung ist die Funktionalgruppe, die gezwungen wird, in einem Korrespondenzendgerät (CN) angeordnet zu sein, herkömmlich konzentriert auf einer Netzwerkseite, wodurch äquivalente Funktionen bereitgestellt werden können ohne Hinzufügen von Funktionen an den CN (oder durch Durchführen einer Minimal-Hinzufügung).
Demgemäß kann selbst ein tragbares Endgerät mit einem geringen Durchsatz eine individuelle Dienststeuerung verwenden ohne Bedenken über eine Funktionalhinzufügung und eine Erhöhung in einer Verarbeitungslast.
Ferner wird gemäß der vorliegenden Erfindung die Funktion zum Akzeptieren der Registrierung eines CN mit einer Verbindungsschicht, die kein bestimmtes Protokoll verwenden kann, vorbereitet als ein Verfahren zum Registrieren eines CN bei einem benachbarten Router (Proxy-CN), ausgestattet mit der Funktionalgruppe, konzentriert auf einer Netzwerkseite zusätzlich zu einem Verfahren, das den Registrierungsmechanismus des bestimmten Protokolls verwendet, wodurch die Unabhängigkeit von der Verbindungsschicht bzw. Übertragungsschicht sichergestellt wird.
Demgemäß kann eine Registrierung bei einem Proxy-CN und Verwendung von einer individuellen Dienststeuerung implementiert werden selbst mit verschiedenen Verbindungsschichten.

Claims

Ein Mobilkommunikationssystem zusammengesetzt aus einer Vielzahl von Unternetzwerken und zum Ermöglichen eines Korrespondenzendgerät (25) zum Kommunizieren mit einem Mobilendgerät (12), wobei das Mobilendgerät (12) eine Einrichtung aufweist zum Bewegen von einem Unternetzwerk (1) zu einem anderen Unternetzwerk (2) und eine Authentifizierungseinheit (23) enthält zum Authentifizieren des Korrespondenzendgeräts (25); gekennzeichnet durch: eine Einstelleinheit zum Einstellen einer Binde-Cache-Information bzw. Bindezwischenspeicherinformation, die das Korrespondenzendgerät (25) benötigt zum Kommunizieren mit dem Mobilendgerät (12) und Aktualisieren der Binde-Cache-Information, wenn das Mobilendgerät (12) sich von einem ersten Unternetzwerk (1) zu einem zweiten Unternetzwerk (2) bewegt, wobei die Einstelleinheit eine Cache-Managementfunktion bereitstellt für einen Binde-Cache und eine Einrichtung aufweist zum Detektieren eines Binde-Caches zum Erzeugen eines Eintrags, falls ein Eintrag für den Binde-Cache nicht existiert, und zum Aktualisieren eines Eintrags mit empfangener Information, falls der Binde-Cache schon existiert; und eine Kommunikationseinheit zum Kommunizieren zwischen Netzwerksteuergeräten, um die Binde-Cache-Information einzustellen, wobei die Kommunikationseinheit eine Einrichtung zum Detektieren einer Binde-Cache-Nachricht aufweist, zum Bestimmen, ob ein Cache entsprechend einem Zielkorrespondenzendgerät existiert, und falls er existiert, zum Aktualisieren des Binde-Caches, und falls er nicht existiert, zum Erzeugen und Übertragen einer Bindebestätigungsnachricht, wobei die Authentifizierungseinheit, die Einstelleinheit und die Kommunikationseinheit installiert werden in einem Proxy-Korrespondenzendgerät (24) in einem Netzwerk umfassend die Vielzahl der Unternetzwerke; und wobei die Authentifizierungseinheit (23) einen Verbindungsschichtauthentifizierungs-Server zum Authentifizieren des Korrespondenzendgeräts umfasst, wenn das Korrespondenzendgerät nicht einen Mobil-IP verwenden kann, und wobei das Proxy-Korrespondenzendgerät eine Einrichtung enthält zum Authentifizieren des Korrespondenzendgeräts, wenn das Korrespondenzendgerät die Mobil-IP verwenden kann.
Das Mobilkommunikationssystem nach Anspruch 1, ferner dadurch gekennzeichnet, dass eine Mobil-IP adoptiert wird als Kommunikationsprotokoll.
Das Mobilkommunikationssystem nach Anspruch 2, ferner dadurch gekennzeichnet, dass das Korrespondenzendgerät (25) nicht das Mobil-IP unterstützt.
Das Mobilkommunikationssystem nach Anspruch 2, ferner gekennzeichnet durch: eine Tunneleinheit zum Editieren eines Datenpakets, empfangen von dem Korrespondenzendgerät (25) und bestimmt für das Mobilendgerät (12), und zum Übertragen des editierten Datenpakets direkt an das erste Unternetzwerk (1), wenn das Korrespondenzendgerät (25) in dem ersten Unternetzwerk (1) existiert, und das Mobilendgerät (12) in dem zweiten Unternetzwerk (2) existiert.
Das Mobilkommunikationssystem nach Anspruch 1, ferner dadurch gekennzeichnet, dass das Korrespondenzendgerät (25) ein Endgerät ist, das von einem Unternetzwerk (1) an ein anderes Unternetzwerk (2) sich bewegen kann.
Das Mobilkommunikationssystem nach Anspruch 1, ferner gekennzeichnet durch: einen Router (24), gekoppelt mit dem Korrespondenzendgerät (25), wobei die Einstelleinheit und die Kommunikationseinheit angeordnet sind in dem Router (24).
Das Mobilkommunikationssystem nach Anspruch 2, gekennzeichnet durch: eine Besuchszustandsverifiziereinrichtung zum Bestimmen, ob oder ob nicht das Korrespondenzendgerät (25) in einem vorbestimmten Bereich existiert.
Das Mobilkommunikationssystem nach Anspruch 7, ferner gekennzeichnet durch: eine Einrichtung, betriebsfähig, falls das Korrespondenzendgerät (25) nicht existiert in dem vorbestimmten Bereich, zum Löschen der Binde-Cache-Information für das Korrespondenzendgerät (25).
Das Mobilkommunikationssystem nach Anspruch 2, ferner gekennzeichnet durch: eine Einrichtung, betriebsfähig, falls das Korrespondenzendgerät (25) ein Mobil-IP-Korrespondenzendgerät (25) ist, zum Bestimmen, dass das Korrespondenzendgerät (25) einen vorbestimmten Bereich verlassen hat, wenn das Korrespondenzendgerät (25) nicht eine Registrierung in dem vorbestimmten Bereich ausführt.
Das Mobilkommunikationssystem nach Anspruch 7, ferner dadurch gekennzeichnet, dass die Besuchszustandsverifiziereinrichtung bestimmt, dass das Korrespondenzendgerät (25) nicht länger in dem vorbestimmten Bereich existiert durch Detektieren, dass Pakete bezüglich dem Korrespondenzendgerät (25) nicht empfangen und übertragen werden.
Ein Mobilkommunikationsverfahren zum Erlauben eines Korrespondenzendgeräts (25) zum Kommunizieren mit einem Mobilendgerät (12) in einem Netzwerk, zusammengesetzt aus einer Vielzahl von Unternetzwerken mit Netzwerksteuergeräten, und zum Weiterführen einer Kommunikation, selbst wenn das Mobilendgerät (12) sich von einem Unternetzwerk (1) zu einem anderen Unternetzwerk (2) bewegt, einschließlich dem Schritt eines Authentifizierens des Korrespondenzendgeräts (25); und gekennzeichnet durch die Schritte eines Einstellens von Binde-Cache-Information, die das Korrespondenzendgerät (25) benötigt zum Kommunizieren mit dem Mobilendgerät (12); Aktualisieren der Binde-Cache-Information, wenn das Mobilendgerät (12) sich bewegt von einem ersten Unternetzwerk (1) zu einem zweiten Unternetzwerk (2); und Kommunizieren der Binde-Cache-Information zwischen den Netzwerksteuergeräten, um die Binde-Cache-Information einzustellen, wobei der Authentifizierungsschritt, der Einstellschritt und der Kommunikationsschritt ausgeführt werden in einem Proxy-Korrespondenzendgerät (24) in einem Netzwerk, umfassend die Vielzahl der Unternetzwerke, und wobei der Einstell- und Aktualisierschritt Verwalten von Binde-Caches enthält, Detektieren des Binde-Caches, Erzeugen eines Eintrags eines Eintrags für den Binde-Cache, dass dieser nicht existiert, und Aktualisieren eines Eintrags mit empfangener Information des Binde-Caches, falls der Binde-Cache schon existiert, der Kommunikationsschritt enthält Detektieren einer Binde-Cache-Nachricht, Bestimmen, ob ein Cache entsprechend einem Zielkorrespondenzendgerät existiert, Aktualisieren eines Binde-Caches, falls es existiert, und Erzeugen und Übertragen einer Bindebestätigungsnachricht, falls er nicht existiert, und wobei der Authentifizierungsschritt ein Authentifizieren des Korrespondenzendgeräts enthält mittels eines Verbindungsschichtauthentifizierungs-Servers, wenn das Korrespondenzendgerät Mobil-IP nicht verwenden kann, und Authentifizieren des Korrespondenzendgeräts durch das Proxy-Korrespondenzendgerät, wenn das Korrespondenzendgerät die Mobil-IP verwenden kann.
Das Mobilkommunikationsverfahren nach Anspruch 11, ferner dadurch gekennzeichnet, dass eine Mobil-IP adoptiert wird als Kommunikationsprotokoll in dem Mobilkommunikationsverfahren.
Das Mobilkommunikationsverfahren nach Anspruch 12, ferner dadurch gekennzeichnet, dass das Korrespondenzendgerät (25) nicht Mobil-IP unterstützt.
Das Mobilkommunikationsverfahren nach Anspruch 12, ferner gekennzeichnet durch: Editieren eines Datenpakets, empfangen von dem Korrespondenzendgerät (25), und bestimmt für das Mobilendgerät (12); und Übertragen des editierten Datenpakets direkt an das zweite Unternetzwerk (2) und Hervorrufen, dass das Datenpaket das Mobilendgerät (12) erreicht, wenn das Korrespondenzendgerät (25) existiert in dem ersten Unternetzwerk (1) und das Mobilendgerät in dem zweiten Unternetzwerk (2) existiert.
Das Mobilkommunikationsverfahren nach Anspruch 11, ferner dadurch gekennzeichnet, dass das Korrespondenzendgerät (25) ein Endgerät ist, das unter der Vielzahl von Unternetzwerken sich bewegen kann.
Das Mobilkommunikationsverfahren nach Anspruch 11, ferner dadurch gekennzeichnet, dass die Einstell- und Kommunikationsschritte ausgeführt werden in einem Router (24), gekoppelt an das Korrespondenzendgerät (25).
Das Mobilkommunikationsverfahren nach Anspruch 12, ferner gekennzeichnet durch: Bestimmen, ob oder ob nicht das Korrespondenzendgerät (25) existiert in einem vorbestimmten Bereich, wobei der vorbestimmte Bereich ein Bereich ist, wo das Korrespondenzendgerät (25) auf das Netzwerk zugreifen kann.
Das Mobilkommunikationsverfahren nach Anspruch 17, ferner dadurch gekennzeichnet, dass falls das Korrespondenzendgerät (25) nicht existiert in dem vorbestimmten Bereich, die Binde-Cache-Information für das Korrespondenzendgerät (25) gelöscht wird.
Das Mobilkommunikationsverfahren nach Anspruch 12, ferner dadurch gekennzeichnet, dass falls das Korrespondenzendgerät (25) ein Mobil-IP-Korrespondenzendgerät (25) ist, Bestimmen, dass das Korrespondenzendgerät (25) einen vorbestimmten Bereich verlassen hat, wenn das Korrespondenzendgerät (25) nicht eine Registrierung bei dem vorbestimmten Bereich ausführt.
Das Mobilkommunikationsverfahren nach Anspruch 17, ferner dadurch gekennzeichnet, dass der Besuchszustandsverifizierschritt bestimmt, dass das Korrespondenzendgerät (25) nicht länger in dem vorbestimmten Bereich existiert durch Detektieren, dass Pakete nicht übertragen und empfangen werden durch das Korrespondenzendgerät (25).