DE60317494T2

DE60317494T2 - Verfahren und vorrichtung zum erreichen von kompatibilität zwischen komponenten von einem drahtlosen kommunikationssystem

Info

Publication number: DE60317494T2
Application number: DE60317494T
Authority: DE
Inventors: Jun San Diego WANG; Raymond T. San Diego HSU
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2002-04-15
Filing date: 2003-04-14
Publication date: 2008-09-18
Anticipated expiration: 2023-04-15
Also published as: AU2003221938A1; BR0309209A; EP1881673A2; CN101877896B; JP2005522967A; CN1653775B; WO2003090425A1; US20030193909A1; ATE378767T1; KR20040101507A; CN1653775A; CN101877896A; EP1881673A3; DE60317494D1; EP1495615B1; US7286510B2; EP1495615A1; TW200405741A

Description

HINTERGRUND
Gebiet
Die vorliegende Erfindung betrifft drahtlose Kommunikationssysteme im Allgemeinen, und insbesondere Verfahren und Vorrichtungen zur Übergabe von einem Paketdatendienst.
Hintergrund
Mobiles Internetprotokoll (IP) ist beabsichtigt zum Ermöglichen, dass sich Knoten von einem IP Teilnetz zu einem anderen bewegen, von einem Ethernetsegment zu einem anderen, oder von einem Ethernetsegment zu einem drahtlosen LAN. Die Absicht ist, dass die IP Adresse eines Mobilknoten (MN = Mobile Node) die Gleiche bleibt über eine gegebene Bewegung. Solange die Knotenbewegung nicht zwischen Punkten der Anbringung an unterschiedlichen IP Unternetzen auftritt, können Verbindungsschichtmechanismen zur Mobilität (das heißt Verbindungsschichtübergabe) schnellere Konvergenz und erheblich geringeren Overhead als MobillP bieten. Ein Problem existiert in dem Vorsehen von Kompatibilität zwischen unterschiedlichen Protokollen, und die verschiedenen Revisionen von derartigen Protokollen. Insbesondere wenn neue Protokolle eingeführt werden, können diese Konflikte mit vorhergehenden Revisionen und Protokollen verursachen.
Es gibt deshalb einen Bedarf für Kompatibilität zwischen unterschiedlicher Drahtloskommunikation und Datentransferprotokollen. Insbesondere gibt es einen Bedarf für eine Rückwärts- und Vorwärts kompatible Schnittstelle für Mobil IP Protokolle.
Die europäische Patentanmeldung mit Veröffentlichungsnummer EP 1 161 032 offenbart ein Routenoptimierverfahren und eine Agentenvorrichtung, wobei eine erweiterte Bindungsanfragenachricht zu einem Heimagenten gesendet wird, wenn dieser in einer Liste von Heimagenten identifiziert wird, wel cher dazu in der Lage ist, eine solche erweiterte Bindungsanfragenachricht zu interpretieren. „IP Mobility Support for IPv4, revised, draft-ietf-mobileiprfc2002–bis-08.txt", IETF Internet Draft, 19. September 2001, diskutiert die Verwendung von autorisierungsermöglichenden Erweiterungen in der Anrufregistrierung.
Die vorliegende Erfindung löst das Problem mit einem Verfahren gemäß Anspruch 1 und einer Vorrichtung gemäß Anspruch 15.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm eines Kommunikationssystems, welches Mobil IP unterstützt.
2 ist ein Zeitgebungsdiagramm, welches eine Anrufregistrierung in einem Kommunikationssystem unter Verwendung von authentifizierungsermöglichenden Erweiterungen verwendet.
3 ist ein Flussdiagramm eines Anrufregistrationsvorgangs unter Verwendung von authentifizierungsermöglichtenden Erweiterungen.
4 ist ein Zeitgebungsdiagramm, welches eine Anrufregistrierung in einem Kommunikationssystem unter Verwendung einer Versionsidentifizierungsnachricht zeigt.
5 ist ein Flussdiagramm eines Anrufregistrierungsvorgangs, welcher eine Versionsidentifizierungsnachricht zeigt.
6–9 sind Zeitgebungsdiagramme, welche verschiedene Anrufsregistrierungsprozesse zeigen.
DETAILLIERTE BESCHREIBUNG
Das Wort „exemplarisch" wird hierin exklusiv verwendet, um „als ein Beispiel, Version oder Illustration dienend" zu bedeuten. Jedes hierin als „exemplarisch" beschriebenes Ausführungsbeispiel wird nicht notwendigerweise als bevorzugt oder vorteilhaft gegenüber anderen Ausführungsbeispielen be trachtet. Während die verschiedenen Aspekte der Ausführungsbeispiele in Zeichnungen gezeigt werden, sind die Zeichnungen nicht notwendigerweise maßstabsgetreu gezeichnet, sofern nicht anderweitig angegeben.
Die folgende Diskussion entwickelt die exemplarischen Ausführungsbeispiele durch zunächst Präsentieren eines Netzwerk implementierenden mobil IP zum Kommunizieren von Daten zu und von einem Mobilknoten. Dann wird ein Spreizspektrum – Drahtloskommunikationssystem diskutiert. Als nächstes wird das mobil IP Netzwerk gezeigt, und zwar implementiert in dem Drahtloskommunikationssystem. Die Nachrichten sind gezeigt, welche einen Mobilknoten mit einem Heimagenten registrieren, wodurch ermöglicht wird, dass IP Daten zu und von dem Mobilknoten gesendet werden. Schließlich werden Verfahren zum erneuten Beanspruchen von Ressourcen bei dem Heimagenten erläutert.
Man beachte, dass das exemplarische Ausführungsbeispiel als ein Beispiel durchgängig in dieser Diskussion geliefert wird; jedoch können alternative Ausführungsbeispiele verschiedene Aspekte ohne Abweichung von dem Umfang der vorliegenden Erfindung beinhalten. Insbesondere sind die verschiedenen Ausführungsbeispiele auf ein Datenverarbeitungssystem, ein Drahtloskommunikationssystem, ein mobil IP Netzwerk und jegliches andere System anwendbar, welche die effiziente Verwendung und das Management von Ressourcen wünschen.
Das exemplarische Ausführungsbeispiel verwendet ein Spreizspektrumdrahtloskommunikationssystem. Drahtloskommunikationssysteme werden weithin verwendet um verschiedene Typen von Kommunikation wie Sprache, Daten usw. vorzusehen. Diese Systeme können auf Codemultiplex-Vielfachzugriff (CDMA = code division multiple access), Zeitmultiplex-Vielfachzugriff (TDMA = time division multiple access) oder irgendwelchen anderen Modulationstechniken basieren. Ein CDMA System bietet bestimmte Vorteile gegenüber anderen Typen von Systemen, einschließlich erhöhter Systemkapazität.
Ein System kann ausgebildet sein um einen oder mehrere Standards wie den „TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" hierin nachfolgend als der IS-95 Standard bezeichnet, zu unterstützen, wobei der Standard von einem Konsortium bereit gestellt wird, welches „3rd Generation Partnerchip Project" genannt wird, hierin als 3GPP bezeichnet, und in einem Satz von Dokumenten einschließlich der Dokumenten mit Nummern 3G TS 25.211, 3G TS 25.212, 3G TS 25.213 und 3G TS 25.214, 3G TS 25.302, hierin bezeichnet als der W-CDMA Standard, wobei der Standard von einem Konsortium angeboten wird, welches „3rd Generation Partnership Project 2" benannt wird, hierin als 3GPP2 bezeichnet, und TR-45.5, hierin als der cdma2000 Standard bezeichnet, früher bezeichnet als IS-2000 MC. Die hierin zitierten Standards werden hierdurch ausdrücklich im Weg der Referenz mit aufgenommen.
Jeder Standard definiert spezifisch die Verarbeitung von Daten zur Übertragung von der Basisstation zum Mobilen, und umgekehrt. Als ein exemplarisches Ausführungsbeispiel betrachtet die folgende Diskussion ein Spreizspektrumkommunikationssystem, welches mit dem CDMA2000 Standard von Protokollen konsistent ist. Alternative Ausführungsbeispiele können einen anderen Standard beinhalten.
Ein Kommunikationssystem 100 gemäß einem Ausführungsbeispiel ist in 1 gezeigt. Das Kommunikationssystem 100 beinhaltet sowohl drahtlose Teile wie auch Internetprotokoll (IP) Teile. Die Terminologie, welche zum Beschreiben der verschiedenen Elemente des Systems 100 verwendet wird, ist beabsichtigt zum Erleichtern des Verständnisses von Mobil IP, wie hierin beschrieben. Ein Heimnetzwerk 102 für einen Mobilknoten (MN) beinhaltet einen Heimagenten (HA = Home Agent) 104 und Heimagentenauthentifizierung, Verwaltung und Abrechnung (HAAR = Home Agent Authentication, Administration and Accounting) Einheit 106. Man beachte, dass die Authenti fizierung ein Prozess des Verifizierens ist, wie durch die Verwendung von kryptographischen Techniken, der Identität des Ursprungs einer Nachricht.
Das Heimnetzwerk 102 ist in Kommunikation mit einem IP Host 108. Wie gezeigt hat sich der MN 116 zu einem fremden System 110 bewegt, welches einen Paketdatendienstknoten (PDSN = Packet Data Service Node) 112 und einen fremden Agenten (FA = Foreign Agent) 112 beinhaltet.
Ein MN, wie ein MN 116, ist ein Host oder ein Router, welcher seinen Punkt der Anbringung von einem Netzwerk oder Teilnetzwerk zu einem anderen verändert. Ein MN kann seinen Ort ohne Veränderung seiner IP Adresse verändern; ein MN kann damit fortfahren, mit anderen Internetknoten bei jedem Ort unter Verwendung seiner (konstanten) IP Adresse zu kommunizieren, unter der Annahme dass Verbindungsschichtkonnektivität zu einem Punkt der Anbringung verfügbar ist.
Ein HA ist ein Router auf einem MN Heimnetzwerk, welcher Datagramme zur Lieferung zu dem MN tunnelt, wenn der MN weg von daheim ist, und behält derzeitige Ortsinformation für den MN. Ein FA ist ein Router auf einem MN besuchten Netzwerk, welcher Routingdienste für den MN vorsieht, während er registriert ist. Der FA enttunnelt und liefert Datagramme zu dem MN, welche durch den Heimagenten des MN getunnelt wurden. Für Datagramme, welche durch einen MN gesendet wurden, kann der FA als ein voreingestellter Router für die registrierten MNs dienen.
Einem MN 116 wird eine langzeitige IP Adresse auf einem Heimnetzwerk 102 gegeben. Diese Heimadresse, das heißt IP Adresse des MN, wird auf die gleiche Art und Weise wie eine „permanente" IP Adresse verwaltet, welche einem stationären Host gegeben wird. Wenn er von dem Heimnetzwerk 102 entfernt ist, wird eine „Care of Address" bzw. eine Nachsendeadresse mit dem MN 116 assoziiert, welcher den derzeitigen Punkt der Anbringung des MN reflektiert. Die Care of Address ist eine IP Adresse für das Ende ei nes Tunnels. Der MN 116 verwendet die Heimadresse als die Quelladresse von IP Datagrammen, welche von dem MN 116 gesendet werden.
Ein Heimnetzwerk, wie das Heimnetzwerk 102, ist ein Netzwerk, möglicherweise virtuell, welches einen Netzwerkpräfix hat, welcher zu der Heimadresse eines MNs passt. Man beachte, dass standardmäßige IP Routingmechanismen Datagramme liefern werden, welche zu der Heimadresse eines MNs bestimmt sind, und zwar zu dem Heimnetzwerk des Mobilknotens. Ein fremdes Netzwerk ist dann jedes Netzwerk anders als das Heimnetzwerk. Man beachte, dass diese Ausdrücke pro MN sind.
Wenn es weg von daheim ist, verwendet Mobil IP Protokolltunnel zum verdecken der Heimadresse eines MNs gegenüber intervenierenden Routen zwischen dem Heimnetzwerk und seinem derzeitigen Ort. Der Tunnel wird an der Care of Address des MNs beendet. Die Care of Address muß eine Adresse sein, zu welcher Datagramme über konventionelles IP Routing geliefert werden können. An der Care of Address wird das ursprüngliche Datagramm von dem Tunnel entfernt und zu dem MN geliefert. Ein Tunnel ist der Pfad, welchem ein Datagramm folgt, während es gekapselt ist. Das Modell ist, dass während es gekapselt ist, ein Datagramm zu einem bekannten entkapselnden Agenten geroutet wird, welcher das Datagramm entkapselt und es dann zu seiner endgültigen Position korrekt liefert.
Datagramme zu dem MN 116 werden von dem IP Host 108 zu dem Heimnetzwerk 102 auf Pfad a geliefert. Die Datagramme werden unter Verwendung von Standard IP Routingtechniken gesendet. Das Datagramm wird durch den HA 104 empfangen und abgefangen und zu der Care of Address getunnelt. Der HA 104 leitet das getunnelte Datagramm zu dem fremden Netzwerk 110 über den Pfad c weiter. Der FA 140 enttunnelt das Datagramm zur Lieferung zu dem MN 116. Der FA 114 sendet das Datagramm zu dem MN 116 über den Pfade.
Während es in Kommunikation mit den fremden Netzwerk 110 ist, werden Datagramme von dem MN 116 über Standard IP Routingtechniken von dem fremden Netzwerk 110 zu dem IP Host 108 gesendet. Man beachte, dass der MN 116 ausserhalb des fremden Netzwerks 110 zur Klarheit des Betriebs gezeigt ist; jedoch wird der MN 116 innerhalb eines geographischen oder virtuellen Gebiets betrieben, welches durch das fremde Netzwerk 110 bedient wird.
Der Betrieb des Systems 100 wie bis jetzt beschrieben ist konsistent mit demjenigen, welcher durch RFC2002, benannt „IP Mobility Support", spezifiziert, editiert durch C. Perkins, und datiert auf Oktober 1996, wie auch derjenigen, welche durch RFC3220, benannt „IP Mobility Support for IPv4" spezifiziert ist, editiert durch C. Perkins und datiert auf Januar 2002. Diese beiden Dokumente werden durch die Internet Engineering Task Force oder IETF veröffentlicht.
Verschiedene Unterschiede werden in RFC3220 präsentiert, was zu möglichen Konflikten zwischen Systemen und Kompatibilitätsmerkmalen zwischen verschiedenen Revisionen eines gegebenen Systems führt. Diese Differenzen werden als Beispiele von Kompatibilitätsmerkmalen betreffend Drahtloskommunikation und Mobil IP spezifisch präsentiert; jedoch wird eine Vielzahl von anderen Differenzen und Inkompatibilitäten mit Bezug auf die vorliegende Diskussion betrachtet.
Ursprüngliche Spezifikation
Wie in RFC2002 spezifiziert ist, sieht Mobil IP Registration einen flexiblen Mechanismus für MNs vor, um derzeit erreichbare Information zu dem HA zu kommunizieren. Es ist das Verfahren, durch welches die MNs Vorwärtsdienste anfordern, wenn sie ein fremdes Netzwerk besuchen, den HA über eine derzeitige Care of Address zu informieren, eine Registrierung zu erneuern, welche dabei ist auszulaufen, und/oder sich bei der Rückkehr nach Heim zu entregistrieren. Registriernachrichten tauschen Information zwischen einem MN aus, (optional) einem FA, und dem HA. Die Registrierung erzeugt oder modifiziert eine Mobilitätsbindung bei dem HA, assoziiert die Heimadresse des MN mit der derzeitigen Care of Address des MN für eine spezifische Lebenszeit.
Mehrere andere (optionale) Fähigkeiten sind durch die Registrationsprozedur verfügbar, welche den Mobilknoten dazu in die Lage versetzt, mehrere gleichzeitige Registrierungen aufrecht zu erhalten, so dass eine Kopie von jedem Datagramm zu jeder aktiven Care of Address getunnelt werden kann, spezifische Cares of Address entregistriert werden können während andere Mobilitätsbindungen erhalten werden, und die Adresse eines HA zu entdecken, wenn MN nicht mit dieser Information konfiguriert ist. Mobil IP definiert zwei unterschiedliche Registrierprozeduren, eine über einen FA, welcher die Registrierung zu dem HA des MN weiterleitet, und eine direkt mit dem HA des MN. Die folgenden Regeln bestimmen, welche dieser zwei Registrierprozeduren in jedem bestimmten Umstand verwendet werden soll. Wenn ein Mobilknoten eine FA Care of Address registriert, MUSS der MN über die FA registrieren. Wenn ein MN eine co-angeordnete Care of Address verwendet, und eine Agentenbenachrichtigung von einer FA auf der Verbindung empfängt, auf welcher der MN die Care of Address verwendet, SOLL der MN über die FA registrieren (oder über einen anderen FA auf dieser Verbindung), wenn das 'R'Bit in der empfangenen Agentenbenachrichtigungsnachricht gesetzt ist. Wenn ein MN anderenfalls eine co-lokalisierte Care of Address verwendet, MUSS der MN direkt bei seinem HA registrieren. Wenn ein MN zu seinem Heimnetzwerk zurückgekehrt ist und mit seinem HA (ent)registriert, MUSS der MN direkt mit seinem HA registrieren. Beide Registrierprozeduren beinhalten den Austausch von Registration ReQuest (RRQ) und Registration RePly (RRP) Nachrichten. Wenn über einen FA registriert, benötigt die Registrierprozedur die folgenden vier Nachrichten:

