DE60119009T2

DE60119009T2 - System und Verfahren für mobilen Datendienst

Info

Publication number: DE60119009T2
Application number: DE2001619009
Authority: DE
Inventors: Fujitsu Limited Yoichiro Kawasaki-shi Igarashi; Fujitsu Nishi-Nihon Shinya Sawara-ku Fukukoka-shi Yamamura; Fujitsu Limited Mitsuaki Kawasaki-shi Kakemizu; Fujitsu Nishi-Nihon Kazunori Sawara-ku Fukukoka-shi Murata; Fujitsu Limited Masaaki Kawasaki-shi Wakamoto
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-02-21
Filing date: 2001-02-13
Publication date: 2006-11-23
Anticipated expiration: 2021-02-14
Also published as: EP1128632A2; JP2001237878A; EP1128632A3; EP1624643A1; US20010016492A1; EP1128632B1; DE60119009D1; JP4060021B2

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein System und ein Verfahren, die eine Diensteinformation in einem Netz verteilen, und insbesondere ein System und ein Verfahren, die zu Netzeinrichtungen eine Information über einen Dienst, der durch ein Netz bereitgestellt wird, in dem Netz verteilen, das Mobilknoten enthält.
Beschreibung des verwandten Sachstandes
Mit der schnellen Verbreitung des Internets ist das Volumen von IP-Paketverkehr stark zunehmend. Auch mit der Verbreitung von Mobiltelefonen ist eine Standardisierung durch IMT-2000 (International Mobile Telecommunications 2000) fortgeschritten, und es wird erwartet, dass Hochgeschwindigkeits-IP-Kommunikationen in einer Mobilumgebung weit verbreitet werden. Jedoch kann nicht ausgesagt werden, dass die Techniken zum Verbessern von Funktionen von IP-Kommunikationen (beispielsweise QoS (Dienstequalität, Quality of Service), ein Mehrwertdienst (wie etwa eine netzweite Lastverteilung eines WWW-Servers etc.) vollständig ausgereift sind, obwohl nach diesem wahrscheinlich ein hoher Bedarf besteht.
Als ein Verfahren, das ein IP-Netz steuert, ist PBN (Policy-Based Networking) hauptsächlich von U.S.-Anbietern vorgeschlagen worden.
Mit dem PBN wird eine Betriebsstrategie in einer Netzeinrichtung, die in einem Netz angeordnet ist, eingestellt, und jede Netzeinrichtung arbeitet in Übereinstimmung mit der Strategie, wodurch diversifizierte Mehrwertdienste bereitgestellt werden. Beispiele der Mehrwertdienste schließen eine Garantie einer Bandbreite, eine Garantie einer Verzögerungszeit, eine Paketfilterung, eine Zugriffsbeschränkung etc. ein. Um diese Dienste bereitzustellen, werden RSVP (Resource Reservation Protocol), Diff-Serv (Differentiated Services), etc. häufig verwendet. Der Diff-Serv ist ein Protokoll zum bevorzugten Übertragen eines bestimmten Pakets auf der Grundlage der Priorität, die jedem Paket zugewiesen ist.
Jedoch treten, da eine Mobilumgebung in dem normalen PBN nicht vollständig berücksichtigt wird, die folgenden Probleme auf. Wenn nämlich eine Strategie (die oben beschriebene QoS, etc.) für jedes Mobilendgerät in dem PBN eingestellt wird, muss die entsprechende Strategie für sämtliche der Netzeinrichtungen eingestellt werden, die möglicherweise das Mobilendgerät enthalten. Folglich nimmt die Menge von Einstellungen der Strategie in dem gesamten Netz zu. Zusätzlich ist es, weil die Anzahl von Netzeinrichtungen, die möglicherweise das Mobilendgerät enthalten können, groß ist, unpraktisch, die Strategie für jedes Mobilendgerät in jeder der Vorrichtungen einzustellen. Überdies ist es, wenn eine Information, die in dem PBN übertragen wird, einzeln auf einen entsprechenden Fundamentaldienst, wie etwa eine Mobil-IP, etc., angewandt wird, notwendig, eine Spezifikation für jeden Dienst vorzubereiten und zu überprüfen.
Als ein Protokoll zum Aufnehmen eines Mobilendgeräts in einer Netzeinrichtung wird ein IP-Mobility Support (nachstehend als eine "Mobil-IP" oder eine "MIP" bezeichnet) durch die RFC 2002 ausgegeben.
In einem IP-Netz, wo Sprach- und Datenkommunikationen integriert sind, und Endgeräte verschiedener Typen angeschlossen sind, ist es notwendig, die QoS-Funktion zum Zweck eines Schützens eines verzögerungssensitiven Verkehrs oder eines Verkehrs mit einer hohen Geschäftspriorität zu implementieren. Als ein Verfahren, das die QoS-Funktion implementiert, sind Int-Serv, Diff-Serv, etc. vorgeschlagen. Der Diff-Serv mit einem kleinen Overhead wird als vielversprechend für ein Träger- oder ein Backbone-Netz unter den vorgeschlagenen Verfahren angesehen.
Jedoch müssen mit dem Diff-Serv Strategien für sämtliche der Netzeinrichtungen in dem Pfad eingestellt werden. Deswegen ist eine Netzverwaltung nur mit dem Diff-Serv kompliziert. Folglich wird ein Konzept vorgeschlagen, derart, dass ein Strategie-Server in einem Netz angeordnet ist, und der Strategie-Server stellt Strategien für jeweilige Einrichtungen ein, wodurch das gesamte Netz auf eine zentralisierte Weise verwaltet wird (dieses Konzept wird manchmal als das PBN bezeichnet).
Jedoch ist es in einem nahtlosen, globalen Netz, das durch verschiedene Provider und Träger konfiguriert ist, die Mobilendgeräte enthalten, notwendig, es zuzulassen, dass sämtliche lokale Netze eine Strategie für einen möglicherweise angeschlossenen Benutzer bestimmen und eine Information für Netzeinrichtungen einstellen. Wenn Versuche gemacht werden, dies mit dem PBN zu implementieren, muss jedes der lokalen Netze die Strategieinformation sämtlicher Benutzer speichern, oder eine Strategieinformation muss vorab für sämtliche der Netzeinrichtungen gesendet werden, mit welcher ein Benutzer möglicherweise verbunden werden kann. Jedoch ist es, da die Anzahl von Benutzern sehr groß ist, äußerst ineffizient und unpraktisch, dieses Verfahren zu verwenden.
Überdies muss, wenn jede Netzeinrichtung veranlasst wird, die Strategieinformation für sämtliche der Benutzer dauerhaft zu halten, die Speichermenge einer Netzeinrichtung erhöht werden, was zu einer Verschlechterung des Durchsatzes führt. Im Gegensatz dazu wird, wenn ein Verfahren, das einen Strategie-Server bei Bedarf abfragt, ohne zu veranlassen, dass jede Netzeinrichtung eine Strategieinformation erhält, eingesetzt wird, der Overhead einer Anforderung groß, was zu einer höheren Wahrscheinlichkeit führt, dass SLA (Service Level Agreement) nicht eingehalten werden kann.
Um die oben beschriebenen Probleme zu lösen, hat der Anmelder der vorliegenden Erfindung zuvor das Verfahren vorgeschlagen, das die Information über einen Mehrwertdienst an Netzeinrichtungen unter Verwendung eines Protokolls verteilt, das für die Mobil-IP ähnlich und relevant ist. Eine Patentanmeldung, die dieses Verfahren offenbart, wurde eingereicht (Patentanmeldenummern in Japan sind 11-276703 und 2000-101414, und eine Anmeldenummer in den Vereinigten Staaten ist 09/672,866). Nachstehend werden die Mobil-IP und das Verfahren, das in der Patentanmeldung vorgeschlagen ist, kurz beschrieben werden.
1 ist ein schematisches Diagramm zum Erläutern der Mobil-IP und der zuvor eingereichten Erfindung. Ein AAAH (Authentifizierungs-, Autorisierungs- und Abrechnungs-Hausvermitler) 1 und ein AAAF (Authentifizierungs-, Autorisierungs- und Abrechnungs-Fremdvermittler) 2 authentifizieren einen Mobilknoten (MN) 11, bestimmen, ob ein Zugriff auf/von dem Mobilknoten 11 zu autorisieren ist oder nicht, und führen einen Abrechnungsprozess für den Mobilknoten 11 durch. Eine Dienstesteuerdatenbank 3 speichert die Information (Dienstesteuerinformation) über einen Dienst, der jedem Mobilknoten 11 bereitgestellt wird.
Ein HA (Hausvermittler) 4 und ein FA (fremder Vermittler) 5 sind Router, die den Mobilknoten 11 aufnehmen und IP-Pakete gemäß der Dienstesteuerinformation weitergeben, die von dem AAAH 1 oder dem AAAF 2 verteilt wird.
Dieses Netz umfasst: (1) die Funktion zum Erfassen des Orts eines Mobilknotens 11; (2) die Funktion zum Registrieren des Orts des Mobilknotens 11; und (3) die Funktion zum Übertragen von Paketen zu dem Mobilknoten 11 an einen Ort, wo sich der Mobilknoten aufhält.
Jeder FA sendet periodisch eine Ankündigungsnachricht. Die IP-Adresse des entsprechenden FA ist in der Ankündigungsnachricht enthalten. Dementsprechend wird sich, wenn sich der Mobilknoten 11 von dem Kommunikationsgebiet eines FA zu jenem eines anderen bewegt, die IP-Adresse, die in der Ankündigungsnachricht enthalten ist, die von dem Mobilknoten 11 empfangen wird, zu einem bestimmten Zeitpunkt ändern. Wenn die Änderung in der IP-Adresse in der Ankündigungsnachricht erfasst wird, wird erkannt, dass der Mobilknoten 11 in das Kommunikationsgebiet eines unterschiedlichen FA eintritt, und die IP-Adresse des Mobilknotens 11 wird zu dem neuen FA und HA 4 übermittelt. Zu dieser Zeit übermittelt der neue FA seine IP-Adresse zu dem HA 4. Auf diese Weise wird der neue FA, der den Mobilknoten 11 neu aufnimmt, in dem HA 4 registriert, und die IP-Adresse des Mobilknotens 11 wird in dem neuen FA registriert.
Eine Paketübertragung von einem CN (Korrespondenzknoten) 12 zu dem Mobilknoten 11 wird wie folgt ausgeführt. Das Paket, dem die IP-Adresse des Mobilknotens 11 als eine Zieladresse zugeordnet ist, wird nämlich einmal zu dem HA 4 übertragen. Auf einem Empfang des Pakets, das an den Mobilknoten 11 adressiert ist, hin überträgt der HA 4 dieses Paket zu dem FA, der gegenwärtig den Mobilknoten 11 enthält. Hier wird angenommen, dass der FA 5 den Mobilknoten 11 enthält. In diesem Fall empfängt der FA 5 das Paket von dem HA 4 und sendet das Paket zu dem Mobilknoten 11. Auf diese Weise wird das Paket zu dem Knoten an einem Ort übertragen, wo sich der Mobilknoten aufhält.
Mit dem oben beschriebenen Verfahren wird eine Dienstesteuerinformation für jeden Mobilknoten zu dem FA, der den Mobilknoten 11 enthält, gemäß der Ortsregistrierung verteilt. Beispielsweise extrahiert, wenn der Mobilknoten 11 in das Kommunikationsgebiet des FA 5 eintritt, der AAAH 1 die Dienstesteuerinformation des Mobilknotens 11 aus der Dienstesteuerdatenbank 3 und verteilt die extrahierte Information zu dem HA 4 und dem FA 5. Der HA 4 und der FA 5 führen dann den Mehrwertdienst (QoS, Paketfilterung, usw.), der von dem Mobilknoten 11 abgefragt wird, gemäß der Dienstesteuerinformation aus.
Auf diese Weise kann ein Dienst äquivalent zu dem vorhandenen PBN in der Mobilumgebung bereitgestellt werden. Zu dieser Zeit wird die Dienstesteuerinformation (die einer PBN-Strategie entspricht) nicht zu sämtlichen der FAs verteilt, sondern nur zu dem FA, der tatsächlich den Mobilknoten 11 enthält.
Jedoch weist dieses Verfahren immer noch die folgenden Probleme auf.

(1) Da eine Dienstesteuerinformation in einem Format konfiguriert ist, das sich in Abhängigkeit von jedem Dienst unterscheidet, müssen ein HA und ein FA eines Dienstes gewärtig sein.
(2) Eine Dienstesteuerinformation wird für sämtliche der Mobilendgeräte erzeugt und zu einem HA und einem FA ungeachtet dessen verteilt, ob ein Kontrakt, einen Mehrwertdienst zu empfangen, ausgeführt ist oder nicht. Folglich wird ein Overhead groß.
(3) Die Funktion zum Ersetzen der für die Mobil-IP-spezifischen Prozesse durch die Prozesse, die den Funktionen entsprechen, die inhärent in einem Router sind, ist erforderlich. Dementsprechend müssen, wenn die Funktionen der Mobil-IP erweitert werden, die Programme eines HA und eines FA in bestimmten Fällen modifiziert werden. Folglich besteht eine Möglichkeit, dass ein Dienstesteuerverfahren selbst geändert werden muss.
(4) In einem System, wo eine einzelne virtuelle Adresse einer Mehrzahl von Hardware-Resourcen zugewiesen ist, ist eine Synchronisation zwischen einem FA und einem FA für die Prozedur zum Auswählen einer der Mehrzahl von Hardware-Resourcen nicht eingerichtet, wenn ein Paket zu der virtuellen Adresse übertragen wird.

In einem Artikel mit dem Titel "Mobile IP and Security Issue: An Overview", datiert 25. Oktober 1999, von C. Perkins, Seiten 131 bis 148, ist eine Prozedur zum Registrieren des Orts eines Mobilknotens in einem System, das einen AAA-Server, einen Hausvermittler und einen fremden Vermittler umfasst, und ein Verfahren zum Authentifizieren einer Mobil-IP zwischen unterschiedlichen Verwaltungsdomänen offenbart.
In "Remote Authentication Dial In User Service (RADIUS)" von C. Rigney et al., Januar 1997, IEFT RFC 2058, ist das öffentlich bekannte Authentifizierungsprotokoll RADIUS diskutiert. Ein System, das einem authentifizierten Benutzer einen entsprechenden Dienst bereitstellt, ist offenbart.
Zusammenfassung der Erfindung
Die vorliegende Erfindung zielt auf ein Bereitstellen eines Verfahrens, das einen Mehrwertdienst für jedes Endgerät in einem IP-Netz definiert, das eine Mobilumgebung einschließt, und ein Zulassen, dass ein Mehrwertdienst mit einer größeren Skalierbarkeit hinzugefügt und erweitert wird, ab.
Ein Mobilkommunikationsdienste-Bereitstellungssystem gemäß der vorliegenden Erfindung nimmt die Konfiguration an, wo die Ortsregistrations-Anforderungsinformation, die von einem mobilen Knoten gesendet wird, zu einem Hausvermittler über einen fremden Vermittler und ein Serversystem übertragen wird, und die Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler zu dem mobilen Knoten über das Serversystem und den fremden Vermittler zurückgegeben wird, wobei der Ort des Mobilknotens in dem Hausvermittler und dem fremden Vermittler registriert ist, und ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt ist. Der Hausvermittler und der fremde Vermittler umfassen eine Steuereinheit zum Bestimmen des Übertragungsziels eines Pakets. Das Serversystem umfasst: eine Extraktionseinheit, die ein Diensteprofil, das dem Mobilknoten entspricht, aus der Datenbank zum Verwalten von Diensteprofilen extrahiert, die die Information zum Bereitstellen eines Dienstes gemäß der Ortsregistrierungs-Anforderungsinformation von dem Mobilknoten einschließt, auf der Grundlage eines den Mobilknoten identifizierenden Mobilknoten-Identifizierers, der in der Ortsregistrierungs-Anforderungsinformation eingeschlossen ist; eine Verwaltungseinheit, die das Diensteprofil, das von der Extraktionseinheit extrahiert wird, in ein Format editiert, das für die Steuereinheit verfügbar ist; und eine Verteilungseinheit, die das Diensteprofil, das von der Dienstverwaltungseinheit editiert ist, zu dem Hausvermittler und dem fremden Vermittler verteilt. Der Hausvermittler und der fremde Vermittler stellen einen Dienst durch eine Benutzung der Steuereinheit gemäß des Diensteprofils bereit, das von dem Serversystem verteilt ist.
Gemäß der vorliegenden Erfindung wird ein Diensteprofil durch ein Serversystem in das Format editiert, das für einen Hausvermittler und einen fremden Vermittler unverändert verfügbar ist. Folglich müssen der Hausvermittler und der fremde Vermittler sich über den Typ eines Dienstes nicht bewusst sein, wenn ein angeforderter Dienst für jeden Mobilknoten bereitgestellt wird. Folglich werden Modifikationen in den Programmen oder den Daten, die von dem Hausvermittler und dem fremden Vermittler verwendet werden, wenn ein Dienst hinzugefügt/geändert wird, verringert.
Es sei darauf hingewiesen, dass das Serversystem ein Diensteprofil zu dem Hausvermittler und dem fremden Vermittler nicht verteilen kann, wenn der Mobilknoten einen Mehrwertdienst in der oben beschriebenen Konfiguration nicht anfordert. Zu dieser Zeit können der Hausvermittler und der fremde Vermittler jeweils einen Fundamentaldienst gemäß der Informationen bereitstellen, die die Haus- und fremden Vermittler selbst erzeugen.
In dieser Konfiguration nehmen die Informationsmengen, die zwischen dem Serversystem und dem Haus- und fremden Vermittler ausgetauscht werden, ab. Zusätzlich kann der Speicherraum zum Speichern eines Diensteprofils in jedem Hausvermittler und fremden Vermittler verringert werden, was zu einer Verbesserung in der Verarbeitungsgeschwindigkeit beiträgt.
Zusätzlich kann in der oben beschriebenen Konfiguration angenommen werden, dass ein Adressbereich, der für einen vorbestimmten Dienst verfügbar ist, zuvor spezifiziert wird, ein Diensteprofil, das die Information einschließt, die den Adressbereich darstellt, der zuvor spezifiziert ist, als eine Bedingung zum Extrahieren eines bestimmten Pakets aus empfangenen Paketen in dem Hausvermittler und dem fremden Vermittler voreingestellt wird, und das Serversystem eine Adresse innerhalb des Adressbereichs, der zuvor spezifiziert ist, dem Mobilknoten zuweisen kann, der den vorbestimmten Dienst anfordert.
In dieser Konfiguration wird das Paket, das zu/von dem Mobilknoten übertragen wird, durch den Hausvermittler oder den fremden Vermittler gemäß dem Diensteprofil extrahiert, und der Dienst (nämlich der oben beschriebene, vorbestimmte Dienst), der dem Diensteprofil entspricht, wird ausgeführt.
Dementsprechend nehmen auch in dieser Konfiguration die Informationsmengen, die zwischen dem Serversystem und dem Hausvermittler und dem fremden Vermittler ausgetauscht werden, ab. Überdies kann der Speicherraum zum Speichern eines Diensteprofils in jeweils dem Hausvermittler und dem fremden Vermittler verringert werden, was zu einer Verbesserung in der Verarbeitungsgeschwindigkeit beiträgt.
Überdies kann in der oben beschriebenen Konfiguration, wenn ein Dienst zum Übertragen eines Pakets, das eine einzige virtuelle Adresse als eine Zieladresse aufweist, die einer Mehrzahl von Mobilknoten zugewiesen ist, zu einem beliebigen der Mehrzahl von Mobilknoten bereitgestellt wird, ein Adress-Proxy-Server, der das Paket empfängt, dem die oben beschriebene, virtuelle Adresse zugewiesen ist, angeordnet werden, und das Serversystem kann das Diensteprofil zum Extrahieren des Pakets, dem die virtuelle Adresse zugeordnet ist, und zum Übertragen des Pakets zu einem bestimmten Mobilknoten unter der Mehrzahl von Mobilknoten zu dem Adress-Proxy-Server verteilen, und kann auch zu einem fremden Vermittler das Diensteprofil zum Übertragen des Pakets, das an den fremden Vermittler adressiert ist, der den bestimmten Mobilknoten enthält, zu dem bestimmten Mobilknoten verteilen.
In dieser Konfiguration wird die Übertragung des Pakets, dem die virtuelle Adresse zugewiesen ist, durch das Serversystem auf eine vereinheitlichte Weise gesteuert. Dementsprechend wird das Paket, das die virtuelle Adresse als ein Ziel aufweist, sicher zu dem bestimmten Knoten, der durch das Serversystem bestimmt ist, übertragen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Mobilkommunikationsdienst-Bereitstellungsverfahren bereitgestellt, mit welchem eine Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten zu einem Hausvermittler über einen fremden Vermittler und ein Serversystem übertragen wird, und eine Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler zu dem Mobilknoten über das Serversystem und den fremden Vermittler zurückgegeben wird, so dass ein Ort des Mobilknotens für den Hausvermittler und den fremden Vermittler registriert wird, und ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt wird, dadurch gekennzeichnet, dass: der Hausvermittler und der fremde Vermittler eine Steuereinheit umfassen, die ein Übertragungsziel eines Pakets bestimmt, wobei das Verfahren umfasst: Extrahieren, durch das Serversystem, eines Diensteprofils, das dem Mobilknoten entspricht, aus einer Datenbank zum Verwalten eines Diensteprofils, die eine Information zum Bereitstellen eines Dienstes gemäß der Ortsregistrierungs-Anforderungsinformation von dem Mobilknoten einschließt, auf der Grundlage eines den Mobilknoten identifizierenden Mobilknoten-Identifizierers, der in der Ortsregistrierungs-Anforderungsinformation enthalten ist; Editieren, durch das Serversystem, des extrahierten Diensteprofils in ein Format, das für die Steuereinheit verfügbar ist; und Verteilen des editierten Diensteprofils von dem Serversystem zu dem Hausvermittler und dem fremden Vermittler, und der Hausvermittler und der fremde Vermittler stellen einen Dienst unter Verwendung der Steuereinheit gemäß dem Diensteprofil bereit, das durch die Diensteverwaltungseinheit editiert ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Serversystem zur Verwendung in einem Mobilkommunikationsdienste-Bereitstellungssystem bereitgestellt, bei welchem eine Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten zu einem Hausvermittler über einen fremden Vermittler und ein Serversystem verteilt wird, und eine Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler zu dem Mobilknoten über das Serversystem und den fremden Vermittler zurückgegeben wird, so dass ein Ort des Mobilknotens für den Hausvermittler und den fremden Vermittler registriert ist, und ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt wird, dadurch gekennzeichnet, dass das Serversystem umfasst: eine Extraktionseinheit, die ein Diensteprofil für den Mobilknoten aus einer Datenbank zum Verwalten eines Diensteprofils extrahiert, die eine Information zum Bereitstellen eines Dienstes gemäß der Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten enthält, auf der Grundlage eines Mobilknoten-Identifizierers, der den Mobilknoten identifiziert, der in der Ortsregistrierungs-Anforderungsinformation enthalten ist; eine Diensteverwaltungseinheit, die das Diensteprofil, das von der Extraktionseinheit extrahiert wird, in ein Format editiert, das für eine Steuereinheit zum Bestimmen eines Übertragungsziels eines Pakets verfügbar ist; und eine Verteilungseinheit, die das editierte Diensteprofil zu dem Hausvermittler und dem fremden Vermittler verteilt, so dass der Hausvermittler und der fremde Vermittler einen Dienst unter Verwendung der Steuereinheit gemäß dem Diensteprofil, das von der Dienstverwaltungseinheit editiert ist, bereitstellt.
Gemäß noch einem weiteren Aspekt der vorliegenden Erfindung ist eine Vermittlungseinrichtung als ein Hausvermittler oder ein fremder Vermittler zur Verwendung in einem Mobilkommunikationsdienste-Bereitstellungssystem bereitgestellt, bei welchem eine Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten zu dem Hausvermittler über den fremden Vermittler und ein Serversystem übertragen wird, und eine Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler zu dem Mobilknoten über das Serversystem und den fremden Vermittler zurückgegeben wird, so dass ein Ort eines Mobilknotens für den Hausvermittler und den fremden Vermittler registriert wird, und ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt wird, dadurch gekennzeichnet, dass der Vermittler umfasst: eine Dienste-unabhängige Einheit, die ein Verarbeitungsverfahren zur ein empfangenes Paket gemäß einer Header-Information des empfangenen Pakets bestimmt; eine Individualdienst-Steuereinheit, die die Dienste-unabhängige Einheit gemäß einem Diensteprofil verwendet, das in ein Format, das für die Dienste-unabhängige Einheit verfügbar ist, durch das Serversystem editiert ist; und eine Paketsteuereinheit, die ein Paket gemäß einem Verarbeitungsergebnis einer Verwendung der Dienste-unabhängigen Einheit verarbeitet und ein Übertragungsziel eines Pakets bestimmt.
Kurze Beschreibung der Zeichnungen
In den Zeichnungen zeigen:
1 ein schematisches Diagramm zum Erläutern eines Mobil-IP und der zuvor eingereichten Erfindung;
2 ein schematisches Diagramm, das den Hintergrund der vorliegenden Erfindung erläutert;
3 ein schematisches Diagramm, das die Netzkonfiguration einer Ausführungsform gemäß der vorliegenden Erfindung zeigt;
4 ein Blockdiagramm, das die Funktionen der Ausführungsform gemäß der vorliegenden Erfindung zeigt;
5 ein Blockdiagramm, das die Funktionen eines AAAH zeigt;
6 die Originaldaten eines Diensteprofils beispielhaft, die in einer Dienstesteuerdatenbank gespeichert sind;
7 die Dienstequalitäten beispielhaft, die in der Dienstesteuerdatenbank registriert sind;
8 beispielhafte Abrechnungsverfahren, die gegenüber der Dienstesteuerdatenbank registriert sind;
9 beispielhaft eine Beschränkungsbedingung, die gegenüber der Dienstesteuerdatenbank registriert ist;
10 beispielhaft das Profil für einen Diff-Serv-Dienst;
11 beispielhaft das Profil für einen ANYCAST-Dienst;
12 beispielhaft das Diensteprofil, das durch einen AAAH erzeugt ist;
13 beispielhaft eine ANYCAST-Adressverwaltungstabelle;
14 beispielhaft die Sitzungstransaktion des AAAH;
15 ein Blockdiagramm, das die Funktion eines AAAF zeigt;
16 beispielhaft die Sitzungstransaktion der AAAF;
17 ein Blockdiagramm, das die Funktionen einer HA, einer FA und eines CN zeigt;
18 beispielhaft die Sitzungstransaktion der HA und der FA;
19 beispielhaft einen Diensteprofil-Cache;
20 beispielhaft eine Suchstrategie-Verwaltungstabelle;
21 beispielhaft eine Besucherliste;
22 beispielhaft eine Mobilitätsbindung;
23 beispielhaft einen Bindungs-Cache;
24 beispielhaft eine ANYCAST-Tabelle;
25 beispielhaft eine Routing-Tabelle;
26 die Sequenz für Verteilungsdiensteprofile (Nr. 1);
27 einen Anfangszustand;
28A und 28B beispielhaft die Diensteprofile, die durch den FA zu der Zeit einer Anfangskonfiguration erzeugt werden;
29 beispielhaft das Diensteprofil, das durch den HA zu der Zeit einer Anfangskonfiguration erzeugt wird;
30 die Prozedur zum Erzeugen eines Diensteprofils durch den AAAH;
31A und 31B beispielhaft die Diensteprofile, die zu dem HA zu verteilen sind;
32A und 32B beispielhaft die Diensteprofile, die zu dem FA zu verteilen sind;
33 die Prozedur zum Einstellen von Diensteprofilen in dem HA;
34 die Prozedur zum Übertragen von Diensteprofilen zu dem AAAF;
35 die Prozedur zum Einstellen von Diensteprofilen in dem FA;
36 die Prozedur zum Übertragen eines Pakets von einem Mobilknoten zu einem Korrespondenzknoten;
37 die Prozedur zum Übertragen eines Pakets von dem Korrespondenzknoten zu dem Mobilknoten;
38 die Sequenz für Verteilungsdiensteprofile (Nr. 2);
39 die Sequenz für Verteilungsdiensteprofile (Nr. 3);
40 die Sequenz für Verteilungsdiensteprofile (Nr. 4);
41 die Sequenz für Verteilungsdiensteprofile (Nr. 5);
42 ein Flussdiagramm, das die Betriebsschritte des AAAH erläutert;
43 ein Flussdiagramm, das die Betriebsschritte des AAAF (Nr. 1) erläutert;
44 ein Flussdiagramm, das die Betriebsschritte des AAAF (Nr. 2) erläutert;
45 ein Flussdiagramm, das die Betriebsschritte des HA, des FA und des CN erläutert;
46 beispielhaft das Diensteprofil, das in dem HA eingestellt ist;
47 beispielhaft das Diensteprofil, das in dem FA eingestellt ist;
48 ein Beispiel eines Verfahrens, das einen IP-Adressbereich vorbestimmt, der für Diensteklassen verwendet wird;
49 beispielhaft die Sequenz zum Einstellen eines Diensteprofils in einer Routen-Optimierungsprozedur;
50 ein schematisches Diagramm, das einen ANYCAST-Dienst erläutert;
51 beispielhaft ein Diensteprofil, das zu einem Adress-Proxy-Server verteilt wird;
52 beispielhaft ein Diensteprofil, das zu dem HA verteilt wird;
53 beispielhaft ein Diensteprofil, das zu dem FA (Nr. 1) verteilt wird;
54 beispielhaft ein Diensteprofil, das durch den FA erzeugt wird;
55 beispielhaft ein Diensteprofil, das zu dem FA (Nr. 2) verteilt wird;
56 die Sequenz zum Einstellen einer ANYCAST-Information (Nr. 1);
57 die Sequenz zum Einstellen der ANYCAST-Information (Nr. 2);
58 die Sequenz zum Übertragen eines Pakets mit einem ANYCAST-Dienst;
59 die Sequenz zum Löschen der Registrierung für den ANYCAST-Dienst (Nr. 1);
60 die Sequenz zum Löschen einer Registrierung für den ANYCAST-Dienst (Nr. 2);
61 das Format des Mobil-IP;
62A das Format eines IP-Headers;
62B das Format eines UDP-Headers;
63A bis 63D das Format einer Mobil-IP-Registrierungsanforderungsnachricht;
64A und 64B das Format einer Mobil-IP-Registrierungsantwortnachricht;
65 das Format einer Mobil-IP-BU-Nachricht;
66 das Format einer Mobil-IP-BA-Nachricht;
67 das Format einer DIAMETER-Nachricht;
68 das Format des gemeinsamen Headers der DIAMETER-Nachricht;
69A bis 69C das Format eines AVP der DIAMETER-Nachricht;
70 das Format einer AMR-Nachricht eines DIAMETER-Protokolls;
71 das Format einer HAR-Nachricht des DIAMETER-Protokolls;
72 das Format einer AMA-Nachricht des DIAMETER-Protokolls; und
73 das Format einer HAA-Nachrichgt des DIAMETER-Protokolls.
Beschreibung der bevorzugten Ausführungsformen
Nachstehend werden Ausführungsformen gemäß der vorliegenden Erfindung in der folgenden Reihenfolge unter Bezugnahme auf die Zeichnungen beschrieben werden.

1. Hintergrund der Erfindung
2. Kurzdarstellung der vorliegenden Erfindung
3. Konfiguration eines Gesamtsystems
4. Konfiguration eines AAAH
5. Konfiguration eines AAAF
6. Konfigurationen eines HA, eines FA und eines CN
7. Sequenz für die Verteilung von Diensteprofilen
7A. In dem Fall, wo der AAAH den HA spezifiziert
7B. In dem Fall, wo der AAAF den HA spezifiziert
7C. Flussdiagramm jeder Einheit
7D. Verwaltung von Diensteprofilen
7E. Routenoptimierung
8. ANYCAST-Dienst

1. Hintergrund der Erfindung
Zunächst wird der Hintergrund der Erfindung unter Bezugnahme auf 2 beschrieben. Vorgesehen ist hier der Fall, wo sich ein Mobilknoten, der in einem Hausvermittler untergebracht ist, zu dem Kommunikationsgebiet eines fremden Vermittlers bewegt.

Prozedur Schritt 1: Ein Hausvermittler (HA) 200 und ein fremder Vermittler (FA) 500 geben periodisch eine Vermittlerbenachrichtungsnachricht aus, bei welcher die IP-Adresse jedes der Vermittler selbst eingestellt wird. Ein Mobilknoten 600 bestimmt, ob der Mobilknoten 600 selbst in entweder dem Kommunikationsgebiet des Hausvermittlers 200 oder jenem des fremden Vermittlers 500 verbleibt, indem eine Vermittlerankündigungsnachricht empfangen wird. Es wird angenommen, dass der Mobilknoten 600 gegenwärtig das Kommunikationsgebiet des Hausvermittlers 200 besucht.
Prozedur Schritt 2: Wenn sich der Mobilknoten 600 von dem Kommunikationsgebiet des Hausvermittlers 200 zu jenem des fremden Vermittlers 500 bewegt, empfängt er eine Vermittlerankündigungsnachricht von dem fremden Vermittler 500. Auf einen Empfang dieser Nachricht hin gibt der Mobilknoten 600 eine Ortsregistrierungs-Anforderungsnachricht zu dem fremden Vermittler 500 aus. Die Information zum Identifizieren des Mobilknotens 600 wird in dieser Nachricht eingestellt.
Prozedur Schritt 3: Auf einen Empfang der Ortsregistrierungs-Anforderungsnachricht von dem Mobilknoten 600 hin sendet der fremde Vermittler 500 eine AMR-(Authentifizierungsanforderungs)-Nachricht zu einem AAAF (Authentifizierungs-, Autorisierungs- und Abrechnungs-Fremd-Vermittler) über ein IP-Netz 80, so dass eine Authentifizierung, eine Autorisierung, eine Abrechnung etc. durchgeführt werden. Die Information zum Identifizieren des Mobilknotens 600 und des fremden Vermittlers 500 sind in dieser Nachricht eingestellt.
Prozedur Schritt 4: Der AAAF 400 identifiziert einen AAAH (Authentifizierungs-, Autorisierungs- und Abrechnungs-Haus) 100, der die Authentifizierung des Mobilknotens 600 durchführt, indem die empfangene Nachricht analysiert wird, und die AMR-Nachricht zu dem AAAH 100 über das IP-Netz 80 schickt.
Prozedur Schritt 5: Der AAAH 100 extrahiert notwendige Information aus der empfangenen AMR-Nachricht und führt die Authentifizierung des Mobilknotens 600 durch. Der AAAH 100 extrahiert beispielsweise einen Mobilknoten-Identifizierer (NAI: Networf Access Identifier, Mobilknotenkennzeichen) aus der AMR-Nachricht und greift auf eine Dienstesteuerdatenbank 300 unter Verwendung des extrahierten Identifizierers als ein Schlüssel zu. Folglich wird ein Benutzerprofil (eine Diensteprofilinformation), das dem Mobilknoten 600 entspricht, extrahiert. Wenn der AAAH 100 die Authentifizierung der AMR-Nachricht erfolgreich durchführt, fügt er die oben beschriebene Diensteprofilinformation zu einer HAR (Registrierungsanforderungs)-Nachricht hinzu und schickt die Nachricht zu dem Hausvermittler 200 über das IP-Netz 80.
Prozedur Schritt 6: Der Hausvermittler 200 extrahiert eine Information, wie etwa einen Sitzungs-ID, eine Lebensdauer, etc. von der empfangenen HAR-Nachricht und führt eine Ortsregistrierung des Mobilknotens 600 durch. Der Hausvermittler 200 extrahiert nämlich aus der HAR-Nachricht die Information zum Schicken eines Pakets, das an den Mobilknoten 600 adressiert ist, zu einem Ort, den der Mobilknoten 600 besucht und erzeugt eine Dienstesteuerinformation (eine Diensteprofiltabelle einer Dienstesteuertransaktion 230). Die resultierende Information wird zu dem AAAH 100 unter Verwendung einer HAA (Hausvermittler-MIP-Antwort: Registrierungsantwort)-Nachricht übermittelt. Zu dieser Zeit kann die HAA-Nachricht die Diensteprofilinformation des Mobilknotens 600 enthalten.
Prozedur Schritt 7: Auf einen Empfang der HAA-Nachricht hin extrahiert der AAAH 100 eine notwendige Information aus der oben beschriebenen AMR-Nachricht oder dem Benutzerprofil und erzeugt eine Dienstesteuerinformation (eine Diensteprofil-Tabelle einer Dienstesteuertransaktion 120). Zusätzlich sendet der AAAH 100 zu dem AAAF 400 eine HAMA (AA-Mobilknotenantwort: Authentifizierungsantwort)-Nachricht als eine Nachricht als Antwort auf die AMR-Nachricht. Zu dieser Zeit wird die oben beschriebene Diensteprofilinformation dieser AMA-Nachricht hinzugefügt.
Prozedur Schritt 8: Der AAAF 400 extrahiert eine notwendige Information aus der AMA-Nachricht und erzeugt eine Dienstesteuerinformation (eine Diensteprofiltabelle einer Dienstesteuertransaktion 420). Zusätzlich schickt der AAAF 400 die AMA-Nachricht zu dem fremden Vermittler 500.
Prozedur Schritt 9: Der fremde Vermittler 500 extrahiert eine notwendige Information aus der AMA-Nachricht und erzeugt eine Dienste-Steuerinformation (eine Diensteprofiltabelle einer Dienstesteuertransaktion 530). Überdies sendet der fremde Vermittler 500 eine Registrierungsantwortnachricht auf der Grundlage der AMA-Nachricht und sendet die erzeugte Nachricht zu dem Mobilknoten 600. Auf diese Weise ist die Ortsregistrierungsprozedur beendet. Danach stattet der fremde Vermittler 500 den Mobilknoten 600 mit einem Dienst unter Verwendung einer empfangenen Dienstesteuerinformation aus.

Wie oben beschrieben, wird der Ort des Mobilknotens 600 immer von dem Hausvermittler 200 verwaltet. Zusätzlich kann, da die Dienstesteuerinformation für den Mobilknoten 600 zu dem fremden Vermittler übertragen wird, der den Mobilknoten 600 aufnehmen soll, der Mobilknoten 600 einen Dienste äquivalent zu dem PBN an jedweden Ort empfangen, wo der fremde Vermittler vorhanden ist.
In dem oben beschriebenen Netz (Netzwerk) wird das Paket, das an den Mobilknoten 600 adressiert ist, einmal zu dem Hausvermittler 200 in normalen Fällen übertragen. Hier erkennt der Hausvermittler 200, dass der Mobilknoten 600 durch den fremden Vermittler 500 aufgenommen ist. Dementsprechend schickt der Hausvermittler 200 ein empfangenes Paket zu dem fremden Vermittler 500, der das Paket dann zu dem Mobilknoten 600 schickt.
2. Kurzfassung der vorliegenden Erfindung
Zum Verständnis einer Erläuterung sind Ausdrücke vordefiniert. In der folgenden Beschreibung zeigt ein "Individualdienst" einen Satz von Diensten an, die für jeden Benutzer zugeschnitten sind. Zusätzlich wird eine Diensteeinheit (wie etwa Diff-Serv, ANYCAST, etc.), die einen Individualdienst konfiguriert, einfach als ein "Dienst" bezeichnet. Unterdessen wird ein Dienst, der nicht für jeden Benutzer zugeschnitten ist (wie etwa eine Mobil-IP, die durch die IETF (Internet Engineering Task Force) festgelegt ist, etc.) als ein "Fundamentaldienst" bezeichnet.
3 ist ein schematisches Diagramm, das die Netzkonfiguration gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
Wenn sich ein Mobilknoten 600 zu dem Kommunikationsgebiet eines fremden Vermittlers 500 bewegt, extrahiert ein AAAH 100 die Dienstesteuerinformation, die dem Mobilknoten 600 entspricht, aus der Dienstesteuerdatenbank 300, wie unter Bezugnahme auf 2 erläutert. Es sei darauf hingewiesen, dass die Information (das Diensteprofil) zum Bereitstellen eines Individualdienstes, der von jedem Benutzer angefordert wird, in der Dienstesteuerdatenbank 300 für jeden Benutzer gespeichert ist. Dann verteilt der AAAH 100 das extrahierte Diensteprofil zu dem fremden Vermittler 500. Das Format des DIensteprofils ist ungeachtet eines Dienstetyps vereinheitlicht. Das heißt, dass das Diensteprofil eine Dienste-abhängige Information nicht einschließt.
Das Diensteprofil, das von dem AAAH 100 zu dem fremden Vermittler 500 (und dem Hausvermittler 200) übertragen wird, wird in ein Format vereinheitlicht, das durch die Funktionen verarbeitet werden kann, die der fremde Vermittler 500 und der Hausvermittler 200 ursprünglich bereitstellen. Hier sind der fremde Vermittler 500 und der Hausvermittler 200 beispielsweise durch Router implementiert. In diesem Fall sind die Funktionen, die der fremde Vermittler 500 und der Hausvermittler 200 ursprünglich bereitstellen, beispielsweise (1) die Funktion zum Leiten eines Pakets, (2) die Funktion zum Extrahieren eines bestimmten Pakets unter empfangenen Paketen, (3), die Funktion zum wieder Einschreiben eines Teils der Information eines empfangenen Pakets und dergleichen. Diese Funktionen werden beispielsweise durch den Prozess zum Referenzieren einer Tabelle, die eine Routing-Information speichert, dem Prozess zum Ausführen einer Anpassung zwischen vorhandenen Daten und dem Header eines empfangenen Pakets und dergleichen implementiert. Dementsprechend verteilt, nachdem die Information, um jeden Benutzer mit einem Individualdienst zu versehen, in die Information editiert oder konvertiert ist, die verwendet wird, wenn die oben beschriebenen Prozesse durchgeführt werden (wie etwa die Information zum Spezifizieren einer zu referenzierenden Tabelle, die Information zum Spezifizieren eines Anpassschlüssels, etc.), der AAAH 100 die editierte Information zu dem fremden Vermittler 500 (und dem Hausvermittler 200).
Die Konfigurationen jedes fremden Vermittlers 500 und jedes Hausvermittlers 200 sind grundsätzlich die gleichen, und schließen jeweils eines Dienste-unabhängige Funktion zum Steuern eines Fundamentaldienstes und eine Individualdienst-Steuerfunktion (SCF) ein. Das Diensteprofil, das von dem AAAH 100 verteilt wird, wird von der Individualdienst-Steuerfunktion verarbeitet. Zu dieser Zeit wird das Diensteprofil in ein Format eingeschrieben oder konvertiert, das durch die Funktion verarbeitet werden kann, die der fremde Vermittler 500 ursprünglich bereitstellt. Dementsprechend kann der fremde Vermittler 500 das empfangene Diensteprofil unverändert verwenden, ohne es zu editieren. Die Dienste-unabhängige Funktion und die Individualdienst-Steuerfunktion wirken zusammen, so dass der fremde Vermittler 500 einen Dienst gemäß dem Diensteprofil bereitstellt.
Wenn die Ortsregistrierungsprozedur des Mobil-IP, die Hand-Off- (handover) Prozedur eines Mobilknotens oder eine Leitoptimierungsprozedur und die oben beschriebenen Funktionen zusammenwirken und miteinander ausgeführt werden, wird es möglich, einen Individualdienst zu steuern, während der vollständige Vorteil aus den Funktionen, die dem Mobil-IP spezifisch sind, gezogen wird.
3. Konfiguration eines Systems der vorliegenden Erfindung
4 ist ein Blockdiagramm, das die Funktionen der Ausführungsform gemäß der vorliegenden Erfindung zeigt. Die Funktionen werden jeweils untenstehend unter Bezugnahme auf 4 erläutert.
Ein Diensteprovider (Hausnetz) 50, ein Zugriffsprovider (fremdes Netz) 60 und ein Korrespondenzknoten 700 sind über ein IP-Netz 800 (oder eine Mobil-IP) verbunden.
Der Diensteprovider 50 schließt einen AAAH 100, eine Dienstesteuerdatenbank 300 und einen Hausvermittler (HA) 200 ein. Die Verbindung zwischen dem AAAH 100 und dem HA 200 wird beispielsweise unter Verwendung eines AAA-Protokolls ausgeführt. Zusätzlich greift der AAAH 100 auf die Dienstesteuerdatenbank 300 unter Verwendung eines vorbestimmten Datenbanksuchprotokolls zu. Das Datenbanksuchprotokoll ist beispielsweise ein LDAP (Light Directory Access Protocol), obwohl es nicht sonderlich beschränkt ist.
Der Zugriffsprovider 60 schließt einen AAAF 400 und einen fremden Vermittler (FA) 500 ein. Die Verbindung zwischen dem AAAF 400 und dem FA 500 wird beispielsweise unter Verwendung des AAA-Protokolls ausgeführt. In 4 ist ein Mobilknoten (MN) 600 gegenwärtig von dem FA 500 mit der Mobil-IP aufgenommen. Die Verbindung zwischen dem AAAH 100 und dem AAAF 400 ist mit dem AAA-Protokoll ausgeführt.
Die AAAs (der AAAH 100 und der AAAF 400) sind Server, die eine Authentifizierung, eine Autorisierung und eine Abrechnung durchführen. Die Konfigurationen des AAAH und des AAAF sind grundsätzlich die gleichen. Der AAA, der auf die Datenbank zugreifen kann, bei welcher die Teilnehmerdaten eines bestimmten Benutzers registriert sind, wird als ein AAAH bezeichnet, und die anderen AAAs werden als AAAFs bezeichnet, wenn die Aufmerksamkeit auf den bestimmten Benutzer fokussiert ist.
Der AAAH 100 weist eine Funktion zum Übermitteln des HA 200 zum Benachrichtigen des HA 200 und des FA 500 über die Diensteprofilinformation auf. Die Diensteprofilinformation wird aus der Dienststeuerdatenbank 300 durch eine Diensteverwaltungseinheit extrahiert. Das heißt, dass die Diensteverwaltungseinheit des AAAH 100 aus der Dienstesteuerdatenbank 300 das Diensteprofil des Benutzers extrahiert, der eine Authentifizierungsanforderung ausgibt, und ein Diensteprofil erzeugt, das ein Mehrzweckformat aufweist, bei welchem eine Paketsteuerinformation eingestellt werden kann. Das Diensteprofil wird zu dem HA 200 unter Verwendung einer HA-Registrierungsanforderungsnachricht (HAR) und zu dem FA 500 unter Verwendung einer Authentifizierungsantwortnachricht (AMA) übermittelt. Überdies umfasst der AAAH eine ANYCAST-Adressverwaltungstabelle für einen ANYCAST-Dienst, der später zu beschreiben ist. Unterdessen identifiziert der AAAF den AAAH gemäß dem NAI eines Benutzers und führt einen Nachrichtenaustausch zwischen dem FA und dem AAAH als ein Proxy durch.
Überdies führt der AAA gemäß der vorliegenden Erfindung die Übergabe zwischen ISPs aus, wobei Details davon durch die IETF noch nicht festgesetzt worden sind, und hält eine erweiterte Sitzungstransaktion zum Halten der Beziehung mit einer anderen Einheit, um die Konsistenz einer Dienstesteuerung aufrechtzuerhalten, während ein Benutzer verbunden ist. Es sei darauf hingewiesen, dass eine Protokollsteuereinheit eine Schnittstelle für das AAA-Protokoll ist.
Der HA und der FA weisen grundsätzlich die gleiche Konfiguration auf und sind Funktionseinheiten, die jeweils durch das RFC2002 definiert sind. Wenn Aufmerksamkeit auf einen bestimmten Mobilknoten gerichtet ist, ist ein Vermittler, der die Hausadresse dem Mobilknoten zugeordnet aufweist, ein HA, wohingegen ein Vermittler, der die Hausadresse nicht dem Mobilknoten zugeordnet aufweist, ein FA ist.
Auf einen Empfang eines Pakets hin, welchem die Hausadresse eines Mobilknotens als ein Ziel zugeordnet ist, kapselt der HA das Paket ein und sendet das Paket zu der Care-Of-Adresse des FA, der der Hausadresse entspricht. Diese Adresse wird ursprünglich durch eine Tabelle verwaltet, die als eine Mobilitätsbindung bezeichnet wird. Zusätzlich ist der HA ein AAA-Protokoll-Client. Überdies umfasst der HA eine Dienste-unabhängige Einheit zum Ausführen der oben beschriebenen Funktionen, ein Diensteprofil-Cache zum Speichern einer Dienstedatei, die in der Regstrierungsanforderungs-(HAR)-Information von dem AAAH eingestellt ist, und eine Individualdienst-Steuereinheit zum Durchführen einer Paketsteuerung durch ein Referenzieren auf eine Suchstrategie-Verwaltungstabelle, die die Suchstrategie des Diensteprofil-Caches definiert.
Der FA entkapselt das Paket, das eingekapselt und übertragen ist, und schickt dieses Paket zu der Verbindungsschichtadresse, die der Hausadresse entspricht. Diese Adresse wird ursprünglich durch eine Tabelle verwaltet, die als eine Besucherliste bezeichnet wird. Der FA ist ein Zugriffsrouter eines Mobilknotens und ist gleichzeitig auch ein AAA-Protokoll-Client. Der FA umfasst ferner eine Dienste-unabhängige Einheit zum Ausführen der oben beschriebenen Funktionen, ein Diensteprofil-Cache zum Speichern eines Diensteprofils, das in einer Authentifizierungsantwort-(AMA)-Nachricht von dem AAA eingestellt eingestellt ist, eine Individualdienst-Steuereinheit zum Durchführen einer Paketsteuerung durch ein Referenzieren auf eine Suchstrategie-Verwaltungstabelle, die die Suchstrategie des Diensteprofil-Caches definiert, und eine ANYCAST-Tabelle, die eine Besucherliste ist, die erweitert ist, um die Information für einen ANYCAST-Dienst zu speichern.
Der HA und der FA umfassen jeweils eine Sitzungstransaktion zum Verwalten einer DIAMETER-Sitzung. Eine Protokollsteuereinheit ist eine Schnittstelle für das AAA-Protokoll und die Mobil-IP. Eine Paketsteuereinheit führt ein Paketleiten, ein Filtern, eine Header-Wiedereinschreibung, etc. durch.
Der Mobilknoten (MN) 600 ist ein Mobilendgerät, das die Funktionen zum Senden und Empfangen von Paketen mit der Mobil-IP aufweist. Der Korrespondenzknoten (CN) 700 sendet/empfängt Pakete zu/von dem Mobilknoten 600. Der Korrespondenzknoten 700 umfasst auch eine Dienste-unabhängige Einheit, eine individiduelle Dienstesteuereinheit, eine Protokollsteuereinheit und eine Paketsteuereinheit.
Die Mobil-IP (MIP) ist ein Protokoll, das durch die RFC2002 festgelegt ist. Die Mobil-IP, die in dieser Spezifikation bezeichnet ist, schließt Erweiterungen ein, die möglicherweise in der Zukunft festgelegt werden können. Das Format der Mobil-IP ist in den 61 bis 66 gezeigt.
61 zeigt das Format einer Mobil-IP-Nachricht. Der IP-Header und der UDP-Header dieser Nachricht sind in den
62A bzw. 62B gezeigt. TOS (Typ eines Dienstes, Type of Service), eine Quellenadresse, eine Zieladresse, etc. sind in dem IP-Header eingestellt, wohingegen ein Quellenanschluss, ein Zielanschluss, etc. in dem UDP-Header eingestellt sind.
63A zeigt das Format einer Mobil-IP-Registrierungsanforderungsnachricht. Diese Nachricht wird zwischen einem Mobilknoten und einem fremden Vermittler verwendet. 63B zeigt das Format der Registrierungsanforderung innerhalb der Registrierungsanforderungsnachricht. Die Registrierungsanforderung schließt eine Lebensdauer, eine Hausadresse, einen Hausvermittler, eine Care-Of-Adresse, einen Identifizierer, etc. ein, und schließt weiter ein Erweiterungsgebiet ein.
63C zeigt das Format des Erweiterungsgebiets (Mobilknoten-NAI-Erweiterung), das in 63B gezeigt ist. In diesem Erweiterungsgebiet wird der NAI eines Mobilknotens eingestellt. 63D zeigt das Format des Erweiterungsgebiets (vorherige Fremde-Vermittler-Benachrichtigungserweiterung), das in 63B gezeigt ist. In diesem Erweiterungsgebiet sind die Lebensdauer eines Caches, die Adresse eines vorherigen fremden Vermittlers, eine neue Care-Of-Adresse etc. eingestellt.
64A trägt das Format einer Mobil-IP-Registrierungsantwortnachricht. Diese Nachricht wird zwischen einem Mobilknoten und einem fremden Vermittler verwendet. 64B zeigt das Format einer Registrierungsantwort innerhalb der Registrierungsantwortnachricht. Die Registrierungsantwort schließt eine Lebensdauer, eine Hausadresse, einen Hausvermittler, einen Identifizierer, etc. ein, und schließt ferner ein Erweiterungsgebiet ein.
65 zeigt das Format einer Mobil-IP-BU-(Bindungsaktualisierungs-) Nachricht. Diese Nachricht wird zwischen fremden Vermittlern und zwischen einem Hausvermittler und einem Korrespondenzknoten verwendet. 66 zeigt das Format einer Mobil-IP-BA-(Bindungsbestätigungs-) Nachricht. Auch diese Nachricht wird zwischen fremden Vermittlern und zwischen einem Hausvermittler und einem Korrespondenzknoten verwendet.
Das AAA-Protokoll ist nicht sonderlich beschränkt. Jedoch wird angenommen, dass das DIAMETER-Protokoll, das gegenwärtig von der IETF durchgesehen wird, in den Ausführungsformen verwendet wird. Das AAA-Protokoll ist verfügbar für sämtliche Protokolle, die die Information über eine Authentifizierung, eine Autorisierung, eine Abrechnung und Strategien übertragen können. Die Diensteprofilinformation gemäß der vorliegenden Erfindung wird mit einem erweiterbaren Attributparameter übertragen, der als ein AVP (Attributwertpaar) bezeichnet wird, das durch das DIAMETER-Protokoll definiert ist. Das erweiterte Attribut ist die Diensteprofilinformation.
67 zeigt das Format einer DIAMETER-Nachricht. Der gemeinsame Header dieser Nachricht ist in 68 gezeigt. Hier identifiziert ein Identifizierer eindeutig eine Beziehung zwischen einer Registrierungsanforderung und einer Registrierungsantwort.
69A zeigt das grundlegende Format des DIAMETER-AVP (Attributwertpaar, Attribute Value Pair). Wenn der AVP-Code = 256 in diesem fundamentalen Format eingestellt ist, wird ein DIAMETER-Befehl erzeugt. Das Format des DIAMETER-Befehls ist in 69B gezeigt. Der Wert, der einer Nachricht entspricht, wird in einem Befehlscode eingestellt. 69C zeigt das Format eines allgemeinen AVP außer dem DIAMETER-Befehl.
70 zeigt das Format einer AMR-Nachricht des DIAMETER-Protokolls. Diese Nachricht wird zwischen einem fremden Vermittler und einem AAAH-Server verwendet. 71 zeigt das Forma einer HAR-Nachricht des DIAMETER-Protokolls. Diese Nachricht wird zwischen einem AAAH-Server und einem Hausvermittler verwendet.
72 zeigt das Format einer AMA-Nachricht des DIAMETER-Protokolls. Diese Nachricht wird zwischen einem fremden Vermittler und einem AAAH-Server verwendet. 73 zeigt das Format einer HAA-Nachricht des DIAMETER-Protokolls. Diese Nachricht wird zwischen einem AAAH-Server und einem Hausvermittler verwendet.
4. Konfiguration des AAAH
5 ist ein Blockdiagramm, das die Funktionen eines AAAH zeigt. Hier sind Authentifizierungs-, Autorisierungs- und Abrechnungsfunktionen weggelassen.
Ein AAAH 100 extrahiert aus einer Dienstesteuerdatenbank 300 ein Diensteprofil, das einem Benutzer entspricht, der eine Authentifizierungsanforderung, beispielsweise auf den Empfang einer Authentifizierungsanforderungs-(AMR)-Nachricht hin ausgibt, und verteilt das extrahierte Diensteprofil zu einem HA und einem FA. Der AAAH wirkt nämlich als ein Server in einem System, das einen Mobilkommunikationsdienst bereitstellt.
Der AAAH 100 umfasst eine Diensteverwaltungseinheit 102 und eine Protokollsteuereinheit 101. Die Protokollsteuereinheit 101 erzeugt eine Sitzungstransaktion zum Verwalten einer DIAMETER-Sitzung. Die Diensteverwaltungseinheit 102 erzeugt ein Diensteprofil durch ein Referenzieren auf die Dienstesteuerdatenbank 300. Überdies umfasst die Diensteverwaltungseinheit 102 die Verwaltungstabelle zum Verwalten einer bestimmten Gruppe, um einen Dienst bereitzustellen. Hier umfasst die Diensteverwaltungseinheit 102 beispielsweise eine ANYCAST-Adressverwaltungstabelle als eine Verwaltungstabelle.
6 veranschaulicht beispielhaft die Originaldaten eines Diensteprofils, das in der Dienstesteuerdatenbank 300 gespeichert ist. In der Dienstesteuerdatenbank 300 ist die Teilnehmerinformation jedes Benutzers (einschließlich eines Diensteprofils) unter Verwendung des NAI eines Benutzers als ein Schlüssel gespeichert. Als eine SLA (Service Level Agreement (Dienstepegelübereinstimmung): eine Vertragsbedingung eines Teilnehmers) sind beispielsweise die Dienstequalitäten, die in 7 gezeigt sind, das Abrechnungsverfahren, das in 8 gezeigt ist, die Restriktionsbedingungen, die in 9 gezeigt sind, etc. eingestellt. Als ein Individualdienst kann beispielsweise Diff-Serv, eine Paketfilterung, ANYCAST, Multicast, etc. eingestellt werden. Hier ist das Profil für den Diff-Serv-Dienst in 10 gezeigt, und das Profil für den ANYCAST-Dienst ist in 11 gezeigt.
12 veranschaulicht beispielhaft das Diensteprofil, das durch die Diensteverwaltungseinheit 102 des AAAH 100 erzeugt wird. Dieses Diensteprofil wird durch ein Editieren der Daten erhalten, die aus der Dienstesteuerdatenbank 300 extrahiert werden, und zu einem HA und einem FA verteilt.
Das Diensteprofil besteht aus einem Profilidentifizierer, einer Zielpaket-Steuerinformation, einer Routing/Paketeditierinformation und einer individuellen Steuerinformation. Der Profilidentifizierer ist ein Wert zum eindeutigen Identifizieren eines Diensteprofils in einem Netz. Die Zielpaket-Steuerinformation ist eine Filterinformation zum Klassifizieren eines empfangen Pakets. Die Routing/Paketeditierinformation ist eine Editierinformation eines IP-Headers, der auf das Paket angewandt wird, das die Zielpaket-Steuerinformation trifft, und eine Information, die das Sendeziel des Pakets anzeigt. Die einzelne Steuerinformation zeigt eine Dienste-spezifische Steuertabelle an, die von einer Dienste-unabhängigen Einheit verarbeitet wird, und muss als nächstes für das Paket gesucht werden, das die Dienstepaket-Steuerinformation trifft.
(1) Profilidentifizierer
Ein "Profilidentifizierer" besteht aus einem Sitzungsidentifizierer und einer Profilnummer. Der Sitzungsidentifizierer ist ein Sitzungs-ID, wohingegen die Profilnummer ein Wert ist, der jeder Sitzung eindeutig zugewiesen ist. Der Profilidentifizierer ist durch jeweilige Einheiten (AAAH, AAAF, HA, FA, etc.) geteilt und wird verwendet, um ein Diensteprofil zu bestimmen, das sich auf eine Benutzersitzung bezieht, und um einen spezifischen Dienst innerhalb einer Benutzersitzung zu identifizieren. Als ein Sitzungs-ID wird beispielsweise ein Sitzungs-ID, der in einer DIAMETER-Sitzung-ID-AVP verwendet wird, benutzt. Der Sitzungs-ID wird unter Verwendung des NAI eines Mobilknotens wie folgt in dieser Ausführungsform dargestellt.
<NAI von MN><31-Bit-Wert)<Option>
(2) Zielpaket-Steuerinformation
Eine "Zielpaket-Steuerinformation" besteht aus der IP-Adresse einer Übertragungsquelle, der IP-Adresse eines Ziels, der Anschlussnummer der Übertragungsquelle und der Anschlussnummer des Ziels. Wenn ein Teil der Bits der IP-Adresse auf "egal" eingestellt ist, wird dieses Teil durch einen Platzhalter "*" wie folgt dargestellt.
172.27.180.*
172.27.*.*
Es ist nicht notwendig, sämtliche dieser vier Werte einzustellen. Wenn ein empfangenes Paket gemäß einer Zielpaket-Steuerinformation extrahiert wird, wird ein auftretender Treffer beispielsweise unter der Bedingung erkannt, dass sämtliche Einstellwerte zu sämtlichen entsprechenden Werten passen, die in dem empfangenen Paket eingestellt sind.
(3) Routing/Paketeditierinformation
Ein "Einkapselungs-(Verschlüsselungs-)-Verfahren" spezifiziert ein Einkapselungsverfahren, das auszuführen ist, wenn ein Paket nicht durch eine Dienste-unabhängige Funktion eingekapselt wird. Die Information zum Einkapseln eines Pakets durch eine Dienste-unabhängige Funktion ist in einem HA oder einem FA eingestellt.
Eine "Übertragungszieladresse" spezifiziert eine Zieladresse, wenn ein Paket nicht durch die Dienste-unabhängige Funktion übertragen wird. Eine Mehrzahl von Adressen kann als eine "Übertragungszieladresse" spezifiziert werden. Zusätzlich wird, wenn ein Paket zu der Care-Of-Adresse eines Mobilknotens übertragen wird, die Paketübertragung gemäß einer Mobilitätsbindungstabelle, die später zu beschreiben ist, ausgeführt.
Ein "TOS" spezifiziert einen Wert, der in das TOS-Feld des Pakets einzuschreiben ist, das von dem HA oder dem FA empfangen wird. Wenn dieser Wert spezifiziert ist, werden der IP-Header des Pakets, das die oben beschriebenen Zielpaket-Steuerinformation trifft, und jener des Pakets, das von der Dienste-unabhängigen Funktion editiert ist (wie etwa ein Paket, das durch ein Referenzieren auf die Mobilitätsbindungstabelle eingekapselt ist), wieder eingeschrieben.
Eine "Entkapselungsinstruktion" spezifiziert, ob ein Paket, das die oben beschriebenen Zielpaket-Steuerinformation trifft, wenn es eingekapselt ist, zu entkapseln ist oder nicht. Der Entkapselungsprozess wird ausgeführt, bevor eine individuelle Steuertabelle gesucht wird.
4. Individuelle Steuerinformation
Eine "individuelle Steuerinformation" besteht aus einer Dienstesteuertyp-Information und einem Steuerinformationsidentifizierer. Die Dienstesteuertypinformation ist vorgesehen, die Steuertabelle, auf die von dem HA oder dem FA zuzugreifen ist, zu instruieren. Die Steuertabelle, die in dem HA oder dem FA angeordnet ist, ist beispielsweise ein Diensteprofil-Cache, Steuerdaten, die spezifisch für die Mobil-IP sind (Einbindungs-Cache, eine Mobilitätsbindung, eine Besucherliste), eine Routingtabelle und Dienste-spezifische Steuerdaten (eine ANYCAST-Tabelle, etc.). Der Steuerinformationsidentifizierer zeigt das Verbindungsziel der Steuertabelle, auf die gemäß der Dienstesteuertypinformation zugegriffen wird, an. Der Steuerinformationsidentifizierer ist beispielsweise ein Identifizierer zum Identifizieren oder ein Zeiger, der auf einen Eintrag in jeder Steuertabelle zeigt.
Der AAAH 100 erzeugt das Diensteprofil, das in 12 gezeigt ist, auf der Grundlage der Originaldaten des Diensteprofils, das in den 6 bis 11 gezeigt ist. Ein Verfahren zum Erzeugen eines Diensteprofils ist nicht sonderlich eingeschränkt. Jedoch kann ein Diensteprofil auf der Grundlage des Typs und des Inhalts eines Dienstes erzeugt werden, der von einem Benutzer angefordert wird. Beispielsweise können, wenn ein Benutzer den Diff-Serv-Dienst anfordert, die IP-Adresse, die Anschlussnummer, etc., die in 10 gezeigt sind, in der Zielpaket-Steuerinformation eingestellt werden. Zusätzlich kann das TOS auf der Grundlage eines Suchausdrucks und einer Diensteklasse einer Diff-Serv-Strategie eingestellt werden. Oder, wenn ein ANYCAST-Dienst angefordert wird, kann eine ANYCAST-Tabelle in der Dienstesteuertypinformation spezifiziert werden, und gleichzeitig kann eine Zielpaket-Steuerinformation auf der Grundlage einer ANYCAST-Adresse eingestellt werden.
Wie oben beschrieben, ist das Diensteprofil immer in dem gleichen Format ungeachtet des Typs eines Dienstes, der für einen Benutzer bereitzustellen ist. Die Gesamtinformation zum Bereitstellen eines Individualdienstes ist nämlich in dem in
12 gezeigten Format gespeichert und wird zu dem HA und dem FA verteilt.
13 veranschaulicht beispielhaft eine ANYCAST-Adressverwaltungstabelle, die in dem AAAH 100 angeordnet ist. Diese Tabelle ist in Einheiten von ANYCAST-Adressblöcken konfiguriert. Jeder der Blöcke schließt eine ANYCAST-Adresse, eine oder mehrere NAIs, die der ANYCAST-Adresse entsprechen, die Hausadresse des Endgeräts, das von jedem NAI identifiziert ist, und den Zustand des Endgeräts, das durch den NAI identifiziert ist, ein. Der Zustand des Endgeräts ist beispielsweise ein Online-, ein Offline-, ein anhängiger, ein Fehler-, ein Stau-Zustand, etc.
14 veranschaulicht beispielhaft die Sitzungstransaktion des AAAH. Die Sitzungstransaktion wird erzeugt und gehalten, um eine DIAMETER-Nachricht zu senden/zu empfangen, und um die Verbindung mit einem Diensteprofil aufrechtzuerhalten. Die Sitzungstransaktion des AAAH schließt einen Sitzungs-ID, eine HA-Adresse, die Adresse des gegenwärtigen AAAF, die Adresse des AAAF, der eine AMR-Nachricht sendet, eine Sicherheitsinformation, einen Sitzungszeitgeber und Diensteprofile ein.
5. Konfiguration des AAAF
15 ist ein Blockdiagramm, das die Funktionen eines AAAF zeigt. Auf einen Empfang einer Authentifizierungsanforderungs-(AMR)-Nachricht von einem Mobilknoten schickt ein AAAF 400 diese Nachricht zu einem AAAH 100. Auf den Empfang eines Diensteprofils von dem AAAH 100 hin verteilt der AAAF 400 das Diensteprofil zu einem FA 500. Der AAAF 400 kann auch einen HA spezifizieren. In diesem Fall verteilt der AAAF 400 das Diensteprofil zu einem HA 200 und dem FA 500 auf einen Empfang des Diensteprofils von dem AAAH 100 hin.
Der AAAF 400 umfasst eine Protokollsteuereinheit 401. Die Protokollsteuereinheit 401 erzeugt eine Sitzungstransaktion zum Verwalten einer DIAMETER-Sitzung. Die Sitzungstransaktion des AAAF schließt einen Sitzungs-ID, eine AAAH-Adresse, HA-Adresse, den NAI eines vorherigen FA, den NAI eines gegenwärtigen FA, eine Sicherheitsinformation, einen Sitzungszeitgeber, ein Diensteprofil und einen Transaktionszustand ein, wie in 16 gezeigt.
Es sei darauf hingewiesen, dass der AAAF grundsätzlich die gleiche Konfiguration wie jene des AAAH aufweist. Dementsprechend wirkt der AAAF als ein Server in einem System, das einen Mobilkommunikationsdienst ähnlich dem AAAH bereitstellt.
6. Konfigurationen des HA, FA und CN
17 ist ein Blockdiagramm, das die Funktionen eines HA, eines FA und eines CN zeigt. Die HA, FA und CN weisen grundsätzlich die gleiche Konfiguration auf, und umfassen jeweils eine Paketsteuereinheit 201, eine Protokollsteuereinheit 202, eine Individualdienst-Steuereinheit 203 und eine Dienste-unabhängige Funktionseinheit 204 auf.
Die Paketsteuereinheit 201 weist die Funktion zum Filtern eines Pakets auf und klassifiziert empfangene Pakete in ein Protokollpaket und ein Datenpaket durch ein Decodieren des Headers jedes Pakets. Auf einen Empfang eines Protokollpakets hin fordert die Paketsteuereinheit 201 die Protokollsteuereinheit auf, das Paket zu verarbeiten. Auf ein empfangenes Datenpaket hin leitet die Paketsteuereinheit 201 die Information, die zum Verarbeiten des Pakets erforderlich ist, zu der Individualdienst-Steuereinheit 203 durch. Die Paketsteuereinheit 201 editiert die Pakete (schreibt ihre Header wieder ein, etc.) und schickt die Pakete gemäß den Instruktionen von der Individualdienst-Steuereinheit 203 und der Dienste-unabhängigen Funktionseinheit 204.
Die Protokollsteuereinheit 202 ist eine Einheit, die die Mobil-IP und das DIAMETER-Protokoll verarbeitet, und setzt eine notwendige Information (wie etwa die Information für eine Ortsregistrierung, etc.) in die Dienste-unabhängige Funktionseinheit 204 in Übereinstimmung mit dem Protokoll. Zusätzlich erzeugt die Protokollsteuereinheit 202 eine Sitzungstransaktion zum Verwalten einer DIAMETER-Sitzung. Die Sitzungstransaktion des HA und des FA ist in 18 gezeigt. Überdies speichert, wenn ein Diensteprofil von einem AAA übermittelt wird, die Protokollsteuereinheit 202 das Diensteprofil in dem Diensteprofil-Cache der Individualdienst-Steuereinheit 203.
Die Individualdienst-Steuereinheit 203 umfasst eine Diensteprofil-Cache 211, der ein Satz einer Dienstesteuerinformation ist, und eine Suchstrategie-Verwaltungstabelle 212, in welcher die Strategie zum Suchen des Diensteprofil-Caches 211 eingestellt ist.
19 veranschaulicht beispielhaft den Diensteprofil-Cache 211. Der Diensteprofil-Cache besteht aus einem individuellen Knoten-SPC (NSPC) und einem AAA-übermittelten SPC (ASPC). Der individuelle Knoten-SPC ist ein Diensteprofil-Cache, den der HA, der FA oder der CN zuvor umfasst, und besteht aus einem Quellendiensteprofil (NSPCsrc), einem Quellen-Vorbesetzt-Diensteprofil (NDSPsrc), einem Zieldiensteprofil (NSPCdst), einem Ziel-Vorbesetzt-Diensteprofil (NDSPdst) und einem Vorbesetzt-Diensteprofil (NDSP). Unterdessen ist der AAA-übermittelte SPC ein Diensteprofil-Cache, der von dem AAAH verteilt ist, und besteht aus einem Quellenprofil (ASPCsrc) und einem Zieldiensteprofil (ASPCdst). Die Diensteprofile sind wechselseitig unabhängig.
Die Diensteprofile werden in das in 12 gezeigte Format eingeschrieben. Jedes der Diensteprofile schließt nämlich (1) die Information (Zielpaket-Steuerinformation) zum Extrahieren eines bestimmten Pakets aus empfangenen Paketen, (2) die Information (Routing/Paketeditierinformation) zum Editieren eines extrahierten Pakets und (3) die Information (individuelle Steuerinformation) zum Referenzieren auf Korrespondenztabellen, die in der Dienste-unabhängigen Einheit 204 angeordnet sind, ein. 12 zeigt das Diensteprofil, das von dem AAA zu dem HA oder dem FA verteilt wird. Das Diensteprofil, das als ein individueller Knoten-SPC zuvor in dem HA oder dem FA angeordnet ist, weist auch die gleiche Konfiguration auf. Wenn der AAAH die Originaldaten eines Diensteprofils aus der Dienstesteuerdatenbank extrahiert, editiert er nämlich die Originaldaten in das gleiche Format wie jenes des Diensteprofils, das in dem HA oder dem FA zuvor angeordnet ist, und verteilt das Diensteprofil zu dem HA oder dem FA.
In der Zielpaket-Steuerinformation des Quellen-SPC (NSPCsrc und ASPCsrc) und des Quellen-Vorbesetzt-SP (NDSPsrc) ist zumindest entweder die Quellenadresse oder die Quellenanschlussnummer eingestellt. Dementsprechend wird das Paket, das von einer bestimmten Übertragungsquelle oder einem Quellenanschluss übertragen wird, gemäß dem Diensteprofil verarbeitet. Überdies ist zumindest entweder die Zieladresse oder die Zielanschlussnummer in der Zielpaket-Steuerinformation des Ziel-SPC (NSPCdst und ASPCdst) und der Ziel-Vorbesetzt-SP (NDSPdst) eingestellt. Deswegen wird das Paket, das zu einem bestimmten Ziel oder Zielanschluss vorrückt, gemäß dem Diensteprofil verarbeitet. Das Vorbesetzt-SP (NDSP) ist angeordnet, das Paket zu verarbeiten, das nicht gemäß einem der obigen Diensteprofile verarbeitet ist.
Wenn ein Datenpaket die Paketsteuereinheit 201 erreicht, bestimmt die Individualdienst-Steuereinheit 203 das Diensteprofil zum Verarbeiten des Pakets. Das Verfahren zum Auswählen eines vorbestimmten Diensteprofils aus dem Diensteprofil-Cache 211 ist in einer Suchstrategie-Verwaltungstabelle 212 beschrieben.
20 veranschaulicht beispielhaft die Suchstrategie-Verwaltungstabelle 212. Die Suchstrategie-Verwaltungstabelle 211 verwaltet eine Suchstrategie (Suchreihenfolge) zum Durchsuchen des Diensteprofil-Caches 211. Die Suchstrategie ist nicht sonderlich beschränkt. Jedoch ist sie so geschrieben, dass ein Suchbereich erweitert ist, beispielsweise von einem Dienste-spezifischen Profil zu einem geteilten Diensteprofil.
Wenn der Diensteprofil-Cache 211 mit der Suchstrategie-Verwaltungstabelle 212, die in 20 gezeigt ist, durchsucht wird, wird die Zielpaket-Steuerinformation des Quellen-SPC (ASPCsrc), die von einem AAA verteilt ist, zuerst extrahiert. Dann werden die Quellenadresse und die Quellenanschlussnummer, die in der Zielpaket-Steuerinformation eingestellt sind, jeweils mit der Quellenadresse und der Quellenanschlussnummer innerhalb eines empfangenen Pakets verglichen. Wenn diese Adressen und Anschlussnummern jeweils zu dieser Zeit zueinander passen, wird die Tabelle der Dienste-unabhängigen Einheit 204 gemäß dem Quellen-SPC (ASPCscr) referenziert. Wenn die entsprechende Information in der referenzierten Tabelle gespeichert ist, wird das empfangene Paket gemäß dieser Information verarbeitet. Wenn die entsprechende Information nicht in der referenzierten Tabelle gespeichert ist, wird der Prozess beendet, indem erkannt wird, dass ein Fehler auftritt. Wenn zumindest entweder die Quellenadressen oder die Quellenanschlussnummern nicht zueinander passen, wird der Quellen-SPC (NSPCsrc), der in dem HA, dem FA oder dem CN voreingestellt ist, extrahiert.
Der Prozess, der durchgeführt wird, wenn der Quellen-SPC (NSPCsrc) extrahiert ist, ist grundsätzlich der gleiche wie jener, der durchgeführt wird, wenn der Quellen-SPC (ASPCsrc), der von dem AAA verteilt ist, extrahiert wird. Wenn die Quellenadressen und die Quellenanschlussnummern jeweils zueinander passen, wird nämlich ein empfangenes Paket durch ein Referenzieren auf die Tabelle der Dienste-unabhängigen Einheit gemäß des Quellen-SPC (NSPCsrc) verarbeitet. Wenn eine entsprechende Information in der Tabelle der Dienste-unabhängigen Einheit 204 nicht gespeichert ist, obwohl die Quellenadressen und die Quellenanschlussnummern jeweils zueinander passen, wird ein Quellen-Vorbesetzt-SP (NDSPsrc) extrahiert.
Der oben beschriebene Prozess wird auf eine ähnliche Weise bis zu dem Diensteprofil wiederholt, bei welchem die gleiche Adresse und Anschlussnummer wie jene des empfangenen Pakets gefunden werden, gemäß der Suchstrategie-Verwaltungstabelle 212. Wenn das entsprechende Diensteprofil trotz der Ausführung der Prozedurschritte 1 bis 4 in der Suchstrategie-Verwaltungstabelle 212, die in 20 gezeigt ist, nicht gefunden werden kann, wird ein Vorbesetzt-SP (NDSP) in dem Prozedurschritt 5 extrahiert. Das Paket wird dann gemäß dem Vorbesetzt-SP (NDSP) verarbeitet.
Wie oben beschrieben wird das Diensteprofil, bei welchem die gleiche Adresse und Anschlussnummer wie jene eines Datenpakets eingestellt sind, auf ein Eintreffen des Datenpakets hin extrahiert, und das Datenpaket wird gemäß dem Diensteprofil verarbeitet. Zu dieser Zeit können der HA, der FA und der CN das empfangene Paket nur durch ein Referenzieren auf die Tabelle der Dienste-unabhängigen Einheit 204 gemäß der Dienstedatei, die von einem AAA verteilt ist, oder einem zuvor angeordneten Diensteprofil verarbeiten. Der HA, der FA und der CN können nämlich einen Individualdienst für jeden Benutzer bereitstellen, der in der Dienstesteuerdatenbank 300 gespeichert ist, indem das Diensteprofil, das von dem AAA verteilt ist, unverändert verwendet wird.
Die Dienste-unabhängige Einheit 204 umfasst eine Besucherliste, eine Mobilitätsbindung, einen Bindungs-Cache, eine ANYCAST-Tabelle und eine Routingtabelle. Die Besucherliste, die Mobilitätsbindung und der Bindungs-Cache unter diesen Tabellen sind Steuertabellen zum Verwalten der Mobil-IP. Die Routingtabelle ist eine Paketsteuertabelle, die ein Router ursprünglich umfasst. Die ANYCAST-Tabelle ist eine Steuertabelle, die angeordnet ist, einen ANYCAST-Dienst, der ein Mehrwertdienst ist, auszuführen.
21 veranschaulicht beispielhaft die Besucherliste. Die Besucherliste, die in dem FA angeordnet ist, ist eine Tabelle zum Ausführen einer Entsprechung zwischen der IP-Adresse (Hausadresse) eines Mobilknotens und der Verbindungsschichtadresse (wie etwa einer MAC-Adresse) des Mobilknotens.
22 veranschaulicht beispielhaft die Mobilitätsbindung. Die Mobilitätsbindung, die in dem HA angeordnet ist, ist eine Tabelle zum Ausführen einer Entsprechung zwischen der IP-Adresse (Hausadresse) eines Mobilknotens und der Adresse (Care-Of-Adresse) des FA, der den Mobilknoten aufnimmt. Die Mobilitätsbindung wird referenziert, wenn der HA das Paket, das an den Mobilknoten adressiert ist, empfängt. In diesem Fall wird die Care-Of-Adresse, die der IP-Adresse des Pakets entspricht, extrahiert, und das Paket wird eingekapselt und zu dem FA geschickt, der die extrahierte Care-Of-Adresse aufweist. Es sei darauf hingewiesen, dass die Mobilitätsbindung beispielsweise aktualisiert wird, wenn sich der Mobilknoten von dem Kommunikationsgebiet eines FA zu jenem eines anderen bewegt.
23 veranschaulicht beispielhaft den Bindungs-Cache. Der Bindungs-Cache, der in dem FA und dem CN angeordnet ist, ist eine Routing-Tabelle, die vorübergehend verwendet wird, um die Übertragungseffizienz eines Pakets zu verbessern. Dem Bindungs-Cache wird eine höhere Referenzpräzedenz gegeben als jener der Routingtabelle.
24 veranschaulicht beispielhaft die ANYCAST-Tabelle. Die ANYCAST-Tabelle, die in dem FA angeordnet ist, speichert die Information, die erforderlich ist, um einen ANYCAST-Dienst bereitzustellen. Die ANYCAST-Tabelle wird beispielsweise erhalten, indem zusätzlich eine ANYCAST-Adresse und die Adresse eines Adress-Proxy-Servers registriert werden, der die ANYCAST-Adresse aufweist.
25 veranschaulicht beispielhaft die Routingtabelle. Die Routingtabelle, die in dem HA, dem FA und dem CN angeordnet ist, wird verwendet, um die nächste Sprungadresse (wie etwa den nächsten Router) als ein Übertragungsziel zu erhalten, zu welchem ein Paket auf der Grundlage der Zieladresse, die in dem Header des empfangenen Pakets gespeichert ist, zu übertragen ist.
7. Sequenz zum Verteilen von Diensteprofilen
Das Wesen eines IP-Dienstes verdichtet sich auf eine Zielpaketauswahl, ein Paketeditieren und eine Routing-Ziel-Bestimmung. Gemäß der vorliegenden Erfindung wird der Editierprozess einer Dienstesteuerinformation für jeden Dienst durch einen AAAH ausgeführt, und eine verallgemeinerte Paketeditierfunktion wird zu einem mobilen Vermittler (wie etwa einem FA) verteilt. Folglich kann der mobile Vermittler das verteilte Diensteprofil als eine Paketsteuerinformation unverändert verwenden, was zu einer Beschleunigung des Prozesses führt.
Zusätzlich werden gemäß der vorliegenden Erfindung die Konfiguration eines Diensteprofil-Caches, der ein Satz von Diensteprofilen ist, und ein Verfahren zum Durchsuchen des Diensteprofil-Caches systematisiert. In dem HA und dem FA gemäß der vorliegenden Erfindung sind die Dienste-unabhängige Einheit, die eine Paketsteuerung auf der Grundlage der Mobil-IP durchführt, und die Individualdienst-Steuereinheit, die die Dienste-unabhängige Einheit auf der Grundlage eines Dienstesatzes für jeden Benutzer verwendet, getrennt. Dementsprechend ist beispielsweise, wenn ein Dienst hinzugefügt/geändert wird, kein grundsätzlicher Bedarf vorhanden, das Programm oder die Daten der Dienste-unabhängigen Einheit wieder einzuschreiben, und der einzige Betriebsschritt, der durchgeführt werden muss, besteht darin, die Einstellungen der Individualdienst-Steuereinheit zu aktualisieren. Das heißt, dass erwartet wird, dass eine Diensthinzufügung, -Änderung, -Implementierung etc. einfach werden.
Überdies ist gemäß der vorliegenden Erfindung ein Diensteprofil-Verwaltungsverfahren, das eine Dienstesteuerung innerhalb des Rahmens der Nachrichten, die durch die vorhandene Mobil-IP festgelegt sind, entwickelt.
Nachstehend wird der Fall, wo der Diff-Serv-Dienst auf die Mobil-IP angewandt wird, als eine Ausführungsform eingesetzt.
In den Ausführungsformen gemäß der vorliegenden Erfindung kann ein HA entweder durch einen AAAH oder durch einen AAAF spezifiziert werden. Untenstehend beschrieben sind der Fall (A), wo ein AAAH einen HA spezifiziert, und der Fall (B), wo ein AAAF einen HA spezifiziert.
7A. Fall, wo ein AAAH einen HA spezifiziert
In der folgenden Ausführungsform sind (1) die Sequenz zu der Zeit einer Anfangsregistrierung, (2) die Sequenz in dem Fall, wo sich ein Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines bestimmten AAAF zu jenem eines anderen FA bewegt, und (3) die Sequenz in dem Fall, wo sich ein Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines AAAF zu jenem eines FA innerhalb eines anderen AAAF bewegt, beschrieben.
7A (1) Sequenz zu der Zeit einer Anfangsregistrierung
26 zeigt die Sequenz zum Verteilen von Diensteprofilen. Veranschaulicht ist hier die Sequenz, nachdem die Ankündigungsnachricht, die ein FA 500 periodisch ausgibt, von einem Mobilknoten 600 empfangen wird. In dieser Figur zeigen Nachrichten, auf die ein "*" folgt, an, dass ein Diensteprofil angehängt ist.
Der Mobilknoten 600 sendet eine Registrierungsanforderungs-(Reg-Req)-Nachricht zu dem FA 500. Auf einen Empfang der Registrierungsanforderungs-(Reg-Req)-Nachricht hin sendet der FA 500 eine Authentifizierungsanforderungs-(AMR)-Nachricht zu einem AAAF 400. Auf einem Empfang einer Authentifizierungsanforderungs-(AMR)-Nachricht hin schickt der AAAF 400 diese Nachricht zu einem AAAH 100 des Mobilknotens 600. Auf einen Empfang der Authentifizierungsanforderungs-(AMR)-Nachricht hin extrahiert der AAAH 100 die Originaldaten des Diensteprofils des Mobilknotens 600 aus einer Dienstesteuerdatenbank 300 und editiert die Daten in ein Format, das für einen HA 200 und den FA 500 unverändert verfügbar ist. Der AAAH 100 sendet dann das editierte Diensteprofil unter Verwendung einer Registrierungsanforderungs-(HAR)-Nachricht zu dem HA 200. Folglich erzeugt der HA 200 eine Mobilitätsbindung (die die Information einschließt, die anzeigt, dass der Mobilknoten 600 durch den FA 500 aufgenommen ist) und fügt das empfangene Diensteprofil einem Diensteprofil-Cache gleichzeitig hinzu.
Dann sendet der HA 200 eine Registrierungsantwort-(HAA)-Nachricht zu dem AAAH 100. Auf den Empfang der Registrierungsantwort-(HAA)-Nachricht hin sendet der AAAH 100 das Diensteprofil zu dem AAAF 400 unter Verwendung einer Authentifizierungsantwort-(AMA)-Nachricht. Auf den Empfang der Authentifizierungsantwort-(AMA)-Nachricht hin sendet der AAAF 400 das Diensteprofil zu dem FA 500 unter Verwendung der Authentifizierungsantwort-(AMA)-Nachricht. Folglich erzeugt der FA 500 eine Besucherliste (die die Information einschließt, die anzeigt, dass der Mobilknoten 600 von dem FA 500 aufgenommen ist), und fügt das empfangene Diensteprofil einem Diensteprofil-Cache hinzu. Dann gibt der FA 500 eine Registrierungsantwort-(Reg-Resp)-Nachricht zu dem Mobilknoten 600 zurück.
Wie oben beschrieben, wird das Diensteprofil, das den Individualdienst für den Mobilknoten 600 anzeigt, zu dem HA 200 und dem FA 500 verteilt, wenn die Ortsregistrierungssequenz des Mobilknotens 600 ausgeführt wird. Dementsprechend kann der Mobilknoten 600 den Individualdienst, der zuvor ausgehandelt ist, empfangen, während er von dem FA 500 aufgenommen ist.
Als nächstes wird die oben beschriebene Sequenz im Detail erläutert. Zunächst sei angenommen, dass die Diensteprofile jeweils in den Diensteprofil-Caches erzeugt und gespeichert werden, wenn der HA und der FA anfänglich konfiguriert werden, wie in 27 gezeigt. Zusätzlich werden Routingtabellen durch ein Netzverwaltungssystem oder ein Routingprotokoll eingestellt. Da ein Verfahren zum Erzeugen einer Routingtabelle die vorliegende Erfindung nicht direkt betrifft, ist ihre Erläuterung hier weggelassen.
Die 28A und 28B veranschaulichen beispielhaft die Diensteprofile, die von dem FA zu der Zeit einer Anfangskonfiguration erzeugt werden. Das in 28A gezeigte Diensteprofil stellt dar, dass die Routingtabelle referenziert wird, wenn die Route eines empfangenen Pakets bestimmt wird. Das Diensteprofil, das in 28B gezeigt ist, stellt dar, dass der Cache, der in 28A gezeigt ist, referenziert wird, nachdem ein Entkapselungsprozess ausgeführt ist, auf den Empfang eines Pakets hin, bei welchem der FA 500 als eine Zieladresse eingestellt ist.
29 veranschaulicht beispielhaft das Diensteprofil, das durch den HA zu der Zeit einer Anfangskonfiguration erzeugt wird. Dieses Diensteprofil stellt dar, dass die Routingtabelle referenziert wird, wenn die Route eines empfangenen Pakets bestimmt wird.
30 zeigt die Prozedur zum Erzeugen eines Diensteprofils durch den AAAH.

