DE60312184T2

DE60312184T2 - Verfahren eines gateways zum auswählen eines kanals zur übertragung von datenpaketen

Info

Publication number: DE60312184T2
Application number: DE60312184T
Authority: DE
Inventors: Xiaobao Chen
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2002-09-24
Filing date: 2003-09-24
Publication date: 2007-11-08
Anticipated expiration: 2023-09-25
Also published as: US20050243820A1; US9949238B2; WO2004030309A2; US20110286425A1; ATE355693T1; WO2004030309A3; US7995523B2; ATE384383T1; US8611296B2; JP4426451B2; EP1543666B1; AU2003269191A1; EP1543666A2; AU2003269191A8; DE60312184D1; ES2280780T3; JP2006500844A; US20140177553A1; ES2297798T3

Description

GEBIET DER VORLIEGENDEN ERFINDUNG
Die vorliegende Erfindung betrifft Vorrichtungen und Verfahren zum Befähigen eines Netzübergangsknotenpunktes eines ersten paketvermittelten Datennetzwerkes, einen ersten Kanal für die Übertragung eines getunnelten Datenpakets an eine Zielpaketdatenprotokolladresse eines ortsveränderlichen Knotenpunktes mit einem Dienst in dem ersten Netzwerk auszuwählen, wobei der Netzübergangsknotenpunkt so angeordnet ist, dass er den ersten Kanal aus einer Vielzahl von Kanälen, von denen jeder dazu da ist, Datenpakete zur Zielpaketdatenprotokolladresse des ortsveränderlichen Knotenpunktes zu übertragen, auswählt, wobei das Auswählen so vor sich geht, dass eine Paketdatenprotokolladresse, die einem vom Netzübergangsknotenpunkt empfangenen Datenpaket zugeordnet ist, auf einem oder mehreren Datenpaketfiltern, die einer Vielzahl von Kanälen zugeordnet sind, abzubilden.
Insbesondere, jedoch nicht ausschließlich, betrifft die vorliegende Erfindung Vorrichtungen und Verfahren zum Befähigen eines General Packet Radio Service Gateway Support Node (GGSN) eines 2G oder 3G General Packet Radio Service (GPRS)-Netzwerkes, einen geeigneten Paketdatenprotokoll (Packet Data Protocol/PDP)-Zusammenhang für das Übertragen eines Datenpaketes, gesendet von einem Korrespondenzknotenpunkt (Correspondence Node/CN) in einem externen IP-Netzwerk an einen ortsveränderlichen Knotenpunkt (MN) im GPRS-Netzwerk auszuwählen, wobei die Makroortsunabhängigkeit des MN unterstützt wird durch die Verwendung des Mobilen Internet Protokolls, der MN von seinem Heimnetzwerk (HN) entfernt ist, und wobei das Datenpaket an die Heimadresse des MN adressiert ist und durch einen Vermittler der Ausgangsposition des MN in seinem HN getunnelt wird.
Stand der Technik
Während herkömmliche 2G Mobilnetze, wie die, welche dem Globalen System für Mobilkommunikations-(GSM) Standards entsprechen, leitungsvermittelte Sprach- und Datendienste an die ortsunabhängigen Stationen (MSs) von Nutzern bereitgestellt haben, gibt es ein hohes Bestreben in der mobilen Telekommunikationsbranche, paketvermittelte mobile Netzwerke einzusetzen. Paketvermittelte mobile Netzwerke besitzen signifikante Vorteile hinsichtlich der Netzwerk- und Funkressourceneffizienz und sie ermöglichen auch das Bereitstellen fortschrittlicherer Nutzerdienste. Bei der Konvergenz ortsfester und mobiler Telekommunikationsnetzwerke ist das Internet Protokoll (IP), welches in ortsfesten Netzwerken weit verbreitet ist, die natürliche Wahl als Paket-Routing-Mechanismus für mobile Paket-Netzwerke. Derzeit kommt das IP Version 4 (IPv4) weitverbreitet in der ortsfesten Netzwerkdomäne zum Einsatz. Jedoch wird erwartet, dass es allmählich zum IP Version 6 (IPv6) wechseln wird, welches anerkannte Vorteile gegenüber dem IPv4 aufweist, besonders hinsichtlich eines enorm vergrößerten Adressraumes, effizienterem Routing, größerer Skalierbarkeit, verbesserter Sicherheit, Dienstgüte (QoS)-Integration, Unterstützung für Multicasting und weiterer Merkmale.
Zu besonderen Beispielen mobiler paketvermittelter Dienste, die derzeit im Einsatz sind, zählen der General Packet Radio Service (GPRS), wie er sowohl in 2G GSM-Netzwerken als auch in 3G Universal-Mobiltelekommunikationssystem (UMTS)-Netzwerken (im Folgenden als GPRS-Netzwerke bezeichnet) implementiert ist. Es wird auch erwartet, dass drahtlose, Nicht-GPRS-Zugriffstechnologien wie drahtlose lokale Netzwerke (wLAN) eine flexible und kostengünstige Ergänzung zum GPRS für den lokalen Breitbanddienstzugriff in einigen Bereichen wie Hotspots (Konferenzzentren, Flug häfen, Ausstellungszentren usw.) bereitstellen werden. Dementsprechend werden Mobilnetzbetreiber das Roaming ortsunabhängiger Stationen zwischen GPRS- und Nicht-GPRS-Netzwerken oder untergeordneten Netzwerken unterstützen wollen.
Während GPRS-Netzwerke, welche von Anfang an als Mobilnetze ausgelegt wurden, eingebautes Ortsunabhängigkeitsmanagement (für MSs innerhalb des GPRS-Netzwerkes) und Roaming-Funktionalität (für MSs, die zwischen GPRS-Netzwerken wechseln) besitzen, wurde in der Internet Engineering Task Force (IETF) daran gearbeitet, die Ortsunabhängigkeit von IP-Benutzerterminals im Allgemeinen zu unterstützen. Zu diesem Zweck hat die IETF die Mobilen IP (MIP)-Protokolle entwickelt. Das MIP ist dafür ausgelegt, die Ortsunabhängigkeit zu unterstützen, wenn sich ortsunabhängige Stationen (oder ortsunabhängige Knotenpunkte (MNs) in der MIP-Terminologie) zwischen IP-Netzwerken mit unterschiedlichen Präfixen von untergeordneten Netzwerken (Makroortsunabhängigkeit) bewegen. Zum Beispiel kann das MIP verwendet werden, um die Ortsunabhängigkeit zwischen einem GPRS-Netzwerk und einem Nicht-GPRS-Netzwerk wie einem wLAN-Netzwerk zu unterstützen. Es wird nicht erwartet, dass das Mobile IP für das Ortsunabhängigkeitsmanagement innerhalb eines Netzwerkes oder untergeordneten Netzwerkes (Mikroortsunabhängigkeit) verwendet werden wird, was üblicherweise durch Zugriffstechnologie-spezifische Layer-2-Mechanismen wie den WCDMA Softer/Soft-Handover gemanagt wird.
Es gibt zwei Versionen des MIP, die den beiden Versionen des IP entsprechen. Das MIP Version 4 (MIPv4) ist dafür ausgelegt, IP-Adressortsunabhängigkeit für IP Version 4 (IPv4)-Adressen bereitzustellen, wohingegen das neuere MIP Version 6 (MIPv6) dafür ausgelegt ist, IP-Adressortsunabhängigkeit für IP Version 6 (IPv6)-Adressen bereitzustellen. Das MIPv4 wird im IETF Request for Comment (RFC) 2002, verfügbar auf der IETF-Website
http://www.ietf.org/rfc/rfc2002.txt?number=2002, beschrieben. Der Internet-Draft für das MIPv6 ist im IETF Internet-Draft „Mobility Support in IPv6", verfügbar auf der IETF-Website unter http://search.ietf.org/internet-drafts/draftietf-mobileip-ipv6-18.txt, beschrieben und als draft-ietf-mobileip-ipv6-18.txt referenziert.
Das MIPv4-Ortsunabhängigkeitsmanagement ist in 1 veranschaulicht. Einem MN 40 ist eine Heim-IP-Adresse (HAddr) in seinem Heimnetzwerk (HN) 42 zugewiesen. Routingvorgänge im HN stellen sicher, dass, wo immer sich der MN innerhalb des HN befindet, ein IP-Paket gesendet von einem Korrespondenzknotenpunkt (CN) 46 den MN erreicht. Wenn jedoch der MN in ein Fremdnetzwerk (FN) 44 wechselt, müssen IP-Pakete, die an seine HAddr adressiert sind, zu seinem neuen Standort im FN geroutet werden. Beim MIPv4 wird ein Router 48 im HN, bekannt als der Vermittler der Ausgangsposition (HA), verwendet, um als ein Paketweiterleitungsdienst im Namen des MN zu agieren, wenn dieser von seiner Heimposition entfernt ist. In einem ersten Arbeitsmodus des MIPv4 (bekannt als FA-CoA-Modus) wird dem MN, wenn er im FN ankommt, eine Care-of-Adresse (CoA) durch einen Router 50 im FN, bekannt als der Vermittler der Fremdposition (FA), zugewiesen. Aufgrund festgestellter Einschränkungen des IPv4-Adressraumes ist angedacht, dass mehr als ein MN die gleiche CoA gemeinsam nutzen könnten. Nach der Zuweisung der CoA sendet der FA 50 ein verbindliches Update an den HA zum Anmelden der CoA. Danach wird, wenn der CN ein Paket an die HAddr des MN in seinem HN (Fall 1) sendet, das Paket durch den HA abgefangen und basierend auf der CoA über den Tunnel 52 an den FA im FN getunnelt.
Das Tunneln beinhaltet das Verkapseln eines ersten Datenpaketes (mit einem Header und Nutzdaten) als die Nutzdaten eines zweiten Datenpaketes, welches einen neuen Header aufweist, welcher als seine Quell- und Zieladressen die Start- und Endpunkte des Tunnels anzeigt, und das Übertragen des zweiten Datenpaketes wie gewöhnlich zum Tunnelendpunkt, wo es entkapselt wird, um das erste Datenpaket zu erhalten. Nach dem Entkapseln leitet der Tunnelendpunkt, der FA, unter Verwendung von Routingvorgängen im FN das ursprüngliche Paket an den MN weiter. Beim MIP beinhaltet das Tunneln die IP-in-IP-Verkapselung unter Verwendung des IEFT Request for Comment (RFC) 2003. So wird beim MIPv4 ein IPv4-Paket durch dessen Verkapselung innerhalb eines anderen IPv4-Paketes getunnelt.
Als ein optionaler Vorgang beim MIPv4 kann der MN dann ein verbindliches Update an den CN senden, um seine CoA anzumelden. Danach kann der CN Pakete direkt an den MN unter seiner aktuellen CoA senden, anstatt indirekt über dessen HAddr (Fall 2), und diese Pakete werden durch den FA im FN empfangen und unter Verwendung von Routingvorgängen im FN an den MN geroutet. Dies ist bekannt als Routenoptimierung, da potentiell ineffizientes Dreiecksrouting über den HA, der sich im Allgemeinen nicht auf einem effizienten Routingpfad zwischen dem CN und dem FA befindet, vermieden wird.
Bei einem zweiten optionalen Arbeitsmodus des MIPv4 (bekannt als CoCoA-Modus) werden die CoAs nicht durch MNs, die von ihrem Heimnetzwerk entfernt sind, gemeinsam genutzt, und es wird kein FA verwendet. Dem MN wird eine einmalige CoA, bekannt als eine nicht abgesetzte CoA (CoCoA) zugewiesen, unter Verwendung von standardmäßigen dynamischen IP-Adresszuweisungsvorgängen – z.B. die Verwendung des Dynamischen Host Control Protokolls (DHCP). Bei diesem Arbeitsmodus muss der MN selbst ein verbindliches Update an seinen HA senden, um seine neu zugewiesene CoCoA anzumelden. Danach werden Pakete gesendet durch einen CN und adressiert an den MN unter seiner HAddr vom HA direkt an den MN getunnelt. Wie im FA-CoA-Modus kann als ein optionaler Vorgang im CoCoA-Modus der MN auch ein verbindliches Update an einen CN senden, um seine CoCoA anzumelden. Danach können Pakete durch den CN direkt an den MN unter seiner CoCoA gesendet werden.
Das MIPv6-Ortsunabhängigkeitsmanagement ist in 2 veranschaulicht. Zwei beträchtliche Unterschiede des MIPv6 gegenüber dem MIPv4 sind Folgende. Erstens werden aufgrund des enorm vergrößerten Adressraumes beim IPv6, CoAs, die einem MN in einem FN zugewiesen sind, niemals gemeinsam genutzt (d.h. sie entsprechen der optionalen CoCoA beim MIPv4). Zweitens besteht daraus resultierend kein Bedarf, einen FA im FN einzusetzen. Bezugnehmend auf 2, mit MIPv6, wird einem MN 40, wenn er sich von seinem HN 42 in ein FN 44 bewegt, eine einmalige CoA zugewiesen, und er sendet ein verbindliches Update an seinen HA 48 in seinem HN, um die CoA anzumelden. Pakete von einem CN 46 adressiert an die HAddr werden durch den HA 48 (Fall 1) abgefangen und über den Tunnel 54 an die CoA getunnelt. Dieses Tunneln kann unter Verwendung des IPv6 Generischen Pakettunnelungsmechanismus, beschrieben in IETF RFC 2473, erreicht werden. Jedoch ist bei MIPv6 die Routenoptimierung keine Option, sondern ein grundlegender Bestandteil des Protokolls und im Allgemeinen sollte der MN ein verbindliches Update an den CN senden, so dass dieser Pakete direkt an den MN unter seiner CoA (Fall 2) adressieren kann. Wenn ein MN ein Paket getunnelt von einem CN über den HA des MN erhält, kann er dies als ein Zeichen dafür nehmen, dass der CN keine Verbindung für den MN hat und kann ein verbindliches Update an den CN einleiten. Es sei darauf hingewiesen, dass beim MIPv6 das verbindliche Update an den CN die neue CoA des MN als die Quelladresse im IPv6-Header verwenden muss (siehe Klausel 11.6.2 des MIPv6 IETF-Internet-Draft).
Das 3rd Generation Partnership Project (3GPP), welches für die GPRS-Standards verantwortlich ist, hat erkannt, dass MIP in GPRS-Netzwerken möglicherweise unterstützt werden muss. Die Technische Spezifikation 23.060 Klausel 5.7 gibt an: „Zur effizienten Unterstützung der optionalen Mobilen IP-Dienste, siehe 3G TS 23.121, in der Paketdomäne, muss die Funktionalität des Vermittlers der Fremdposition (FA) im GGSN bereitgestellt sein. Die Schnittstelle zwischen dem GGSN und dem FA, einschließlich der Abbildung zwischen der Care-of-IP-Adresse und dem GTP-Tunnel im PLMN ist vermutlich nicht standardisiert, da der GGSN und der FA als ein integrierter Knotenpunkt gelten." Ferner gibt 3G TS 23.121 (verfügbar von der 3GPP-Website unter
http://www.3gpp.org/ftp/specs/2002-06/R1999/23 series/) an, dass „...es wichtig ist, Mobiles IP auch UMTS- und GPRS-Nutzern anzubieten, um es ihnen zu ermöglichen, zu und von anderen Zugriffstechnologien zu wechseln, während andauernde Datensitzungen, z.B. TCP oder UDP" aufrechterhalten werden und dass „da IP-Adressen beim IPv4 knapp sind, angenommen werden muss, dass das Mobile IPv4 bevorzugt mit den Care-of-Adressen des Vermittlers der Fremdposition (FA) verwendet werden wird. Im Vergleich zur Verwendung von nicht abgesetzten Care-of-Adressen behalten die Care-of-Adressen des FA die IP-Adressen nicht nur bei, sie sind auch effizienter über die Funkschnittstelle."
Jedoch kann es Umstände geben, unter denen die obigen Annahmen falsch sind. Erstens kann ein GPRS-Netzbetreiber CoCoAs beim MIPv4 verwenden wollen, anstatt CoAs des FRs. Zum Beispiel können IPv4-Adressen innerhalb eines bestimmten GPRS-Netzwerkes nicht knapp sein und CoCoAs können bevorzugt sein, um die Skalierbarkeit und Routingeffizienz zu verbessern. Zweitens kann es Umstände geben, unter welchen der GPRS-Netzbetreiber die FA-Funktionalität nicht in den Netzübergangs-GPRS-Unterstützungsknotenpunkt (GGSN) integrieren wollen würde, welcher der Netzübergang ist, der das GPRS-Netzwerk mit externen paketvermittelten Netzwerken verbindet. Zum Beispiel kann der GGSN überladen sein und eine Trennung des GGSN und der FA-Funktionalität würde den Lastausgleich verbessern. Ferner kann es als vorteilhaft erachtet werden, den FA in Knotenpunkten zu platzieren, welche näher an den Rändern des GPRS-Netzwerkes liegen, wie Zugriffsknotenpunkte, zur Verbesserung der Skalierbarkeit. Drittens hat das 3GPP selbst kürzlich entschieden, dass das IPv6 bei UMTS R5 IP Multimedia System (IMS) und IP-Funkzugriffsnetzwerken im Allgemeinen unterstützt werden muss. Somit ist klar, dass GPRS-Netzwerke das MIPv6 sowie das MIPv4 in Zukunft unterstützen werden müssen und, wie zuvor beschrieben, besitzt das MIPv6 keinen FA und verwendet CoAs, welche einmalig für den MN sind (d.h. immer „nicht abgesetzt").
Die Erfinder der vorliegenden Erfindung haben erkannt, dass sich bei GPRS-Netzwerken, die gemäß der gegenwärtigen Dienstbeschreibungen (Ausgabe 1999) implementiert werden, unter jedem der drei oben aufgeführten Umstände Probleme ergeben. Ein besonderes Merkmal von GPRS-Netzwerken, welche Ausgabe 1999 und Nach-Ausgabe 1999 (z.B. R4, R5) der GPRS-Dienstbeschreibung entsprechen, ist die Unterstützung dessen, was als Paketdatenprotokoll (PDP)-Zusammenhänge bekannt ist. Das Spezifizieren unterschiedlicher PDP-Zusammenhänge ist aus einer Vielzahl von Gründen von Nutzen. Insbesondere ermöglichen es PDP-Zusammenhänge, abweichende QoS-Levels und weitere Parameter für den Verkehr zu und von einer einzelnen PDP-Adresse einer MS zu spezifizieren. Dies ermöglicht die effiziente Übertragung einer Vielfalt von Datenverkehr, wie Nicht-Echtzeit-Verkehr (z.B. diskontinuierliche und stoßartige Datenübertragungen, gelegentliche Übertragungen von großen Datenvolumen) und Echtzeitverkehr (z.B. Sprache, Video). Zum Beispiel kann eine MS in einem GPRS-Netzwerk, welches eine PDP-Adresse, wie eine IPv4- oder IPv6-Adresse, aufweist, mit einer Vielzahl anderer Telekommunikationsgeräte in externen paketvermittelten Netzwerken kommunizieren, und zwar unter Verwendung unterschiedlicher PDP-Zusammenhänge mit abweichenden QoS-Parametern für jeden einzelnen Zusammenhang. Es ist im Allgemei nen die Aufgabe der MS, PDP-Zusammenhänge wie erforderlich zu erstellen und zu modifizieren.
Eingehende Datenpakete von einem externen Netzwerk für die Abwärtstrecke zu einer MS werden im GPRS-Netzwerk durch den GGSN empfangen. Wenn die PDP-Adresse der MS mehrere PDP-Zusammenhänge eingerichtet hat, ist es entscheidend, dass der GGSN in der Lage ist, den geeigneten PDP-Zusammenhang für jedes Paket zu bestimmen, so dass dieses ordnungsgemäß an die MS übertragen werden kann. Dies wird unter Verwendung von Traffic Flow Templates (TFTs), die den PDP-Zusammenhängen zugeordnet sind, erreicht. Die TFTs können Paketfilterinformationen enthalten, die durch den GGSN verwendet werden, um den geeigneten PDP-Zusammenhang für Datenpakete auf der Abwärtsstrecke zu bestimmen. Gemäß aktueller 3GPP-Standards ist eine spezifizierte Information zur Verwendung bei der Paketfilterung die Quelladresse des eingehenden Datenpaketes – z.B. die IP-Adresse des Quellknotenpunktes wie im IP-Paketheader angegeben. Wenn ein eingehendes Datenpaket am GGSN ankommt, wird seine Quelladresse mit vorhandenen TFTs verglichen, die der PDP-Adresse der MS zugeordnet sind. Wenn eine Übereinstimmung gefunden wird, wird das Paket an die MS an ihrer PDP-Adresse gemäß des geeigneten PDP-Zusammenhangs übertragen. Wenn jedoch keine Übereinstimmung gefunden wird, kann das Paket vom GGSN fallen gelassen werden. Und genau hier entsteht das Problem.
Angenommen, die MS im GPRS-Netzwerk ist durch das MIPv6 mit Makroortsunabhängigkeit ausgestattet und hat sich gerade erst in das GPRS-Netzwerk bewegt, welches ein FN ist – d.h. sie besitzt einen HA und eine HAddr in einem HN (welches ein GPRS-Netzwerk sein kann oder nicht) und sie hat sich in das GPRS-Netzwerk bewegt, wo ihr eine CoA zugewiesen wurde. Nennen wir nun die MS einen MN und das Telekommunikationsgerät im externen Netzwerk einen CN für die Konsistenz mit der MIP-Technologie. Nach dem Wechsel in das GPRS-Netzwerk sendet der MN ein verbindliches Update an seinen HA in seinem HN zum Anmelden seiner neuen CoA. Er sendet normalerweise auch ein verbindliches Update seiner neuen CoA an den CN. Jedoch kann, selbst wenn er dies tut, der CN aus verschiedenen Gründen weiterhin Datenpakete an den MN unter seiner HAddr senden. Solche Datenpakete werden durch den HA des MN abgefangen und unter Verwendung von IPv6-Tunnelung (RFC 2473) an den MN getunnelt. Gemäß RFC 2473, „wird bei der Verkapselung das Quellfeld des Tunnel-IPv6-Headers mit der IPv6-Adresse des Tunneleingangspunkt-Knotenpunktes gefüllt" – d.h. mit der IPv6-Adresse das HA. Somit besitzt ein getunneltes Datenpaket ankommend am GGSN im GPRS-Netzwerk nicht die IP-Adresse des CN als seine Quelladresse, sondern die IP-Adresse des HA (Anm.: dies ist nicht die HAddr des MN). Diese Adresse kann durch den GGSN unter Verwendung einer TFT, welche die Quelladresse des CN identifiziert, nicht erkannt werden und das Datenpaket wird möglicherweise fallen gelassen.
Begrifflich kann man sich das Problem so vorstellen, dass sich der MIP-Tunnel über den GGSN hinaus erstreckt und die CN-Quelladresse vor dem GGSN „verbirgt". Dies ist auch der Fall beim MIPv4, wenn der FA nicht in den GGSN integriert ist, sondern sich weiter in Richtung der Ränder des Netzwerkes befindet, oder wo CoCoAs verwendet werden, da sich in beiden Fällen der Tunnelendpunkt wieder über den GGSN hinaus erstrecken wird. Es sei auch darauf hingewiesen, dass dieses Problem in dem allgemeinen Fall zutrifft, wenn sich der MN in das GPRS-Netzwerk als ein FN bewegt, selbst wenn keine Kommunikationssitzung mit einem bestimmten CN aufgebaut ist. Es kann erwartet werden, dass ein möglicher zukünftiger CN Datenpakete an den MN aus verschiedenen Gründen über dessen HAddr senden möchte, und dass diese über den HA getunnelt werden. Daher entsteht das Problem allgemein.
Die vorliegende Erfindung stellt eine Lösung für das obige Problem bereit.
Patentanmeldung WO 02/23831 betrifft eine Anordnung und ein Verfahren in einem Kommunikationssystem, welche/s die Kommunikation von Paketdaten mit einer Reihe von Endnutzerstationen, einer Hauptleitung, einer Reihe von Zugriffsmitteln zum Bereitstellen von Zugriff zwischen Endnutzerstationen und externen Paketdatennetzwerken unterstützt. Es werden Informationssteuerungsmittel bereitgestellt, welche endnutzergesteuert sind, so dass ein Endnutzer selektiv den Empfang von Datenpaketen von dem/n externen Paketdatennetzwerk/en steuern kann.
Kurzdarstellung der vorliegenden Erfindung
Gemäß eines ersten Aspektes der vorliegenden Erfindung wird ein Verfahren bereitgestellt, welches einen Netzübergangsknotenpunkt eines ersten paketvermittelten Datennetzwerkes befähigt, einen ersten Kanal für die Übertragung eines getunnelten Datenpaketes an eine Zielpaketdatenprotokolladresse eines ortsunabhängigen Knotenpunktes mit einem Dienst in dem ersten Netzwerk auszuwählen, wobei der Netzübergangsknotenpunkt so angeordnet ist, dass er den ersten Kanal aus einer Vielzahl von Kanälen, von denen jeder zum Übertragen von Datenpaketen an die Zielpaketdatenprotokolladresse des ortsunabhängigen Knotenpunktes da ist, auswählt, wobei das Auswählen durch den Abgleich einer Paketdatenprotokolladresse, die einem Datenpaket zugeordnet ist, welches durch den Netzübergangsknotenpunkt empfangen wird, mit einem oder mehreren Datenpaketfiltern, die einer Vielzahl von Kanälen zugeordnet sind, erfolgt, wobei das Verfahren Folgendes umfasst:

a) das Feststellen eines auslösenden Ereignisses, das anzeigt, dass der Netzübergangsknotenpunkt angepasst ist, ein Datenpaket zu empfangen, das über einen tun nelnden Knotenpunkt eines zweiten paketvermittelten Datennetzwerkes außerhalb des ersten Netzwerkes getunnelt wird; und,
b) als Reaktion auf das Feststellen, das Veranlassen, dass eine erste Paketdatenprotokolladresse in einen ersten Datenpaketfilter, der dem ersten Kanal zugeordnet ist, eingefügt wird, wobei die erste Paketdatenprotokolladresse, wenn sie einem vom Netzübergangsknotenpunkt empfangenen Datenpaket zugeordnet ist, anzeigt, dass das Datenpaket über den tunnelnden Knotenpunkt getunnelt worden ist, und der erste Datenpaketfilter zur Verwendung durch den Netzübergangsknotenpunkt bestimmt ist, wenn er aus der Vielzahl von Kanälen zur Übertragung von Datenpaketen an den ortsunabhängigen Knotenpunkt an der Zielpaketdatenprotokolladresse auswählt.