a) Die MN sendet eine RRQ zu dem prospektiven FA um den Registrierprozess zu beginnen.
b) Die FA verarbeitet die RRQ und leitet ihn dann zu dem HA weiter.
c) Die HA sendet einen RRP zu dem FA zum Bewilligen oder Ablehnen der Anfrage, das heißt RRQ.
d) Der FA verarbeitet den RRP und leitet ihn dann zu dem MN weiter, um ihn über die Disposition seiner Anfrage zu informieren.

Wenn der MN stattdessen direkt bei seinem HA registriert, benötigt die Registrierprozedur nur die folgenden zwei Nachrichten:

a) Der Mobilknoten sendet eine Registrieranfrage zu dem Heimagenten.
b) Der Heimagent sendet eine Registrierantwort zu dem Mobilknoten, wodurch die Anfrage bewilligt oder abgelehnt wird.

Die Registriernachrichten verwenden das Benutzerdatagrammprotokoll (UDP = User Datagram Protocol). Eine nicht Null-UDP-Prüfsumme soll in dem Header beinhaltet sein, und muß durch den Empfänger geprüft werden.
Jeder MN, FA und HA muß dazu in der Lage sein, eine Mobilsicherheitszuordnung für mobile Entitäten zu unterstützen, indiziert durch ihren Sicherheitsparameterindex (SPE = Security Parameter Index), und IP Adresse. In dem Fall von dem MN muß dies die Heimadresse sein. Registriernachrichten zwischen einem MN und seinem HA müssen mit dem mobilen Knoten-Heimauthentifizierungerweiterung (MN-HA Authentifizierungserweiterung) authentifiziert sein. Die MN-HA Authentifizierungserweiterung folgt unmittelbar allen nicht-Authentifizierungserweiterungen, außer bei denjenigen FAspezifischen Erweiterungen, welche zu der Nachricht addiert werden können, nachdem die MN die Authentifizierung berechnet.
Ein MN registriert bei seinem HA unter Verwendung einer RRQ Nachricht derart, dass der HA eine Mobilitätsbindung für den MN erzeugen oder modifizieren kann (zum Beispiel mit einer neuen Lebenszeit). Die RRQ Anfrage muß zu dem HA durch den FA weitergeleitet werden, durch welchen der MN registriert ist, oder sie kann direkt zu dem HA gesendet werden, und zwar in dem Fall, in welchem der MN eine co-angeordnete Care of Address registriert.
Der feste Teil der RRQ wird von einem oder mehreren dieser Erweiterungen gefolgt. Die MN-HA Authentifizierungserweiterung muss in allen RRQ Anfragen enthalten sein. Ein Mobilitätsagent gibt eine RRP Nachricht zu einem MN zurück, welche eine RRQ Nachricht gesendet hat. Wenn die MN Dienst von einem FA anfordert; wird der FA den RRP von dem HA empfangen und ihm nachfolgend zu dem MN weiterleiten. Die RRP Nachricht beinhaltet die notwendigen Codes zum Informieren des MN über den Status seiner RRQ Anfrage, zusammen mit der Lebenszeit, welche durch den HA bewilligt wurde, welche kleiner sein kann als die ursprüngliche RRQ Anfrage.
Exakt eine MN-HA Authentifizierungserweiterung muß in allen RRQ Anfragen und RRP Antworten vorhanden sein, und ist beabsichtigt zum Eliminieren von Problemen, welche aus der unkontrollierten Ausbreitung von entfernten Umlenkungen in dem Internet resultieren. Der Ort der Erweiterung markiert das Ende der Authentifizierungsdaten. Ferner werden zusätzliche Erweiterungen unterstützt, wie nicht-Authentifizierungserweiterungen, welche durch den FA verwendet werden, MN-FA Authentifizierungserweiterungen, und/oder MN-AAA Authentifizierungserweiterungen. Man beachte, dass der MN sowohl die MN-HA Authentifizierungserweiterung wie auch die MN-AAA Authentifizierungserweiterung in der RRQ Nachricht zu dem PDSN und FA während der Mobil IP Registrierung beinhalten muß. MN-AAA Authentifizierungserweiterung ist in RFC3012 spezifiziert. Man beachte, dass einige Standards und Standardversionen vor IS-95, wie der Standard, welcher als IS-835-A identifiziert ist, diese Anforderung haben. Zusätzlich erlaubt dies der Mobilstation, beide Authentifizierungserweiterungen zu senden. Die IS-835-A Standardversion ist einschränkender als die IS-835-B Standardversion, wodurch das Mobiltelefon beide Authentifizierungserweiterungen senden muß. Ferner müssen der PDSN und der FA beide Erweiterungen in der RRQ Nachricht beinhalten, welche zu dem HA gesendet wird.
Überarbeitete Spezifikation
Im Gegensatz zu den Spezifikationen von RFC2002, spezifiziert der RFC 3220, dass der PDSN und der FA nur die Authentifizierungserweiterungen senden, insbesondere die MN-HA Authentifizierungserweiterung. Jeder MN, FA und HA muß dazu in der Lage sein, eine Mobilitätssicherheitszuweisung für mobile Entitäten zu unterstützen, indiziert durch SPI und IP Adresse. In dem Fall des MN muß dies die Heimadresse sein. Registriernachrichten zwischen einem MN und einem HA müssen mit einer „autorisierungsermöglichenden Erweiterung" authentifiziert sein, wie die MN-HA Authentifizierungserweiterung. Diese Erweiterung muß die erste Authentifizierungserweiterung sein; andere fremde Agenten spezifische Erweiterungen können zu der Nachricht hinzugefügt werden, nachdem der Mobilknoten die Authentifizierung berechnet.
Autorisierungsermöglichende Erweiterung ist eine Authentifizierung, welche eine (Registrations) Nachricht akzeptabel für den schlussendlichen Rezipienten der Registriernachricht macht. Die autorisierungssermöglichende Erweiterung muss einen SPI beinhalten. Wie in RFC3220 verwendet, bezieht sich die autorisierungsermöglichende Erweiterung auf Authentifizierungserweiterungen, welche der Registrieranfragenachricht ermöglichen, dass sie für den Heimagenten akzeptabel ist. Unter Verwendung von zusätzlichem Protokoll kann es möglich für den MN sein, Authentifizierung seiner Registrierung zu dem HA zu liefern, und zwar durch eine andere Authentifizierungseinheit innerhalb des Netzwerks, welche für den HA akzeptabel ist.
Ein MN registriert sich in dem HA unter Verwendung einer RRQ Nachricht derart, dass der HA eine Mobilitätsbindung für den MN erzeugen oder modifizieren kann (zum Beispiel mit einer neuen Lebenszeit). Der RRQ kann zu dem HA durch den FA weitergeleitet werden, durch welchen sich der MN registriert, oder er kann direkt zu dem HA in dem Fall gesendet werden, in welchem der MN eine co-angeordnete Care of Address registriert.
Exakt eine autorisierungsermöglichende Erweiterung muß in allen RRQs vorhanden sein und auch in allen RRPs, welche durch den HA erzeugt werden. Die MN-HA Autentifizierungserweiterung ist eine autorisierungsermöglichung für Registriernachrichten. Diese Anfrage ist beabsichtigt zum Eliminieren von Problemen, welche aus der unkontrollierten Ausbreitung von entfernten Umlenkungen in dem Internet resultieren. Der Ort der Erweiterung markiert das Ende der authentifizierten Daten.
Wie in dem RFC3220 spezifiziert, wenn der HA mehr als eine Authentifizierungserweiterung empfängt, das heißt autorisierungsermöglichende Erweiterung, wird der HA die Registrieranfrage des MNs ablehnen und sollte einen RRP zu dem MN über FA/PDSN mit einem designierten Fehlercode senden. In einem Ausführungsbeispiel wird der Fehlercode als 131 identifiziert, was anzeigt, dass der MN mit der Authentifizierung gescheitert ist.
Derzeitige Lösung
Zum Aufrechterhalten der Rückwärtskompatibilität mit der ursprünglichen Spezifikation, das heißt RFC2002, wird das folgende Verfahren durch den 3GPP2 TSG-P unterstützt. Bei anfänglicher Registrierung beinhaltet die MS die MN-HA und die MN-AAA Authentifizierungserweiterungen. Zum Unterstützen von Rückwärtskompatibilität mit vorherigen Versionen, wird 3GPP2 „autorisierungsermöglichende Erweiterungen" bzw. „authorization enabling extentions" Attribut von dem Heim AAA (RADIUS) Server zu dem PDSN hinzugefügt, wodurch angezeigt wird, ob authentifizierungsermöglichende Erweiterungen entfernt werden können.
Der PDSN behandelt Authentifizierungserweiterungen wie folgt. Wenn der PDSN das 3GPP2 „authentifizierungsermöglichenden Erweiterungen" Attribut von dem Heim AAA (RADIUS) Server empfängt, soll der PDSN nicht irgendwelche Erweiterungen folgend auf die MN-HA Authentifizierungserweiterungen entfernen. Man beachte, dass das Attribut in einer derzeitigen Wahlauflösungsversion von IS-835-B beschrieben ist. Das Attribut ist hierin nachfol gend beschrieben. Man beachte auch, dass der Radiusserver der AAA Server unter Verwendung des Radiusprotokolls ist. Das Szenario ist in 2 gezeigt. Wenn der PDSN das Attribut nicht empfängt, entfernt er die MN-AAA Authentifizierungserweiterung von der RRQ nach der Vervollständigung der Mobilknotenauthentifizierung durch die AAA Infrastruktur, wie durch Mobil IP RFC3220 spezifiziert, und zwar vor dem Weiterleiten der RRQ zu dem HA.
2 zeigt die Verarbeitung innerhalb des Systems 100, wobei Systemelemente auf der horizontalen Achse repräsentiert sind, und die vertikale Achse repräsentiert Zeit. Zur Zeit t1 sendet der MN 116 eine RRQ, welche als RRQ(1) identifiziert ist, welche sowohl eine MN-HA Authentifizierungserweiterung wie auch eine MN-AAA Authentifizierungserweiterung beinhaltet. Die RRQ(1) wird durch den PDSN 112 und/oder FA 114 empfangen, welcher) ansprechend darauf eine Zugriffsanfragenachricht zu HAAR 106 zur Zeit t2 sendet/senden. Zur Zeit t3 antwortet der HAAR 106 mit einer Zugriffsakzeptiernachricht. Die Zugriffsakzeptiernachricht beinhaltet die autorisierungsermöglichenden Erweiterungen. Zur Zeit t4 sendet/senden der PDSN 112 und/oder FA 114 eine RRQ identifiziert als RRQ(2) zu dem HA 104. Zur Zeit t5 antwortet der HA 104 mit einer RRP Nachricht, welche als RRP(1) identifiziert ist. Der PDSN 112 und/oder FA 114 antwortet/antworten mit einer RRP Nachricht, welche als RRP(2) identifiziert ist und zwar zur Zeit t6.
3 zeigt den Prozess 120 für den Entscheidungsdurchführungsprozess. Wenn ein autorisierungsermöglichendes Erweiterungsattribut bei der Entscheidungsraute 112 empfangen wird, fährt die Verarbeitung zu Schritt 126 zum Verarbeiten der zusätzlichen Erweiterungen fort. Wenn das Attribut nicht empfangen wird, fährt die Verarbeitung zu Schritt 124 zum Entfernen der zusätzlichen Erweiterungen fort. Beide Verarbeitungspfade führen den Registrierprozess bei Schritt 128 fort.