(1)–(4) Auf einen Empfang der Registrierungsanforderungsnachricht, die von dem Mobilknoten 600 übertragen wird hin, erzeugt der FA 500 eine DIAMETER-Sitzungstransaktion und eine Besucherliste. Die DIAMETER-Sitzungstransaktion und die Besucherliste sind beispielsweise die in den 18 und 21 gezeigten. Der FA 500 sendet dann eine Registrierungsanforderung (AMR: AA-Mobilknoten-Anforderung)-Nachricht zu dem AAAF 400.
(5)–(6) Der AAAF 400 erzeugt eine DIAMETER-Sitzungstransaktion. Diese Transaktion ist beispielsweise die in 16 gezeigte. Dann identifiziert der AAAF 400 den Authentifizierungs-Hausserver (AAAH 100) des Benutzers des Mobilknotens 600 auf der Grundlage des Netzidentifizierers (NAI) des Benutzers, der durch die AMR-Nachricht benachrichtigt wird, und schickt die AMR-Nachricht zu dem identifizierten AAAH 100.
(7)–(9) Der AAAH 100 erzeugt eine DIAMETER-Sitzungstransaktion. Diese Transaktion ist beispielsweise die in 14 gezeigte. Der AAAH 100 sucht dann die Dienstesteuerdatenbank unter Verwendung des NAI des Benutzers als ein Schlüssel, der durch die AMR-Nachricht benachrichtigt wird, und extrahiert die Originaldaten des Diensteprofils dieses Benutzers. Überdies erzeugt der AAAH 100 ein Diensteprofil, das in dem HA 200 und dem FA 500 einzustellen ist, auf der Grundlage der Information, die in den Originaldaten des Diensteprofils eingestellt ist, und einer Strategie, die vorbestimmt ist, um ein Diensteprofil zu editieren.