Bei einer Ausführungsform, bei welcher der Netzübergangsknotenpunkt angeordnet ist, um aus der Vielzahl von Kanälen auszuwählen, indem eine Quelladresse eines empfangenen Datenpakets mit einem oder mehreren Datenpaketfiltern, die einer Vielzahl von Kanälen zugeordnet sind, abgeglichen wird, ist die erste Paketdatenprotokolladresse die Paketdatenprotokolladresse des tunnelnden Knotenpunktes. Somit kann das erste Problem mit oder ohne Modifikation der standardisierten Funktionalität des Netzübergangsknotens gelöst werden.
Bevorzugt wird das auslösende Ereignis von dem ortsunabhängigen Knotenpunkt erkannt und der ortsunabhängige Knotenpunkt richtet die Einbeziehung der ersten Paketdatenprotokolladresse in den ersten Datenpaketfilter ein. Bevorzugt besitzt der ortsunabhängige Knotenpunkt eine Heimpaketdatenprotokolladresse im zweiten Netzwerk und das auslösende Ereignis ist, dass der ortsunabhängige Knotenpunkt seine Zielpaketdatenprotokolladresse bei dem tunnelnden Knoten punkt so anmeldet, dass die an den ortsunabhängigen Knotenpunkt unter seiner Heimpaketdatenprotokolladresse adressierten Datenpakete von dem tunnelnden Knotenpunkt zu dem ortsunabhängigen Knotenpunkt unter seiner Zielpaketdatenprotokolladresse getunnelt werden können.
Zu weiteren Aspekten der vorliegenden Erfindung zählt ein Netzübergangsknotenpunkt angeordnet nach dem Verfahren des oben beschriebenen ersten Aspektes.
Weitere Aspekte der vorliegenden Erfindung sind in den beigefügten Ansprüchen dargelegt.
Es folgt nun, als Beispiel, eine detaillierte Beschreibung der bevorzugten Ausführungsformen der vorliegenden Erfindung, wobei:
Kurzbeschreibung der Figuren
1 eine begriffliche Darstellung ist, welche das Ortsunabhängigkeitsmanagement wie beim MIPv4 bereitgestellt zeigt;
2 eine begriffliche Darstellung ist, welche das Ortsunabhängigkeitsmanagement wie beim MIPv6 bereitgestellt zeigt;
3 eine Netzwerkarchitekturdarstellung ist, welche ein GPRS-Netzwerk und ein wLAN-Netzwerk verbunden über eine externe paketvermittelte Netzwerkwolke zeigt;
4 ein Nachrichtenflussdiagramm ist, welches einen PDP-Zusammenhang-Modifikationsvorgang in einem GPRS-Netzwerk zeigt, wodurch es einem GGSN ermöglicht wird, getunnelte Pakete für die Abwärtsstrecke an einen MN mit dem entsprechenden Tunnel des PDP-Zusammenhangs gemäß der ersten und dritten Ausführungsform der vorliegenden Erfindung abzugleichen;
5 ein Flussdiagramm ist, welches den modifizierten Vorgang befolgt von einem GGSN eines GPRS-Netzwerkes gemäß der ersten und dritten Ausführungsform der vorliegenden Erfindung zeigt;
6A und 6B Blockdiagramme sind, welche die modifizierte Struktur von IPv6-Datenpaketen gesendet durch den HA gemäß einer zweiten Ausführungsform der vorliegenden Erfindung zeigen;
7 ein Flussdiagramm ist, welches den modifizierten Vorgang befolgt von einem GGSN eines GPRS-Netzwerkes gemäß der zweiten Ausführungsform der vorliegenden Erfindung zeigt;
8A, 8B und 8C Blockdiagramme sind, welche die modifizierte Struktur von IPv6-Datenpaketen gesendet durch den HA gemäß einer vierten Ausführungsform der vorliegenden Erfindung zeigen; und
9 ein Flussdiagramm ist, welches den modifizierten Vorgang befolgt von einem GGSN eines GPRS-Netzwerkes gemäß der vierten Ausführungsform der vorliegenden Erfindung zeigt.
Detaillierte Beschreibung von Ausführungsformen der vorliegenden Erfindung
3 zeigt eine Netzwerkarchitektur, in der sowohl ein GPRS-Netzwerk 10 als auch ein wLAN-Netzwerk 20 mit einem oder mehreren externen Paketnetzwerken in der externen Paketnetzwerkwolke 30 verbunden sind.
Das GPRS-Netzwerk 10 ist mit den externen Paketnetzwerken über einen oder mehrere Gateway GPRS Support Nodes (GGSNs) (obwohl hier nur ein GGSN 12 dargestellt ist) verbunden, welche mit einem oder mehreren Serving GPRS Support Nodes (SGSNs) (obwohl hier nur ein SGSN 14 dargestellt ist) über eine interne IP-basierte paketvermittelte Hauptleitung kommunizieren. Der SGSN 14 beobachtet die Position einzelner ortsunabhängiger Stationen (MSs) verbunden mit dem GPRS-Service und führt Sicherheitsfunktionen und die Zugriffskontrolle durch. Der SGSN 14 ist selbst mit einem oder mehreren Funkzugriffsnetzwerken (Radio Access Networks/RANs) 16 (entweder das Basisstation-Subsystem (BSS) im 2G GSM-Netzwerk oder das UMTS Terrestrische Funkzugriffsnetzwerk (UTRAN) im 3G UMTS-Netzwerk) verbunden. Die RANs kontrollieren die Kommunikation einer oder mehreren MSs 18 drahtlos.
Weitere Hauptkomponenten des GPRS-Netzwerkes 10, wie das Home Location Register (HLR), welches GSM- und UMTS-Bezugsdaten speichert, und das Mobile Switching Centre/Visitor Location Register (MSC/VLR), welches leitungsvermittelte Dienste verwaltet und auch die Position einzelner ortsunabhängiger Stationen (MSs) beobachtet, sind aus Gründen der Übersichtlichkeit weggelassen. Der Leser sei auf die GPRS-Dienstbeschreibung (Ausgabe 1999) Technische Spezifikation, bezeichnet als 3G TS 23.060 v3.12.0 (2002-06) und verfügbar von der 3GPP-Website unter
http://www.3gpp.org/ftp/specs/2002-06/R1999/23 series/), verwiesen, welche eine detaillierte Dienstbeschreibung für 2G (GPRS/GSM) und 3G (GPRS/UMTS) ortsunabhängige Paketnetzwerke bereitstellt. Die Funktionalität von GPRS-Netzwerken ist allgemein gut bekannt, trotzdem werden weitere Aspekte unten detailliert beschrieben.
Das wLAN-Netzwerk 20 ist mit den externen Paketnetzwerken über einen Zugriffs-Controller (AC) 22 verbunden, welcher einen oder mehrere Zugriffspunkte 24 kontrolliert, die drahtlos mit einer oder mehreren MSs 26 kommunizieren. Die Funktionalität von wLAN-Netzwerken ist allgemein gut bekannt und wird hierin nicht weiter detailliert beschrieben.
Um auf paketvermittelte GPRS-Dienste zuzugreifen, führt eine MS zuerst einen GPRS-Verbindungsvorgang mit dem SGSN (entweder eine 2G GSM GPRS-Verbindung oder eine 3G UMTS GPRS-Verbindung) durch. Es werden Authentifizierungs- und Positionsaktualisierungsvorgänge durchgeführt und wenn diese erfolgreich sind, macht der GPRS-Verbindungsvorgang die MS verfügbar für das Paging über den SGSN und die Benachrichtigung von eingehenden Paketdaten. Um jedoch tatsächlich Paketdaten zu senden und zu empfangen, muss die MS eine zugewiesene Paketdatenprotokoll (PDP)-Adresse (z.B. eine IP-Adresse) besitzen, und sie muss zumindest einen PDP-Zusammenhang zur Verwendung mit dieser PDP-Adresse aktivieren. Jede PDP-Adresse für eine MS kann einen oder mehrere ihr zugeordnete PDP-Zusammenhänge besitzen und Daten, welche die PDP-Zusammenhänge definieren, sind in der MS, dem SGSN und dem GGSN gespeichert. Der Vorgang der PDP-Zusammenhang-Aktivierung macht die MS nicht nur für den SGSN bekannt, sondern auch für den entsprechenden GGSN, und die Zusammenarbeit mit externen Datennetzwerken kann beginnen.
PDP-Zusammenhänge werden verwendet, um den Status wie Routinginformationen und Dienstgüte (QoS)-Anforderungen in Knotenpunkten des GPRS-Netzwerkes aufrechtzuerhalten. Insbesondere ermöglichen es mehrere PDP-Zusammenhänge, ein oder mehrere Levels der QoS für eine einzelne PDP-Adresse einer MS zu spezifizieren, um eine effiziente Übertragung einer Vielfalt von Datenverkehr wie Nicht-Echtzeit-Verkehr (z.B. diskontinuierliche und stoßweise Datenübertragungen, gelegentliche Übertragungen großer Datenvolumen) und Echtzeitverkehr (z.B. Sprache, Video) zu ermöglichen. So kann eine Anwendung, die mit einer einzelnen PDP-Adresse auf einer MS läuft, ein oder mehrere QoS-Levels nach ihren Bedürfnissen nutzen, indem ein oder mehrere PDP-Zusammenhänge verwendet werden. Ein PDP-Zusammenhang kann sich in einem von zwei Zuständen befinden – aktiv oder inaktiv. Wenn er inaktiv ist, enthält ein PDP-Zusammenhang keine Routing- oder Abbildungsinformationen zum Verarbeiten von Paketen in Bezug auf die PDP-Adresse. Es können keine Daten übertragen werden. Wenn er aktiv ist, ist der PDP-Zusammenhang für die PDP-Adresse in der MS, dem SGSN und dem GGSN aktiviert. Der PDP-Zusammenhang enthält Abbildungs- und Routinginformationen für die Übertragung von PDP-Paketen für diese bestimmte PDP-Adresse zwischen der MS und dem GGSN.
Nutzerdaten werden mittels Tunnelung zwischen externen Netzwerken und der MS übertragen. Zwischen dem SGSN und der MS werden Tunnelungsvorgänge verwendet, welche sich zwischen 2G GSM- und 3G UMTS-Netzwerken unterscheiden. Zwischen dem GGSN und dem SGSN werden Pakete jedoch unter Verwendung eines üblichen Verkapselungsvorgangs gemäß dem GPRS Tunnelling Protocoll (GTP) getunnelt. Die PLMN-Hauptleitung der Paketdomäne verkapselt ein Datenpaket mit einem GTP-Header und fügt dieses GTP-Paket in ein UDP-Paket ein, welches wiederum in ein IP-Paket eingefügt wird. Die IP- und GTP-Paketheader beinhalten die GSN-Adressen und den Tunnelendpunktidentifikator, welche notwendig sind, um einen PDP-Zusammenhang einmalig zu adressieren. Wo es mehrere PDP-Zusammenhänge für eine einzelne PDP-Adresse einer MS gibt, muss es eine entsprechende Zahl an GTP-Tunneln aufgebaut zwischen dem GGSN und dem SGSN für die Paketdatenübertragung geben. Es sei darauf hingewiesen, dass die in GPRS-Netzwerken verwendeten GTP-Tunnel nicht zu verwechseln sind mit MIP-Tunneln.
Wenn es mehrere PDP-Zusammenhänge für eine PDP-Adresse gibt, lenkt der GGSN Pakete der Abwärtsstrecke zu den unterschiedlichen GTP-Tunneln, basierend auf sogenannten Traffic Flow Templates (TFTs), die den PDP-Zusammenhängen zugewiesen sind. Jeder PDP-Zusammenhang kann einer TFT zugeordnet sein. Jedoch kann, als eine strenge Regel, jederzeit höchstens ein PDP-Zusammenhang, welcher der gleichen PDP-Adresse zugeordnet ist, existieren, ohne dass ihm eine TFT zugewiesen ist. So gibt es bei n-mehrfachen PDP-Zusammenhängen immer entweder n TFTs oder (n-1) TFTs, welche jeweils einzelnen der n PDP-Zusammenhänge entsprechen. Wenn es eine 1-zu-1-Abbildung zwischen TFTs und den GTP-Tunneln, welche jedem PDP-Zusammenhang entsprechen, gibt, dann erfolgt die Auswahl des GTP-Tunnels direkt auf Grundlage der TFT. Wenn es eine (n-1)-zu-n-Abbildung gibt, erfolgt die Auswahl auch direkt, sie kann jedoch einen einfachen Eliminierungsprozess beinhalten, wenn für eine TFT keine Übereinstimmung gefunden werden kann.
TFTs werden auch bei der Verwendung von Auswertungspräzedenzindizes bevorzugt. Bei Empfang eines Datenpaketes sucht der GGSN mittels Auswertung nach einer Übereinstimmung, zuerst im Paketfilter unter allen TFTs, der den kleinsten Auswertungspräzedenzindex hat und, falls keine Übereinstimmung gefunden wird, fährt er fort mit der Auswertung von Paketfiltern in ansteigender Reihenfolge nach ihrem Auswertungspräzedenzindex. Dieser Vorgang wird so lange ausgeführt, bis eine Übereinstimmung gefunden wird, und in diesem Fall wird das Datenpaket über den GTP-Tunnel an den SGSN getunnelt, welcher dem PDP-Zusammenhang zugeordnet ist, der dem übereinstimmenden TFT-Paketfilter entspricht. Gemäß 3G TS 23.060 Klausel 9.3 wird, wenn keine Übereinstimmung gefunden wird, das Datenpaket über den PDP-Zusammenhang getunnelt, welchem keine TFT zugewiesen ist; wenn jedoch allen PDP-Zusammenhängen eine TFT zugewiesen ist, muss der GGSN das Datenpaket verwerfen.
Die TFTs enthalten Attribute in Bezug auf die Header der Datenpakete der Abwärtsstrecke, welche verwendet werden, um Datenpakete zu filtern und sie somit zu dem GTP-Tunnel für den korrekten PDP-Zusammenhang zu routen oder darauf abzu bilden. Die Attribute sind hinsichtlich der IP-Headerfelder definiert. Gemäß 3G TS 23.060 Klausel 15.3.2 werden die Datenpaket-Headerattribute enthalten in TFTs hinsichtlich sowohl IPv4- als auch IPv6-Headerfeldern spezifiziert. Jede TFT besteht aus zwischen 1 und 8 Paketfiltern, von denen jeder durch einen einmaligen Paketfilteridentifikator identifiziert ist. Ein Paketfilter besitzt auch einen Auswertungspräzedenzindex, der einmalig innerhalb aller TFTs den PDP-Zusammenhängen zugeordnet ist, die sich die gleiche PDP-Adresse teilen. Gemäß 3G TS 23.060 Klausel 15.3.2 enthält jeder gültige Paketfilter einen einmaligen Identifikator innerhalb einer bestimmten TFT, einen Auswertungspräzedenzindex, der innerhalb aller TFTs einmalig für eine PDP-Adresse ist, und mindestens eines der folgenden IPv4- oder IPv6-Paketheaderattribute:

– Quelladresse und Maske des untergeordneten Netzes.
– Protokollnummer (IPv4) oder Nächster Header (IPv6).
– Zielanschlussbereich.
– Quellanschlussbereich.
– IPSec Sicherheitsparameterindex (SPI).
– Dienstart (TOS) (IPv4) oder Verkehrsklasse (IPv6) und Maske.
– Flusslabel (IPv6).

Jedoch können nicht alle davon in Kombination verwendet werden, ohne zu Widersprüchen zu führen. In der Praxis werden die Quelladresse und Maske des untergeordneten Netzes am üblichsten verwendet, da, bei normalen Anwendungsfällen, eine MS einen unterschiedlichen PDP-Zusammenhang für ihre (oder eine ihrer) PDP-Adressen für jede unterschiedliche Korrespondenzknotenpunkt-PDP-Adresse einrichtet. Es sei darauf hingewiesen, dass die Attributliste nicht das Zieladress-Attribut enthält, nur den Zielanschlussbereich. Dies geschieht aufgrund dessen, dass TFT-Paketfilter nicht verwendet werden, um Pakete auf einer von einer Vielzahl von Zieladressen abzubilden, sondern auf dem GTP-Tunnel, der einem von einer Vielzahl von PDP-Zusammenhängen eingerichtet für eine einzelne Zieladresse an einer einzelnen MS entspricht.
Jedoch kann, wie bereits zuvor diskutiert, das Quelladressattribut unter bestimmten Umständen möglicherweise nicht ausreichend sein, dass der GGSN eingehende Datenpakete für die Abwärtsstrecke an den MN abbildet. Gemäß der vorliegenden Erfindung wird der Vorgang, den eine MIPv4- oder MIPv6-aktivierte MS (diese soll nun MN genannt werden) befolgt, modifiziert. Beim Wechsel in das GPRS-Netzwerk verbindet sich der MN mit dem GPRS-Netzwerk und es wird ihm eine CoA (oder CoCoA) – d.h. eine IPv4- oder IPv6-Adresse – zur Verwendung während seines Aufenthaltes im GPRS-Netzwerk zur Verfügung gestellt. Unter Verwendung herkömmlicher MIP-Vorgänge meldet der MN diese Adresse bei seinem HA in seinem HN an, und zwar unter Verwendung des MIPv4- oder MIPv6-Heimverbindungs-Updatevorgangs. Um dies zu tun, muss er zuerst einen PDP-Zusammenhang im GPRS-Netzwerk aktivieren, unter Verwendung des MS-initiierten PDP-Zusammenhang-Aktivierungsvorgangs beschrieben in 3G TS 23.060 Klausel 9.2.2, hierin durch Verweis eingefügt.
Erste Ausführungsform
Gemäß einer ersten Ausführungsform der vorliegenden Erfindung modifiziert der MN bei erfolgreicher Heimverbindung den aktivierten PDP-Zusammenhang, um in einer TFT, die dem PDP-Zusammenhang zugeordnet ist, die Adresse des Vermittlers der Ausgangsposition – d.h. eine IPv4- oder IPv6-Adresse – einzufügen, um den GGSN zu befähigen, Pakete, die über den HA getunnelt wurden zu filtern. Der MN verwendet den MS-initiierten PDP-Zusammenhang-Modifikationsvorgang, beschrieben in 3G TS 23.06 Klausel 9.2.3 und hierin durch Verweis eingefügt. 4 zeigt den PDP-Zusammenhang-Modifikationsvorgang. Bei Schritt 60 führt der MN 18 unter Verwendung des aktivierten PDP-Zusammenhangs den MIP-Heimverbindungsvorgang mit seinem HA in seinem HN (nicht gezeigt) durch. Angenommen dieser ist erfolgreich, sendet der MN bei Schritt 62 eine Aufforderung zum Modifizieren des PDP-Zusammenhangs an seinen SGSN 14. Die Aufforderungsnachricht zum Modifizieren des PDP-Zusammenhangs enthält eine Anweisung, eine TFT, die dem PDP-Zusammenhang zugeordnet ist, hinzuzufügen oder zu modifizieren, um die IP-Adresse des Vermittlers der Ausgangsposition im HN des MN einzufügen. Es sei darauf hingewiesen, dass der MN optional auch eine Anweisung zum Modifizieren des QoS-Profils in der Aufforderungsnachricht zum Modifizieren des PDP-Zusammenhangs senden kann. Bei Schritt 64 sendet der SGSN 14 eine Aufforderungsnachricht zum Aktualisieren des PDP-Zusammenhangs an den GGSN 12, welche die Anweisung enthält, die TFT wie zuvor hinzuzufügen oder zu modifizieren. Der GGSN 12 prüft die Anweisung (um zum Beispiel zu sehen, ob die Attribute im Paketfilter der TFT eine gültige Kombination bilden), und wenn diese akzeptabel ist, speichert oder modifiziert er die TFT für den PDP-Zusammenhang dementsprechend. Dann sendet der GGSN 12 bei Schritt 66 eine Antwortnachricht zum Aktualisieren des PDP-Zusammenhangs an den SGSN 14, was eine erfolgreiche Durchführung anzeigt. Bei Schritt 68 kann die Funkzugriffsträgermodifikation durchgeführt werden (zum Beispiel in einem G3 GPRS-Netzwerk im Iu-Modus, wo sich das QoS-Profil des PDP-Zusammenhangs verändert hat). Bei Schritt 70 sendet der SGSN 14 eine Annahmenachricht zum Modifizieren des PDP-Zusammenhangs an den MN, um die erfolgreiche Modifikation des PDP-Zusammenhangs (d.h. der TFT) zu bestätigen.
Bei einer alternativen Version der ersten Ausführungsform wird ein modifizierter TFT-Paketfilter verwendet, bei dem die Liste möglicher IPv4- oder IPv6-Paketheaderattribute, die im Paketfilter beinhaltet sein können, wie folgt erweitert ist:

– Quelladresse und Maske des untergeordneten Netzes.
– Adresse des Vermittlers der Ausgangsposition.
– Protokollnummer (IPv4) oder Nächster Header (IPv6).
– Zielanschlussbereich.
– Quellanschlussbereich.
– IPSec Sicherheitsparameterindex (SPI).
– Dienstart (TOS) (IPv4) oder Verkehrsklasse (IPv6) und Maske.
– Flusslabel (IPv6).

So können, für einen PDP-Zusammenhang, TFT-Paketfilter gespeichert am MN und der GGSN die IPv4- oder IPv6-Adresse des Vermittlers der Ausgangsposition des MN in einem speziell angegebenen Feld beinhalten. Das Verhalten des Adressattributs des Vermittlers der Ausgangsposition hinsichtlich der Gültigkeit der Kombination mit anderen Attributen ist das gleiche wie das Verhalten des Quelladressattributs (siehe 3G TS 23.060 Klausel 15.3.2). Jedoch kann eine TFT einen Paketfilter umfassen, der entweder das Quelladressattribut oder das Adressattribut des Vermittlers der Ausgangsposition allein oder beide Attribute, Quelladresse und Adresse des Vermittlers der Ausgangsposition, in Kombination aufweist. In dem Fall, dass beide Attribute in einem einzelnen TFT-Paketfilter spezifiziert sind, werden sie als Alternativen behandelt, d.h. sie werden mittels des logischen Operators ODER kombiniert. Somit stimmt ein Datenpaket, welches entweder eine Quelladresse aufweist, die mit dem Quelladressattribut übereinstimmt ODER welches eine Quelladresse aufweist, die mit dem Adressattribut des Vermittlers der Ausgangsposition übereinstimmt, zumindest mit diesen Attributen des TFT-Paketfilters überein. Die Funktionalität des GGSN wird modifiziert, um den Abgleich eingehender Datenpakete für die Abwärtsstrecke an eine MS mittels des modifizierten TFT-Paketfilters durchzuführen. Es sei darauf hingewiesen, dass die gleiche Wirkung erzielt wird, indem zwei Paketfilter in eine TFT eingefügt werden – einer, bei dem das Quelladressattribut definiert ist und bei dem anderen ist das Adressattribut des Vermittlers der Ausgangsposition definiert.
Der modifizierte Vorgang befolgt von einem GGSN gemäß dieser ersten Version der ersten Ausführungsform ist im Flussdiagramm von 5 gezeigt. Der Vorgang startet mit Schritt 80. Bei Schritt 82 empfängt der GGSN ein Datenpaket für die Abwärtsstrecke an einen bestimmten MN, welcher eine CoA im GPRS-Netzwerk besitzt. Bei Schritt 84 vergleicht der GGSN die Quelladresse des Datenpaketes mit den Quelladressfeldern von TFTs von PDP-Zusammenhängen, die der CoA des MN zugeordnet sind. Wenn bei Schritt 86 festgestellt wird, dass eine Übereinstimmung vorliegt, wird der Vorgang fortgesetzt mit Schritt 88, wo das Paket mittels des PDP-Zusammenhangs, welcher die übereinstimmende TFT enthält, an den MN übertragen wird. Der Vorgang wird mit Schritt 96 fortgesetzt und endet. Dies entspricht der herkömmlichen Operation eines GGSN. Wenn jedoch bei Schritt 86 festgestellt wird, dass keine Übereinstimmung vorliegt, wird der Vorgang mit Schritt 90 fortgesetzt, wo der GGSN die Quelladresse des Datenpaketes mit den erweiterten Adressfeldern des Vermittlers der Ausgangsposition von TFTs von PDP-Zusammenhängen, die der CoA des MN zugeordnet sind, vergleicht. Wenn bei Schritt 92 festgestellt wird, dass eine Übereinstimmung vorliegt, wird der Vorgang fortgesetzt mit Schritt 94, wo das Paket mittels des PDP-Zusammenhangs, welcher die übereinstimmende TFT enthält, an den MN übertragen wird. Der Vorgang wird mit Schritt 96 fortgesetzt und endet. Wenn jedoch bei Schritt 92 festgestellt wird, dass keine Übereinstimmung vorliegt, wird der Vorgang mit Schritt 96 fortgesetzt und endet. Es sei darauf hingewiesen, dass die Nichtübereinstimmung der Quelladresse des Datenpaketes mit einer TFT dazu führen kann, dass das Datenpaket fallen gelassen wird oder, alternativ dazu, mittels eines PDP-Zusammenhangs an den MN übertragen wird, dem keine TFT zugeordnet ist, wenn ein solcher existiert.
Alternativ dazu werden in einer zweiten Version der ersten Ausführungsform die standardmäßigen TFT-Paketfilterattribute verwendet, und der zuvor unter Verweis auf 4 beschriebene MS-initiierte PDP-Zusammenhang-Modifikationsvorgang wird verwendet, um eine neue TFT hinzuzufügen oder eine bestehende TFT zu modifizieren, um einen neuen Paketfilter hinzuzufügen, indem die HA-Adresse des MN in das standardmäßige Quelladressattribut eingefügt wird. Dieser neue Paketfilter wäre zusätzlich zu jedem bereits vorhandenen Paketfilter für die TFT. Alternativ dazu kann der Paketfilter einen bereits vorhandenen Paketfilter ersetzen oder modifizieren.
Während zuvor beschrieben wurde, dass der PDP-Zusammenhang, der nach der Durchführung des MIP-Heimverbindungs-Updatevorgangs aktiviert ist, modifiziert wird, wird ersichtlich sein, dass jeder aktivierte PDP-Zusammenhang modifiziert werden kann, um einen neuen TFT-Paketfilter einzufügen oder einen bereits bestehenden TFT-Paketfilter zu modifizieren, um die HA-Adresse des MN einzufügen. Somit kann, zum Bei spiel, ein PDP-Zusammenhang, der für eine Kommunikationssitzung mit einem CN aktiviert ist, modifiziert werden, um eine zugeordnete TFT zu besitzen, mit 1) einem Paketfilter, welcher sowohl die Quelladresse des CN aufweist als auch die HA-Adresse des MN (unter Verwendung der erweiterten Attributliste), oder alternativ dazu mit 2) zwei Paketfiltern – einem, der die Quelladresse des CN aufweist und der andere mit der HA-Adresse des MN (unter Verwendung entweder der erweiterten oder der standardmäßigen Attributliste). Auf diese Art und Weise können Pakete gesendet durch den CN an die HAddr des MN und getunnelt über den HA durch den GGSN an den entsprechenden PDP-Zusammenhang gefiltert werden, wie auch Pakete gesendet durch den CN direkt an die CoA (oder CoCoA) des MN.
Außerdem wird ersichtlich sein, dass ein PDP-Zusammenhang zusammen mit einem zugeordneten TFT-Paketfilter, welcher die HA-Adresse des MN beinhaltet, aktiviert werden kann, und zwar unter Verwendung des MS-initiierten PDP-Zusammenhang-Aktivierungsvorgangs beschrieben in 3G TS 23.060 Klausel 9.2.2, hierin durch Verweis eingefügt. So kann zum Beispiel ein PDP-Zusammenhang für eine Kommunikationssitzung mit einem CN aktiviert werden und im Aktivierungsvorgang kann eine TFT dem PDP-Zusammenhang zugeordnet werden, welche Folgendes aufweist: entweder 1) einen Paketfilter mit sowohl der Quelladresse des CN als auch der HA-Adresse des MN (unter Verwendung der erweiterten Attributliste) oder alternativ dazu 2) zwei Paketfilter – einen mit der Quelladresse des CN und den anderen mit der HA-Adresse des MN (unter Verwendung entweder der erweiterten oder der standardmäßigen Attributliste). Auf diese Art und Weise können Pakete gesendet durch den CN an die HAddr des MN und getunnelt über den HA durch den GGSN an den entsprechenden PDP-Zusammenhang gefiltert werden, wie auch Pakete gesendet durch den CN direkt an die CoA (oder CoCoA) des MN.
Es wird ersichtlich sein, dass in der ersten Ausführungsform andere Ereignisse als die Durchführung eines Heimverbindungsvorgangs des MN verwendet werden können, um die Erstellung oder Modifikation von TFT-Filtern wie beschrieben auszulösen. Im Allgemeinen kann jeder Knotenpunkt des GPRS-Netzwerkes erkennen, dass ein Paket für den MN getunnelt werden kann und kann so den MN anweisen oder anderweitig für die Erstellung oder Modifikation von TFT-Filtern wie beschrieben sorgen.
Zweite Ausführungsform
Gemäß einer zweiten Ausführungsform der vorliegenden Erfindung, welche MNs betrifft, die eine IPv6 HAddr besitzen, wird der HA des MN modifiziert, um die IP-Adresse des CN in einen IPv6 Hop-by-Hop-Optionen Erweiterungsheader des verkapselten IPv6-Paketes für alle Datenpakete, die er an den MN tunnelt, einzufügen. 6A zeigt die Struktur des verkapselnden Datenpaketes. Der IPv6-Grundheader 100 kommt als erstes. Die Existenz des IPv6 Hop-by-Hop-Optionen Erweiterungsheaders 102 wird angezeigt, gemäß dem standardmäßigen IPv6 (RFC 2460), indem eine Null in das Feld IPv6 Nächster Header des IPv6-Grundheaders 100 eingefügt wird. Der Hop-by-Hop-Optionen Erweiterungsheader 102 folgt dann umgehend auf den IPv6-Grundheader 100. Schließlich folgen die Nutzdaten 104 – d.h. der Header der oberen Schicht wie TCP oder UDP und das verkapselte Datenpaket – auf den Hop-by-Hop-Optionen Erweiterungsheader 102. 6B zeigt die Struktur des Hop-by-Hop-Optionen Erweiterungsheaders 102. Die Felder Nächster Header und Hdr Ext Len des Hop-by-Hop-Optionen Erweiterungsheaders 102 sind aus Gründen der Übersichtlichkeit weggelassen. Die IP-Adresse des CN wird in einer Typ-Länge-Wert (Type-Length-Value/TLV) codierten Option in den Hop-by-Hop-Optionen Erweiterungsheader 102 eingefügt. So wird eine geeignete Optionstypnummer (8-Bit) 106 verwendet, um den Typ der Option (d.h. die Spezifikation der HAddr des MN für ein Paket getunnelt über den HA des MN) zu identifizieren, gefolgt von der Optionsdatenlänge 108 (welche von der Länge der CN-Adresse abhängt), gefolgt von den Optionsdaten selbst – d.h. der CN-Adresse 110.
Bei dieser Ausführungsform ist der GGSN IPv6-aktviert und er untersucht den Hop-by-Hop-Erweiterungsheader von jedem empfangenen IPv6-Paket, welches einen solchen Header aufweist. Es sei darauf hingewiesen, dass, da sich der Tunnel vom HA bis hin zum MN erstreckt, der GGSN ein Zwischenknotenpunkt ist, und gemäß der IPv6-Spezifikation (RFC 2460) muss der GGSN den Hop-by-Hop-Erweiterungsheader untersuchen. Umgekehrt sei darauf hingewiesen, dass gemäß der IPv6-Spezifikation (RFC 2460) der GGSN keinen anderen IPv6-Erweiterungsheader untersuchen muss, da es sich bei ihm um einen Zwischenknotenpunkt handelt. Ferner ist der GGSN modifiziert, um zu versuchen, die IP-Adresse des CN identifiziert in einem IPv6-Datenpaket, welches einen Hop-by-Hop-Erweiterungsheader enthält, an die TFT-Paketfilter gespeichert für PDP-Zusammenhänge, die der CoA des MN zugeordnet sind, abzubilden, und, wenn eine Übereinstimmung gefunden wird, die Datenpakete dementsprechend zu übertragen. Der Vorgang befolgt vom GGSN ist in 7 gezeigt. Der Vorgang beginnt mit Schritt 120. Bei Schritt 122 empfängt der GGSN ein Datenpaket für die Abwärtsstrecke an einen bestimmten MN, welcher eine CoA im GPRS-Netzwerk besitzt. Bei Schritt 124 untersucht der GGSN den Hop-by-Hop-Optionen Erweiterungsheader des empfangenen Paketes. Bei Schritt 126 vergleicht der GGSN die CN-Adresse spezifiziert im Hop-by-Hop-Optionen Erweiterungsheader mit den Quelladressfeldern von TFTs von PDP-Zusammenhängen zugeordnet zur IP-Adresse des MN (d.h. seiner CoA). Wenn bei Schritt 128 festgestellt wird, dass eine Übereinstimmung vorliegt, fährt der Vorgang mit Schritt 130 fort, wo das Paket mittels des PDP-Zusammenhangs, welcher die übereinstimmende TFT enthält, an den MN übertragen wird. Der Vorgang fährt dann fort mit Schritt 132 und endet. Wenn jedoch bei Schritt 128 festgestellt wird, dass keine Übereinstimmung vorliegt, fährt der Vorgang mit Schritt 132 fort und endet.
Der GGSN versucht auch, die Quelladresse des empfangenen Datenpaketes mit den Quelladressfeldern von TFTs von PDP-Zusammenhängen, die dem MN zugeordnet sind, gemäß der standardmäßigen GGSN-Funktionalität abzugleichen. So wird ein Datenpaket, welches entweder eine Quelladresse aufweist, die mit dem Quelladressattribut übereinstimmt ODER welches eine IP-Adresse spezifiziert in einem Hop-by-Hop-Optionen-Header aufweist, die mit dem Quelladressattribut übereinstimmt – welche die IP-Adresse des CN ist – mit mindestens diesen Attributen des TFT-Paketfilters übereinstimmen und wird zu dem GTP-Tunnel geroutet, der dem entsprechenden PDP-Zusammenhang entspricht. Es sei darauf hingewiesen, dass die Nichtübereinstimmung des Datenpaketes mit einer TFT dazu führen kann, dass das Datenpaket fallen gelassen wird, oder, alternativ dazu, dass es mittels eines PDP-Zusammenhangs an den MN übertragen wird, dem keine TFT zugeordnet ist, falls ein solcher existiert. Optional kann der MN nach dem Empfang des getunnelten Datenpaketes einen PDP-Zusammenhang modifizieren oder einen neuen PDP-Zusammenhang erstellen, um zu ermöglichen, dass getunnelte Datenpakete, wie zuvor in Bezug auf die erste Ausführungsform beschrieben, durch den GGSN an den MN übertragen werden.
Bei einer Variante der zweiten Ausführungsform ist der HA des MN modifiziert, um die IP-Adresse des CN selektiv in einen Hop-by-Hop-Optionen Erweiterungsheader des verkapselnden IPv6-Paketes für Datenpakete, die er an den MN tunnelt, einzufügen. Die Einfügung erfolgt nur, wenn der HA erkennt, dass dem MN Dienste in einem GPRS-Netzwerk bereitgestellt werden. So werden a) die laufenden Verarbeitungskosten dafür, dass der HA einen Hop-by-Hop-Optionen Erweiterungsheader in das getunnelte Datenpaket einfügt und b) die Zwischenknotenpunkte auf dem Weg in Richtung MN (ein schließlich des GGSN), welche den Hop-by-Hop-Optionen Erweiterungsheader überprüfen, dort eliminiert, wo sie nicht notwendig sind.
Dritte Ausführungsform
Gemäß einer dritten Ausführungsform der vorliegenden Erfindung wird ein PDP-Zusammenhang ohne zugeordnete TFT immer dann festgelegt, wenn sich ein MIP-aktivierter MN von seiner Heimposition entfernt in einem GPRS-Netzwerk befindet. So versucht der GGSN bei Empfang eines Datenpaketes, das Paket mit den PDP-Zusammenhängen mit zugeordneten TFTs abzugleichen; wenn dies jedoch fehlschlägt, wird das Paket mittels des PDP-Zusammenhangs ohne zugeordnete TFT geroutet. So wird ein Paket getunnelt über den HA des MN durch den GGSN an den MN übertragen, wo es entkapselt werden kann. Der MN kann dann das Paket einer bestehenden Kommunikationssitzung zuordnen, wenn eine solche existiert, indem er die Quelladresse des entkapselten Paketes prüft. Der MN kann dann einen PDP-Zusammenhang modifizieren oder einen neuen erstellen, um zu ermöglichen, dass getunnelte Paketdaten, wie zuvor in Bezug auf die erste Ausführungsform beschrieben, durch den GGSN an den MN übertragen werden.
Die Ansätze der ersten und zweiten Ausführungsform werden gegenüber dem Ansatz der dritten Ausführungsform bevorzugt, da bei diesem Ansatz keine CoA unterstützt werden kann, weil dem PDP-Zusammenhang keine TFT zugeordnet ist. Außerdem verschwendet dieser Ansatz Trägerressourcen, da ein GTP-Tunnel und ein PDP-Zusammenhang für Verkehr aufrechterhalten werden müssen, der möglicherweise über den HA an den MN geroutet wird, trotz dass bereits ein PDP-Zusammenhang und ein entsprechender GTP-Tunnel für die Kommunikationssitzung mit dem CN eingerichtet sind. Jedoch kann der Ansatz für einige Dienste ohne spezifische QoS-Anforderungen wie Background-Class-Dienste und Nicht-Echtzeit-Dienste von Nutzen sein.
Vierte Ausführungsform
Gemäß einer vierten Ausführungsform der vorliegenden Erfindung wird der HA-Tunnelungsvorgang wie folgt modifiziert. Erstens adressiert der HA getunnelte Datenpakete nicht an die CoA des MN, sondern an die Adresse des GGSN im GPRS-Netzwerk. In Kürze wird unten beschrieben, wie dem HA die Adresse des GGSN bereitgestellt wird, wenn sie ihm nicht schon bekannt ist. Zweitens fügt der HA die CN-Adresse in einen IPv6-Zieloption-Header ein, welcher vom GGSN bei Ankunft des getunnelten Datenpaketes gelesen werden kann. Drittens ist die CoA des MN in einen IPv6-Routing-Header Typ 0 Erweiterungsheader des getunnelten Paketes eingefügt. Dieser Routing-Header ermöglicht, dass ein IPv6-Paket durch eine Vielzahl von Knotenpunkten an verschiedenen Adressen geroutet wird, wobei damit begonnen wird, dass es an die Zieladresse des Paketes (in diesem Fall den GGSN) geliefert wird, und dann wird es wiederum an jeden Knotenpunkt, der einer Liste weiterer Routing-Adressen enthalten im Routing-Header (in diesem Fall nur die CoA des MN) entspricht, weitergeleitet.
8A zeigt die Struktur des verkapselnden Datenpaketes. Der IPv6-Grundheader 140 kommt zuerst. Die Existenz des IPv6-Routing-Headers (Typ 0) 142 wird gemäß dem standardmäßigen IPv6 (RFC 2460) im Feld IPv6 Nächster Header des IPv6-Grundheaders 100 angezeigt. Es sei darauf hingewiesen, dass die Zieladresse im IPv6-Grundheader 140 die Adresse des GGSN ist. Der IPv6-Routing-Header (Typ 0) 142 folgt dann umgehend auf den IPv6-Grundheader 140. Die Existenz des IPv6-Zieloption Erweiterungsheaders 144 wird gemäß dem standardmäßigen IPv6 (RFC 2460) im Feld IPv6 Nächster Header des IPv6-Routing-Headers (Typ 0) 142 angezeigt. Der IPv6-Zieloption Erweiterungsheader 144 folgt dann umgehend auf den IPv6-Routing-Header (Typ 0) 142. Schließlich folgen die Nutzdaten 146 – d.h. der Header der oberen Schicht wie TCP oder UDP und das verkapselte Datenpaket – auf den Zieloption-Erweiterungsheader 144.
8B zeigt die Struktur des Zieloption-Erweiterungsheaders 144 selbst. Das Format dieses Erweiterungsheaders ist im MIPv6-Internet-Draft unter Klausel 6.3 beschrieben. Die Felder Nächster Header und Hdr Ext Len des Zieloption-Erweiterungsheaders 144 sind aus Gründen der Übersichtlichkeit weggelassen. Die Adresse des CN ist in einer Typ-Länge-Wert (TLV) codierten Option in den Zieloption-Erweiterungsheader 144 eingefügt. So wird die Optionstypnummer 148 verwendet, um den Typ der Option (in diesem Fall 201, wie im MIPv6 spezifiziert) zu identifizieren, gefolgt von der Optionsdatenlänge 150 (welche von der Länge der Adresse des CN abhängt), gefolgt von den Optionsdaten selbst – d.h. die CN-Adresse 152.
8C zeigt die Struktur des Routing-Headers (Typ 0) Erweiterungsheaders 142 selbst. Das Format dieses Erweiterungsheaders ist im IPv6 (RFC 2460) beschrieben. Die Felder Nächster Header und Hdr Ext Len des Routing-Headers (Typ 0) Erweiterungsheaders 142 sind aus Gründen der Übersichtlichkeit weggelassen. Das Routing-Typ-Feld 154 (d.h. 0 in diesem Fall) kommt als nächstes, gefolgt vom Feld Übrige Segmente, welches anfänglich durch den HA auf 1 gesetzt ist (dieses zählt nach unten auf 0, wenn dass Datenpaket vom GGSN an die CoA des MN weitergeleitet wird). Dann folgt ein reserviertes Feld (auf 0 gesetzt) und dann die CoA des MN selbst.
Bei dieser Ausführungsform ist der GGSN IPv6-aktivert und er überprüft den Zieloption-Erweiterungsheader 144 des empfangenen IPv6-Paketes vor dessen Weiterleitung gemäß dem Routing-Header (Typ 0) Erweiterungsheader 142. Es sei darauf hingewiesen, dass durch das Bereitstellen der Adresse des GGSN als die Zieladresse das getunnelte Paket zuerst an den GGSN geliefert wird, der als Zielknotenpunkt fungiert (anstatt als ein Zwischenknotenpunkt wie bei der dritten Ausführungsform), und daher ist er in der Lage, den Zieloption-Erweiterungsheader 144 zu lesen. Ferner ist der GGSN modifiziert, um zu versuchen, die IP-Adresse des CN, die im Zieloption-Header identifiziert ist, an die TFT-Paketfilter gespeichert für PDP-Zusammenhänge, die der CoA des MN zugeordnet sind, abzubilden, welche in der IPv6-Routing-Header Typ 0 Option enthalten ist. Wenn eine Übereinstimmung gefunden wird, überträgt der GGSN dementsprechend die Datenpakete an den GTP-Tunnel, der dem entsprechenden PDP-Zusammenhang der CoA des MN zugeordnet ist.
Der Vorgang befolgt vom GGSN ist in 9 gezeigt. Der Vorgang beginnt mit Schritt 170. Bei Schritt 172 empfängt der GGSN ein Datenpaket mit einem IPv6-Routing-Header Typ 0, welcher anzeigt, dass das Paket für die Abwärtsstrecke an einen bestimmten MN, welcher eine CoA im GPRS-Netzwerk besitzt, bestimmt ist. Bei Schritt 174 untersucht der GGSN den Zieloption-Erweiterungsheader des empfangenen Paketes. Bei Schritt 176 vergleicht der GGSN die CN-Adresse spezifiziert im Zieloption-Erweiterungsheader mit den Quelladressfeldern von TFTs von PDP-Zusammenhängen zugeordnet zur CoA des MN. Wenn bei Schritt 178 festgestellt wird, dass eine Übereinstimmung vorliegt, fährt der Vorgang mit Schritt 180 fort, wo das Paket mittels des PDP-Zusammenhangs, welcher die übereinstimmende TFT enthält, an den MN übertragen wird. Der Vorgang fährt dann fort mit Schritt 182 und endet. Wenn jedoch bei Schritt 178 festgestellt wird, dass keine Übereinstimmung vorliegt, fährt der Vorgang mit Schritt 182 fort und endet.
Der GGSN versucht auch, die Quelladresse des empfangenen Datenpaketes mit den Quelladressfeldern von TFTs von PDP-Zusammenhängen zugeordnet zum MN gemäß der standardmäßigen GGSN-Funktionalität abzugleichen. So wird ein Datenpaket, welches entweder eine Quelladresse aufweist, die mit dem Quelladressattribut übereinstimmt ODER welches eine IP- Adresse spezifiziert in einem Zieloption-Header aufweist, die mit dem Quelladressattribut übereinstimmt – welche die IP-Adresse des CN ist – mit mindestens diesen Attributen des TFT-Paketfilters übereinstimmen und wird zu dem GTP-Tunnel geroutet, der dem entsprechenden PDP-Zusammenhang entspricht. Optional kann der MN dann einen PDP-Zusammenhang modifizieren oder einen neuen PDP-Zusammenhang erstellen, um zu ermöglichen, dass getunnelte Datenpakete wie zuvor in Bezug auf die erste Ausführungsform beschrieben durch den GGSN an den MN übertragen werden.
Wie jedoch bereits zuvor angegeben, erfordert dieser Vorgang, dass der HA die Adresse des GGSN im GPRS-Netzwerk kennt oder ihm diese bereitgestellt wird. Der HA kann die Adresse des GGSN im GPRS-Netzwerk möglicherweise aufgrund eines kommerziellen Arrangements zwischen den beiden Netzwerken kennen, wie zum Beispiel eine Roaming-Vereinbarung. Wenn dies jedoch nicht der Fall ist, kann ihm die Adresse wie Folgt bereitgestellt werden. Bevorzugt kann zur gleichen Zeit wie ein Heimverbindungs-Updatevorgang durchgeführt wird, jedoch möglicherweise auch später, der MN eine Nachricht senden, oder bevorzugt den GGSN selbst anweisen, eine Nachricht an den HA zu senden, welche die IP-Adresse des GGSN beinhaltet. Der MN kann seinen GGSN anweisen, ein solches Paket zu senden, unter Verwendung der PDP-Konfigurationsoptionen, welche in 3G TS 23.060 Klausel 9.2.2, hierin durch Verweis eingefügt, beschrieben sind. PDP-Konfigurationsoptionen enthalten optionale PDP-Parameter, die der GGSN an eine MS übertragen kann. Das Senden dieser optionalen PDP-Parameter kann durch den MN in der Aufforderungsnachricht zum Aktivieren des PDP-Zusammenhangs angefordert werden, die verwendet wird, um einen PDP-Zusammenhang für die Verwendung festzulegen, wenn das Heimverbindungsupdate an den HA gesendet wird, wenn der MN erstmalig in das GPRS-Netzwerk wechselt.
Bei einer Variante der vierten Ausführungsform wird die HA-Funktionalität so modifiziert, dass sie den zuvor beschriebenen Vorgang selektiv nur verwendet, wenn der HA vom MN informiert wird, dass ihm (dem MN) Dienste in einem GPRS-Netzwerk bereitgestellt werden.
Es wird ersichtlich sein, dass die vorliegende Erfindung Netzwerke betrifft, bei denen es sich nicht um das GPRS-Netzwerk handelt. Im Allgemeinen betrifft sie jedes Netzwerk, in welchem ein Netzübergangknotenpunkt möglicherweise einen aus einer Vielzahl von Kanälen (ob nun PDP-Zusammenhänge oder andere) für die Übertragung von Paketen der Abwärtsstrecke in Richtung eines Knotenpunktes, ob nun eines Nutzers oder eines Netzwerk-Nebenknotenpunktes, auswählen muss.
Es wird auch ersichtlich sein, dass die vorliegende Erfindung Situationen betrifft, in denen der Knotenpunkt (egal ob ein Nutzerknotenpunkt oder ein Netzwerkknotenpunkt) getunnelte Pakete erhalten kann, und zwar aus Gründen außer der Tatsache, dass es sich um einen MIP-aktivierten MN handelt. Im Allgemeinen gilt die vorliegende Erfindung immer dann, wenn Pakete zwischen Netzwerken oder untergeordneten Netzwerken getunnelt werden können, wobei der Netzübergangsknotenpunkt möglicherweise einen aus einer Vielzahl von Kanälen für die Übertragung von Paketen der Abwärtsstrecke in Richtung eines Knotens auswählen muss und wo sich der Tunnel über den Netzübergangsknotenpunkt oder die Knotenpunkte des Zielnetzwerkes hinaus erstreckt. Zum Beispiel findet die vorliegende Erfindung Anwendung in Virtuellen Privaten Netzwerken unter Verwendung des Layer 2 Tunnelling Protocoll (L2TP) oder anderer Tunnelungsprotokolle.
Die vorliegende Erfindung betrifft auch Situationen, in denen Netzübergangsknotenpunkte allgemeine Paketfilterungs- und/oder Firewall-Funktionen zum Schutz gegen unerlaubten Dienst/Trägerzugriff und/oder Dienstangriffe durchführen müssen.