Abhängig von den Möglichkeiten der Systemelemente kann die Lösung von 2 und 3 andere Probleme präsentieren. Die verschiedenen Szena rien sind in der folgenden Tabelle beschrieben. Mit Bezug auf die Systemelemente, im Allgemeinen entspricht IS-835-A RFC2002, während IS-835-B dazu beabsichtigt ist, RFC3220 zu entsprechen. Man beachte, dass diese Standards und Versionen als Beispiele von Systemkonfigurationen geliefert werden. Alternative Ausführungsbeispiele können irgendeinen einer Vielzahl von Standards, Versionen, Systemkomponenten und Konfigurationen beinhalten. Tabelle 1 Verschiedene Szenarien zum Betrachten von unterschiedlichen Konfigurationen

FA/PDSN Version	Heim AAA Version	HA Version	Kommentare
IS-835-B	IS-835-B	RFC2002 RFC3220	Kein Problem, weil. sowohl Heim AAA wie auch FA/PDSN Version B sind. Der Heim AAA weist an, wenn die HA-AAA Authentifizierungserweiterung entfernt werden soll.
IS-835-A	IS-835-A/B	RFC2002	Beide Erweiterungen werden gemäß dem IS-835-A gesendet werden, weil der FA/PDSN dem IS-835-A entspricht.
IS-835-B	IS-835-A	RFC2002	Kann Probleme einführen, weil der FA/PDSN nur die MN-HA Authentifizierungserweiterung sendet, weil Version-A Heim AAA nicht das „autorisierungsermöglichende Erweiterung" Attribut sendet. Für HA, welcher mit sowohl RFC2002 wie auch IS-835-A entspricht, werden Authentifizierungserweiterungen erwartet aber nicht empfangen.
IS-835-A	IS-835-A/B	RFC3220	Immer noch ein Problem, weil der. HA eine Erweiterung empfangen kann, welche nicht unter RFC3220 erlaubt ist.
IS-835-B	IS-835-A	RFC3220	Der FA/PDSN empfängt nicht das „autorisierungsermöglichenden Erweiterungen" Attribut, sondern sendet stattdessen nur die MN-HA Authentifizierungserweiterung zu dem HA.