Das Diensteprofil fällt unter zwei Typen: ein Zieldiensteprofil, dessen Suchbedingung eine Zielinformation ist (wie etwa eine Zieladresse und eine Zielanschlussnummer), und ein Quellendiensteprofil, dessen Suchbedingung eine Quelleninformation ist (wie etwa eine Quellenadresse und eine Quellenanschlussnummer). Als ein Identifizierer jedes Diensteprofils sind ein Sitzungs-ID und eine beliebige Profilnummer eingestellt. Überdies kann das Diensteprofil beispielsweise unter den folgenden Bedingungen verwaltet werden: (1) wenn sowohl die Zielinformation als auch die Quelleninformation als Suchinformation verwendet werden, werden sie in ein Quellendiensteprofil gesetzt; (2) das Quellendiensteprofil und das Zieldiensteprofil werden für jeden Dienstetyp, der bereitzustellen ist, erzeugt; und (3) das Quellendiensteprofil wird mit einer höheren Präzedenz als das Zieldiensteprofil angewandt.
Die 31A und 31B veranschaulichen beispielhaft die Diensteprofile, die zu dem HA zu verteilen sind. Das Diensteprofil, bei welchem eine Zielinformation als eine Suchbedingung eingestellt ist, ist in 31A gezeigt, wohingegen das Diensteprofil, bei welchem eine Quelleninformation als eine Suchbedingung eingestellt ist, in 31B gezeigt ist.
Die 32A und 32B veranschauliche beispielhaft die Diensteprofile, die zu dem FA zu verteilen sind. Das Diensteprofil, bei welchem eine Zielinformation als eine Suchbedingung eingestellt ist, ist in 32A gezeigt, wohingegen das Diensteprofil, bei welchem eine Quelleninformation als eine Suchbedingung eingestellt ist, in 32B gezeigt ist.
Diese Diensteprofile werden auf der Grundlage der Information, die in den Originaldaten der Diensteprofile eingestellt ist, und der Strategie erzeugt, die vorbestimmt ist, um ein Diensteprofil zu editieren, wie oben beschrieben. Wenn das Diensteprofil (siehe 31A) für den Benutzer, der den Diff-Serv-Dienst anfordert, der zu dem HA zu verteilen ist, erzeugt wird, werden beispielsweise die Adresse und die Anschlussnummer des Mobilknotens, den der Benutzer verwendet, jeweils als eine Zieladresse und eine Zielanschlussnummer eingestellt. Zusätzlich wird der TOS-Wert, der zu der Zeit einer Subskription an dem Diff-Serv-Dienst bestimmt wird, in "TOS" eingestellt. Überdies wird eine Mobilitätsbindungstabelle in einer "individuellen Steuerinformation" eingestellt, um so das Paket, das an den Mobilknoten adressiert ist, zu dem FA zu schicken, der den Mobilknoten aufnimmt.
33 zeigt die Prozedur zum Einstellen von Diensteprofilen in dem HA.