Claims

Verfahren zum Befähigen eines Netzübergangsknotenpunktes (12) eines ersten paketvermittelten Datennetzwerks (10), einen ersten Kanal für die Übertragung eines getunnelten Datenpaketes an eine Zielpaketdatenprotokolladresse eines ortsveränderlichen Knotenpunktes (18) mit einem Dienst im ersten Netzwerk (10) auszuwählen, wobei der Netzübergangsknotenpunkt (12) so angeordnet ist, dass er den ersten Kanal aus einer Vielzahl von Kanälen, von denen jeder dazu da ist, Datenpakete zur Zielpaketdatenprotokolladresse des ortsveränderlichen Knotenpunktes (18) zu übertragen, auswählt, wobei das Auswählen so vor sich geht, dass eine Paketdatenprotokolladresse, die einem Datenpaket empfangen durch den Netzübergangsknotenpunkt (12) zugeordnet ist, mit einem oder mehreren Datenpaketfiltern, die der Vielzahl von Kanälen zugeordnet sind, abgeglichen wird, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: a) das Feststellen eines auslösenden Ereignisses, das anzeigt, dass der Netzübergangsknotenpunkt angepasst ist, ein Datenpaket, das über einen tunnelnden Knotenpunkt (48) eines zweiten paketvermittelten Datennetzwerkes außerhalb des ersten Netzwerkes (10) getunnelt wurde zu empfangen; und, b) als Reaktion auf das Feststellen, das Veranlassen, dass eine erste Paketdatenprotokolladresse in einen ersten Datenpaketfilter, der dem ersten Kanal zugeordnet ist, eingefügt wird, wobei die erste Paketdatenprotokolladresse, wenn sie einem Datenpaket empfangen durch den Netzübergangsknotenpunkt (12) zugeordnet ist, anzeigt, dass das Datenpaket über den tunnelnden Knotenpunkt getunnelt worden ist, und der erste Datenpaketfilter zur Verwendung durch den Netzübergangsknotenpunkt (12) bestimmt ist, wenn er aus der Vielzahl von Kanälen zur Übertragung von Datenpaketen an den ortsunabhängigen Knotenpunkt (18) unter der Zielpaketdatenprotokolladresse auswählt.
Verfahren nach Anspruch 1, wobei der Netzübergangsknotenpunkt (12) so angeordnet ist, um aus der Vielzahl von Kanälen auszuwählen, indem eine Quelladresse eines empfangenen Datenpaketes mit dem einen oder den mehreren Datenpaketfiltern, die der Vielzahl von Kanälen zugeordnet sind, abgeglichen wird, und die erste Paketdatenprotokolladresse die Paketdatenprotokolladresse des tunnelnden Knotenpunktes (48) ist.
Verfahren nach einem vorhergehenden Anspruch, wobei das auslösende Ereignis von dem ortsunabhängigen Knotenpunkt (18) festgestellt wird, und der ortsunabhängige Knotenpunkt (18) die Einbeziehung der ersten Paketdatenprotokolladresse in den ersten Datenpaketfilter veranlasst.
Verfahren nach Anspruch 3, wobei der ortsunabhängige Knotenpunkt (18) eine Heimpaketdatenprotokolladresse in dem zweiten Netzwerk (20) besitzt und das auslösende Ereignis ist, dass der ortsunabhängige Knotenpunkt (18) seine Zielpaketdatenprotokolladresse bei dem tunnelnden Knotenpunkt so anmeldet, dass die an den ortsunabhängigen Knotenpunkt (18) unter seiner Heimpaketdatenprotokolladresse adressierten Datenpakete von dem tunnelnden Knotenpunkt zu dem ortsunabhängigen Knotenpunkt (18) unter seiner Zielpaketdatenprotokolladresse getunnelt werden können.
Verfahren nach Anspruch 3, wobei das auslösende Ereignis ist, dass der ortsunabhängige Knotenpunkt (18) ein getunneltes Datenpaket empfängt, das von dem Netzübergangsknotenpunkt (12) durch einen zweiten Kanal gesendet wurde, der keinen zugeordneten Datenpaketfilter besitzt.
Verfahren nach einem vorhergehenden Anspruch, wobei die Ortsunabhängigkeit des ortsunabhängigen Knotenpunktes (18) zwischen Netzwerken oder untergeordneten Netzwerken durch die Verwendung der Mobilen Internet Protokoll (MIP)-Standards unterstützt wird, der tunnelnde Knotenpunkt (48) ein Vermittler der Ausgangsposition (HA) des ortsunabhängigen Knotenpunktes ist, und die Zielpaketdatenprotokolladresse eine Care-of-Adresse (CoA, CoCoA) des ortsunabhängigen Knotenpunktes (18) ist.
Verfahren nach Anspruch 6, wobei die erste Paketdatenprotokolladresse die Adresse des Vermittlers der Ausgangsposition (HA) des ortsunabhängigen Knotenpunktes (18) in dem zweiten Netzwerk (20) ist.
Verfahren nach einem vorhergehenden Anspruch, wobei der erste Paketfilter vor Schritt b) erstellt wurde, um den Netzübergangsknotenpunkt (12) zu befähigen, den ersten Kanal für die Übertragung von Datenpaketen, die von einem Korrespondenzknotenpunkt gesendet wurden, der an einer Kommunikationssitzung mit dem ortsunabhängigen Knotenpunkt beteiligt ist, auszuwählen, und in Schritt b) wird der erste Datenpaketfilter so modifiziert, dass er die erste Paketdatenprotokolladresse einschließt.
Verfahren nach Anspruch 8, wobei die erste Paketdatenprotokolladresse eine Datenpaketprotokolladresse des Korrespondenzknotenpunktes im ersten Datenpaketfilter ersetzt.
Verfahren nach Anspruch 8, wobei die erste Paketdatenprotokolladresse zu dem ersten Datenpaketfilter hinzugefügt ist, der auch eine Datenpaketprotokolladresse des Korrespondenzknotenpunktes umfasst.
Verfahren nach einem der Ansprüche 1 bis 10, wobei der erste Paketfilter in Schritt b) neu erstellt wird.
Verfahren nach einem vorhergehenden Anspruch, wobei das erste Netzwerk (10) mit den General Packet Radio Service (GPRS)-Standards übereinstimmt und die Vielzahl von Kanälen einer Vielzahl von Paketdatenprotokollzusammenhängen in dem ersten Netzwerk (10) entspricht.
Netzübergangsknotenpunkt (12) eines ersten paketvermittelten Datennetzwerkes (10), wobei der Netzübergangsknotenpunkt (12) so angeordnet ist, um einen Kanal zum Übertragen eines Datenpaketes an eine Zielpaketdatenprotokolladresse eines ortsunabhängigen Knotenpunktes mit einem Dienst in dem ersten Netzwerk aus einer Vielzahl von Kanälen, die alle zur Übertragung von Datenpaketen an die Zieldatenprotokollpaketadresse des ortsunabhängigen Knotenpunktes (18) da sind, auszuwählen, wobei das Auswählen durch einen Abgleich einer Paketdatenprotokolladresse, die einem Datenpaket empfangen durch den Netzübergangsknotenpunkt zugeordnet ist, mit einem oder mehreren Paketfiltern, die der Vielzahl von Kanälen zugeordnet sind, erfolgt dadurch gekennzeichnet, dass als Reaktion auf die Feststellung eines auslösenden Ereignisses, welches anzeigt, dass der Netzübergangsknotenpunkt (12) angepasst ist, ein Datenpaket, das über einen tunnelnden Knotenpunkt (48) eines zweiten paket-vermittelten Datennetzwerkes (20) außerhalb des ersten Netzwerkes (10) getunnelt wurde zu empfangen, der Netzübergangsknotenpunkt (12) so angeordnet ist, dass er einen ersten Kanal aus der Vielzahl von Kanälen auswählen kann, indem er eine Paketdatenprotokolladresse, die einem empfangenen Datenpaket zugeordnet ist, mit einer ersten Paketdatenprotokolladresse, die in einen ersten Datenpaketfilter enthalten ist, der dem ersten Kanal zugeordnet ist, abgleicht, wobei die erste Paketdatenprotokolladresse darauf hinweist, dass das Datenpaket über den tunnelnden Knotenpunkt (48) getunnelt wurde.
Netzübergangsknotenpunkt (12) nach Anspruch 13, wobei der Netzübergangsknotenpunkt (12) so angeordnet ist, aus der Vielzahl von Kanälen durch den Abgleich einer Quelladresse eines empfangenen Datenpaketes mit dem einen oder den mehreren Datenpaketfiltern, die der Vielzahl von Kanälen zugeordnet sind, auszuwählen, und die erste Paketdatenprotokolladresse die Paketdatenprotokolladresse des tunnelnden Knotenpunktes (48) ist.
Netzübergangsknotenpunkt (12) nach Anspruch 13 oder 14, wobei das auslösende Ereignis von dem ortsunabhängigen Knotenpunkt (18) festgestellt wird, und der Netzübergangsknotenpunkt (12) von dem ortsunabhängigen Knotenpunkt (18) angewiesen wird, die erste Paketdatenprotokolladresse in den ersten Datenpaketfilter einzufügen.
Netzübergangsknotenpunkt (12) nach Anspruch 15, wobei der ortsunabhängige Knotenpunkt (18) eine Heimpaketdatenprotokolladresse in dem zweiten Netzwerk (10) besitzt und das auslösende Ereignis ist, dass der ortsunabhängige Knotenpunkt (18) seine Zielpaketdatenprotokolladresse bei dem tunnelnden Knotenpunkt (48) so anmeldet, dass die an den ortsunabhängigen Knotenpunkt (18) unter seiner Heimpaketdatenprotokolladresse adressierten Datenpakete von dem tunnelnden Knotenpunkt (48) an den ortsunabhängigen Knotenpunkt (18) unter seiner Zielpaketdatenprotokolladresse getunnelt werden können.
Netzübergangsknotenpunkt (12) nach Anspruch 16, wobei das auslösende Ereignis ist, dass der ortsunabhängige Knotenpunkt (18), der ein getunneltes Datenpaket, das von dem Netzübergangsknotenpunkt (12) über einen zweiten Kanal gesendet wurde, welchem kein Datenpaketfilter zugeordnet ist, empfängt.
Netzübergangsknotenpunkt (12) nach einem der Ansprüche 13 bis 17, wobei die Ortsunabhängigkeit des ortsunabhängigen Knotenpunktes zwischen Netzwerken oder untergeordneten Netzwerken durch die Verwendung der Mobilen Internet Protokoll (MIP)-Standards unterstützt wird, der tunnelnde Knotenpunkt (48) ein Vermittler der Ausgangsposition (HA) des ortsunabhängigen Knotenpunktes (18) ist, und die Zielpaketdatenprotokolladresse eine Care-of-Adresse (CoA, CoCoA) des ortsunabhängigen Knotenpunktes (18) ist.
Netzübergangsknotenpunkt (12) nach Anspruch 18, wobei die erste Paketdatenprotokolladresse die Adresse des Vermittlers der Ausgangsposition (HA) des ortsunabhängigen Knotenpunktes (18) in dem zweiten Netzwerk (10) ist.
Netzübergangsknotenpunkt (12) nach einem der Ansprüche 13 bis 19, wobei der erste Paketfilter vor der Reaktion auf die Feststellung des auslösenden Ereignisses nach Anspruch 13 erstellt wurde, um den Netzübergangsknotenpunkt (12) zu befähigen, den ersten Kanal für die Übertragung von Datenpaketen, die von einem Korrespondenzknotenpunkt (12) gesendet wurden, der an einer Kommunikationssitzung mit dem ortsunabhängigen Knotenpunkt (18) beteiligt ist, auszuwählen, und in Schritt b) der erste Datenpaketfilter so modifiziert wird, dass er die erste Paketdatenprotokolladresse beinhaltet.
Netzübergangsknotenpunkt (12) nach Anspruch 20, wobei die erste Paketdatenprotokolladresse eine Datenpaketprotokolladresse des Korrespondenzknotenpunktes im ersten Datenpaketfilter ersetzt.
Netzübergangsknotenpunkt (12) nach Anspruch 20, wobei die erste Paketdatenprotokolladresse zu dem ersten Datenpaketfilter, welcher auch eine Paketdatenprotokolladresse des Korrespondenzknotenpunktes umfasst, hinzugefügt ist.
Netzübergangsknotenpunkt (12) nach einem der Ansprüche 13 bis 19, wobei der erste Paketfilter als Reaktion auf die Feststellung des auslösenden Ereignisses nach Anspruch 13 neu erstellt wird.
Netzübergangsknotenpunkt (12) nach einem der Ansprüche 13 bis 23, wobei das erste Netzwerk mit den General Packet Radio Service (GPRS)-Standards übereinstimmt und die Vielzahl von Kanälen einer Vielzahl von Paketdatenprotokollzusammenhängen in dem ersten Netzwerk entspricht.