Typischerweise sind der HA und HAAR in einer Domain des gleichen Trägers, und der HAAR kennt oder hat Zugriff auf die Version des HA. Deshalb ist es sowohl für die Rückwärts- wie auch die Vorwärtskompatibilität wünschenswert, dass der HAAR die Version des HA zu dem FA/PDSN anzeigt, anstatt des Sendens des „autorisierungsermöglichenden Erweiterung" Attributs. Zusätzlich, wenn die HA Version dem HAAR unbekannt ist, oder wenn der FA/PDSN nicht dieses neue Attribut empfängt, werden beiden Authentifizierungserweiterungen von dem FA/PDSN zu dem HA gesendet.
4 zeigt ein Szenario zum Liefern der HA Versionsinformation. Die vertikale Achse repräsentiert Zeit, während die horizontale Achse die System elemente repräsentiert. Bei anfänglicher Registrierung beinhaltet die MS den MN-HA und die MN-AA Authentifizierungserweiterungen in einer RRQ Nachricht identifizieren als RRQ(1) gesendet zur Zeit t1 der FA und/oder PDSN. Der FA und/oder PDSN sendet/senden eine Zugriffsanfrage zu dem HAAR zur Zeit t2. Zum Unterstützen von Rückwärtskompatibilität mit vorherigen Versionen antwortet die HAAR auf die Zugriffsanfrage durch Liefern einer Zugriffsakzeptanz zu dem FA und/oder PDSN zur Zeit t3. Die Zugriffsanfrage identifiziert die HA Version. In einem Ausführungsbeispiel sendet der HA-AR einen Versionsidentifizierer, welcher mit dem 3GPP2 „HA Versionsindikator" Attribut konsistent ist. Die Attributinformation zeigt die Version des HA mit Bezug auf RFC2002 oder RFC3220 an. Man beachte, dass die Attributinformation hierin unten stehend geliefert wird. In einem Ausführungsbeispiel ist der RFC2002HA äquivalent zu IS-835-A und RFC3220 HA ist äquivalent zu IS-835-B.
Für einen Release-B PDSN (das heißt RFC3220 unterstützend) werden die Authentifizierungserweiterungen wie in dem Flussdiagramm von 5 behandelt. Der Prozess 200 beginnt bei der Entscheidungsraute 202 zum Bestimmen, ob eine HA Versionsidentifikation, wie ein Attribut, wie hierin unten stehend diskutiert, von einem HAAR empfangen wird. Die Versionsidentifikation kann in einer Zugriffsakteptanznachricht wie in 4 gezeigt beinhaltet sein. Wenn die HA Versionsidentifikation empfangen wird, fährt die Verarbeitung mit der Entscheidungsraute 204 fort. Wenn die Versionsidentifikation nicht empfangen wird, fährt die Verarbeitung mit Schritt 212 zum Behalten der zusätzlichen Erweiterungen, welche in einer RRQ Nachricht von einem MN enthalten sind, fort. Von der Entscheidungsraute 204, wenn die Versionsidentifikation anzeigt, dass der HA die RFC3220 Version (Version 2) unterstützt, das heißt HA entspricht RFC3220, entfernt der PDSN zusätzliche Erweiterungen, wie die MN-AAA Authentifizierungserweiterung bei Schritt 206. Man beachte, dass die zusätzlichen Erweiterungen von dem RRQ nach der Vervollständigung der MN Authentifizierung durch die AAA Infrastruktur entfernt werden, wenn er die RRQ zu dem HA weiter leitet, wie durch Mobil IP RFC3220 spezifiziert, und zwar vor dem Weiterleiten der RRQ zu dem HA. Man beachte, dass wenn der PDSN die RRQ Nachricht zu dem HA weiterleitet, zusätzliche Erweiterungen von der RRQ Nachricht nach der Vervollständigung der MN Authentifizierung durch die AAA Infrastruktur entfernt werden, wie durch Mobil IP RFC3220 spezifiziert.
Zurückkehrend zu der Entscheidungsraute 204, wenn der PDSN die Versionsidentifizierung empfängt, wie das 3GGP2 „HA Versionsindikator" Attribut, von dem HAAR Server, welcher es anzeigt, dass der HA RFC2002 (Version 1) entspricht, behält der PDSN jegliche zusätzlichen Erweiterungen bei Schritt 208 folgend auf die MN-HA Authentifizierungserweiterung. Ähnlich, wenn der PDSN die Versionsidentifikation empfängt, wie das 3GPP2 „HA Versionsindikator" Attribut, von dem HAAR Server, welches anzeigt, dass die HA Version unbekannt ist, behält der PDSN jegliche Erweiterungen bei Schritt 208 folgend auf die MN-HA Authentifizierungserweiterung.
Die Verwendung einer Versionsidentifikation, wie das „HA Versionsindikator" Attribut, zusätzlich oder anstatt des „autorisierungsermöglichenden Erweiterung" Attributs, sieht Vorwärtskompatibilität zum Unterscheiden von zukünftigen HA Versionen von derzeitigen HA Versionen vor. Zum Beispiel können zukünftige FA und HA Mobil IP Registrierwiderruf [draft-ietf-mobileip-regrevok-02.txt] unterstützen. Über das „HA Versionsindikator" Attribut, wird ein Widerruf fähiger FA das Senden von Widerrufnachricht zu HA vermeiden, welcher nicht Widerruf unterstützt.
Das Verfahren wie in 4 und 5 gezeigt sieht eine Lösung vor, wenn der FA und/oder PDSN, wie auch der HAAR, eine neue Version (Version 2) unterstützt, wie der RFC3220, während der HA die vorherige Version (Version 1) unterstützt, wie RFC2002. Jedoch existiert immer noch ein Problem, wenn der FA und/oder PDSN die neue Version (Version 2) unterstützt, der HAAR unterstützt die alte Version (Version 1), und der HA unterstürzt die neue Version (Version 2). Für diese Konfiguration unterstützt der HAAR nicht das neue Attribut, das heißt Versionsidentifikation, und deshalb wird der FA und/oder PDSN beide Erweiterungen zu dem HA senden. Alternative Aus führungsbeispiele werden präsentiert, um dieses Problem zu vermeiden, wie auch andere, welche durch Konfigurationen erzeugt werden, welche inkonsistente Revisionen von Hardware und Software haben.
Ein Ausführungsbeispiel ist in 6 gezeigt, und ist detailliert wie folgt ausgeführt:

a) die MS sendet eine RRQ zu FA/PDSN einschließlich sowohl der MN-HA Authentifizierungserweiterung und MN-HA Authentifizierungserweiterung.
b) der FA/PDSN sendet eine Zugriffsanfragenachricht zu dem HAAA.
c) Der HAAR antwortet mit einer Zugriffsakzeptanz. In diesem Beispiel unterstützt der HAAR RFC2002, und weiß deshalb nicht, wie das neue Attribut „HA Versionsindikator" behandelt werden soll.
d) der FA/PDSN sendet eine RRQ zu dem HA einschließlich sowohl der MN-HA Authentifizierungserweiterung wie auch MN-HAAA Authentifizierungserweiterung.
e) Wenn der HA dem RFC3320 entspricht, sendet der HA einen RRP mit einem Fehlercode, wie Fehlercode 131, welcher anzeigt, dass der MN mit der Authentifizierung gescheitert ist, zu dem FA/PDSN.
f) Der FA/PDSN schaut auf den RRP zum Empfangen des Fehlercodes 131 und wird eine andere RRQ zu dem HA einschließlich nur der MN-HA Authentifizierungserweiterung senden.
g) Der HA sendet einen RRP zu dem FA/PDSN.
h) Der FA/PDSN leitet den RRP zu der MS weiter.