(10) Der AAAH 100 bringt ein Zieldiensteprofil (MN-HAdest) und ein Quellendiensteprofil (MN-HAsrc) an einer Registrierungsanforderungs-(HAR: Hausvermittler-MIP-Anforderung)-Nachricht an und sendet diese Nachricht zu dem HA 200.
(11)–(12) Der HA 200 erzeugt eine DIAMETER-Sitzungstransaktion und fügt die übermittelten Diensteprofile dem Diensteprofil-Cache gleichzeitig hinzu. Diese Transaktion ist beispielsweise die in 18 gezeigte. Zusätzlich erzeugt der HA 200 eine Mobilitätsbindung auf der Grundlage der Information, die in der HAR-Nachricht eingestellt ist. Die Mobilitätsbindung ist beispielsweise die in 22 gezeigte. Dann wird die Information zum Verbinden mit der erzeugten Mobilitätsbindung als ein "Steuerinformationsidentifizierer" des Zieldiensteprofils (MN-HAdest) eingestellt.

34 veranschaulicht beispielhaft die Prozedur zum Übertragen von Diensteprofilen zu dem AAAF.

(13) Auf eine Beendigung der Einstellungen des Diensteprofil-Caches und des Prozesses für die HAR-Nachricht hin gibt der HA 200 eine Registrierungsantwort-(HAA: Hausvermittler-MIP-Antwort)-Nachricht zu dem AAAH.
(14) Der AAAH 100 bringt das Zieldiensteprofil (MN-FAdest) und das Quellendiensteprofil (MN-FAsrc) an einer Authentifizierungsantwort-(AMA: AA-Mobilknoten-Antwort)-Nachricht an und sendet diese Nachricht zu dem AAAF 400.

Dann hält der AAAF 400 die übertragenen Diensteprofile unter Verwendung der AMA-Nachricht durch ein Verbinden mit der Sitzungstransaktion für den Hand-Off-Prozess innerhalb der gleichen Domäne.
35 zeigt die Prozedur zum Einstellen von Diensteprofilen in dem FA.

(15) Der AAAF 400 bringt das Zieldiensteprofil (MN-FAdest) und das Quellendiensteprofil (MN-FAsrc) an der Authentofizierungsantwort-(AMA: AA-Mobilknoten-Antwort)-Nachricht an und sendet diese Nachricht zu dem FA 500.

Der FA 500 fügt dann die übermittelten Diensteprofile dem Diensteprofil-Cache hinzu. Zu dieser Zeit werden das Zieldiensteprofil (MN-FAdest) und das Quellendiensteprofil (MN-FAsrc) beispielsweise dem "Ziel-SPC-(ASPCsrc)" und dem "Quellen-SPC-(ASPCsrc)" in dem AAA-übermittelten SPC, der in 19 gezeigt ist, jeweils hinzugefügt. Zusätzlich wird die Information (die Hausadresse und die Adresse des HA 200), die durch die AMA-Nachricht übertragen werden, in die Besucherliste gesetzt. Überdies werden das Zieldiensteprofil (MN-FAdest) und die Besucherliste verbunden.

(16) Auf eine Beendigung der Erzeugung des Diensteprofil-Caches und des Prozesses für die AMA-Nachricht gibt der FA 500 eine Registrierungsantwortnachricht an den Mobilknoten 600 zurück.

Mit der oben beschriebenen Sequenz werden die Diensteprofile jeweils in die Diensteprofil-Caches des HA 200 und des FA 500 gesetzt. Danach werden das Paket, das von dem Mobilknoten 600 zu einem beliebigen Endgerät (Korrespondenzknoten CN 700) gesendet wird, und das Paket, das von dem Korrespondenzknoten CN 700 zu dem Mobilknoten 600 gesendet wird, gemäß dieser Diensteprofile verarbeitet.
36 zeigt die Prozedur zum Übertragen eines Pakets von dem Mobilknoten zu dem Korrespondenzknoten. Es sei hier angenommen, dass der Diff-Serv-Dienst bereitgestellt wird, und das in 32 gezeigte Diensteprofil wird in den FA 500 gesetzt.
Auf einen Empfang des Datenpakets, das an den Korrespondenzknoten CN 700 adressiert ist, durchsucht der FA 500 den Diensteprofil-Cache in der Reihenfolge, die in der Suchstrategie-Verwaltungstabelle, die in 20 gezeigt ist, beschrieben ist. Der FA 500 extrahiert nämlich das Diensteprofil (ASPCsrc), das in 32B gezeigt ist. Weil die "Adresse des Mobilknotens 600" und die "Adresse des Korrespondenzknotens 700" jeweils als die Quellenadresse und die Zieladresse des empfangenen Pakets eingestellt sind, passen die Quellenadresse, die in dem empfangenen Paket eingestellt ist, und jene in dem extrahierten Diensteprofil zueinander. Dementsprechend wird das empfangene Paket gemäß dem Diensteprofil (ASPCsrc), das in 32B gezeigt ist, verarbeitet. Folglich wird dieses Paket gemäß der Routingtabelle geroutet, nachdem der TOS-Wert eingestellt ist.
37 zeigt die Prozedur zum Übertragen eines Pakets von dem Korrespondenzknoten zu dem Mobilknoten. Es sei auch hier angenommen, dass der Diff-Serv-Dienst bereitgestellt wird, und das Diensteprofil, das in 31 gezeigt ist, wird in den HA 200 gesetzt, und das Diensteprofil, das in 32 gezeigt ist, wird in den FA 500 gesetzt.