In diesem Ausführungsbeispiel sendet der FA erneut eine RRQ, welcher die MN-AAA Authentifizierungserweiterung vermeidet und zwar beim Empfang einer RRQ mit einem Fehlercode. Der MN muß die RRQ jedoch nur einmal senden, wodurch Luftressourcen gespart werden.
Ein alternatives Ausführungsbeispiel ist in 7 gezeigt, und wie folgt detailliert ausgeführt:

a) Der MN sendet eine RRQ zu dem FA/PDSN mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AA Authentifizierungserweiterung enthaltend.
b) Der FA/PDSN sendet eine Zugriffsanfrage zu dem HAAR.
c) Der HAAR antwortet mit einer Zugriffsakzeptanznachricht. In diesem Beispiel unterstützt der HAAR RFC2002, und unterstützt deshalb nicht das neue Attribut „HA Versionsindikator".
d) Der FA/PDSN sendet eine RRQ zu dem HA mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AAA Authentifizierungserweiterung beinhaltet.
e) Weil der HA RFC3220 unterstützt, wird ein RRP mit dem neuen Fehlercode gesendet, welcher auf einen Wert eingestellt ist, welcher anzeigt, dass nur eine Erweiterung erlaubt ist. Der RRP wird zu dem FA/PDSN gesendet.
f) Beim Empfangen des neuen Fehlercodes wird der FA/PDSN eine andere RRQ zu dem HA mit nur der MN-HA Authentifizierungserweiterung beinhaltet senden.
g) Der HA sendet einen RRP zu dem FA/PDSN.
h) Der FA/PDSN leitet den RRP zu der MS weiter.

Man beachte, dass die HA und die FA, welche den neuen Fehlercode unterstützen, nicht konsistent mit RFC3220 sind. Eine Modifikation zu RFC3220 würde ein solches Ausführungsbeispiel erlauben. Der MN muss jedoch nur die RRQ einmal senden, wodurch Luftressourcen gespart werden.
Noch ein anderes Ausführungsbeispiel ist in 8 gezeigt, und wie folgt detailliert ausgeführt, wobei der MN wissen muss, dass die Authentifizierung fehlgeschlagen ist, und wenn der MN die Registrierung erneut versuchen wird.

a) Die MS sendet RRQ zu FA/PDSN mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AA Authentifizierungserweiterung beinhaltet.
b) Der FA/PDSN sendet eine Zugriffsanfrage zu HAAR.
c) Der HAAR antwortet mit einer Zugriffsakzeptanz. In diesem Beispiel entspricht der HAAR dem IS-835-A, und unterstützt deshalb nicht das neue Attribut „HA Versionsindikator".
d) Der FA/PDSN sendet RRQ zu HA mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AAA Authentifizierungserweiterung beinhaltet.
e) Weil der HA dem RFC3320 entspricht wird der RRT mit dem Fehlercode eingestellt auf 131 senden (Mobilknoten ist mit Authentifizierung fehlgeschlagen), und zwar zu dem FA/PDSN.
f) Der FA/PDSN leitet den RRP zu der MS mit Fehlercode 131 weiter, und speichert, dass die Authentifizierung mit der Information für die korrespondierende MS fehlgeschlagen ist.
g) Die MS sendet erneut RRQ zu dem FA/PDSN mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AAA Authentifizierungserweiterung beinhaltet.
h) Der FA/PDSN sendet die RRQ zu HA mit nur der MN-HA Authentifizierungserweiterung beinhaltet.
i) Der HA antwortet mit RRP zu dem FA/PDSN.
j) Der FA/PDSN leitet den RRP zu der MS weiter.

Hier sendet der MN erneut die RRQ, was zu erhöhter Registrierlatenz führt. Zusätzlich addiert das Verfahren von 8 Komplexität zu der FA Implementierung, um die Historie von fehlgeschlagener Authentifizierung für die MN aufzuzeichnen. Es addiert auch einige Komplexität zu der MN Implementierung, wobei der MN die RRQ beim Empfang der RRQ erneut mit einem Fehlercode sendet, wie Fehlercode 131. Man beachte auch, dass die FA und HA Aktionen gemäß den Anforderungen von RFC3220 sind.
Noch ein anderes Ausführungsbeispiel ist in 9 gezeigt, und wie folgt detailliert ausgeführt:

a) Die MS sendet eine RRQ zu dem FA/PDSN mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AAA Authentifizierungserweiterung beinhaltet.
b) Der FA/PDSN sendet eine Zugriffsanfrage zu dem HAAR.
c) Der HAAR antwortet mit einer Zugriffsakzeptanz. In diesem Fall unterstützt der HAAR RFC2002, und unterstützt deshalb nicht das neue Attribut „HA Versionsindikator."
d) Der FA/PDSN sendet eine RRQ zu dem HA mit sowohl der MN-HA Authentifizierungserweiterung wie auch der MN-AAA Authentifizierungserweiterung beinhaltet.
e) Weil der HA RFC3320 entspricht, wird er einen RRP mit einem Fehlercode senden, wie dem Fehlercode 131, welcher die fehlgeschlagene Authentifizierung des MN anzeigt, und zwar zu dem FA/PDSN.
f) Der FA/PDSN leitet den RRP zu der MS mit dem Fehlercode weiter.
g) Die MS sendet erneut die RRQ zu dem FA/PDSN mit nur der MN-HA Authentifizierungserweiterung beinhaltet.
h) Der FA/PDSN sendet die RRQ zu dem HA mit nur der MN-HA Authentifizierungserweiterung beinhaltet.
i) Der HA antwortet mit einem RRP zu dem FA/PDSN.
j) Der FA/PDSN leitet den RRP zu dem MN weiter.

In diesem Ausführungsbeispiel sendet der MN erneut die RRQ, was zu erhöhter Registrierlatenz führt. Zusätzlich addiert dieses Ausführungsbeispiel Komplexität zu der MN Implementierung zum erneuten Senden der RRQ, ohne die MN-AAA Authentifizierungserweiterung, beim Empfang des RRP mit dem Fehlercode. Obwohl die MN nicht RFC3220 verletzt, kann sie den Drahtlosstandard verletzen. Die FA und HA Aktionen entsprechen auch RFC3220.
Autorisierungsermöglichende Erweiterungen
Man beachte, dass das autorisierungsermöglichende Erweiterungen Attribut die benötigte Aktion des FA anzeigt, bevor die RRQ Nachricht zu dem HA weitergeleitet wird. Dies tritt optional in einer RADIUS Zugriffsakzeptanznachricht auf. Dieses Attribut ist zum Unterstützen von Rückwärtskompatibilität mit vorherigen Versionen des Standards. Dieses Attribut ist beabsichtigt, um in einem nachfolgenden Release bzw. Version abgelehnt zu werden. Wenn es keine Kompatibilitätsmerkmale gibt, wird dieses Attribut nicht benötigt.
HA Versionsindikator
Indiziert die Version des HA. Dies tritt optional in einer Radiuszugriffsakzeptanznachricht auf. Dieses Attribut ist zum Unterstützen von Rückwärtskompatibilität mit vorhergehenden Versionen dieses Standards. Wenn es keine Kompatibilitätsmerkmale gibt, wird dieses Attribut nicht benötigt.
Während die Beschreibung und Ausführungsbeispiele, welche hierin oben stehend präsentiert wurden, zu einer Inkompatibilität zwischen Systemelementen bezüglich Registriererweiterungen referiert, können alternative Ausführungsbeispiele andere Inkompatibilitäten haben. Deshalb dienen die hierin oben stehend präsentierten Ausführungsbeispiele als Beispiele, aber die vorliegende Erfindung erweitert sich auf jegliche Anzahl von Situationen, in welchen die Systemelemente unterschiedliche Protokolle und/oder unterschiedliche Versionen des gleichen Protokolls unterstützen. Zum Beispiel kann eine Versionsidentifikation zum Auflösen von irgendeiner einer Vielzahl von Inkompatibilitäten verwendet werden. Ebenso können verschiedene Ausführungsbeispiele die Verantwortung zum Lösen von Inkompatibilitäten zwischen mehreren Systemelementen teilen.
Der Fachmann wird verstehen, dass Information und Signale unter Verwendung von irgendeiner einer Vielzahl von unterschiedlichen Technologien und Techniken repräsentiert sein kann. Zum Beispiel können Daten, Anweisungen, Befehle, Informationen, Signale, Bits, Symbole und Chips auf welche durchgängig in der oben stehenden Beschreibung Bezug genommen wurde, als Spannungen, Ströme, elektromagnetische Wellen, magnetische Felder oder Partikel, optische Felder oder Partikel, oder jegliche Kombination davon repräsentiert werden.
Der Fachmann wird ferner erkennen, Dass die verschiedenen illustrativen logischen Blöcke, Module, Schaltkreise und Algorithmusschritte, welche im Zusammenhang mit den hierin offenbarten Ausführungsbeispielen beschrieben wurden, als elektronische Hardware, Computersoftware, oder Kombinationen von beiden implementiert sein können. Zum klaren Illustrieren dieser Austauschbarkeit von Hardware und Software wurden verschiedene illustrative Komponenten, Blöcke, Module, Schaltkreise und Schritte oben im Allgemeinen im Ausdruck ihrer Funktionalität beschrieben. Ob solche Funktionalität als Hardware oder Software implementiert wird, hängt von einer bestimmten Anwendung und Designeinschränkungen, welche dem Gesamtsystem auferlegt sind, ab. Der Fachmann wird die beschriebene Funktionalität auf verschiedene Wege für jede bestimmte Anwendung implementieren, aber solche Implementierungsentscheidungen sollen nicht als eine Abweichung von dem Umfang der vorliegenden Erfindung verursachend interpretiert werden.
Die verschiedenen illustrativen logischen Blöcke, Module und Schaltkreise, welche im Zusammenhang mit den hierin offenbarten Ausführungsbeispielen beschrieben wurden, können mit einem Mehrzweckprozessor, einem digitalem Signalprozessor (DSP = digital signal processor), einen Anwendungsspezifischen integrierten Schaltkreis (ASIC = application specific integrated circuit), einem Feld programmierbaren Gate Array (FPGA = field programmable gate array) oder anderen programmierbaren logischen Einrichtungen, diskreter Gatter- oder Transistorlogik, diskreten Hardwarekomponenten oder jede Kombination davon ausgeführt sein, welche ausgebildet sind zum Durchführen der hierin beschriebenen Funktionen. Ein Mehrzweckprozessor kann ein Mikroprozessor sein, aber in der Alternative kann der Prozessor irgendein konventioneller Prozessor, Controller, Mikrocontroller oder Zu standsmaschine sein. Ein Prozessor kann auch als eine Kombination von Berechnungseinrichtungen implementiert sein, zum Beispiel eine Kombination eines DSP mit einem Mikroprozessor, einer Vielzahl von Mikroprozessoren, einer oder mehrere Mikroprozessoren im Zusammenhang mit einem DSP Kern, oder irgendeiner anderen solchen Konfiguration.
Die hierin in Zusammenhang mit den Ausführungsbeispielen offenbarten Schritte eines Verfahrens oder Algorithmus können direkt in Hardware, in einem Softwaremodul, welches durch einen Prozessor ausgeführt wird, oder in einer Kombination der beiden ausgeführt sein. Ein Softwaremodul kann in einem RAM Speicher, Flashspeicher, ROM Speicher, EPROM Speicher, EEPROM Speicher, Registern, Festplatte, einer entfernbaren Scheibe, einer CD-Rom oder irgendeiner anderen Form von Speichermedium, welches im Stand der Technik bekannt ist, vorhanden sein. Ein exemplarisches Speichermedium ist mit dem Prozessor derart verbunden, dass der Prozessor Information von dem Speichermedium auslesen kann und Information in dieses schreiben. In der Alternative kann das Speichermedium integral mit dem Prozessor sein. Der Prozessor und das Speichermedium können in einem ASIC vorhanden sein. Der ASIC kann in einem Benutzerterminal vorhanden sein. In der Alternative können der Prozessor und das Speichermedium als diskrete Komponenten in einem Benutzerterminal vorhanden sein.
Die vorhergehende Beschreibung der bevorzugten Ausführungsbeispiele wird gegeben, um jedem Fachmann zu ermöglichen, die vorliegende Erfindung auszuführen oder zu benutzen. Verschiedene Modifikationen dieser Ausführungsbeispiele werden dem Fachmann offensichtlich sein, und die allgemeinen hierin definierten Prinzipien können auf andere Ausführungsbeispiele ohne Abweichung von dem Umfang der Erfindung angewandt werden. Somit ist es nicht beabsichtigt, die vorliegende Erfindung auf die hierin gezeigten Ausführungsbeispiele einzuschränken, sondern ihr soll der Umfang gemäß den angefügten Ansprüchen zugestanden werden.