(1) Das Datenpaket, das an den Mobilknoten 600 adressiert ist, wird zu dem HA 200 geschickt, weil seine Adresse zu dem Segment des HA 200 gehört.
(2) Auf einen Empfang des Datenpakets von dem Korrespondenzknoten CN 700 hin durchsucht der HA 200 zunächst das Diensteprofil (ASPCsrc) gemäß der Suchstrategie-Verwaltungstabelle, die in 20 gezeigt ist. Hier sei angenommen, dass der Mobilknoten 600 ein Paket von jedwedem Endgerät empfangen kann und keine Einstellungen in der Zielpaket-Steuerinformation in dem Diensteprofil (ASPCsrc) ausgeführt werden. In diesem Fall wird dann das Diensteprofil (NSPCsrc) gemäß der Suchstrategie-Verwaltungstabelle, die in 20 gezeigt ist, durchsucht. Aus dem oben beschriebenen Grund wird angenommen, dass kein "Treffer" auch in diesem Fall auftritt.
(3) Der HA 200 durchsucht das Diensteprofil (ASPCdest) in Abfolge zu dem oben beschriebenen (2). Es sei hier angenommen, dass das Diensteprofil (ASPCdest), das in 31A gezeigt ist, durchsucht wird. Da die Zieladresse des oben beschriebenen Datenpakets und jene, die in der Zielpaket-Steuerinformation eingestellt ist, in diesem Fall zueinander passen, muss der Prozess gemäß diesem Diensteprofil ausgeführt werden. Hier wird in dem Diensteprofil (ASPCdest) der TOS-Wert eingestellt, und die Mobilitätsbindung wird als ein Verbindungsziel spezifiziert.
(4) Der HA 200 referenziert die Mobilitätsbindung und kapselt das Paket, das zu dem FA 500 zu schicken ist, gemäß der Mobil-IP-Prozedur ein. Zusätzlich setzt der HA 200 den TOS-Wert in das eingekapselte Paket.
(5) Auf einen Empfang dieses Datenpakets hin durchsucht der FA 500 den Diensteprofil-Cache. Weil die Zieladresse des eingekapselten Pakets "FA 500" in diesem Fall ist, trifft dieses Paket das Mobil-IP-Vorbesetzt-Diensteprofil, das in 28B gezeigt ist. In diesem Diensteprofil ist eine Entkapselungsinstruktion eingestellt, und ein Diensteprofil-Cache wird als ein Verbindungsziel eingestellt. Dementsprechend durchsucht der FA 500 wiederum den Diensteprofil-Cache nach einem Entkapseln des empfangenen Pakets.

Als die Zieladresse des entkapselten Pakets ist der "Mobilknoten 600" eingestellt. Dementsprechend trifft dieses entkapselte Paket das Diensteprofil (ASPCdest), das in 32A gezeigt ist. Überdies ist eine Besucherliste als ein Verbindungsziel in diesem Diensteprofil spezifiziert. Dementsprechend schickt der FA 500 das Datenpaket zu der Verbindungsschichtadresse des Mobilknotens 600, die in der Besucherliste registriert ist, gemäß der Mobil-IP-Prozedur.
7A (2) Sequenz in dem Fall, wo sich der Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines bestimmten AAAF zu jenem eines anderen FA bewegt.
38 zeigt die Sequenz zum Verteilen von Diensteprofilen. Veranschaulicht ist hier der Fall, wo sich der Mobilknoten 600 von dem Kommunikationsgebiet eines FA 500p zu jenem eines FA 500n bewegt. Es sei angenommen, dass sowohl der FA 500p als auch der FA 500n zu dem AAAF 400 gehören.

(1) Wenn der Mobilknoten 600 in das Kommunikationsgebiet des FA 500n eintritt, empfängt er von dem FA 500n eine Vermittlerankündigung, in welcher ein S-Bit (sanftes Hand-Off-Bit) eingestellt ist.
(2) Der Mobilknoten 600 extrahiert die Adresse des FA, der die Ermittlerankündigung gesendet hat, und bestimmt, ob sich der Domänenabschnitt des NAI des FA ändert oder nicht. Weil sowohl der FA 500p als auch der FA 500n zu dem AAAF 400 gehören, ändert sich die Domäne nicht. Dementsprechend setzt der Mobilknoten 600 eine "Vorherige FA-Ankündigungserweiterung" in eine Registrierungsanforderungsnachricht und sendet die Nachricht zu dem FA 500n. Die "Vorherige FA-Benachrichtungserweiterung ist in 63D gezeigt.
(3) Auf einen Empfang der Registrierungsanforderungsnachricht, die die "Vorherige FA-Ankündigungserweiterung" einschließt, hin erzeugt der FA 500n eine Besucherliste und benachrichtigt den AAAF 400 von "vorheriger FA-NAI-AVP" und "MN-FA-SPI-AVP" zu dem AAAF 400 unter Verwendung der AMR-Nachricht, die in 70 gezeigt ist, um einen Sitzungsschlüssel von dem AAAF 400 zu erhalten. Der "Vorherige FA-NAI-AVP" identifiziert den FA 500p in diesem Fall.
(4) Der AAAF 400 identifiziert eine Sitzung gemäß dem "MN-FA-SPI-AVP". Der AAAF 400 sendet dann die AMA-Nachricht, in welcher die Sitzungsschlüsselgruppe, die durch die Sitzung identifiziert ist, und das Diensteprofil eingestellt sind, zu dem FA 500n.
(5) Auf einen Empfang des Sitzungsschlüssels, der durch die AMA-Nachricht übermittelt ist, hin führt der FA 500n die Authentifizierung des Mobilknotens 600 mit diesem Schlüssel durch. Wenn der FA 500 die Authentifizierung des Mobilknotens erfolgreich durchführt, erzeugt er eine Dienstesteuertransaktion und sendet eine Bindungsaktualisierungsnachricht zu dem FA 500p. Hier muss ein "A-Bit" der Bindungsaktualisierungsnachricht ohne Fehler eingestellt werden. Zusätzlich wird eine Routenoptimierungs- Authentifizierung verwendet, so dass der FA die Authentifizierung einer Routenoptimierung durchführt. Überdies wird ein Diensteprofil, das mit der Besucherliste des FA 500n verbunden ist, als das Diensteprofil eingestellt. Jedoch wird das Verbindungsziel auf einen Bindungs-Cache geändert.
(6) Auf einen Empfang der Bindungsaktualisierungsnachricht hin löscht der FA 500p die Besucherliste für den Mobilknoten 600 und erzeugt einen Bindungs-Cache. Zusätzlich setzt der FA 500p den Bindungs-Cache als ein Verbindungsziel des Diensteprofils. Der FA 500p sendet dann eine Bindungsbestätigungsnachricht zu dem Mobilknoten 600. Die Bindungsbestätigungsnachricht wird eingekapselt und zu dem FA 500n gesendet, der die Nachricht entkapselt und die entkapselte Nachricht zu dem Mobilknoten 600 schickt. Danach beendet, wenn die Lebensdauer des registrierten Caches ausläuft, der FA 500p die Bereitstellung eines Dienstes für den Mobilknoten 600.
(7) Der FA 500n sendet eine Registrierungsanforderungsnachricht zu dem HA 200 mit einer normalen Prozedur.
(8) Der HA 200 gibt eine Registrierungsantwortnachricht zu dem FA 500n zurück. Auf einen Empfang der Registrierungsantwortnachricht hin wird der FA 500n bereit, Daten zu dem Mobilknoten 600 danach zu senden.
(9) Der FA 500n gibt die Registrierungsantwortnachricht zu dem Mobilknoten 600 zurück.
(10) Das Paket von dem Korrespondenzknoten 700 zu dem Mobilknoten 600 wird eingekapselt und zu dem FA 500 geschickt. Nachdem das Paket einmal durch den FA 500 entkapselt ist, wird es wieder eingekapselt und zu dem FA 500n geschickt. Der FA 500n entkapselt dieses Paket und schickt es zu dem Mobilknoten 600.

7A (3) Sequenz in dem Fall, wo sich der Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines AAAF zu jenem eines FA innerhalb eines anderen AAAF bewegt.
39 zeigt die Sequenz zum Verteilen von Diensteprofilen. Veranschaulicht ist hier der Fall, wo sich der Mobilknoten 600 von dem Kommunikationsgebiet eines FA 500p, untergeordnet einem AAAF 400p zu jenem eines FA 500n, untergeordnet einem AAAF 400n, bewegt.

(1) Wenn sich der Mobilknoten 600 von dem Kommunikationsgebiet des FA 500p zu jenem des FA 500n bewegt, empfängt der Mobilknoten 600 von dem FA 500n die Vermittlerankündigung, in welcher das S-Bit gesetzt ist.
(2) Der Mobilknoten 600 extrahiert die Adresse des FA, der die Vermittlerankündigung gesendet hat, und bestimmt, ob sich der Domänenabschnitt des NAI des FA geändert hat oder nicht. Da der FA 500p und der FA 500n in diesem Fall zu unterschiedlichen AAAFs gehören, hat sich die Domäne gändert. Dementsprechend setzt der Mobilknoten 600 "MN-AAA-Authentifizierung" in eine Registrierungsanforderungsnachricht und sendet diese Nachricht zu dem FA 500n.
(3) Der FA 500n erzeugt eine Besucherliste. Zu dieser Zeit existiert keine entsprechende Sitzungstransaktion. Dementsprechend setzt der Mobilknoten 600 "Sitzungs-ID=0" in die AMR-Nachricht und sendet diese Nachricht zu dem AAAF 400n.
(4) Der AAAF 400n schickt die AMR-Nachricht zu dem AAAH 100 auf der Grundlage des NAI, der durch die AMR-Nachricht übermittelt ist.
(5) Der AAAH 100 führt die folgenden Prozesse auf einen Empfang der AMR-Nachricht hin durch.
– Sitzungszusammenlegungsprozess: Auf einem Empfang der AMR-Nachricht hin, in welcher "Sitzungs-ID=0" gesetzt ist, sucht der AAAH 100 eine Sitzungstransaktion unter Verwendung des NAI des Mobilknotens 600. Wenn in dieser Suche ein Treffer gefunden wird, wird der ID dieser Sitzung für eine nachfolgende Sitzung verwendet. Wenn ein Treffer nicht gefunden wird, erzeugt der AAAH 100 erneut eine Sitzungstransaktion und ordnet einen Sitzungs-ID der erzeugten Transaktion zu. Wenn die AMR-Nachricht, in welcher ein Sitzungs-ID gesetzt ist, empfangen wird, sucht der AAAH 100 die Sitzungstransaktion unter Verwendung des empfangenen Sitzungs-ID.
– Schlüsselgruppenerzeugung: Der AAH 100 erzeugt sämtliche Sicherheitsschlüssel und aktualisiert einen Sitzungszeitgeber.
– Der AAH sendet eine HAR-Nachricht zu dem HA 200 (eine Diensteprofilübertragung ist beliebig, wenn eine Sitzungstransaktion nicht erzeugt wird).
(6) Der HA 200 aktualisiert die Mobilitätsbindung und gibt eine AMA-Nachricht zu dem AAAH 100 zurück.
(7) Der AAAH 100 führt einen Vergleich zwischen dem AAAF, der die AMR-Nachricht gesendet hat, und dem AAAF innerhalb der Sitzungstransaktion aus. Wenn sie nicht zueinander passen, setzt der AAAH 100 "Vorheriger-FA-NAI" in die AMA-Nachricht und sendet diese Nachricht. Der "Vorheriger-FA-NAI" identifiziert den FA 500p zu dieser Zeit.
(8) Der AAAF 400n setzt ein Diensteprofil in die Sitzungstransaktion und sendet das Diensteprofil zu dem FA 500n unter Verwendung der AMA-Nachricht.
(9) Auf einen Empfang der AMA-Nachricht hin, bei welcher der "Vorheriger-FA-NAI" gesetzt ist, fügt der FA 500n das Diensteprofil dem Diensteprofil-Cache hinzu. Dann identifiziert der FA 500n den FA 500p auf der Grundlage des "Vorheriger-FA-NAI" und sendet die Bindungsaktualisierung, bei welcher die RO-Authentifizierung, die durch die AMA-Nachricht übermittelt ist und das Diensteprofil gesetzt sind, zu dem FA 500p.
(10) Der FA 500p löscht die Besucherliste des Mobilknotens 600 und erzeugt gleichzeitig einen Bindungs-Cache. Dann ersetzt der FA 500p das Diensteprofil, das in dem Diensteprofil-Cache gespeichert ist, durch das Diensteprofil, das durch die Bindungsaktualisierung übermittelt ist, und verbindet das Diensteprofil mit dem Bindungs-Cache. Der FA 500p gibt dann eine bindungsbestätigte ??? Nachricht zu dem Mobilknoten 600 zurück.
(11) Der FA 500n gibt eine Registrierungsantwortnachricht zu dem Mobilknoten 600 zurück. Das Diensteprofil und der Bindungs-Cache des FA 500p werden bei dem Auslauf der Lebensdauer des Caches gelöscht. Der Diensteprofil-Cache und die Sitzungstransaktion des AAAF 400p werden auf eine Sitzungs-Auszeit hin gelöscht.

7B. Fall, wo ein AAAF einen HA spezifiziert
Beschrieben in der folgenden Ausführungsform sind (1) die Sequenz zu der Zeit einer Anfangsregistrierung, (2) die Sequenz in dem Fall, wo sich ein Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines bestimmten AAAF zu jenem eines anderen FA bewegt, und (3) die Sequenz in dem Fall, wo sich ein Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines AAAF zu jenem eines FA innerhalb eines anderen AAAF bewegt.
7B(1) Sequenz zu der Zeit einer Anfangsregistrierung
40 zeigt die Sequenz zum Verteilen von Diensteprofilen. In dieser Sequenz ist der Prozess von dann, wenn der Mobilknoten 600 eine Registrierungsanforderungsnachricht sendet, bis dann, wenn der AAAH 100 ein Diensteprofil erzeugt, der gleiche wie jener in dem Fall, wo der AAAH 100 den HA spezifiziert (siehe oben beschrieben 7A(1)). Eine Erläuterung der Sequenz für diesen Abschnitt ist deswegen hier weggelassen.

(1) Der AAAH 100 bringt ein Zieldiensteprofil (MN-HAdest), ein Quellendiensteprofil (MN-HAsrc), ein Zieldiensteprofil (MN-FAdest) und ein Quellendiensteprofil (MN-FAsrc) an einer AMA-(AA-Mobilknotenantwort)-Nachricht an und sendet diese Nachricht zu dem ARAF 400.
(2) Der AAAF 400 hält die übermittelten Diensteprofile durch ein Verbinden mit der Sitzungstransaktion in einer Reihenfolge für den Hand-Off-Prozess innerhalb der gleichen Domäne.
(3) Der AAAF 400 bringt das Zieldiensteprofil (MN-HAdest) und das Quellendiensteprofil (MN-HAsrc) an einer HAR-(Hausvermittler-MIP-Anforderung)-Nachricht an und sendet diese Nachricht zu dem HA 200.
(4) Der HA 200 erzeugt eine DIAMETER-Sitzungstransaktion und fügt die übermittelten Diensteprofile zu seinem eigenen Diensteprofil-Cache hinzu. Zusätzlich erzeugt der HA 200 eine Mobilitätsbindung auf der Grundlage der Information der Registrierungsanforderung, die durch die HAR-Nachricht übermittelt ist. Überdies setzt der HA 200 die Verbindungsinformation für eine Eingabe der erzeugten Mobilitätsbindung als ein Steuerinformations-Identifizierer des Zieldiensteprofils (MN-HAdest).
(5) Der AAAF 400 bringt das Zieldiensteprofil (MN-FAdest) und das Quellendiensteprofil (MN-FAsrc) an der AMA-Nachricht an und sendet diese Nachricht zu dem FA 500.
(6) Der FA 500 fügt die übermittelten Diensteprofile seinem Diensteprofil-Cache hinzu. Zu dieser Zeit werden das Zieldiensteprofil (MN-FAdest) und das Quellendiensteprofil (MN-FAsrc) jeweils dem Ziel-SPC (ASPCdst) und dem Quellen-SPC (ASPCsrc) des AAA-übermittelten SPC hinzugefügt. Überdies setzt der FA 500 die Information (die Hausadresse und die HA-Adresse), die durch die AMA-Nachricht übermittelt sind, in die Besucherliste und spezifiziert diese Liste als ein Verbindungsziel des Zieldiensteprofils (MN-FAdest).
(7) Auf eine Beendigung der Erzeugung des Diensteprofil-Caches und des Prozesses für die AMA-Nachricht hin gibt der FA 500 eine Registrierungsantwortnachricht an den Mobilknoten 600 zurück.

Mit der oben beschriebenen Sequenz werden die Diensteprofile jeweils in die Diensteprofile-Caches des HA 200 und des FA 500 gesetzt. Danach werden das Paket, das von dem Mobilknoten 600 zu dem Korrespondenzknoten CN 700 übertragen wird, und das Paket, das von dem Korrespondenzknoten CN 700 zu dem Mobilknoten 600 übertragen wird, gemäß dieser Diensteprofile verarbeitet. Die Betriebsschritte, die durchgeführt werden, wenn ein Datenpaket unter Referenzieren auf den Diensteprofil-Cache verarbeitet wird, sind die gleiche wie jene in dem Fall, wo der AAAH 100 den HA spezifiziert (siehe oben beschrieben 7A(1)). Dementsprechend ist eine Erläuterung der Sequenz für diesen Abschnitt hier weggelassen.
7B(2) Sequenz in dem Fall, wo sich ein Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines bestimmten AAAF zu jenem eines anderen FA bewegt.
Diese Sequenz ist die gleiche wie jene in dem Fall, wo der AAAH 100 den HA spezifiziert (siehe oben beschrieben 7A(2)). Ihre Erläuterung ist deswegen hier weggelassen.
7B(3) Sequenz in dem Fall, wo sich ein Mobilknoten von dem Kommunikationsgebiet eines FA innerhalb eines AAAF zu jenem eines FA innerhalb eines anderen AAAF bewegt
41 zeigt die Sequenz zum Verteilen von Diensteprofilen. Veranschaulicht ist hier der Fall, wo sich der Mobilknoten 600 von dem Kommunikationsgebiet eines FA 500p, untergeordnet einem AAAF 400p, zu jenem eines FA 500n, untergeordnet einem AAAF 400n, auf eine ähnliche Weise wie in dem in 39 gezeigten Beispiel bewegt. In dieser Sequenz ist der Prozess von dann, wenn der Mobilknoten 600 eine Vermittlerankündigung von dem FA 500n empfängt, bis dann, wenn der AAAH 100 eine Transaktion erzeugt, der gleiche wie in dem Fall, wo der AAAH 100 den HA 200 spezifiziert (siehe oben beschrieben 7A(3)). Seine Erläuterung ist deswegen hier weggelassen.

(1) Wenn die Adresse, die dem HA innerhalb der Sitzungstransaktion zugeordnet ist, "0000" oder "FFFF" ist, wenn darauf referenziert wird, wird eine AMR-Nachricht zu dem AAAF (nämlich dem AAAF 400p) gesendet, der den HA 200 spezifiziert hat.
(2) Der AAAF 400p sendet eine HAR-Nachricht zu dem HA 200.
(3)–(4) Der HA 200 aktualisiert eine Mobilitätsbindung gemäß der HAR-Nachricht und gibt eine HAA-Nachricht zu dem AAAF 400p zurück.
(5) Der AAAH 100 führt einen Vergleich zwischen dem AAAF (AAAF 400n), der die AMR-Nachricht gesendet hat, und jenem innerhalb der Sitzungstransaktion aus. Wenn sie nicht zueinander passen, sendet der AAAH 100 zu dem AAAF 400n die AMA-Nachricht, in welcher "Vorheriger-FA-NAI" gesetzt ist. Ein Diensteprofil wird an dieser AMA-Nachricht angebracht.
(6) Der AAAF 400n schickt die AMA-Nachricht zu dem FA 500n. Auf diese Weise wird das Diensteprofil zu dem FA 500n verteilt.
(7)–(8) Auf einen Empfang der AMA-Nachricht hin, in welcher der "Vorheriger-FA-NAI" gesetzt ist, fügt der FA 500n das Diensteprofil, das an der Nachricht angebracht ist, seinem Diensteprofil-Cache hinzu. Überdies identifiziert der FA 500n den FA 500p auf der Grundlage des "Vorheriger-FA-NAI", der in der oben beschriebenen Nachricht gesetzt ist. Der FA 500n sendet zu dem FA 500p dann die Bindungsaktualisierung, wo die RO-Authentifizierung, die durch die AMA-Nachricht übermittelt ist, und das Diensteprofil gesetzt sind.
(9)–(10) Der FA 500p löscht die Besucherliste des Mobilknotens 600 und erzeugt gleichzeitig einen Bindungs-Cache. Dann ersetzt der FA 500p das gegenwärtige Diensteprofil durch das Diensteprofil, das durch die Bindungsaktualisierung übermittelt ist, und verbindet das Diensteprofil mit dem Bindungs-Cache. Der FA 500p gibt dann eine Bindungsbestätigungsnachricht zu dem Mobilknoten 600 zurück.
(11) Der FA 500n gibt eine Registrierungsantwortnachricht zu dem Mobilknoten 600 zurück. Das Diensteprofil und der Bindungs-Cache des FA 500p werden bei Auslauf des Caches gelöscht. Der Dienste-Cache und die Sitzungstransaktion des AAAF 400p werden auf eine Sitzungs-Auszeit hin gelöscht.

7C. Flussdiagramm jeder Einheit
42 ist ein Flussdiagramm, das den Prozess des AAAH 100 erläutert. Dieser Prozess wird beispielsweise auf den Empfang eines DIAMETER-Protokollpakets durchgeführt.
In einem Schritt S1 wird der Nachrichtentyp eines empfangenen Pakets erfasst. Wenn der Nachrichtentyp eine AMR-Nachricht ist, schreitet der Prozess zu einem Schritt S2 fort. Wenn der Nachrichtentyp entweder eine AMA- oder eine HAA-Nachricht ist, schreitet der Prozess zu einem Schritt S8 fort. Wenn der Nachrichtentyp eine SFR-Nachricht ist, schreitet der Prozess zu einem Schritt S13 fort. In dem Schritt S2 wird erfasst, ob eine Sitzungstransaktion bereits erzeugt worden ist oder nicht. Wenn die Sitzungstransaktion bereits erzeugt worden ist, schreitet der Prozess zu einem Schritt S9 fort. Wenn die Sitzungstransaktion noch nicht erzeugt worden ist, wird sie in einem Schritt S3 erzeugt.
In einem Schritt S4 wird eine Dienstesteuerdatenbank unter Verwendung des NAI durchsucht, der in der AMR-Nachricht als ein Schlüssel gesetzt ist, und ein Diensteprofil wird auf der Grundlage des Ergebnisses der Suche erzeugt. In einem Schritt S5 wird das erzeugte Diensteprofil in die Sitzungstransaktion gesetzt.
In einem Schritt S6 wird erfasst, ob der AAAH einen HA spezifizieren muss oder nicht. Welcher von dem AAAH und einem AAAF ein HA spezifiziert, kann vorbestimmt sein oder dynamisch geändert werden. Wenn der AAAH einen HA spezifizieren muss, wird die HAR-Nachricht, an welcher das Diensteprofil angebracht ist, zu dem HA in einem Schritt S7 gesendet. Wenn der AAAH einen HA nicht spezifizieren muss, wird eine AMA-Nachricht, an welcher das Diensteprofil angebracht ist, zu dem AAAF in einem Schritt S8 übertragen.
In dem Schritt S9 wird erfasst, ob der AAAF geändert worden ist oder nicht. Wenn der AAAF geändert worden ist, schreitet der Prozess zu einem Schritt S10 fort. Wenn der AAAF nicht geändert worden ist, schreitet der Prozess zu einem Schritt S8 fort, wo eine AMA-Nachricht gesendet wird. In dem Schritt S10 wird erfasst, ob der HA bereits spezifiziert worden ist oder nicht. Wenn der HA bereits spezifiziert worden ist, wird eine HAR-Nachricht zu dem HA in einem Schritt S11 gesendet. Wenn der HA noch nicht spezifiziert worden ist, wird eine AMR-Nachricht zu dem AAAF, der den Mobilknoten zuvor aufgenommen hat, gesendet.
In einem Schritt S13 wird eine SFA-Nachricht zu der Quelle der SFR-Nachricht zurückgegeben. In einem Schritt S14 wird eine Sitzungstransaktion freigegeben.
Die Betriebsschritte des AAAH werden untenstehend als spezifische Beispiele erläutert.
(1) Prozedur zum Registrieren eines Anfangsorts in dem Fall, wo der AAAF einen HA spezifiziert (siehe 40)
Dieser Prozess wird beispielsweise dann durchgeführt, wenn eine Registrierungsanforderungsnachricht von einem Mobilknoten zu einem FA gesendet wird, und eine Authentifizierungsanforderungsnachricht von einem FA zu einem AAAH über den AAAF gesendet wird.