Claims

Ein Verfahren zur Registrierung in einem Kommunikationssystem (100), das Mobile-Internet-Protocol bzw. Mobilinternetprotokoll-(MIP)-Kommunikationen unterstützt, wobei das Verfahren Folgendes aufweist: Empfangen einer Anzeige der MIP-Version, die von einem Heimatagent (104) unterstützt wird, wobei die Versionsanzeige eine Fähigkeit des Heim- bzw. Heimatagenten (104) identifiziert und ansprechend auf die Versionsanzeige, Bestimmen, ob eine Anzahl von Reg istrationserweiterungen in einer Registrierungsnachricht im Einklang steht mit der Fähigkeit des Heimatagenten (104).
Verfahren nach Anspruch 1, das weiterhin Folgendes aufweist: Senden einer Registrierungsanfragenachricht mit der Anzahl von Registrierungserweiterungen bestimmt als im Einklang mit der Fähigkeit des Heimatagenten.
Verfahren gemäß Anspruch 2, wobei die Versionsanzeige von einer Heimauthentifizierungs-, Administrierungs- und –abrechnungseinheit empfangen wird.
Verfahren nach Anspruch 2, wobei eine anfängliche Registrierungsanfragenachricht von einem Mobilknoten empfangen wird.
Verfahren gemäß Anspruch 4, wobei die anfängliche Registrierungsanfragenachricht mehrere Registrierungserweiterungen beinhaltet und die Registrierungsanfragenachricht eine Reg istrierungserweiterung beinhaltet.
Verfahren gemäß Anspruch 1, wobei die Versionsanzeige ein Attribut ist.
Verfahren gemäß einem der Ansprüche 1 bis 6, das weiterhin Folgendes aufweist: Senden einer Registrierungsanfragenachricht an den Heimatagenten (104); Empfangen einer Fehlernachricht von dem Heimatagenten; Entfernen von zusätzlichen Registrierungserweiterungen von der Registrierungsanfragenachricht um eine reduzierte Registrierungsanfragenachricht zu bilden; und Senden der reduzierten Registrierungsanfragenachricht.
Verfahren gemäß Anspruch 7, wobei die Fehlernachricht anzeigt, ob die Autorisierung eines Mobilknotens (116) fehlgeschlagen ist.
Verfahren nach Anspruch 7, wobei die Fehlernachricht anzeigt, dass eine vorbestimmte Anzahl von Reg istrierungserweiterungen zugelassen sind.
Verfahren gemäß Anspruch 7, wobei die Fehlernachricht in einer Registrierungsantwortnachricht enthalten ist.
Verfahren gemäß einem der Ansprüche 1 bis 6, das Folgendes aufweist: Empfangen einer Registrierungsanfragenachricht von einem Mobilknoten (116); Senden der Registrierungsanfragenachricht an den Heimatagenten (104); Empfangen einer Fehlernachricht von dem Heimatagenten anzeigend für eine fehlgeschlagenen Autorisierung; Weiterleiten der Fehlernachricht an den Mobilknoten; Empfangen einer zweiten Registrierungsanfragenachricht von dem Mobilknoten; und erneutes Senden der zweiten Registrierungsanfragenachricht an den Heimatagenten.
Verfahren gemäß Anspruch 11, wobei die zweite Registrierungsanfragenachricht dieselbe wie die Registrierungsanfragenachricht ist.
Verfahren gemäß Anspruch 11, wobei die zweite Registrierungsanfragenachricht unterschiedlich ist von der Registrierungsanfragenachricht.
Verfahren gemäß Anspruch 11, wobei der Mobilknoten bzw. mobile Knoten zusätzliche Registrierungserweiterungen von der Registrierungsanfragenachricht entfernt, um die zweite Registrierungsanfragenachricht zu bilden.
Vorrichtung zum Registrieren in einem Kommunikationssystem (100), das Mobile-Internet-Protocol-, MIP, bzw. Mobilinternetprotokollkommunikationen unterstützt, wobei die Vorrichtung Folgendes aufweist: Mittel zum Empfangen einer Anzeige der MIP-Version, die von einem Heimatagenten (104) unterstützt wird, wobei die Versionsanzeige eine Fähigkeit des Heimatagenten (104) identifiziert; und Mittel zum Bestimmen, ob eine Anzahl von Registrierungserweiterungen in einer Registrierungsnachricht im Einklang steht mit der Fähigkeit des Heimatagenten (104) und zwar ansprechend auf die Versionsanzeige.