S1: Der Prozess schreitet zu dem Schritt S2 fort, da eine AMR-(AA-Mobilknoten-Anforderungs)-Nachricht von dem AAAF empfangen wird.
S2: Eine Sitzungstransaktion wird unter Verwendung der NAI des Mobilknotens als ein Schlüssel gesucht, der durch die AMR-Nachricht übermittelt wird. Es sei darauf hingewiesen, dass eine Sitzungstransaktion zu der Zeit einer Anfangsortsregistrierung noch nicht erzeugt worden ist. Deswegen schreitet der Prozess zu dem Schritt S3 fort.
S3: Eine Sitzungstransaktion wird erzeugt.
S4: Eine Dienstesteuerdatenbank 300 wird unter Verwendung des NAI des Mobilknotens als ein Schlüssel durchsucht, und ein Diensteprofil wird auf der Grundlage der Information, die aus der Suche herrührt, und der Strategie zum Erzeugen eines Diensteprofils erzeugt. Auf diese Weise wird das in 12 gezeigte Diensteprofil erzeugt. Die Strategie zum Erzeugen eines Diensteprofils und ein spezifisches Konfigurationsverfahren sind nicht sonderlich beschränkt. Jedoch sind sie, da bestimmte Beispiele oben stehend bereitgestellt sind, hier nicht erwähnt.
S5: Das Diensteprofil wird in die Sitzungstransaktion gesetzt.
S6: Welcher von dem AAAH und dem AAAF den HA spezifiziert, wird bestimmt, wenn entweder "0000" oder "FFFF" als die HA-Adresse der AMR-Nachricht gesetzt ist. Es wird angenommen, dass eine Bestimmungsbedingung von einem Provider vorgegeben wird. Hier wird angenommen, dass der AAAF den HA spezifiziert. Der Prozess schreitet dann zu dem Schritt S8 fort.
S8: Das Diensteprofil, das in dem Schritt S4 erzeugt wird, wird von der AMA-Nachricht angebracht, und die Nachricht wird zu dem AAAF übertragen.

(2) Prozedur zum Registrieren eines Anfangsorts in dem Fall, wo ein AAAH ein HA spezifiziert (siehe 26)

S1 bis S5: Das gleiche wie der oben beschriebene Fall (1).
S6: Der Prozess schreitet zu dem Schritt S7 auf der Grundlage der Annahme fort, dass der AAAH den HA spezifiziert.
S7: Der HA spezifiziert, und die HAR-Nachricht, an welcher da Diensteprofil angebracht ist, wird zu dem spezifizierten HA gesendet.

(3) Prozedur zum Registrieren des Orts eines Mobilknotens, der sich zwischen ISPs bewegt, in dem Fall von ein AAAH einen HA spezifiziert.
Dieser Prozess wird beispielsweise dann durchgeführt, wenn sich ein bestimmter Mobilknoten von dem Kommunikationsgebiet eines FA, untergeordnet einem AAAF, zu jenem eines anderen FA, untergeordnet einem anderen AAAF, bewegt.

S1: Der Prozess schreitet zu dem Schritt S2 fort, da eine AMR-Nachricht von dem AAAF empfangen wird.
S2: Eine Sitzungstransaktion (siehe 14) wird unter Verwendung des NAI des Mobilknotens als ein Schlüssel gesucht, der durch die AMR-Nachricht übermittelt wird. Da ein Authentifizierungsprozess hier beendet ist, existiert eine Sitzungstransaktion. Dementsprechend schreitet der Prozess zu dem Schritt S9 fort.
S9: Ob der AAAF geändert worden ist oder nicht, wird erfasst, indem ein Vergleich zwischen der Adresse des gegenwärtigen AAAF in der Sitzungstransaktion, die in dem Schritt S2 erhalten wird, und der Quellenadresse der empfangenen AMR-Nachricht ausgeführt wird. Weil hier angenommen wird, dass sich der Mobilknoten zwischen ISPs bewegt, ist der AAAF geändert worden. Deswegen schreitet der Prozess zu dem Schritt S10 fort.
S10: Ob der HA bereits spezifiziert worden ist oder nicht, wird durch den HA selbst durch ein Referenzieren auf die HA-Adresse der Sitzungstransaktion erfasst. Hier wird angenommen, dass der HA bereits durch den AAAH selbst spezifiziert worden ist. Wenn der HA durch den AAAH nicht spezifiziert worden ist, wird beispielsweise angenommen, dass entweder "0000" oder "FFFF" als die HA-Adresse gesetzt ist.
S11: Eine HAR-Nachricht wird zu dem bereits spezifizierten HA übertragen.

(4) Prozedur zum Registrieren des Orts eines Mobilknotens, der sich zwischen ISPs bewegt, in dem Fall, wo ein AAAF den einen HA spezifiziert (siehe 41).

S1 bis S9: Das gleiche wie der oben beschriebene Fall (3).
S10: Der Prozess schreitet zu dem Schritt S12 fort, da der HA durch den AAAF spezifiziert ist. Wenn der HA durch den AAAF spezifiziert ist, wird beispielsweise "0000" oder in "FFFF" als die HA-Adresse eingesetllt.
S12: Eine Sitzungstransaktion (die Adresse des AAAF, der den HA in 14 spezifiziert hat) wird referenziert, und eine AMR-Nachricht wird zu dem AAAF geschickt, der den HA spezifiziert hat.

(5) Prozedur zum Aktualisieren einer Ortsregistrierung bei dem Ablauf eines Sitzungszeitgebers
Dieser Prozess wird beispielsweise bei dem Ablauf eines Sitzungszeitgebers durchgeführt, während ein Mobilknoten in dem Kommunikationsgebiet eines bestimmten FA verbleibt. Wenn der Sitzungszeitgeber abläuft, wird eine AMR-Nachricht zum Aktualisieren der Ortsregistrierung zu einem AAAH gesendet.

S1 bis S2: Das gleiche wie der oben beschriebene Fall (3).
S9: Da keine Ortsregistrierung aufgrund der Bewegung des Mobilknotens vorhanden ist, ist der AAAF nicht geändert worden. Dementsprechend schreitet der Prozess zu dem Schritt S8 fort.
S8: Anbringen des Diensteprofils, das in dem Schritt S4 erzeugt wird, an der AMA-Nachricht, und Senden der Nachricht zu dem AAAF.

(6) Prozedur auf eine Beendigung der Ortsregistrierung an einem HA hin
Dieser Prozess wird auf einen Empfang einer HAA-Nachricht von einem HA oder einer AMA-Nachricht von einem AAAF, der den HA spezifiziert hat, hin durchgeführt. Es sei darauf hingewiesen, dass der AAAH die HAA-Nachricht von dem HA empfängt, wenn eine HAR-Nachricht zu dem HA in dem Schritt S11 gesendet wird. Überdies empfängt der AAAH eine AMA-Nachricht von einem vorherigen AAAF, wenn eine AMR-Nachricht zu dem vorherigen AAAF in dem Schritt S12 gesendet wird.

S1: Der Prozess schreitet zu dem Schritt S8 auf einem Empfang der HAA- oder AMA-Nachricht hin fort.
S8: Das Diensteprofil, das in dem Schritt S4 erzeugt ist, wird an der AMA-Nachricht angebracht, und die Nachricht wird zu dem AAAF gesendet. Auf einem Empfang der AMA-Nachricht von dem vorherigen AAAF hin wird die AMA-Nachricht, an welcher das Diensteprofil angebracht ist, zu einem neuen AAAF gesendet.

(7) Prozedur zum Freigeben einer Sitzung
Dieser Prozess wird auf einem Empfang einer SFR-(sitzungsfreie Anforderung)-Nachricht durchgeführt. Es sei daran erinnert, dass die SFR-Nachricht von einem Server erzeugt wird, der sich nicht direkt auf die vorliegende Erfindung bezieht. Die SFR-Nachricht wird beispielsweise dann erzeugt, wenn ein Abrechnungsserver eine Abrechnungs-Stoppnachricht empfängt.

S1: Der Prozess schreitet zu einem Schritt S13 auf einem Empfang der SFR-Nachricht hin fort.
S13: Eine SFA-(sitzungsfreie Antwort)-Nachricht wird zu dem Server zurückgegeben, der die SFR-Nachricht gesendet hat.
S14: Freigebende Sitzungstransaktion

Die 43 und 44 sind Flussdiagramme, die den Prozess des AAAF 400 erläutern. Dieser Prozess wird beispielsweise auf einen Empfang eines DIAMETER-Protokollpakets durchgeführt.
In einem Schritt S21 wird der Nachrichtentyp eines empfangenen Pakets erfasst. Wenn der Nachrichtentyp eine AMR-Nachricht ist, schreitet der Prozess zu einem Schritt S22 fort. Wenn der Nachrichtentyp eine AMA-Nachricht ist, schreitet der Prozess zu einem Schritt S41 fort. Wenn der Nachrichtentyp eine HAA-Nachricht ist, schreitet der Prozess zu einem Schritt S51 fort. Oder wenn der Nachrichtentyp eine SFR-Nachricht ist, schreitet der Prozess zu einem Schritt S61 fort. In dem Schritt S22 wird erfasst, ob "Vorheriger-FA-NAI" durch die AMR-Nachricht übermittelt ist oder nicht. Wenn der "Vorheriger-FA-NAI" übermittelt ist, schreitet der Prozess zu einem Schritt S31 fort. Wenn der "Vorheriger-FA-NAI" nicht übermittelt ist, schreitet der Prozess zu einem Schritt S23 fort.
In dem Schritt S23 wird eine Sitzungstransaktion unter Verwendung des NAI gesucht, der in der AMR-Nachricht als ein Schlüssel gesetzt ist. In einem Schritt S24 wird erfasst, ob eine Sitzungstransaktion bereits erzeugt worden ist oder nicht. Wenn die Sitzungstransaktion noch nicht erzeugt worden ist, wird sie in einem Schritt S25 erzeugt.
In einem Schritt S26 wird erfasst, ob ein HA bereits durch den AAAF selbst spezifiziert worden ist oder nicht. Wenn der HA bereits spezifiziert worden ist, wird eine HAR-Nachricht zu dem HA in einem Schritt S27 gesendet. Wenn der HA noch nicht spezifiziert worden ist, wird eine AAAH auf der Grundlage des NAI, der in der AMR-Nachricht gesetzt ist, in einem Schritt S28 identifiziert, und die AMR-Nachricht wird zu dem identifizierten AAAH geschickt. Dann wird "HA wird angefordert" als ein Betriebszustand in einem Schritt S29 gesetzt.
In einem Schritt S31 wird die Sitzungstransaktion unter Verwendung einer Sicherheitsinformation gesucht. In einem Schritt S32 wird ein Diensteprofil an der AMA-Nachricht angebracht, das dann zu dem FA gesendet wird. In einem Schritt S33 wird "Warten, verarbeitet zu werden" als ein Betriebszustand gesetzt.
In einem Schritt S41 wird das Diensteprofil in der Sitzungstransaktion gesetzt. In einem Schritt S22 wird erfasst, ob der HA bereits von dem AAAF selbst spezifiziert worden ist oder nicht. Wenn der HA noch nicht spezifiziert worden ist, wird er spezifiziert, und gleichzeitig wird die HAR-Nachricht, an welcher das Diensteprofil angebracht ist, zu dem spezifizierten HA in einem Schritt S43 übertragen. Dann wird "AMA wird verarbeitet" als der Betriebszustand in einem Schritt S44 gesetzt. Andererseits schreitet, wenn der HA bereits spezifiziert worden ist, der Prozess zu einem Schritt S33 fort, nachdem die AMA-Nachricht zu dem FA in einem Schritt S45 geschickt ist.
In einem Schritt S51 wird der Betriebszustand überprüft. Wenn "HA wird angefordert" als der Betriebszustand gesetzt ist, schreitet der Prozess zu dem Schritt S33 fort, nachdem die AMA-Nachricht zu dem AAAH in einem Schritt S52 übertragen ist. Andererseits schreitet, wenn das "AMA wird verarbeitet" als der Betriebzustand gesetzt ist, der Prozess zu dem Schritt S33 fort, nachdem die AMA-Nachricht zu dem FA in einem Schritt S53 geschickt ist.
In einem Schritt S61 wird eine SFA-Nachricht zu dem AAAH gesendet. Dann wird die Sitzungstransaktion in einem Schritt S62 freigegeben.
Die Betriebsschritte des AAAF sind untenstehend als spezifische Beispiele beschrieben.
(1) Prozedur zum Registrieren eines Anfangsorts (siehe 26 und 40)

S21: Der Prozess schreitet zu dem Schritt S22 fort, da eine AMR-Nachricht von dem FA empfangen wird.
S22: Vorheriger FA-NAI-AVP ist nicht in der AMR-Nachricht enthalten. da dies eine Anfangsortsregistrierung ist. Dementsprechend schreitet der Prozess zu dem Schritt S23 fort.
S23: Eine Sitzungstransaktion wird unter Verwendung des NAI gesucht, der durch die AMR-Nachricht als ein Schlüssel übermittelt ist.
S24: Eine Sitzungstransaktion, die ein Suchziel in dem Schritt S23 ist, existiert in dem AAAF nicht, da dies die Anfangsortsregistrierung ist. Dementsprechend schreitet der Prozess zu dem Schritt S25 fort.
S25: Eine Sitzungstransaktion wird erzeugt.
S26: Ein HA ist zu der Zeit einer Anfangsortsregistrierung noch nicht spezifiziert worden. Dementsprechend schreitet der Prozess zu dem Schritt S28 fort. Ob der HA bereits spezifiziert worden ist oder nicht, wird gemäß der HA-Adresse in der Sitzungstransaktion erfasst. Beispielsweise wird "0000" als die HA-Adresse unmittelbar, nachdem eine Sitzungstransaktion erzeugt ist, gesetzt.
S28: Der AAAH des ISP, zu welchem der Mobilknoten gehört, wird auf der Grundlage des Domänenabschnitts des NAI des Mobilknotens identifiziert, der in der AMR-Nachricht gesetzt ist, und die AMR-Nachricht wird zu dem identifizierten AAAH geschickt.
S29: "HA wird angefordert" wird als ein Betriebszustand gesetzt.

(2) Prozedur zum Registrieren des Orts eines Mobilknotens, der sich zwischen ISPs bewegt, in dem Fall, wo der AAAF einen HA spezifiziert (siehe 21).
Beschrieben sind hier die Betriebsschritte des AAAF (äquivalent zu dem AAAF 400p, der in 41 gezeigt ist, und als "Vorheriger AAAF" in diesem Fall bezeichnet, zu welchem der FA, der den Mobilknoten aufnimmt, vor der Bewegung des Mobilknotens gehört.

S21: Der Prozess schreitet zu dem Schritt S22 fort, da der vorherige AAAF die AMR-Nachricht von dem AAAH empfängt.
S22: "Vorheriger FA-NAI-AVP" ist nicht in der AMR-Nachricht enthalten, da sich der Mobilknoten zu einer unterschiedlichen Domäne bewegt. Dementsprechend schreitet der Prozess zu dem Schritt S23 fort.
S23: Eine Sitzungstransaktion wird unter Verwendung des NAI gesucht, der durch die AMR-Nachricht als ein Schlüssel übermittelt ist.
S24: Eine derartige Sitzungstransaktion existiert in dem vorherigen AAAF. Dementsprechend überspringt der Prozess den Schritt S25.
S26: Die Adresse des HA, der durch den AAAF selbst gesetzt ist, wird als die HA-Adresse in der Sitzungstransaktion gesetzt. Dementsprechend schreitet der Prozess zu dem Schritt S27 fort.
S27: Ein HAR-(Hausvermittler-MIP-Anforderungs)-Nachricht wird zu dem HA gesendet.
S29: "HA wird angefordert" wird als ein Betriebszustand gesetzt.

(3) Prozedur zum Registrieren des Orts eines Mobilknotens, der sich innerhalb eines ISP bewegt (38)
Hier sei angenommen, dass der FA, der zuvor den Mobilknoten vor seiner Bewegung aufnahm, als ein "Vorheriger FA" bezeichnet wird, wohingegen der FA, der den Mobilknoten nach seiner Bewegung aufnimmt, als ein "neuer FA" bezeichnet wird.

S21: Der Prozess schreitet zu dem Schritt S22 fort, da der AAAF eine AMR-Nachricht von dem neuen FA empfängt.
S22: Da sich der Mobilknoten innerhalb der gleichen Domäne bewegt, setzt der Mobilknoten "Vorherige FA-NAI-Erweiterung" einer Registrierungsanforderungsnachricht, und der FA setzt "Vorheriger-FA-NAI-AVP" der AMR-Nachricht.
S31: Eine Sitzungstransaktion wird unter Verwendung einer Sicherheitsinformation (MN-FA-SPI) gesucht.
S32: Das Diensteprofil und die Sicherheitsinformation, die in der Sitzungstransaktion gesetzt sind, werden an einer AMA- (AA-Mobilknotenantwort)-Nachricht angebracht, die dann zu dem neuen FA gesendet wird.
S33: "Warten, verarbeitet zu werden" wird als ein Betriebszustand gesetzt.

(4) Prozedur zum Registrieren eines Worts in dem Fall, wo der AAAF einen HA spezifiziert (siehe 40)

S21: Der AAAF empfängt eine AMA-Nachricht von dem AAAH als eine Antwort auf die AMR-Nachricht. Dementsprechend schreitet der Prozess zu dem Schritt S41 fort.
S41: Eine Sitzungstransaktion wird unter Referenzieren auf ein DIAMETER-Identifiziererfeld identifiziert. Das Diensteprofil, das durch die AMA-Nachricht übermittelt ist, wird in die identifizierte Sitzungstransaktion gesetzt.
S42: Es sei hier angenommen, dass der HA noch nicht spezifiziert worden ist, und der Prozess schreitet zu dem Schritt S43 fort. Wenn der HA von dem AAAF selbst spezifiziert worden ist, wird beispielsweise "0000" oder "FFFF" als die HA-Adresse gesetzt, die in der AMA-Nachricht gesetzt ist.
S43: Der HA wird spezifiziert, und die HAR-(Hausvermittler-MIP-Anforderungs)-Nachricht, an welcher das Diensteprofil angebracht ist, wird zu dem spezifizierten HA übertragen.
S44: "AMA wird verarbeitet" ist ein Betriebszustand.

(5) Prozedur zum Registrieren eines Orts in dem Fall, wo der AAAH einen HA spezifiziert (siehe 26 und 41)
Hier werden die Betriebsschritte von beispielsweise dem AAAF 400, der in 26 gezeigt ist, oder dem AAAF 400n, der in 41 gezeigt ist, erläutert.

S21 und S41: Die gleichen wie die oben beschriebenen (4).
S42: Es sei hier angenommen, dass der HA bereits von dem AAAF selbst spezifiziert worden ist, und der Prozess schreitet deswegen zu dem Schritt S45 fort.
S45: Der FA wird auf der Grundlage eines "Gegenwärtigen FA-NAI" in einer Sitzungstransaktion identifiziert, und eine AMA-Nachricht wird zu dem identifizierten FA geschickt.
S33: "Warten, verarbeitet zu werden" wird als ein Betriebszustand gesetzt.

(6) Prozedur zum Registrieren des Orts eines Mobilknotens, der sich zwischen ISPs bewegt, in dem Fall, wo der AAAF den HA spezifiziert (siehe 41)
Hier werden die Betriebsschritte von beispielsweise dem AAAF 400p, der in 41 gezeigt ist, beschrieben.

S21: Der Prozess schreitet zu dem Schritt S51 auf einen Empfang einer HAA-(Hausvermittler-MIP-Antwort)-Nachricht von dem HA als eine Antwort auf eine HAR-Nachricht fort.
S51: Eine Sitzungstransaktion wird auf der Grundlage eines Sitzungs-ID identifiziert, und der Betriebszustand der Sitzungstransaktion wird überprüft. Es sei hier angenommen, dass "HA wird angefordert" als der Betriebszustand gesetzt ist. Der Prozess schreitet deswegen zu dem Schritt S52 fort.
S52: Der AAAH wird aus der Sitzungstransaktion identifiziert, und eine AMA-Nachricht wird zu dem AAAH gesendet.
S33: "Warten, verarbeitet zu werden" wird als der Betriebszustand gesetzt.

(7) Prozedur zum Ausführen einer Registrierungsantwort in dem Fall, wo der AAAH einen HA spezifiziert

S21: Der Prozess schreitet zu dem Schritt S51 auf einen Empfang einer HAA-Nachricht von dem HA als eine Antwort auf eine HAR-Nachricht hin fort.
S51: Eine Sitzungstransaktion wird auf der Grundlage eines Sitzungs-ID identifiziert, und der Betriebszustand der identifizierten Transaktion wird überprüft. Wenn der AAAF den HA spezifiziert, wird "AMA wird verarbeitet" als der Betriebszustand gesetzt. Dies liegt daran, dass die Schritte S43 und S44 ausgeführt worden sein sollten. Dementsprechend schreitet der Prozess zu dem Schritt S53 fort.
S53: Der FA wird aus der Sitzungstransaktion identifziert, und die AMA-Nachricht, an welcher ein Diensteprofil angebracht ist, wird zu dem identifizierten FA gesendet.
S33: "Warten, verarbeitet zu werden" wird als der Betriebszustand gesetzt.

(8) Prozedur zum Freigeben einer Sitzung

S21: Der Prozess schreitet zu dem Schritt S61 auf den Empfang einer SFR-Nachricht von dem AAAH hin fort. Es sei darauf hingewiesen, dass die SFR-Nachricht aus Gründen, wie etwa einem Berechnungsprozessstopp, einem Fehler, etc. erzeugt wird.
S61: Eine Sitzungstransaktion wird auf der Grundlage eines Sitzungs-ID identifiziert, und eine SFR-Nachricht wird zu dem AAAH, der aus der Transaktion identifiziert ist, gesendet.
S62: Die Sitzungstransaktion wird freigegeben.

45 ist ein Flussdiagramm, das die Betriebsschritte des HA 200, des FA 500 oder des CN 700 erläutert. Dieser Prozess wird auf einen Empfang eines Pakets hin durchgeführt.
In dem Schritt S71 wird die IP-Header-Information eines empfangenen Pakets extrahiert. Der IP-Header ist der in 62A gezeigte. Es sei daran erinnert, dass dieser Prozess von der Paketsteuereinheit 201 durchgeführt wird. In dem Schritt S72 werden die Zieladresse und die Anschlussnummer in der Header-Information referenziert, und es wird erfasst, ob das empfangene Paket entweder ein Daten- oder ein Protokollpaket ist. Die Schritte S73 bis S75 werden ausgeführt, wenn ein Protokollpaket empfangen wird, und die Schritte S76 bis S79 werden ausgeführt, wenn ein Datenpaket empfangen wird.
(1) Betriebsschritte, die durchgeführt werden, wenn ein Protokollpaket empfangen wird

S73: Auf einen Empfang einer Protokollprozessanforderung von der Paketsteuereinheit 201 hin analysiert die Protokollsteuereinheit 202 die Anschlussnummer des UDP-Headers und erfasst, ob ein angeforderter Prozess entweder ein Mobil-IP oder ein DIAMETER-Prozess ist.
S74: Wenn ein Diensteprofil von dem DIAMETER-Protokoll verteilt wird, wird der Diensteprofil-Cache der Individualdienst-Steuereinheit 203 mit dem verteilten Diensteprofil aktualisiert.
S75: Die Tabelle der Dienste-unabhängigen Einheit 204 wird gemäß einer Mobil-IP-Nachricht erzeugt, und die Information, die für diese Tabelle erforderlich ist, wird gesetzt. Zusätzlich wird eine notwendige Nachricht gemäß der Mobil-IP gesendet.

(2) Betriebsschritte, die durchgeführt werden, wenn ein Datenpaket empfangen wird

S76: Der Diensteprofil-Cache wird unter Verwendung der Header-Information, die von der Paketsteuereinheit 201 extrahiert ist, als ein Schlüssel gemäß der Strategie durchsucht, die in der Suchstrategie-Verwaltungstabelle gesetzt ist. Dann wird das empfangene Paket gemäß einer "Routing/Paketeditierinformation" in dem extrahierten Diensteprofil editiert. Dieser Prozess wird durch die Individualdienst-Steuereinheit 203 durchgeführt.
S77: Wenn eine vorbestimmte Funktion der Dienste-unabhängigen Einheit 204 durch das Diensteprofil, das in dem Schritt S76 extrahiert ist, spezifiziert ist, wird der Dienste-unabhängigen Einheit 204 eine Steuerung vorgegeben, und der Prozess schreitet zu dem Schritt S78 fort.
S78: Die Dienste-unabhängige Einheit 204 bestimmt das Editierverfahren und das Sendeziel des Pakets unter Referenzieren auf die Steuertabelle, die durch das Diensteprofil spezifiziert ist.
S79: Nachdem das Paket in Abhängigkeit von einem Bedarf editiert ist, wird es geschickt.

7D. Verwaltung von Diensteprofilen
Mit dem System gemäß dieser Ausführungsform kann jeder Benutzer einen Dienst auswählen, den er oder sie zu verwenden wünscht. Dementsprechend existieren eine Vielfalt von Benutzern. Ein Benutzer fordert verschiedene Mehrwert-Dienste an, ein weiterer Benutzer fordert keinen Mehrwert-Dienst an, und noch ein weiterer Benutzer fordert nur einen bestimmten fundamentalen Mehrwert-Dienst an. Die Information über den Dienst, der von jedem Benutzer angefordert wird, ist in der Dienstesteuerdatenbank 300 für jeden Benutzer gespeichert.
Ein Verfahren, das ein Diensteprofil effizient verwendet, wird untenstehend unter der Annahme des Falls erläutert, wo keine der Mehrwert-Dienste angefordert werden, und deshalb, wo nur ein bestimmter fundamentaler Mehrwert-Dienst angefordert wird.
(1) Verwaltung eines Diensteprofils für den Benutzer, der keine Mehrwert-Dienste anfordert
Ein HA und ein FA erzeugen jeweils die Diensteprofile, die in den 46 und 47 zu der Zeit einer Anfangskonfiguration gezeigt sind. Ein Minimum der Information, die erforderlich ist, um die Mobil-IP zu unterstützen, ist in jedem der Diensteprofile gesetzt.
Ein AAAH erzeugt nicht ein Diensteprofil für den Benutzer, der keine Mehrwertdienste anfordert, wenn die Registrierung seines oder ihres Mobilknotens angefordert wird. Ob der Benutzer des Mobilknotens, der die Registrierungsanforderungsnachricht sendet, einen Mehrwertdienst anfordert oder nicht, kann beispielsweise durch ein Durchsuchen einer Dienstesteuerdatenbank mit der Verwendung des NAI, der in der AMR-Nachricht gesetzt ist, die auf eine Registrierungsanforderung hin gesendet wird, als ein Schlüssel bestimmt werden. "Kein Erzeugen eines Diensteprofils auf eine Anforderung einer Mobilknotenregistrierung hin" ist ein Beispiel einer Diensteprofil-Konfigurationsstrategie in dem Schritt S4 der 42.
Dementsprechend wird ein Diensteprofil für einen Mehrwert-Dienst nicht erneut von dem AAAH zu dem HA und dem FA verteilt. Überdies werden keine Einstellungen von dem HA und dem FA in dem AAA-übermittelten SPC in den Diensteprofil-Cache für diesen Benutzer ausgeführt, wie in den 46 und 47 gezeigt.
Wenn ein Datenpaket, das an den Korrespondenzknoten CN adressiert ist, von dem Mobilknoten in der oben beschriebenen Konfiguration gesendet wird, wird es von dem FA empfangen, der den Mobilknoten aufnimmt. Auf einen Empfang dieses Datenpakets hin durchsucht der FA den Diensteprofil-Cache, der in 47 gezeigt ist. Hier sind der "Mobilknoten" und der "Korrespondenzknoten CN" als die Quellenadresse und die Zieladresse dieses Datenpakets jeweils gesetzt. Dementsprechend muss, wenn der Diensteprofil-Cache, der in 47 gezeigt ist, gemäß der in 20 gezeigten Suchstrategie durchsucht wird, ein Vorbesetzt-Diensteprofil (NDSP) referenziert werden. In dem Vorbesetzt-Diensteprofil (NDSP) ist eine Routingtabelle, die ein Router ursprünglich verwaltet, als eine Tabelle bezeichnet, auf die zuzugreifen ist. Das empfangene Datenpaket wird deswegen an den Korrespondenzknoten CN gemäß der Routingtabelle geschickt.
Oder wenn das Datenpaket, das an den Mobilknoten adressiert ist, von dem Korrespondenzknoten CN geschickt wird, wird es zu dem HA übertragen, der der Hausvermittler des Mobilknotens ist. Auf einen Empfang dieses Datenpakets hin durchsucht der HA den Diensteprofil-Cache, der in 46 gezeigt ist. Hier sind der "Korrespondenzknoten" und der Mobilknoten" als die Quellenadresse bzw. die Zieladresse des Datenpakets gesetzt. Dementsprechend muss, wenn der Diensteprofil-Cache, der in 46 gezeigt ist, gemäß der in 20 gezeigten Suchstrategie durchsucht wird, ein Zieldiensteprofil (NSPCdst) referenziert werden. Weil eine Mobilitätsbindung durch das Zieldiensteprofil (NSPCdst) als eine Tabelle, auf die zuzugreifen ist, bezeichnet wird, wird das empfangene Datenpaket zu dem FA gemäß der Mobilitätsbindung geschickt. Zu dieser Zeit wird dieses Paket eingekapselt.
Auf einen Empfang des eingekapselten Pakets hin durchsucht der FA das in 47 gezeigte Diensteprofil. Hier sind der "HA" und der "FA (Care-Off-Adresse)" als die Quellenadresse bzw. die Zieladresse dieses Datenpakets gesetzt.
Dementsprechend muss, wenn der Diensteprofil-Cache, der in 47 gezeigt ist, gemäß der in 20 gezeigten Suchstrategie durchsucht wird, das Zieldiensteprofil referenziert werden. Folglich wird dieses Datenpaket entkapselt. Überdies wird, da der Diensteprofil-Cache als Information, auf die durch das Zieldiensteprofil (NSPCdst) zuzugreifen ist, bezeichnet wird, dieser wiederum unter Verwendung der Header-Information des entkapselten Pakets als ein Schlüssel durchsucht.
Der "HA" und der "Mobilknoten" werden jeweils an die Quellenadresse und die Zieladresse des entkapselten Datenpakets gesetzt. Deswegen muss, wenn der Diensteprofil-Cache, der in 47 gezeigt ist, gemäß der in 20 gezeigten Suchstrategie durchsucht wird, das Ziel-Vorbesetzt-Diensteprofil (NDSPdst) referenziert werden. Dementsprechend wird das entkapselte Paket zu dem Mobilknoten gemäß der Besucherliste geschickt.
(2) Verwaltung eines Diensteprofils für einen Benutzer, der nur einen bestimmten Mehrwert-Dienst anfordert
Es wird erwartet, dass viele Benutzer den fundamentalen Mehrwert-Dienstesatz (wie etwa den Qualitätsgarantie-Dienst, der in 7 gezeigt ist), der von einem Internet-Dienste-Provider bereitgestellt wird, unverändert verwenden, obwohl manche Benutzer einen feinkörnigeren Dienst wünschen. In einer derartigen Situation konvertiert ein Diensteprofilmuster zu einem numerischen Muster. Deswegen kann eine Diensteprofil-Einstellung für jeden Benutzer zu einer Verschwendung von Resourcen führen.
Als ein Verfahren zum Überwinden dieses Problems wird ein Verfahren betrachtet, das eine Entsprechung zwischen einer Diensteklasse, die bereitzustellen ist, und der IP-Adresse, die von einem AAA oder einem HA zuvor zugewiesen wird, ausführt. Beispielsweise bestimmt ein Internet-Dienste- Provider einen IP-Adressbereich, der einen Mobilknoten für jede Diensteklasse zugeordnet wird, und übermittelt anderen Providern den vorbestimmten Bereich. Der Provider, der diese Benachrichtigung empfängt, setzt eine notwendige Information in die Diensteprofil-Caches jedes HA und jedes FA gemäß der Benachrichtigung.
Der AAAH bestimmt, ob der Benutzer eines Mobilknotens nur den fundamentalen Mehrwert-Dienstesatz anfordert, wenn dem Mobilknoten beispielsweise bei einer Anwahlprozedur eine IP-Adresse zugewiesen wird, oder nicht. Ob jeder Benutzer nur den fundamentalen Mehrwert-Dienstesatz anfordert oder nicht, und welche Diensteklasse ausgewählt wird, wenn der Fundamentalsatz angefordert wird, kann durch ein Referenzieren auf die Dienstesteuerdatenbank 300 erfasst werden. Wenn der Benutzer nur den fundamentalen Mehrwertdienstesatz anfordert, weist der AAAH dem Mobilknoten die IP-Adresse zu, die der Diensteklasse entspricht, die von dem Benutzer ausgewählt ist. Zu dieser Zeit verteilt der AAAH ein Diensteprofil zu dem HA und dem FA nicht. Es sei darauf hingewiesen, dass "ein Diensteprofil nicht erzeugen, wenn eine IP-Adresse zugewiesen ist" ein Beispiel einer Diensteprofil-Konfigurationsstrategie in dem Schritt S4 der 42 ist.
Der HA und der FA stellen den fundamentalen Mehrwert-Dienstesatz unter Referenzieren auf den Diensteprofil-Cache bereit. Folglich wird die Kapazität des Diensteprofil-Caches verringert. Überdies ist es ausreichend, wenn nur den oberen Abschnitt einer IP-Adress zu überprüfen, wenn der Diensteprofil-Cache durchsucht wird, wodurch die Suche beschleunigt wird.
48 zeigt ein Beispiel des Verfahrens zum Vorbestimmen von IP-Adressbereichen, die für Diensteklassen verwendet werden. In diesem Beispiel sind "172.27.180.*", "172.27.185.*" und "172.27.190.*" jeweils den Diensteklassen A, B und C als die IP-Adressbereiche zugewiesen. Hier ist "*" ein Platzhalter. In den Diensteprofilen, die zu dem HA und dem FA verteilt werden, ist beispielsweise "172.27.180.*" als eine Zielpaket-Steuerinformation gesetzt, und die Information zum Bereitstellen der Diensteklasse A ist als ein Routing/Paketeditierverfahren und eine einzelne Steuerinformation gesetzt. Dementsprechend führen auf einen Empfang des Pakets, das den oberen Adressabschnitt "172.27.180" als eine Quellenadresse oder eine Zieladresse aufweist, der HA und der FA den Prozess zum Unterstützen der Diensteklasse A für dieses Paket durch.
7E. Routenoptimierung
Das Paket, das von dem Korrespondenzknoten CN 700 an den Mobilknoten 600 adressiert ist, wird einmal zu dem HA 200 gemäß der Adresse des Mobilknotens 600 in normalen Fällen übertragen. Das Paket wird dann zu dem Mobilknoten 600 übertragen, nachdem es von dem HA 200 zu dem FA 500 geschickt worden ist.
Ein Routenoptimierungsprozess ist eine Prozedur zum direkten Übertragen eines Pakets, das an den Mobilknoten 600 adressiert ist, zu dem FA 500 nicht über den HA 200, in dem oben beschriebenen Fall. Eine Verteilung eines Diensteprofils, von dem es erforderlich ist, dass es die oben beschriebene Optimierung implementiert, wird untenstehend unter Bezugnahme auf 49 erläutert.

(1) Der HA 200 empfängt das Datenpaket, das an den Mobilknoten 600 adressiert ist, von dem Korrespondenzknoten CN 700. In diesem Fall trifft dieses Paket das Diensteprofil, bei welchem die Adresse des Mobilknotens 600 als die Filterinformation für die Zieladresse gesetzt ist. Dementsprechend editiert der HA 200 das Paket und kapselt es gemäß der Information des getroffenen Diensteprofils ein, und sendet das eingekapselte Paket zu dem FA 500, der den Mobilknoten 600 aufnimmt. Der FA 500 entkapselt das empfangene Paket und schickt das entkapselte Paket zu dem Mobilknoten 600.
(2) Der HA 200 erkennt, dass der Korrespondenzknoten CN 700 keinen Diensteprofil-Cache und einen Bindungs-Cache aufweist, indem das Datenpaket, das von dem Korrespondenzknoten CN 700 gesendet wird, empfangen wird. Der HA 200 bringt dann das Diensteprofil, das oben beschrieben in (1) verwendet wird, an einer Bindungsaktualisierungsnachricht an und sendet diese Nachricht zu dem Korrespondenzknoten CN 700.
(3) Ein "A-(Antwort)-Bit" der Bindungsaktualisierungsnachricht wird verwendet, um eine Bindungsbestätigungsnachricht anzufordern. Überdies wird eine "Routenoptimierungs-Authentifizierungserweiterung (RO-Authentifizierung)" verwendet, wenn der Korrespondenzknoten CN 700 eine Routenoptimierungsanforderung authentifiziert. Es sei darauf hingewiesen, dass ein Diensteprofil eine Erweiterung für eine Dienstesteuerung ist.
(4) Auf einen Empfang der Bindungsaktualisierungsnachricht hin erzeugt der Korrespondenzknoten CN 700 ein Diensteprofil und einen Bindungs-Cache. Wenn das "A-Bit" gesetzt ist, gibt der Korrespondenzknoten CN 700 eine Bindungsbestätigungsnachricht zu dem HA 200 zurück. Die Lebensdauer des Bindungs-Caches ist eine gegenwärtig verbleibende Zeit der durch die Registrierungsanforderungsnachricht eingesetzten Lebensdauer.
Der Bindungs-Cache wird beispielsweise, wie in 23 gezeigt, konfiguriert. In dem oben beschriebenen Beispiel sind der "Korrespondenzknoten CN 700", der "Mobilknoten 600" und der "FA 500" jeweils als eine Quellenadresse, eine Zieladresse und eine Care-Off-Adresse gesetzt. In diesem Fall ist die "Adresse des Mobilknotens 600" als die Zieladresse einer Zielpaket-Steuerinformation gesetzt, und der Bindungs- Cache ist als eine Tabelle spezifiziert, auf die in dem Diensteprofil zuzugreifen ist.
(5) Der Korrespondenzknoten CN 700 referenziert das Diensteprofil, das oben beschrieben in (4) erzeugt ist, wenn das Paket, das an den Mobilknoten 600 adressiert ist, gesendet wird. Da der Mobilknoten 600 in diesem Fall für das Zieldiensteprofil (ASPCdst) in dem Diensteprofil registriert ist, das von dem AAA übermittelt ist, wird der Bindungs-Cache referenziert. Folglich wird das Paket eingekapselt und zu dem FA 500 getunnelt, der als die Care-Off-Adresse spezifiziert ist. Zu dieser Zeit wird ein notwendiges Editieren für das eingekapselte Paket gemäß dem Diensteprofil durchgeführt.

Wie oben beschrieben, wird ein Diensteprofil von dem HA zu dem Korrespondenzknoten CN verteilt, so dass die Verteilung des Diensteprofils mit einer Routenoptimierung auf einfache Weise implementiert werden kann. Wenn der Routenoptimierungsprozess nicht erforderlich ist, besteht kein Bedarf, die Individualdienst-Steuereinheit 203 und die Dienste-unabhängige Einheit 204 in dem Korrespondenzknoten CN anzuordnen.
8. ANYCAST-Dienst
Es können Fälle vorhanden sein, wo ein einzelner Benutzer eine Mehrzahl von Endgeräten besitzt und es wünscht, ein beliebiges davon Umständen gemäß zu verwenden. Überdies ist in einem System, das eine Mehrzahl von Servern einschließt, die Konfiguration, wo ein Zugriff auf dieses System in einen beliebigen Server geteilt ist, um die Last jedes der Server zu verteilen, bekannt.
In dem ersteren Fall wird eine virtuelle Adresse, die von der Mehrzahl von Endgeräten geteilt wird, verwendet. Wenn ein Paket zu der virtuellen Adresse gesendet wird, wird es zu einem vorbestimmten der Endgeräte geschickt. Im letzteren Fall wird eine virtuelle Adresse, die von einer Mehrzahl von Servern geteilt wird, benutzt. Wenn ein Zugriff auf diese Adresse ausgeführt wird, wird ein Paket zu einem vorbestimmten der Server gesendet.
In dieser Ausführungsform ist der oben beschriebene Dienst definiert, als ein ANYCAST-Dienst bezeichnet zu werden. Zusätzlich ist die virtuelle Adresse in dem oben beschriebenen Beispiel definiert, als eine "ANYCAST-Adresse" bezeichnet zu werden.
50 ist ein schematisches Diagramm, das einen ANYCAST-Dienst erläutert. In dieser Figur ist eine ANYCAST-Adresse (IP#A1) mit einer Mehrzahl von Servern #1 bis #4 zugeordnet. Hier ist eine ANYCAST-Adresse ein Unternetz eines Adress-Proxy-Servers (AP) 800, der später zu beschreiben ist. Zusätzlich sind tatsächliche IP-Adressen der Server #1 bis #4 jeweils "IP#H1" bis "IP#H4". Die Server #1 und #4 sind durch einen FA 500 (#1) aufgenommen, wohingegen die Server #3 und #4 durch einen FA 500 (#2) aufgenommen sind.
Der Adress-Proxy-Server 800 weist grundsätzlich die gleiche Konfiguration wie jene eines HA auf. Es sei jedoch darauf hingewiesen, dass der Adress-Proxy-Server 800 das Paket überträgt, bei welchem eine ANYCAST-Adresse auf eine oder eine Mehrzahl von Adressen gesetzt ist, die der ANYCAST-Adresse entsprechen. In dem in 50 gezeigten Beispiel überträgt der Adress-Proxy-Server 800 auf einen Empfang des Pakets, bei welchem die ANYCAST-Adresse (IP#A1) gesetzt ist, hin das Paket zu einem der Server #1 bis #4. Zu welchem der Server das Paket zu übertragen ist, ist in dem Diensteprofil beschrieben, das durch einen AAAH erzeugt und verteilt ist.
Ein ANYCAST-Dienst wird durch den AAAH in der in 13 gezeigten ANYCAST-Adressverwaltungstabelle verwaltet. Diese Tabelle speichert einen oder mehrere NAIs, die einer ANYCAST-Adresse entsprechen, die Hausadresse des Endgeräts, das durch jeden NAI identifiziert ist, und den Zustand des Endgeräts, das durch jeden NAI identifiziert ist, für jede ANYCAST-Adresse. Der Zustand des Endgeräts ist beispielsweise ein Online-, ein Offline-, ein anhängiger, ein fehlerhafter, ein Stau-Zustand, etc. In dem in der 50 gezeigten Beispiel sind die IP-Adressen (IP#H1 bis IP#H4) der Server #1 bis #4 und ihre Zustände für die ANYCAST-Adresse (IP#A1) gesetzt.
Der AAAH erzeugt ein Diensteprofil zum Übertragen des Pakets, bei welchem eine ANYCAST-Adresse gesetzt ist, zu einer oder einer Mehrzahl von Adressen, die der ANYCAST-Adresse entsprechen, und verteilt das erzeugte Profil zu dem Adress-Proxy-Server 800. Ein Beispiel des Diensteprofils, das zu dem Adress-Proxy-Server 800 verteilt ist, ist in 51 gezeigt.
Bei "Übertragungszieladresse" in diesem Diensteprofil sind eine oder eine Mehrzahl von IP-Adressen (IP#H1 bis IP#H4) der Server #1 bis #4 gesetzt. Welche der Adressen zu setzen ist, wird gemäß der Adressenauswahlstrategie in dem in 11 gezeigten Profil bestimmt. Die Adressauswahlstrategie ist beispielsweise "Auswählen eines Endgeräts in einem Online-Zustand", "ein Endgerät in einem Offline-, andauernden, fehlerhaften oder Stau-Zustand nicht anwählen", etc.
Wenn das oben beschriebene Diensteprofil verteilt ist, sendet der Adress-Proxy-Server 800 das Paket zu dem Ziel, das von dem Diensteprofil spezifiziert ist. Wenn eine Mehrzahl von Zielen durch das Diensteprofil spezifiziert sind, kann der Adress-Proxy-Server 800 sequentiell die Übertragungsziele nacheinander auswählen.
Zu dem HA 200 wird das in 52 gezeigte Diensteprofil verteilt. In diesem Diensteprofil ist eine Mobilitätsbindung als eine Tabelle, auf die zuzugreifen ist, spezifiziert. Bei der Mobilitätsbindung ist der FA 500 (#1) den IP-Adressen der Server #1 und #2 zugeordnet, wie in 50 gezeigt, wohingegen der FA 500 (#2) den IP-Adressen der Server #3 und #4 zugeordnet ist.
Zu dem FA 500 wird das Diensteprofil, das in 53 gezeigt ist, verteilt. Dieses Diensteprofil wird für das Endgerät erzeugt, das an einem ANYCAST-Dienst subskribiert. In diesem Diensteprofil ist die in 24 gezeigte ANYCAST-Tabelle als eine Tabelle, auf die zuzugreifen ist, spezifiziert. Die ANYCAST-Tabelle wird durch ein Einstellen einer "ANYCAST-Adresse" und der Adresse eines Adress-Proxy-Servers" bei einer normalen Besucherliste erhalten.
Der FA 500 erzeugt das in 54 gezeigte Diensteprofil. Bei diesem Diensteprofil ist die Information zum Bereitstellen der Fundamentalfunktionen der Mobil-IP gesetzt. Auch das in 55 gezeigte Diensteprofil wird zu dem FA 500 verteilt. Dieses Diensteprofil wird für das Endgerät erzeugt, das nicht an dem ANYCAST-Dienst subskribiert.
Wenn das Paket, bei welchem eine ANYCAST-Adresse gesetzt ist, von dem Endgerät #1 in dem oben beschriebenen System gesendet wird, wird es zu dem Adress-Proxy-Server 800 übertragen. Der Adress-Proxy-Server 800 überträgt dieses Paket zu einem vorbestimmten Server gemäß dem Diensteprofil, das von dem AAAH verteilt ist. In diesem Beispiel ist die IP-Adresse (IP#H2) des Servers #2 in diesem Paket gesetzt.
Dieses Paket wird zu dem HA 200 übertragen, der der Hausvermittler des Servers #2 ist. Der HA 200 überträgt das Paket zu dem FA 500 (#1) gemäß der Mobilitätsbindung. Dieses Paket wird doppelt eingekapselt.
Auf einem Empfang dieses Pakets hin ruft der FA 500 (#1) die ANYCAST-Tabelle durch ein Referenzieren auf die Diensteprofile, die in den 54 und 53 gezeigt sind. Der FA 500 (#1) entkapselt das Paket dann durch ein Erfassen der Verbindungsschichtadresse des Servers #2 aus der IP-Adresse des Servers #2 auf der Grundlage der ANYCAST-Tabelle, und durch ein Erkennen der ANYCAST-Adresse und des Adress-Proxy-Servers 800. Folglich wird das entkapselte Paket dem Server #2 zugeführt. Auf ähnliche Weise wird das Paket, das von dem Endgerät #2 gesendet wird, zu dem Server #3 übertragen.
Auf diese Weise führen der Adress-Proxy-Server, der HA und der FA den ANYCAST-Dienst gemäß den Diensteprofilen aus, die von dem AAAH erzeugt sind. Zu dieser Zeit wird das Endgerät, das an dem ANYCAST-Dienst subskribiert, von dem AAAH auf eine zentralisierte Weise verwaltet. Dementsprechend wird das Paket in dem ANYCAST-Dienst zu einem geeigneten Mobilknoten ohne Fehler übertragen.
Die 56 und 57 veranschaulichen beispielhaft die Sequenz zum Setzen einer ANYCAST-Information. Diese Sequenz wird gestartet, wenn der Mobilknoten 600 eine Registrierungsanforderungsnachricht zu dem FA 500 sendet. Es sei daran erinnert, dass der AAAH 100 einen Authentifizierungs-Server und einen Autorisierungs-Server einschließt.

(1) Auf den Empfang der Registrierungsanforderungsnachricht hin erzeugt der FA 500 eine Besucherliste und sendet gleichzeitig eine AMR-Nachricht.
(2) Der Authentifizierungsserver des AAAH 100, der die AMR-Nachricht empfangen hat, extrahiert die Authentifizierungsinformation des Benutzers aus der Dienstesteuerdatenbank 300.
(3) Wenn die Authentifizierung erfolgreich ausgeführt ist, wird eine Dienstesteuerung für den Autorisierungs-Server angefordert. Der Autorisierungs-Server liest dann das entsprechende Diensteprofil aus der Dienstesteuerdatenbank 300 und extrahiert eine ANYCAST-Adresse.
(4) Der Autorisierungs-Server sendet eine ANYCAST-Registrierungsanforderungsnachricht zu dem Adress-Proxy-Server 800. Das Diensteprofil wird an dieser Nachricht angebracht.
(5) Der Adress-Proxy-Server 800 spezifiziert den HA 200, der als der Hausvermittler des Mobilknotens 600 dient, und spezifiziert auch gleichzeitig die Hausvermittleradresse des Mobilknotens. Folglich wird der Diensteprofil-Cache, der in 51 gezeigt ist, erzeugt.
(6) Der Adress-Proxy-Server 800 benachrichtigt den Autorisierungs-Server über die Adresse des HA 200 und die Hausadresse des Mobilknotens 600 unter Verwendung einer ANYCAST-Registrierungsantwortnachricht.
(7) Der Autorisierungs-Server erzeugt die in 13 gezeigte Adressverwaltungstabelle. Zusätzlich erzeugt der Autorisierungsserver das Diensteprofil, das dem Mobilknoten 600 entspricht, der die Registrierungsanforderungsnachricht gesendet hat.
(8) Der Autorisierungs-Server benachrichtigt den Authentifizierungs-Server über das erzeugte Diensteprofil unter Verwendung einer Dienstesteuerantwortnachricht.
(9) Der Registrierungsanforderungsprozess wird mit einer normalen Prozedur ausgeführt.
(10) Auf einen Empfang der AMA-Nachricht hin erzeugt der FA 500 eine ANYCAST-Tabelle (erweiterte Besucherliste) auf der Grundlage der Besucherliste und der Information, die durch die AMA-Nachricht übermittelt ist. Der FA 500 benachrichtigt dann den Mobilknoten 600 über die ANYCAST-Adresse.

58 veranschaulicht beispielhaft die Sequenz zum Übertragen eines Pakets unter Verwendung eines ANYCAST- Dienstes. Jedes der Pakete, die in 58 gezeigt sind, stellen sequentiell "eine Quellenadresse", "eine Zieladresse" und eine Nutzlast, von der linken Seite des Zeichnungsblatts an, dar. Die Adressen, die in dieser Figur durch Pfeile angezeigt sind, sind jene, die in einem Routingprozess referenziert sind.
Bereitgestellt unten stehend ist die Sequenz, die implementiert wird, wenn der Korrespondenzknoten CN 700, der ein Datenpaket von dem Mobilknoten 600 empfangen hat, das Paket zu dem Mobilknoten 600 zurückgibt. Es wird angenommen, dass dem Mobilknoten 600 eine ANYCAST-Adresse mit dem oben beschriebenen Prozess gegeben wird.

(1) Der Korrespondenzknoten CN 700 sendet das Paket, dessen Ziel die ANYCAST-Adresse, die dem Mobilknoten 600 zugewiesen ist, ist. Hier ist die ANYCAST-Adresse eine Adresse des Unternetzes des Adress-Proxy-Servers 800. Dementsprechend wird dieses Paket zu dem Adress-Proxy-Server 800 geschickt.
(2) Auf einen Empfang des Pakets hin referenziert der Adress-Proxy-Server das Diensteprofil, das der ANYCAST-Adresse entspricht, die in dem Paket gesetzt ist, und wählt eine der Hausadressen des Mobilknotens 600 aus dem Diensteprofil aus. Ein Verfahren zum Auswählen einer einer Mehrzahl von Hausadressen ist nicht sonderlich beschränkt. Jedoch wird im Wege eines Beispiels eine Hausadresse sequentiell ausgewählt.
(3) Der Adress-Proxy-Server 800 erzeugt ein Diensteprofil, um die ausgewählte Hausadresse des Mobilknotens 600 und die Adresse des Korrespondenzknotens CN 700 zu binden, und sendet das erzeugte Diensteprofil zu dem Korrespondenzknoten CN 700 unter Verwendung einer Bindungsaktualisierungsnachricht. Die Adresse, die durch diese Nachricht übermittelt wird, ist nicht die Care-Off-Adresse (die Adresse des FA, der den Mobilknoten 600 aufnimmt) des Mobilknotens 600, sondern die Hausadresse des Mobilknotens 600.
(4) Der Adress-Proxy-Server 800 kapselt das Paket, das von dem Korrespondenzknoten 700 empfangen wird, ein und sendet das eingekapselte Paket zu der Hausadresse, die oben beschrieben in (2) ausgewählt ist. Dieses Paket wird zu dem HA 200 gemäß der Hausadresse des Mobilknotens 600 übertragen.
(5) Auf einen Empfang des eingekapselten Pakets hin kapselt der HAA 200 das Paket weiter ein. Der HA 200 sendet dann das doppelt eingekapselte Paket zu der Care-Off-Adresse des Mobilknotens 600. Auf diese Weise wird das doppelt eingekapselte Paket zu dem FA 500 übertragen.
(6) Auf einen Empfang des oben beschriebenen Pakets hin referenziert der FA 500 die ANYCAST-Tabelle oder die Besucherliste und sendet das empfangene Paket zu dem Mobilknoten 600. Spezifisch wird der Diensteprofil-Cache unter Verwendung der Adresse (Care-Off-Adresse) des FA 500 als ein Schlüssel durchsucht, so dass der Vorbesetzt-Diesnteprofil-Cache, der in 54 gezeigt ist, trifft. Dementsprechend wird das empfangene Paket gemäß diesem Diensteprofil entkapselt. Dann wird der Diensteprofil-Cache wiederum unter Verwendung der Hausadresse des Mobilknotens 600 als ein Schlüssel durchsucht. Bei dieser Suche trifft der Diensteprofil-Cache, der in 53 gezeigt ist. Das empfangene Paket wird wiederum gemäß dem Diensteprofil entkapselt. Das entkapselte Paket wird dann dem Mobilknoten 600 zugeführt.

Nach einem Empfangen der Bindungsaktualisierungsnachricht durch oben beschriebene (3) sendet der Korrespondenzknoten CN 700 ein eingekapseltes Paket zu dem Netz nach einem Einkapseln des Pakets, bei welchem eine ANYCAST-Adresse als eine Zieladresse gesetzt ist, für sich selbst.
Die 59 und 60 veranschaulichen beispielhaft die Sequenz zum Löschen einer Registrierung bei einem ANYCAST-Dienst. Es sei hier angenommen, dass der AAAH einen Authentifizierungs-Server, einen Autorisierungs-Server und einen Abrechnungs-Server einschließt.

(1) Der Mobilknoten 600 sendet eine Registrierungsanforderungsnachricht, bei welcher "Zeitgeber = 0" gesetzt ist zu dem FA 500 auf eine Beendigung einer Kommunikation hin.
(2) Der FA 500 schickt die Registrierungsanforderungsnachricht zu dem HA 200.
(3) Auf einen Empfang der Registrierungsanforderungsnachricht hin, bei welchem "Zeitgeber = 0" gesetzt ist, sendet der HA 200 eine Bindungsaktualisierungsnachricht, bei welcher "Zeitgebung = 0" gesetzt ist, zu dem Korrespondenzknoten CN 700, zu welchem ein Diensteprofil verteilt wird.
(4) Auf einen Empfang der Bindungsaktualisierungsnachricht hin, bei welcher "Zeitgeber = 0" gesetzt ist, löscht der Korrespondenzknoten CN 700 den Diensteprofil-Cache des Mobilknotens 600 und gibt gleichzeitig eine Bindungsbestätigungsnachricht zu dem HA 200 zurück.
(5) Der HA 200 löscht den Diensteprofil-Cache des Mobilknotens 600 und gibt gleichzeitig eine Registrierungsantwortnachricht zu dem FA 500 zurück.
(6) Der FA 500 sendet die Registrierungsantwortnachricht zu dem Mobilknoten 600. Dann trennt der FA 500 eine Zugriffsnetzverbindung und sendet gleichzeitig eine Abrechnungs-Stopp-Nachricht zu dem Abrechnungsserver des AAAH 100.
(7) Der Abrechnungs-Server stoppt den Abrechnungsprozess und fordert den Autorisierungs-Server auf, die Sitzung freizugeben. Der Autorisierungs-Server fordert den Adress-Proxy-Server 800 auf, die Adressinformation des Mobilknotens 600 aus dem Diensteprofil zu löschen.
(8) Der Autorisierungs-Server fordert den Authentifizierungs-Server des AAAH 100 auf, die Sitzung freizugeben.
(9) Der AAAH 100 fordert den Authentifizierungs-Server des AAAF 400 auf, die Sitzung freizugeben.
(10) Der AAAF 400 löscht das Diensteprofil und gibt gleichzeitig eine Sitzungsfreigabeantwort an den AAAH 100 zurück.
(11) Der AAAH 100 löscht das Diensteprofil und gibt die Sitzungsfreigabeantwort an den Autorisierungs-Server zurück.
(12) Der Autorisierungs-Server gibt die Sitzungsfreigabeantwort an den Abrechnungsserver zurück.
(13) Der Abrechnungs-Server gibt die Abrechnungs-Stopp-Antwortnachricht an den FA 500 zurück.
(14) Der FA 500 löscht den Dienste-Cache.

Gemäß der vorliegenden Erfindung sind die Funktionen zum Steuern von Diensten in einem AAA zentralisiert, wodurch die Lasten für einen HA und einen FA verringert sind, und die Wartung (einschließlich einer Funktons-Hinzufügung und -Löschung) erleichtert ist.
Zusätzlich wird gemäß der vorliegenden Erfindung ein Diensteprofil, auf das referenziert wird, wenn ein Dienst für eine Mehrzahl von Mobilknoten bereitgestellt wird, die den gleichen Dienstesatz anfordern, geteilt, so dass es auf einfache Weise möglich wird, das Diensteprofil zu verwalten, und eine Suchgeschwindigkeit kann aufgrund der Kompression von Suchdaten erhöht werden.
Überdies sind gemäß der vorliegenden Erfindung eine Dienste-unabhängige Einheit, die Fundamentalfunktionen (einschließlich eines Routing-Prozesses und der Mobil-IP), die von einem Dienst nicht abhängig sind, und eine Individualdiensteinheit, die die Dienste-unabhängige Einheit auf der Grundlage der Information zum Bereitstellen jedes Dienstes verwendet, getrennt, wodurch ein Dienst auf einfache Weise hinzufügbar/änderbar ist.
Weiterhin kann gemäß der vorliegenden Erfindung ein bestimmtes Endgerät genau auf einer netzweiten Skala in einem Dienst spezifiziert werden, bei welchem eine virtuelle Adresse einer Mehrzahl von Endgeräten zugeordnet ist.

Claims

Mobilkommunikationsdienste-Bereitsstellungssystem, in welchem eine Ortsregistrierungs-Anfrageinformation von einem Mobilknoten (600) zu einem Hausvermittler (200) über einen fremden Vermittler (500) und ein Serversystem (100, 400) übertragen wird, und eine Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler (200) zu dem Mobilknoten (600) über das Serversystem (100, 400) und den fremden Vermittler (500) zurückgegeben wird, so dass ein Ort eines Mobilknotens für den Hausvermittler (200) und den fremden Vermittler (500) registriert ist, und ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt wird, dadurch gekennzeichnet, dass: der Hausvermittler (200) und der fremde Vermittler (500) eine Steuereinheit umfassen, die ein Übertragungsziel eines Pakets bestimmt; wobei das Serversystem (100, 400) umfasst: eine Extraktionseinheit, die ein Diensteprofil, das dem Mobilknoten (600) entspricht, aus einer Datenbank (300) zum Verwalten eines Diensteprofils, das eine Information zum Bereitstellen eines Dienstes gemäß der Ortsregistrierungs-Anforderungsinformation von dem Mobilknoten (600) einschließt, auf der Grundlage eines den Mobilknoten (600) identifizierenden Mobilknoten-Identifizierers, der in der Ortsregistrierungs-Anforderungsinformation eingeschlossen ist, extrahiert; eine Diensteverwaltungseinheit, die das Diensteprofil, das von der Extraktionseinheit extrahiert wird, in ein Format editiert, das für die Steuereinheit verfügbar ist, so dass der Hausvermittler und der fremde Vermittler das Diensteprofil verwenden können, ohne es selbst zu editieren, und eine Verteilungseinheit, die das Diensteprofil, das von der Diensteverwaltungseinheit editiert ist, zu dem Hausvermittler (200) und dem fremden Vermittler (500) verteilt, und der Hausvermittler (200) und der fremde Vermittler (500) einen Dienst unter Verwendung der Steuereinheit gemäß dem Diensteprofil bereitstellen, das von dem Serversystem (100, 400) verteilt ist.
System nach Anspruch 1, wobei das Serversystem (100, 400) ausgelegt ist, ein Diensteprofil zu dem Hausvermittler (200) und dem fremden Vermittler (500) nur dann zu verteilen, wenn der Mobilknoten (600) einen Mehrwert-Dienst anfordert, und der Hausvermittler (200) und der fremde Vermittler (500) einen Fundamental-Dienst gemäß einer Information bereitstellt, die der Hausvermittler (200) und der fremde Vermittler (500) selbst erzeugen.
System nach Anspruch 1, wobei: ein Adressbereich, der für einen vorbestimmten Dienst verfügbar ist, zuvor spezifiziert ist; ein Diensteprofil, das eine Information einschließt, die den Adressbereich darstellt, der zuvor spezifiziert ist, in dem Hausvermittler (200) und dem fremden Vermittler (500) als eine Bedingung zum Extrahieren eines entsprechenden Pakets aus empfangenen Paketen eingestellt ist; und das Serversystem (100, 400) eine Adresse innerhalb des Adressbereichs dem Mobilknoten (600), der den vorbestimmten Dienst anfordert, zuweist.
System nach Anspruch 1, wobei: das Serversystem (100, 400) eine Hausservervorrichtung (100), die ein Zugriffsrecht auf die Datenbank (300) aufweist, um das Diensteprofil für den Mobilknoten (600) zu extrahieren, und eine fremde Servervorrichtung (400) umfasst, die ein derartiges Zugriffsrecht nicht aufweist; und die Hausservervorrichtung (100) ausgelegt ist, das Diensteprofil zu dem Hausvermittler (200) und der fremden Vermittlervorrichtung (400) zu verteilen, und die fremde Servervorrichtung (400) ausgelegt ist, das Diensteprofil zu dem fremden Vermittler (500) zu schicken.
System nach Anspruch 1, wobei: das Serversystem (100, 400) eine Hausservervorrichtung (100), die ein Zugriffsrecht auf die Datenbank (300) aufweist, um das Diensteprofil für den Mobilknoten (600) zu extrahieren, und eine fremde Servervorrichtung (400) umfasst, die ein derartiges Zugriffsrecht nicht aufweist; und die Hausservervorrichtung (100) ausgelegt ist, das Diensteprofil zu der fremden Dienstevorrichtung (400) zu verteilen, und die fremde Dienstevorrichtung (400) ausgelegt ist, das Diensteprofil zu dem Hausvermittler (200) und dem fremden Vermittler (500) zu schicken.
System nach Anspruch 1, wobei: das Dienstesystem (100, 400) eine Hausservervorrichtung (100), die ein Zugriffsrecht auf die Datenbank (300) aufweist, um das Diensteprofil für den Mobilknoten (600) zu extrahieren, und eine fremde Servervorrichtung (400) umfasst, die ein derartiges Zugriffsrecht nicht aufweist; der Mobilknoten (600) ausgelegt ist, den Hausvermittler (200) über eine Ortsregistrierungs-Anforderungsinformation über einen zweiten fremden Vermittler (500n) zu benachrichtigen, wenn er sich von einem Kommunikationsgebiet eines ersten fremden Vermittlers (500p) zu einem Kommunikationsgebiet des zweiten fremden Vermittlers (500n) bewegt; der Hausvermittler (200) ausgelegt ist, eine Information zum Leiten eines Pakets zu aktualisieren, so dass ein Paket, das an den Mobilknoten (600) adressiert ist, zu dem zweiten fremden Vermittler (500n) übertragen wird; und die fremde Servervorrichtung (400) ausgelegt ist, das Diensteprofil zu dem zweiten fremden Vermittler (500n) zu verteilen.
System nach Anspruch 1, wobei: das Serversystem (100, 400) eine Hausservervorrichtung (100), die ein Zugriffsrecht auf die Datenbank (300) aufweist, um das Diensteprofil für den Mobilknoten (600) zu extrahieren, und erste und zweite fremde Servervorrichtungen (400p, 400n) umfasst, die ein derartiges Zugriffsrecht nicht aufweisen; der Mobilknoten (600) ausgelegt ist, den Hausvermittler (200) über eine Ortsregistrierungs-Anforderungsinformation über einen zweiten fremden Vermittler (500n), die zweite fremde Servervorrichtung (400n) und die Hausservervorrichtung (100) zu informieren, wenn er sich von einem Kommunikationsgebiet eines ersten fremden Vermittlers (500p), der von der ersten fremden Servervorrichtung (400p) verwaltet wird, zu einem Kommunikationsgebiet des zweiten fremden Vermittlers (500n) bewegt, der von der zweiten fremden Servervorrichtung (400n) verwaltet wird; der Hausvermittler (200) ausgelegt ist, eine Information zum Leiten eines Pakets zu aktualisieren, so dass ein Paket, das an den Mobilknoten (600) adressiert ist, zu dem zweiten fremden Vermittler (500n) übertragen wird; und die Hausservervorrichtung (100) ausgelegt ist, das Diensteprofil zu der zweiten fremden Servervorrichtung (400n) zu verteilen, die das Diensteprofil dann zu dem zweiten fremden Vermittler (500n) schickt.
System nach Anspruch 1, wobei: das Serversystem (100, 400) eine Hausservervorrichtung (100), die ein Zugriffsrecht auf die Datenbank (300) aufweist, um ein Diensteprofil für den Mobilknoten (600) zu extrahieren, und erste und zweite fremde Servervorrichtungen (400n, 400P) umfasst, die ein derartiges Zugriffsrecht nicht aufweisen; der Mobilknoten (600) ausgelegt ist, den Hausvermittler (200) über eine Ortsregistrierungs- Anforderungsinformation über einen zweiten fremden Vermittler (500n), die zweite fremde Servervorrichtung (400n), die Hausservervorrichtung (100) und die erste fremde Servervorrichtung (400p) zu informieren, wenn er sich von einem Kommunikationsgebiet eines ersten fremden Vermittlers (500p), der von der ersten fremden Servervorrichtung (400P) verwaltet wird, zu einem Kommunikationsgebiet des zweiten fremden Vermittlers (500n) bewegt, der von der zweiten fremden Servervorrichtung (400n) verwaltet wird; der Hausvermittler (200) ausgelegt ist, eine Information zum Leiten eines Pakets zu aktualisieren, so dass ein Paket, das an den Mobilknoten (600) adressiert ist, zu dem zweiten fremden Vermittler (500n) übertragen wird; und die Hausservervorrichtung (100) ausgelegt ist, das Diensteprofil zu der zweiten fremden Servervorrichtung (400n) zu verteilen, die das Diensteprofil dann zu dem zweiten fremden Vermittler (500n) schickt.
System nach Anspruch 1, wobei: auf einen Empfang des Pakets hin, das an den Mobilknoten (600) von einem entsprechenden Knoten (700) adressiert ist, der Hausvermittler (200) ausgelegt ist, ein Diensteprofil zum Extrahieren eines Pakets, in welchem der Mobilknoten (600) als ein Ziel eingestellt ist, zu dem entsprechenden Knoten (700) zu verteilen; und der entsprechende Knoten (700) ausgelegt ist, eine Information zum Übertragen eines Pakets, das gemäß dem verteilten Diensteprofil extrahiert ist, zu dem fremden Vermittler (500) zu übertragen.
System nach Anspruch 1, wobei dann, wenn ein Dienst zum Übertragen, zu einem beliebigen Mobilknoten unter einer Mehrzahl von Mobilknoten, eines Pakets mit einer virtuellen Adresse, die der Mehrzahl von Mobilknoten zugewiesen ist, als ein Ziel bereitgestellt wird: ein Adress-Proxyserver (800), der das Paket mit der virtuellen Adresse empfängt, angeordnet ist; und das Serversystem (100, 400) ausgelegt ist, zu dem Adress-Proxyserver (800) ein Diensteprofil zum Extrahieren des Pakets, dem die virtuelle Adresse zugewiesen ist, und zum Übertragen des extrahierten Pakets zu dem bestimmten Mobilknoten unter der Mehrzahl von Mobilknoten zu verteilen, und auch zu einem fremden Vermittler (500) ein Diensteprofil zum Übertragen zu dem bestimmten Mobilknoten, eines Pakets, das an den fremden Vermittler (500) adressiert ist, der den bestimmten Mobilknoten enthält, zu verteilen.
Mobilkommunikations-Dienstebereitstellungsverfahren, mit welchem eine Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten (600) zu einem Hausvermittler (200) über einen fremden Vermittler (500) und ein Serversystem (100, 400) übertragen wird, und mit welchem eine Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler (200) zu dem Mobilknoten (600) über das Serversystem (100, 400) und den fremden Vermittler (500) zurückgegeben wird, so dass ein Ort des Mobilknotens (600) für den Hausvermittler (200) und den fremden Vermittler (500) registriert wird, und ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt wird, dadurch gekennzeichnet, dass: der Hausvermittler (200) und der fremde Vermittler (500) eine Steuereinheit umfasst, die ein Übertragungsziel eines Pakets bestimmt, wobei das Verfahren umfasst: Extrahieren, durch das Serversystem (100, 400) eines Diensteprofils, das dem Mobilknoten (600) entspricht, aus einer Datenbank (300) zum Verwalten eines Diensteprofils, das eine Information zum Bereitstellen eines Dienstes gemäß der Ortsregistrierungs-Anforderungsinformation von dem Mobilknoten (600) einschließt, auf der Grundlage eines den Mobilknoten identifizierenden Mobilknoten-Identifizierers, der in der Ortsregistrierungs-Anforderungsinformation enthalten ist; Editieren, durch das Serversystem (100, 400), des extrahierten Diensteprofils in ein Format, das für die Steuereinheit verfügbar ist, so dass der Hausvermittler und der fremde Vermittler das Diensteprofil verwenden können, ohne es selbst zu editieren; und Verteilen des editierten Diensteprofils von dem Serversystem (100, 400) zu dem Hausvermittler (200) und dem fremden Vermittler (500), und wobei der Hausvermittler (200) und der fremde Vermittler (500) einen Dienst unter Verwendung der Steuereinheit gemäß dem Diensteprofil bereitstellen, das von dem Serversystem (100, 400) verteilt wird.
Serversystem (100) zur Verwendung in einem Mobilkommunikations-Dienstebereitstellungssystem, in welchem eine Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten (600) zu einem Hausvermittler (200) über einen fremden Vermittler (500) und ein Serversystem (100) übertragen wird, und bei dem eine Information als Antwort auf die Ortsregistrierungs- Anforderungsinformation von dem Hausvermittler (200) zu dem Mobilknoten (600) über das Serversystem (100) und den fremden Vermittler (500) zurückgegeben wird, so dass ein Ort des Mobilknotens für den Hausvermittler (200) und den fremden Vermittler (500) registriert ist, und bei dem ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt ist, dadurch gekennzeichnet, dass das Serversystem (100) umfasst: eine Extraktionseinheit, die ein Diensteprofil für den Mobilknoten (600) aus einer Datenbank (300) zum Verwalten eines Diensteprofils, das eine Information zum Bereitstellen eines Dienstes gemäß der Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten (600) einschließt, auf der Grundlage eines den Mobilknoten (600) identifizierenden Mobilknoten-Identifizierers extrahiert, der in der Ortsregistrierungs-Anforderungsinformation enthalten ist; eine Diensteverwaltungseinheit, die das Diensteprofil, das von der Extraktionseinheit extrahiert ist, in ein Format editiert, das für eine Steuereinheit verfügbar ist, zum Bestimmen eines Übertragungsziels eines Pakets; und eine Verteilungseinheit, die das editierte Diensteprofil zu dem Hausvermittler (200) und dem fremden Vermittler (500) verteilt, so dass der Hausvermittler (200) und der fremde Vermittler (500) einen Dienst unter Verwendung der Steuereinheit gemäß dem Diensteprofil bereitstellen, das von der Diensteverwaltungseinheit editiert ist.
Vermittlervorrichtung (200, 500) als ein Hausvermittler (200) oder ein fremder Vermittler (500) zur Verwendung in einem Mobilkommunikations-Dienstebereitstellungssystem, in welchem eine Ortsregistrierungs-Anforderungsinformation von einem Mobilknoten (600) zu dem Hausvermittler (200) über den fremden Vermittler (500) und ein Serversystem (100, 400) übertragen wird, und bei dem eine Information als Antwort auf die Ortsregistrierungs-Anforderungsinformation von dem Hausvermittler (200) zu dem Mobilknoten (600) über das Serversystem (100, 400) und den fremden Vermittler (500) zurückgegeben wird, so dass ein Ort des Mobilknotens (600) für den Hausvermittler (200) und den fremden Vermittler (500) registriert ist, und bei dem ein Mobilkommunikationsdienst auf der Grundlage der Registrierung bereitgestellt wird, dadurch gekennzeichnet, dass der Vermittler (200, 500) umfasst: eine Dienste-unabhängige Einheit (204), die ein Verarbeitungsverfahren für ein empfangenes Paket gemäß einer Header-Information des empfangenen Pakets bestimmt; eine individuelle Dienste-Steuereinheit (203), die die Dienste-unabhängige Einheit (204) gemäß einem Diensteprofil verwendet, das in ein Format, das für die Dienste-unabhängige Einheit (204) verfügbar ist, durch das Serversystem (100, 400) editiert ist; und eine Paketsteuereinheit (201), die ein Paket gemäß einem Verarbeitungsergebnis einer Verwendung der Diensteunabhängigen Einheit (204) verarbeitet und ein Übertragungsziel eines Pakets bestimmt.