DE102004008720B4 - Vorrichtung und Verfahren zur Durchführung von Verkehrsflussschablonen-Paketfilterung gemäß Internet-Protokollversionen in einem mobilen Kommunikationssystem - Google Patents

Vorrichtung und Verfahren zur Durchführung von Verkehrsflussschablonen-Paketfilterung gemäß Internet-Protokollversionen in einem mobilen Kommunikationssystem Download PDF

Info

Publication number
DE102004008720B4
DE102004008720B4 DE200410008720 DE102004008720A DE102004008720B4 DE 102004008720 B4 DE102004008720 B4 DE 102004008720B4 DE 200410008720 DE200410008720 DE 200410008720 DE 102004008720 A DE102004008720 A DE 102004008720A DE 102004008720 B4 DE102004008720 B4 DE 102004008720B4
Authority
DE
Germany
Prior art keywords
version
address
tft
packet
ipv4
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE200410008720
Other languages
English (en)
Other versions
DE102004008720A1 (de
Inventor
Hong-Jin Suwon Ahn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of DE102004008720A1 publication Critical patent/DE102004008720A1/de
Application granted granted Critical
Publication of DE102004008720B4 publication Critical patent/DE102004008720B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/06—Interfaces between hierarchically different network devices between gateways and public network devices

Abstract

Verfahren zur Durchführung von Verkehrsflussschablonen-Filterung (TFT) in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem, wobei das Verfahren die folgenden Schritte aufweist:
Extrahieren einer ersten IP-Versionsadresse aus einer zweiten IP-Versions-Quellenadresse, worin die zweite IP-Versionsadresse eine erste IP-Versionsadresse enthält;
Erzeugen von TFT-Information auf der Basis der ersten IP-Versionsadresse, worin die TFT Information eine Angabe enthält, dass die zweite IP Versionsadresse eine erste IP-Versionsadresse enthält; und
Übertragen der TFT-Information an einen Gateway-GPRS-(Allgemeiner Paketfunkdienst)-Unterstützungsknoten (GGSN).

Description

  • Hintergrund der Erfindung
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf ein mobiles Kommunikationssystem und insbesondere auf eine Vorrichtung und ein Verfahren zur Durchführung von Verkehrsflussschablonen-Paketfilterung (TFT) gemäß Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem.
  • Beschreibung der verwandten Technik
  • Ein universelles mobiles Kommunikationssystem (UMTS) stellt ein Kommunikationssystem dar, das mobile Kommunikation der dritten Generation durchführt. Das UMTS unterstützt Paketdatendienste ebenso wie Sprachkommunikationsdienste, und unterstützt Hochgeschwindigkeitsdatenkommunikation, Bewegtbildkommunikation usw. Die schematische Architektur des UMTS-Netzwerks wird mit Bezug auf 1 beschrieben.
  • 1 zeigt ein Blockdiagramm, das die Architektur eines gewöhnlichen UMTS-Netzwerks veranschaulicht.
  • Mit Bezug auf 1, verarbeiten Benutzeinrichtungen (UE) 111, die mit einem erdgebundenen UMTS-Funkzugriffsnetzwerk (UTRAN) 113 verbunden sind, ei nen Ruf und unterstützen beides, einen Schaltungsdienst (CS) und einen Paketdienst (PS). Das UTRAN 113 ist aus wenigstens einem Knoten B (nicht gezeigt) und wenigstens einem Funknetzwerk-Steuergerät (RNC) (nicht gezeigt) aufgebaut. Der Knoten B ist mit dem UE 111 über eine Uu-Schnittstelle verbunden und die RNC ist mit einem dienendem GPRS-Unterstützungsknoten (SGSN) 115 über eine Iu-Schnittstelle verbunden. Ein allgemeiner Funkpaketdienst (GPRS) ist ein Paketdatendienst, der durch das UMTS-Netzwerk zur Verfügung gestellt wird. Das UTRAN 113 führt eine Protokollwandlungsfunktion aus, um Funkdaten oder Steuernachrichten, die über die Luftschnittstelle empfangen werden, in ein Kernnetzwerk CN zu überführen, das ein GPRS-Tunnelprotokoll GTP verwendet. Hier wird das CN als die Gesamtheit aus SGSN 115 und einem Gateway-GPRS-Unterstützungsknoten (GGSN) 119 bezeichnet.
  • Der SGSN 115 ist ein Netzwerkknoten zur Handhabung von Teilnehmerinformationen und Ortinformationen vom UE 111. Der SGSN 115 ist mit dem UTRAN 113 über die Iu-Schnittstelle verbunden und ist mit dem GGSN 119 über eine Gn-Schnittstelle verbunden, so dass Daten und Steuernachrichten gesendet und empfangen werden. Der SGSN 115 ist mit dem Home-Location-Register (HLR) 117 über eine Gr-Schnittstelle verbunden, um Teilnehmerinformationen und Ortsinformationen zu handhaben.
  • Das HLR 117 speichert Teilnehmerinformation und Routeninformation, die einer Paketdomäne zugeordnet sind, und ähnliches. Das HLR 117 ist mit dem SGSN 115 über eine Gr-Schnittstelle verbunden und mit dem GGSN 119 über eine Gc-Schnittstelle verbunden. Natürlich kann sich das HLR 117 im Bereich eines öffentlichen Mobilfunknetzes (PLMN) befinden, wenn Roaming der UE 111 in Betracht gezogen wird. Der GGSN 119 entspricht einem Endpunkt verbunden mit der GTP des UMTS-Netzwerkes und der GGSN 119, welcher über eine Gi-Schnittstelle an ein externes Netzwerk angebunden ist, kann transparent mit dem Internet 121, einem Paketdomänen-Netzwerk (PDN) oder einem PLMN verbunden werden.
  • Die Architektur des UMTS-Kernnetzwerkes, in welchem eine Verkehrsflussschablone TFT benutzt wird, wird schematisch mit Bezug auf 2 beschrieben.
  • 2 ist ein schematisches Blockdiagramm, welches das UMTS-Kernnetzwerk basierend auf einer gewöhnlichen Verkehrsflussschablone veranschaulicht.
  • Bevor das UMTS-Kernnetzwerk mit Bezug auf 2 beschrieben wird, sollte angemerkt werden, dass eine Paketfilterungsfunktion unter Benutzung der TFT durchgeführt wird, und dass das UMTS-Kernnetzwerk die TFT benutzt. Der Gebrauch der TFT wird wie im Folgenden beschrieben. Paketdatenprotokoll-Kontexte (PDP) enthalten zwei Arten von primären und sekundären PDP-Kontexten. Der sekundäre PDP-Kontext hat dieselbe Information wie der primäre PDP-Kontext und kann lediglich dort existieren, wo der primäre PDP-Kontext gegenwärtig ist. Weil der sekundäre PDP-Kontext Informationen des primären PDP-Kontextes benutzt wie sie sind, wird der sekundäre PDP-Kontext erzeugt, nachdem der primäre PDP-Kontext erzeugt wird. Die primären und sekundären PDP-Kontexte benutzen tatsächlich dieselbe Information und lediglich Paketdatenelemente, die mit den primären und sekundären PDP-Kontexten verbunden sind, werden durch die verschiedenen GTP-Tunnel übertragen. Eine solche TFT-Paketfilterungsfunktion ist z. B. aus der WO 02/73989 A1 bekannt.
  • Das UMTS-Kernnetzwerk benutzt die TFT-Information als Filter zur Anzeige der primären und sekundären PDP-Kontexte, wo der sekundärer PDP-Kontext aktiviert wird. Wie in 2 gezeigt, gibt es ein UMTS-Kernnetzwerk 200, d. h. ein Breitband-Codeteilungs-Mehrfachzugriff-Kernnetzwerk 200 (WCDMA), in welchem sieben TFTs gespeichert werden. Eine Gesamtheit von acht GTP-Tunneln wird in Verbindung mit sekundären PDP-Kontexten erzeugt, welche sieben TFTs in einem primären PDP-Kontext entsprechen. IP-Paketdaten, die über ein externes Netzwerk eintreffen, d. h. das Internet 121, werden in den GGSN 119 über die Gi-Schnittstelle eingegeben. Der GGSN 119 speichert die sieben TFTs ein schließlich TFT1 bis TFT7. Ein Pfad zur Eingabe der Paketdaten über die Gi-Schnittstelle wird über einen Paketfilterungs-Arbeitsgang durch die sieben TFTs bestimmt. Die IP-Paketdaten, die durch den GGSN 119 unter Verwendung der TFTs gefiltert werden, werden an den SGSN 115 über die Gn-Schnittstelle, welche dem bestimmten Pfad zugeordnet ist, d. h. dem bestimmten GTP-Tunnel, übermittelt. Der SGSN 115 überträgt die IP-Paketdaten, die er vom GGSN 119 erhalten hat, an ein Funkzugriffsnetzwerk (RAN) 211 durch eine Iu-Schnittstelle unter Verwendung eines zugeordneten GTP-Tunnels.
  • Ein Format der TFT wird nun unter Bezug auf 3 beschrieben.
  • 3 zeigt ein Blockdiagramm, welches das Format einer herkömmlichen TFT veranschaulicht.
  • Die TFT wird von der UE 111 erzeugt und die erzeugte TFT wird durch das UTRAN 113 und den SGSN 115 an den GGSN 119 übertragen. Der GGSN 119 filtert Paketdaten, die durch ein externes Netzwerk zugeführt werden, d. h. das Internet 121, unter Verwendung des TFT zur Anzeige eines primären GTP-Tunnels und eines sekundären GTP-Tunnels, sucht nach einem GTP-Tunnel, über welchen die gefilterten Paketdaten übertragen werden. Wo keine TFT vorliegt, weil der primäre GTP-Tunnel, der den primären PDP-Kontext verwendet, und der sekundäre GTP-Tunnel, der den sekundären PDP-Kontext verwendet, die gleiche PDP-Adresse aufweisen, kann kein GTP-Tunnel bestimmt werden, über den die Paketdaten übertragen werden, welche vom externen Netzwerk empfangen werden, d. h., ob die Paketdaten über den primären GTP-Tunnel oder den sekundären GTP-Tunnel übertragen werden, kann nicht bestimmt werden.
  • Die TFT weist eine Vielzahl von Paketfiltern, d. h. acht Paketfilter auf, die über eindeutige Paketfilter-Identifikatoren (IDs) identifiziert werden können. Die Paketfilter haben besondere Bewertungs-Prioritätenindices für all jene TFTs, die den PDP-Kontexten mit den gleichen PDP-Adressen zugeordnet sind. Jeder Bewer tungs-Prioritätenindex einen Wert zwischen 0 und 255. Die UE 11 handhabt einen Paketfilterindex und einen Bewertungs-Prioritätenindex zugeordnet zu dem Paketfilter und erzeugt den Inhalt eines tatsächlichen Paketfilters. In anderen Worten kann die TFT zusätzlich in einer PDP-Kontext-Abwandlungsprozedur erzeugt werden, die durch die UE 111 angestoßen wird, zusätzlich zu dem PDP-Kontext, der in der PDP-Kontext-Aktivierungsprozedur erzeugt wird. Die TFT kann durch die PDP-Kontext-Abwandlungsprozedur, angestoßen durch den UE 111, korrigiert werden. Ein PDP-Kontext kann nicht mehr als eine ihm zugeordnete TFT haben.
  • Bezug nehmend auf 3 enthält die TFT ein Verkehrsflussschablonenartfeld, ein Verkehrsflussschablonen-Längenfeld, ein TFT-Arbeitscodefeld, ein Anzahl von Paketfilter-Feld und ein Paketfilter-Listenfeld. Das Verkehrsflussschablonenartfeld zeigt die Art einer verwendeten TFT an. Der Wert des Verkehrsflussschablonenartfeldes wird im UMTS-Kernnetzwerk 200 typischerweise auf 137 gesetzt und kann gemäß der Netzwerke verschieden gesetzt werden. Das Verkehrsflussschablonen-Längenfeld zeigt die Länge des verwendeten TFT an, hat eine vorbestimmte Länge, d. h. zwei Byte, und zeigt die Länge der verbleibenden Felder, außer dem Verkehrsflussschablonenartfeld und dem Verkehrsflussschablonen-Längenfeld an. Das TFT-Betriebscodefeld gibt einen Betriebscode des TFT an. Ein Wert, der durch das TFT-Betriebscodefeld angezeigt wird, wird analysiert und es wird bestimmt, wie die TFT, die von der UE 111 empfangen wird, gemäß dem Ergebnis der Analyse verarbeitet wird. Codes, die durch den TFT-Betriebscode angezeigt werden können, sind in der folgenden Tabelle 1 dargestellt. Tabelle 1
    Bits (765) Beschreibung
    000 Frei
    001 Erzeuge neue TFT
    010 Lösche Gespeicherte TFT
    011 Füge Paket Filter zu gespeicherter TFT hinzu
    100 Ersetze Paket Filter in gespeicherter TFT
    101 Lösche Paket Filter aus gespeicherter TFT
    110 Reserviert
    111 Reserviert
  • Wie in obiger Tabelle 1 gezeigt, gibt der Betriebscode "000" einen freien Code an, der TFT-Betriebscode "001" zeigt den Betriebscode für einen Arbeitsgang zur Erzeugung einer neuen TFT an, der TFT-Betriebscode "011" zeigt den Arbeitsgang zur Hinzufügung eines Paketfilters zu einer gespeicherten TFT an, der TFT-Betriebscode "100" zeigt den Arbeitsgang zum Ersetzen eines Paketfilters in der gespeicherten TFT an, der TFT-Betriebscode "101" zeigt einen Arbeitsgang zur Löschung eines Paketfilters aus einer gespeicherten TFT an, und die TFT-Betriebscodes "110" und "111" zeigen jeweils reservierte Werte an. Der GGSN 119 liest das TFT-Betriebscodefeld und führt den entsprechenden Arbeitsgang aus.
  • Das "Anzahl von Paketfiltern"-Feld gibt die Anzahl der Paketfilter an, die in der benutzten TFT gesetzt sind, d. h., die Anzahl von Paketfiltern, die auf einer Paketfilterliste der TFT existieren. Zum Beispiel wo ein Wert des TFT-Betriebscodes als 010 gespeichert ist, d. h. die gespeicherte TFT gelöscht wird, wird der Wert des Anzahl von Paketfilter-Feldes auf 0 gesetzt. Außer für den Fall, in dem die gespeicherte TFT gelöscht wird, ist die Anzahl der Paketfilter größer als 0 und kleiner oder gleich acht, d. h. 0 > Anzahl Paketfilter ≤ 8. Der Grund warum die Anzahl der Paketfilter gleich 0 und kleiner oder gleich 8 ist, liegt darin, dass die maximale Anzahl der Paketfilter im UMTS-Kernnetzwerk 200 acht beträgt. Die TFT-Information kann von wenigstens einem Paketfilter bis zu einem Maximum von acht Paketfiltern aufweisen. Die Paketfilter sind in Einzelfeld-Paketfilter eingeteilt, basierend auf einem Einzelinhalt und in Multifeld-Paketfilter, basierend auf verschiedenem Inhalt. Hier entspricht der Einzelfeld-Paketfilter einem Inhalt, der durch ihn gefiltert wird, d. h. einer Quellenadresse, während der Multifeld-Paketfilter einem mehrfachen Inhalt entspricht, der durch ihn gefiltert werden soll, d. h. der mehrfache Inhalt enthält eine Quellenadresse, einen Protokollinhalt, eine Zieladresse usw. Das Paketfilter-Listenfeld zeigt Inhalte korrespondierend mit Informationen von Paketfiltern an, die tatsächlich benutzt werden, und im TFT gesetzt sind.
  • Die TFT basierend auf dem Format, das in 3 gezeigt ist, ist im GGSN 119 gespeichert. Wenn IP-Paketdaten vom externen Internet 121 empfangen werden, werden die IP-Paketdaten durch Paketfilter, die in der TFT gespeichert sind, gefiltert. Hier gestatten es die IP-Paketdaten, welche durch die Paketfilter innerhalb des TFT gefiltert werden, einen gespeicherten PDP-Kontext zu verwenden. Wenn zum Beispiel eingegebene IP-Paketdaten nicht an den ersten Paketfilter angelegt werden können, wo drei Paketfilter beinhaltend den ersten bis dritten Paketfilter in der TFT existieren, dann werden die eingegebenen IP-Paketdaten an den zweiten Paketfilter angelegt. Wenn auf diese Art, die eingegebenen Paketdaten nicht an den letzten Paketfilter angelegt werden können, d. h. alle Paketfilter, dann verwenden die eingegebenen Paketdaten einen anderen GTP-Tunnel und die nachfolgenden Paketfilter-Arbeitsschritte werden versucht, indem die nachfolgenden TFT eher verwendet werden als die TFT die einem vollständigen Paketfilter-Arbeitsgang zugeordnet ist.
  • Als nächstes wird eine GTP-Tunnel-Erzeugungsprozedur gemäß PDP-Kontext-Aktivierung mit Bezug auf 4 beschrieben.
  • 4 zeigt ein Flussdiagramm, das Nachrichten veranschaulicht, die im GTP-Tunnel-Aktivierungsprozess gemäß der primären PDP-Kontext-Aktvierung erzeugt werden.
  • Damit Daten übertragen werden können, die einer UMTS-Paketdomäne zugeordnet sind, d. h. Paketdaten, muss ein GTP-Tunnel zur Übertragung der Paketdaten erzeugt werden. Pfade zur Erzeugung von GTP-Tunneln werden in Pfade unterteilt demgemäss ob die UE 111 eine Anforderung an das Kernnetzwerk schickt, d. h. UE-initiierte Aktivierung, und einem Pfad demgemäss ob das externe Netzwerk eine Anforderung an das UMTS-Kernnetzwerk sendet, d. h. eine Netzwerkangeforderte Aktivierung.
  • Mit Bezug auf 4 detektiert die UE 111 erzeugte Paketdaten und erzeugt folglich wenigstens einen GTP-Tunnel zur Übertragung der Paketdaten. Die UE 111 sendet im Schritt 411 eine "Aktiviere PDP-Kontext-Anforderung"-Nachricht an den SGSN 115 zur Erzeugung des GTP-Tunnels. Die "Aktiviere PDP-Kontext-Anforderung"-Nachricht enthält Parameter in Verbindung mit einem Netzwerklagen-Dienstezugriffspunkt-Identifikator (NSAPI), einen Arbeitsvorgangs-Identifikator (TI), eine PDP-Art, eine PDP-Adresse, einen Zugriffspunkt-Namen (APN), eine Servicekategorie (QoS) und dergleichen.
  • Der NSAPI ist Information erzeugt durch die UE 111 und kann eine Gesamtheit von 11 Werten einschließlich der Zahlen 5 bis 15 verwenden. Der Wert des NSAPI hat eine Eins-zu-Eins-Entsprechung mit der PDP-Adresse und einem PDP-Kontext-ID. Die PDP-Adresse zeigt die IP-Adresse der UE 111 an, die in der UMTS-Paketdomäne verwendet wird, und konfiguriert die PDP-Kontext-Information. Hier weist der PDP-Kontext verschiedene Informationselemente des GTP-Tunnels auf und wird durch den PDP-Kontext-ID gehandhabt. Der TI wird zwischen der UE 111, dem UTRAN 113 und dem SGSN 115 verwendet. Jedem GTP-Tunnel wird ein spezifischer Wert zugeordnet, um den GTP-Tunnel anzuzeigen. Der TI und der NSAPI basieren auf fast demselben Konzept, außer dass der TI zwischen der UE 111, dem UTRAN 113 und dem SGSN 115 verwendet wird, und der NSAPI zwischen der UE 111, dem SGSN 115 und dem GGSN 119 verwendet wird. Die PDP-Art zeigt die Art eines GTP-Tunnels an, der durch die "Aktiviere PDP-Kontext-Anforderung"-Nachricht erzeugt werden soll. Hier enthalten die Arten von GTP-Tunneln Tunnel, die mit einem IP, einem PPP (Punkt-zu-Punkt-Protokoll), einem mobilen IP, etc. assoziiert sind. Der Zugriffspunkt name gibt einen Zugriffspunkt eines Dienstenetzwerks an, auf den gegenwärtig durch die UE 111 zugegriffen werden soll, welche eine Anforderung zur GTP-Kanalerzeugung tätigt. Die Qos-Parameter geben die Qualität der Paketdaten an, die durch den gegenwärtig erzeugten GTP-Tunnel übertragen werden sollen. In anderen Worten, die Paketdaten, die den GTP-Tunnel verwenden und eine hohe QoS haben, werden früher verarbeitet als diejenigen, welche den GTP-Tunnel verwenden und eine niedrige QoS aufweisen.
  • Der SGSN 115 der die Nachricht "Aktiviere PDP-Kontext-Anforderung" erhält, sendet eine "Funkzugriffs-Trägereinrichtung"-Nachricht an das UTRAN 113, so dass der Funkzugriffsträger zwischen dem SGSN 115 und dem UTRAN 113 im Schritt 413 eingerichtet werden kann. Darüber hinaus sendet das UTRAN 113 die "Funkzugriffs-Trägereinrichtung"-Nachricht an die UE 111, so dass der Funkzugriffsträger zwischen dem UTRAN 113 und der UE 111 im obigen Schritt 413 eingerichtet werden kann. Mit der Einrichtung des Funkzugriffsträgers zwischen dem SGSN 115 und dem UTRAN 113 und des Funkzugriffsträgers zwischen dem UTRAN 113 und der UE 111 wird die Zuordnung von Ressourcen abgeschlossen, die zur Übertragung der Paketdaten über die Luftschnittstelle benötigt werden. Eine "Rufe Ablaufverfolgung auf"-Nachricht, die in 4 gezeigt ist, wird wie folgt beschrieben. Wo eine Ablaufverfolgungsfunktion im UTRAN 113 aktiviert ist, überträgt der SGSN 115 die Nachricht "Rufe Ablaufverfolgung auf" an das UTRAN 113 gemeinsam mit der Ablaufverfolgungsinformation, die vom HLR (Hume Location Register) (nicht gezeigt) oder einem IMC (Betriebs- und Wartungszentrum) (nicht gezeigt) in Schritt 415 erhalten wird. Hier wird die Ablaufverfolgungsfunktion benutzt, um den Datenstrom zu verfolgen.
  • Wenn der Funkzugriffsträger zwischen dem SGSN 115 und dem UTRAN 113 eingerichtet ist, überträgt der SGSN 115 eine "Erzeuge PDP-Kontext-Anforderung"-Nachricht an den GGSN 119 in Schritt 417. Zu diesem Zeitpunkt werden neue Tunnelendpunkt-IDs (TEIDs) zwischen dem SGSN 115 und dem GGSN 119 gesetzt und die TEIDs werden so gesetzt, dass die Paketdaten zwi schen den Netzwerkknoten unter Verwendung der GTP-Tunnel übertragen werden können. In anderen Worten merkt sich der SGSN 115 den TEID des GGSN 119 und der GGSN 119 merkt sich den TEID des SGSN 115. Demnach enthält die "Erzeuge PDP-Kontext-Anforderung" den TEID, der zu verwenden ist, wenn der GGSN 119 die Paketdaten an den SGSN 115 überträgt.
  • Als Antwort auf die "Erzeuge PDP-Kontext-Anforderung"-Nachricht sendet der GGSN 119 eine "Erzeuge PDP-Kontext-Antwort"-Nachricht, wenn die PDP-Erzeugung in Schritt 419 angemessen abgeschlossen ist. Demnach ist die GTP-Tunnelerzeugung zwischen dem SGSN 115 und dem GGSN 119 abgeschlossen und folglich werden Paketdaten übertragen. Als Reaktion auf die "Erzeuge PDP-Kontext-Antwort"-Nachricht sendet der SGSN 115 in Schritt 421 eine "Aktiviere PDP-Kontext-Annahme"-Nachricht an die UE 111. Wenn die UE 111 die "Aktiviere PDP-Kontext-Annahme"-Nachricht erhält, dann wird ein Funkkanal zwischen der UE 111 und dem UTRAN 113 aufgebaut, so dass wenigstens ein GTP-Tunnel vollständig zwischen dem UTRAN 113, dem SGSN 115 und dem GGSN 119 aufgebaut ist. In anderen Worten kann die UE 111 alle Paketdatenelemente übertragen, die an ihre eigene Adresse gesendet werden. Auf der anderen Seite hat der GTP-Tunnel, der durch den oben beschriebenen PDP-Kontext-abhängigen Arbeitsprozess erzeugt wird, eine Eins-zu-Eins-Entsprechung mit einem PDP-Kontext. Da PDP-Kontexte verschieden sind, wenn GTP-Tunnel verschieden sind, weisen die PDP-Kontexte verschiedene Tunnelinformationselemente auf.
  • Der GTP-Tunnel-Erzeugungsprozess gemäß der üblichen PDP-Kontext-Aktivierung, d. h. der primären Kontext-Aktivierungsprozedur, wurde mit Bezug auf 4 beschrieben. Ein weiterer GTP-Tunnel-Erzeugungsprozess gemäß der sekundären PDP-Kontext-Aktivierung, wird nun mit Bezug auf 5 beschrieben.
  • 5 zeigt ein Ablaufdiagramm, das Nachrichten veranschaulicht, die im GTP-Tunnel-Erzeugungsprozess gemäß der sekundären PDP-Kontext-Aktivierung erzeugt werden.
  • Die sekundäre PDP-Kontext-Aktivierungsprozedur ist ein Arbeitsablauf zur Erzeugung wenigstens eines neuen GTP-Tunnels durch Wiederverwendung der GTP-Tunnelinformation des vorangegangenen aktivierten primären PDP-Kontextes. In anderen Worten wird der GTP-Tunnel, der durch die sekundäre PDP-Kontext-Aktivierungsprozedur erzeugt wird, als der sekundäre GTP-Tunnel bezeichnet. Der sekundäre GTP-Tunnel benutzt die primäre PDP-Kontext-Information wie sie ist.
  • Mit Bezug auf 5 sendet die UE 111 eine "Aktiviere sekundäre PDP-Kontext-Anforderung"-Nachricht an den SGSN 115, um im Schritt 511 den sekundären GTP-Tunnel zu erzeugen. Die "Aktivierte sekundäre PDP-Kontext-Anforderung"-Nachricht enthält Parameter, die einem NSAPI entsprechen, einen zugeordneten TI, eine PDP-Art, eine PDP-Adresse, ein APN (Zugriffspunktname), Qos usw. Hier enthält die "Aktivierte sekundäre PDP-Kontext-Anforderung"-Nachricht, die von der "Aktiviere PDP-Kontext-Anforderung"-Nachricht verschieden ist, einen zugeordneten TI und benutzt die zuvor aktivierte primäre PDP-Kontext-Information, d. h. die primäre GTP-Tunnelinformation wie sie ist. Weil der TI zur Anzeige der GTP-Tunnel zwischen der UE 111, dem UTRAN 113 und dem SGSN 115 benutzt wird, wie oben in Verbindung mit 4 beschrieben, wird der korrespondierende TI benutzt, damit einer oder mehrere sekundäre GTP-Tunnel dieselbe Information wie der primäre GTP-Tunnel verwenden können.
  • Als Reaktion auf die "Aktivierte sekundäre PDP-Kontext-Anforderung"-Nachricht sendet der SGSN 115 in Schritt 513 eine "Funkzugriffs-Trägereinrichtung"-Nachricht an den UTRAN 113, damit der Funkzugriffsträger zwischen dem UTRAN 113 und dem SGSN 115 eingerichtet werden kann. Das UTRAN 113 überträgt die "Funkzugriffs-Trägereinrichtung"-Nachricht an die UE 111, so dass in Schritt 515 der Funkzugriffsträger zwischen dem UTRAN 113 und der UE 11 eingerichtet werden kann. Nachdem der Funkzugriffsträger zwischen dem SGSN 115 und dem UTRAN 113 und der Funkzugriffsträger zwischen dem UTRAN 113 und der UE 111 eingerichtet worden sind, ist die Zuordnung der Ressourcen abgeschlossen, die für die Übertragung der Paketdaten per Funk benötigt werden.
  • Wenn der Funkzugriffsträger zwischen dem UTRAN 113 und dem SGSN 115 eingerichtet wird, überträgt der SGSN 115 im Schritt 517 eine "Erzeuge PDP-Kontext-Anforderung"-Nachricht an den GGSN 119. Zur selben Zeit überträgt der SGSN 115 eine primäre NSAPI, um anzuzeigen, dass die GTP-Tunnel, die erzeugt werden sollen, sekundäre GTP-Tunnel sind. Ein Wert der primären NSAPI hat eine Eins-zu-Eins-Entsprechung mit der zuvor aktivierten primären PDP-Kontext-Information. Demnach kann die primäre PDP-Kontext-Information verwendet werden, indem auf den primären NSAPI-Wert verwiesen wird. Darüber hinaus sendet der SGSN 115 die "Erzeuge PDP-Kontext-Anforderung"-Nachricht, die eine TFT enthält. Der Zweck der TFT ist es, die primären und sekundären GTP-Tunnel anzuzeigen. In anderen Worten wird die TFT nicht in dem primären GTP-Tunnel gespeichert und die TFT wird lediglich in den sekundären GTP-Tunneln gespeichert. Wie beim Ablauf zur Erzeugung von primären GTP-Tunneln werden neue TEIDs zwischen dem SGSN 115 und dem GGSN 119 gesetzt, und die TEIDs werden derart gesetzt, dass Paketdaten zwischen den Netzwerkknoten über die GTP-Tunnel übertragen werden können. In anderen Worten merkt sich der SGSN 115 die TEID des GGSN 119 und der GGSN 119 merkt sich die TEID des SGSN 115. Demnach enthält die "Erzeuge PDP-Kontext-Anforderung"-Nachricht die TEID, die verwendet werden soll, wenn der GGSN 119 Paketdaten an den SGSN 115 sendet.
  • Wenn die PDP-Kontext-Erzeugung als Reaktion auf die "Erzeuge PDP-Kontext-Anforderung"-Nachricht angemessen abgeschlossen wurde, sendet der GGSN 119 im Schritt 519 eine "Erzeuge PDP-Kontext-Antwort"-Nachricht. Demnach ist die sekundäre GTP-Tunnelerzeugung zwischen dem SGSN 115 und dem GGSN 119 abgeschlossen und folglich können Paketdaten über sekundäre GTP-Tunnel übertragen werden. Als Antwort auf die "Erzeuge PDP-Kontext-Antwort"-Nachricht überträgt der SGSN 115 in Schritt 521 eine "Aktiviere PDP-Kontext-Annahme"-Nachricht an die UE 111. Wenn die UE 111 die "Aktiviere PDP-Kontext-Anwort"-Nachricht erhält, wird ein Funkkanal zwischen der UE 111 und dem UTRAN 113 aufgebaut, so dass der sekundäre GTP-Tunnel zwischen dem UTRAN 113, dem SGSN 115 und dem GGSN 119 vollständig aufgebaut ist. In anderen Worten kann die UE 111 alle Paketdatenelemente senden und empfangen, die an ihre eigene Adresse übertragen werden. Auf der anderen Seite hat ein sekundärer GTP-Tunnel, der nach dem oben beschriebenen PDP-Kontext-bezogenen Arbeitsablauf erzeugt wurde, eine Eins-zu-Eins-Entsprechung mit dem PDP-Kontext.
  • Ein TFT-Verarbeitungsbetrieb gemäß den TFT-Betriebscodes, die in Verbindung mit 3 beschrieben wurden, wird nun beschrieben. Zuerst wird ein neuer TFT-Erzeugungsarbeitsablauf nun mit Bezug auf 6 beschrieben.
  • 6 ist ein Blockdiagramm, das die Information veranschaulicht, die zur Erzeugung eines neuen TFT benötigt wird.
  • Wenn der TFT-Betriebscode auf "001" gesetzt wird, wie oben in Verbindung mit 3 beschrieben, wird eine neue TFT erzeugt. Andererseits ist ein Feld, das durch "0" bezeichnet wird, wie in 6 gezeigt ist frei, und dieses Feld ist nicht spezifiziert. Das unspezifizierte Feld wird auf "0" gesetzt. Das "Paketfilter-Listen"-Feld, gezeigt in 3, wird im Einzelnen mit Bezug auf 6 beschrieben. Mit Bezug auf 6 wird jedes "Paketfilter-Identifikator"-Feld, das in dem "Paketfilter-Listen"-Feld enthalten ist, zur Anzeige eines entsprechenden Paketfilters aus den Paketfiltern verwendet, die im TFT gesetzt sind. Da wie oben beschrieben die maximale Anzahl der Paketfilter, die in der TFT gesetzt werden können, z. B. acht ist, ist die maximale Anzahl der Paketfilter-IDs acht. In 6 werden die Paketfilter-IDs ausgedrückt durch die Bits 0–2 und die verbleibenden Bits 4–7 bleiben frei.
  • Als nächstes gibt jedes "Paketfilter-Bewertungs-Priorität"-Feld, das im "Paketfilter-Listen"-Feld enthalten ist, die Priorität eines Filters unter allen Filter an, die in der TFT gesetzt sind. In anderen Worten gibt das "Paketfilter-Bewertungs-Priorität"-Feld die Rangfolge der Paketfilter-Arbeitsschritte für Paketdaten an, die vom externen Netzwerk empfangen werden. Je geringer der Wert des "Paketfilter-Bewertungs-Priorität"-Feldes ist, desto höher ist die Rangfolge des Paketfilters für Paketdaten, die vom externen Netzwerk empfangen werden. Falls Paketdaten vom externen Netzwerk empfangen werden, wird ein Paketfilter mit dem niedrigsten Wert des "Paketfilter-Bewertungs-Priorität"-Feldes unter den TFT-Paketfiltern, die in der GGSN 119 gespeichert sind, als erster auf die Paketdaten angewendet. Wo der Paketfilter, der den niedrigsten Wert des "Paketfilter-Bewertungs-Priorität"-Feldes hat, nicht mit der Dateikopfinformation der empfangenen Paketdaten übereinstimmt, wird ein Paketfilter, der den zweitniedrigsten Wert aus dem "Paketfilter-Bewertungs-Priorität"-Feld hat, auf die empfangenen Paketdaten angewendet. Jedes "Länge des Paketfilter-Inhalt"-Feld, das im "Paketfilter-Listen"-Feld enthalten ist, gibt die Länge des entsprechenden Paketfilterinhaltes an.
  • Schließlich beinhaltet jedes "Paketfilter-Inhalt"-Feld, das im "Paketfilter-Liste"-Feld enthalten ist, eine Paketfilter-Komponentenart-ID und die Länge des Paketfilterinhaltes ist veränderlich. Die Länge des "Paketfilter-Inhalt"-Feldes ist veränderlich, weil die Längen der Paketfilter verschieden voneinander sind und weil die Anzahl der Paketfilter, die innerhalb eines TFT gesetzt wird, veränderlich ist. Nachdem die Paketfilter-Komponentenart-ID einmal verwendet wurde, kann sie nicht mehr für irgendein anderes Paketfilter verwendet werden. Die Paketfilter können innerhalb eines TFT nicht auf der Basis von beiden, einer IP-Version 4 (IPv4)-Quellenadressenart und einer IP-Version 6 (IPv6)-Quellenadressenart kon figuriert werden. Ein einzelner Zielporttyp und ein einzelner Zielportbereich können nicht gemeinsam für die Paketfilter verwendet werden. Die Paketfilter-Komponentenarten und die Paketfilter-Komponentenarten-IDs, wie sie oben beschrieben sind, werden in der folgenden Tabelle 2 gezeigt. Tabelle 2
    Bits (76543210) Beschreibung
    00010000 IPv4 Quellen Adress Art
    00100000 IPv6 Quellen Adress Art
    00110000 Protokoll Identifikator/Nächster Dateikopf
    Typ
    01000000 Einzel Zielport Art
    01000001 Zielport Bereichs Art
    01010000 Einzel Quellenport Art
    01010001 Quellenport Bereichs Art
    01100000 Sicherheits-Parameter Index Art
    01110000 Verkehrsart/Verkehrskategorie
    10000000 Flusskennzeichen Art (flow label Type)
    Alle anderen Werte Reserviert
  • Wie in Tabelle 2 gezeigt, besteht ein Paketfilter aus einer Vielzahl von Paketfilter-Komponenten. Jedoch verwendet das gegenwärtige UMTS nicht alle Paketfilterarten. Zum Beispiel wird ein Sendesteuerungsprotokoll/Benutzerdatagrammprotokoll (TCP/UDP)-Portbereich als Paketfilter-Komponente verwendet, aber nicht jeder TCP/UDP-Port wird als Paketfilter-Komponente verwendet. Die Vielzahl der Paketfilter-Komponenten kann den Paketfilter konfigurieren. Zum Beispiel können Endgeräteeinrichtungen (TE) IPv6 Paketdaten klassifizieren, die einen TCP-Portbereich zwischen 4500 und 5000 bei einer Adresse von "::172.168.8.0/96" haben, und können einen Paketfilter aufbauen, so dass der Paketfilter-Bezeichner = 1 ist; IPv6-Quellenadresse = {::172.168.8.08[FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:0:0]}; TCP-Protokollnummer = 6; und der Zielportbereich = 4500 bis 5000. Ein Arbeitsschritt zur Klassifizierung von Paketdaten, der eine Vielzahl von Parameter verwendet, wird als Multifeld-Klassifizierung bezeichnet. Die Paketfilter-Komponentenarten werden nun beschrieben.
  • Zunächst wird das "IPv4-Quellenadressenart"-Feld, das in Tabelle 2 gezeigt ist, beschrieben.
  • Die "IPv4-Quellenadressenart" enthält ein Vier-Oktett-IPv4-Adressen-Feld und ein 4-Oktett-IPv4-Adressenmasken-Feld. Das IPv4-Adressen-Feld wird zuerst vor dem IPv4-Adressenmasken-Feld übertragen. Hier wird eine IPv4-Adresse durch 32 Bits ausgedrückt. Zum Beispiel wird die IPv4-Adresse als "10.2.10.3" ausgedrückt.
  • Es kann einen Fall geben, bei dem das IPv4-Adressen-Feld nicht in der TFT gesetzt werden kann, die durch eine sekundäre PDP-Kontext-Anforderungs-Nachricht übertragen wird, welche benutzt wird, um auf ein Dienstenetzwerk mit einem Zugriffspunktnamen (APN) usw. zuzugreifen. In anderen Worten, wenn der sekundäre PDP-Kontext zuerst aktiviert wird, erhält die UE 111 eine IP-Adresse über einen Domänennamendienst-(DNS)-Server (Domain Name Service Server) in Verbindung mit einem ausgänglich zugegriffenen Dienstenetzwerk. Weil die sekundäre PDP-Kontext-Aktivierungs-Nachricht, die übertragen werden soll, sich schon im Wartestadium befindet, kann der Paketfilterinhalt der TFT nicht verändert werden. Da die UE 111 eine IP-Adresse eines zugeordneten Dienstes erkennt, die es von einem DNS-Server beim nächsten Zugriff erhält, der auf den ursprünglichen Zugriff erfolgt, kann der TFT-Paketfilter-Inhalt das "IPv4-Quellenadressenart"-Feld benutzen. Darüber hinaus, wenn die UE 111 nicht ursprünglich auf eines neues Dienstenetzwerk zugreift, sondern eine sekundäre PDP-Kontext-Aktivierungs-Anforderungs-Nachricht sendet, um mit einer anderen UE zu kommunizieren, kann der Paketfilter-Inhalt basierend auf dem "IPv4-Quellenadressenart"-Feld in der TFT benutzt werden.
  • Als zweites wird das "IPv6-Quellenadressenart"-Feld, das in Tabelle 2 gezeigt ist, beschrieben. Das "IPv6-Quellenadressenart"-Feld beinhalt ein Sechzehn-Oktett-IPv6-Adressen-Feld und ein Sechzehn-Oktett-IPv6-Adressen-Maskenfeld. Das IPv6-Adressen-Feld wird zuerst übertragen vor dem IPv6-Adressen-Maskenfeld. Eine IPv6-Adresse wird durch 128 Bits ausgedrückt. Wenn die IPv6-Adresse verwendet wird, kann ein System, das auf der IPv6-Adresse basiert, die Anzahl von Teilnehmern aufnehmen, die 296 Mal der Anzahl der Teilnehmer entspricht, die von einem System aufgenommen werden können, das auf der oben beschriebenen IPv4-Adresse basiert. Weil das IPv6-Adressen-basierende System weiter eine große Anzahl von Teilnehmern aufnehmen kann im Vergleich zum IPv4-Adressen-basierten System, steigt die Benutzung von IPv6-Adressen an.
  • Ein Aufbau einer IPv6-Adresse wird nun mit Bezug auf 7 beschrieben.
  • 7 zeigt ein Blockdiagramm, welches eine herkömmliche IPv6-Adresse veranschaulicht.
  • Mit Bezug auf 7 wird die IPv6-Adresse durch 128 Bits ausgedrückt und eine Knotenadresse wird durch 128 Bits ausgedrückt.
  • Der ernsthafteste Nachteil in Verbindung mit der IPv6-Adresse ist derjenige, dass die Länge der IPv6-Adresse sehr lang ist. Beispielsweise kann die IPv4-Adresse durch "10.2.10.3" ausgedrückt werden, während die IPv6-Adresse durch "ABSC:1234:EF12:5678:2456:9ABC" ausgedrückt wird. Weil die IPv6-Adresse sehr lang ist, ist es für Teilnehmer schwierig, sich ihre IPv6-Adresse zu merken. Darüber hinaus besteht ein weiteres Problem darin, dass eine große Systembelastung und hohe Kosten auftreten, weil in Verbindung mit der IPv6-Adresse ein Berechnungsvorgang für 128 Bits durchgeführt wird.
  • Das "Protokollidentifikator/Nächster Dateikopf-Art"-Feld, das in Tabelle 2 gezeigt wird, wird nun beschrieben. Das "Protokollidentifikator/Nächster Dateikopf-Art"-Feld enthält einen Ein-Oktett-Protokollidentifikator, d. h. gibt "IPv4" an, oder eine nächste Dateikopf-Art, d. h. gibt "IPv6" an. Das "Einzel-Zielport-Art"-Feld, das in Tabelle 2 gezeigt ist, enthält eine Zwei-Oktett-Zielport-Nummer. Ein Wert des "Einzel-Zielport-Art"-Feldes kann ein UDP oder TCP-Portwert gemäß einem Protokollfeldwert des IP-Dateikopfes sein. Das "Zielport-Bereichs-Art"-Feld, das in Tabelle 2 gezeigt ist, enthält ein Zwei-Oktett-Zielport-Bereich-Unterer-Grenzwert-Feld und ein Zwei-Oktett-Zielport-Bereich-Oberer-Grenzwert-Feld. Ein Wert, der durch das "Zielport-Bereichs-Art"-Feld angegeben wird, kann ein UDP- oder TCP-Portbereich gemäß einem Protokollfeldwert eines IP-Dateikopfes sein.
  • Das "Einzel-Quellenport-Art"-Feld, das in Tabelle 2 gezeigt ist, enthält eine Zwei-Oktett-Quellenport-Nummer. Die Quellenport-Nummer kann ein UDP- oder TCP-Portwert gemäß einem Protokollfeldwert eines IP-Dateikopfes sein. Das "Quellenport-Bereichsart"-Feld, das in Tabelle 2 gezeigt ist, enthält ein Zwei-Oktett-Quellenport-Bereich-Unterer-Grenzwert-Feld und ein Zwei-Oktett-Quellenport-Bereich-Oberer-Grenzwert-Feld. Ein Wert, der durch das Quellenport-Bereichsart-Feld angegeben wird, kann ein UDP- oder TCP-Portbereich gemäß einem Protokollfeldwert des IP-Dateikopfes sein. Das "Sicherheitsparameter-Indexart"-Feld, das in Tabelle 2 gezeigt ist, enthält einen Vier-Oktett-IPSEC-Sicherheitsparameterindex (SPI). Das "Dienstklassenart/Verkehrsklassenart"-Feld, das in der obigen Tabelle 2 gezeigt ist, enthält ein Ein-Oktett-Dienstklassenart-(IPv4)/Verkehrsklasse-(IPv6)-Feld und ein Ein-Oktett-Dienstklassenmaske-(IPv4)/Verkehrsklassenmaske-(IPv6)-Feld. Schließlich enthält das "Flusskennzeichenart"-Feld ein Drei-Oktett-IPv6-Flusskennzeichen. Die Bits 7 bis 4 des ersten Oktetts sind frei und die verbleibenden 20 Bit enthalten ein IPv6-Flusskennzeichen.
  • Der neue TFT-Erzeugungsarbeitsablauf, der dem TFT-Betriebscode "001" entspricht, wurde mit Bezug auf 6 beschrieben. Als nächstes wird der Arbeitsablauf zur Löschung eines gespeicherten TFT, der dem TFT-Betriebscode "010" entspricht, ein Prozess zur Hinzufügung von Paketfiltern zu einem gespeicherten TFT, der einem TFT-Betriebscode "011" entspricht, und ein Arbeitsablauf zum Ersetzen von Paketfiltern in dem gespeicherten TFT, der dem TFT-Betriebscode "100" entspricht, mit Bezug auf 8 beschrieben.
  • 8 zeigt ein Blockdiagramm zur Veranschaulichung benötigter TFT-Informationen, um eine gespeicherte TFT zu löschen, Paketfilter zu einer gespeicherten TFT hinzuzufügen oder Paketfilter in einer gespeicherten TFT zu ersetzen.
  • Mit Bezug auf 8 wird, nachdem ein "TFT-Betriebscode"-Feld bestätigt wurde, unabhängig von einer Paketfilterliste, in der ein TFT gelöscht wird, die TFT mit der TFT-Art, deren Löschung aus den im GGSN 119 gespeicherten TFTs gewünscht wird, von der GGSN 119 gelöscht, wenn das "TFT-Betriebscode"-Feld "010" angibt, was den Wert zur Löschung einer gesetzten TFT angibt. Wo Paketfilter zu gespeicherten TFT hinzugefügt werden, benutzt der Paketfilter-Hinzufügungsablauf dieselben Informationen wie der TFT-Löschungsablauf. Im Paketfilter-Hinzufügungsablauf werden Inhalte einer entsprechenden Paketfilter-Liste zu einer gespeicherten TFT hinzugefügt. Wo Paketfilter in der gespeicherten TFT ersetzt werden benutzt der Paketfilter-Ersetzungsablauf die gleichen Informationen wie der TFT-Löschungsablauf und der TFT-Hinzufügungsablauf. Nachdem die Paketfilter aus einer gespeicherten TFT gelöscht wurden, werden Inhalte einer entsprechenden Paketfilter-Liste eingefügt. Der Arbeitsablauf zur Löschung einer gespeicherten TFT gemäß einem TFT-Betriebscode "010", der Ablauf zur Hinzufügung von Paketfiltern zum gespeicherten TFT gemäß dem TFT-Betriebscode "011", und der Ablauf zur Ersetzung von Paketfiltern in dem gespeicherten TFT gemäß dem TFT-Betriebscode "100" wurden mit Bezug auf 8 beschrieben. Als nächstes wird der Ablauf zur Löschung von Paketfiltern aus der gespeicherten TFT gemäß dem TFT-Betriebscode "101" mit Bezug auf 9 beschrieben.
  • 9 ist ein Blockdiagramm zur Veranschaulichung der benötigten TFT-Informationen zur Löschung von Paketfiltern aus der gespeicherten TFT.
  • Wie in 9 gezeigt, werden unbeachtlich einer Paketfilter-Liste lediglich Paketfilter-IDs in Betracht gezogen, wenn Paketfilter aus der gespeicherten TFT gelöscht werden. Der GGSN 119 löscht Paketfilter aus den Paketfiltern die gespeichert sind gemäß den Paketfilter-IDs, die in den TFT-Informationen enthalten sind, die von der UE 111 erhalten werden. 9 zeigt einen Fall, bei dem eine Anzahl N Paketfilter bestehend aus einem ersten Paketfilter bis zu einem N-ten Paketfilter aus einer TFT gelöscht werden.
  • Als nächstes wird ein Paketfilter-Arbeitsablauf mit Bezug auf 10 beschrieben.
  • 10 zeigt ein Blockdiagramm, das den TFT-Paketfilter-Ablauf eines gewöhnlichen UMTS-Kernnetzwerkes zeigt.
  • Zur Einfachheit der Darstellung nehmen wir an, dass jede TFT lediglich einen einzigen Paketfilter aufweist, wenn der Paketfilterbetrieb in Verbindung mit 10 beschrieben wird. Der GGSN 119 des UMTS-Kernnetzwerkes 200 speichert eine Gesamtheit von vier TFTs und jeder der TFTs enthält einen Paketfilter. Die Tatsache, dass vier TFTs gespeichert sind, bedeutet, dass der GGSN 119 gemeinsam mit dem SGSN 115 an fünf GTP-Tunnel angeschlossen ist, darunter einen primären GTP-Tunnel für einen primären PDP-Kontext und vier sekundäre GTP-Tunnel für sekundäre PDP-Kontexte und die fünf GTP-Tunnel teilen denselben PDP-Kontext. Die fünf GTP-Tunnel sind durch die TFTs bezeichnet.
  • Wenn der Paketfilterbetrieb basierend auf den vier TFTs für Paketdaten, die vom externen Netzwerk erhalten werden, d. h. das Internet 121, nicht erfolgreich ist, werden die Paketdaten, die vom Internet 121 eingehen, lediglich durch den primären GTP-Tunnel für den primären PDP-Kontext an den SGSN 115 gesendet. Zum Beispiel angenommen, dass (Servicekategorie (TOS)) "0x30" ist, ein Protokoll TCP ist, eine Quellenadresse (SA) "1.1.1.1" ist, eine Zieladresse (DA) "2.2.2.2" ist, eine Quellenport-(SP)-Nummer "200" ist, und eine Zielport-(DP)-Nummer "50" ist, in Bezug auf Paketdaten, die vom Internet 121 erhalten werden, stimmen die Paketdaten nicht mit den Paketfilterinhalt von TFT 1 und TFT 2 überein, so dass die Paketfilterung in Bezug auf TFT 1 und TFT 2 nicht durchgeführt wird. Weil jedoch die Paketdaten mit dem Paketfilterinhalt von TFT 3 übereinstimmen, wird die Paketfilterung für die Paketdaten in Bezug auf TFT 3 durchgeführt und ein Ergebnis der Paketfilterung wird an den SGSN 115 durch einen GTP-Tunnel entsprechend dem TFT 3 übertragen. Die vom Internet 121 erhaltenen Paketdaten können nicht in Verbindung mit TFT 1 und TFT 2 gefiltert werden, weil die SA in Verbindung mit dem Paketfilterinhalt von TFT 1 "3.3.3.3" ist und nicht mit der SA von "1.1.1.1" übereinstimmt, die in den empfangenen Paketdaten enthalten ist, und weil ein Protokoll in Verbindung mit dem TFT 2 ein Internet-Steuerungs-Nachrichtenprotokoll (ICMP) ist und es nicht mit TCP übereinstimmt, welches ein Protokoll der empfangenen Paketdaten ist. Weiterhin werden die über das Internet 121 empfangenen Paketdaten in Verbindung mit TFT 3 gefiltert, weil die TOS korrespondierend mit dem TFT-Paketfilterinhalt "0x30" ist und übereinstimmt mit "0x3", welche die TOS ist, die in den empfangenen Paketdaten enthalten ist.
  • Wie oben beschrieben wird die TFT in Verbindung mit dem PDP-Kontext (oder GTP-Tunnel) in der sekundären PDP-Kontext-Aktivierungsprozedur erzeugt. Durch eine UE-veranlasste PDP-Kontext-Veränderungsprozedur kann die UE 111 den PDP-Kontext verbunden mit der TFT erzeugt in der PDP-Kontext-Aktivierungsprozedur hinzufügen/verändern/löschen. Wie oben beschrieben hat ein PDP-Kontext lediglich eine TFT. Hier, wo die UE 111 eine neue TFT erzeugt oder eine TFT modifiziert, welche in dem GGSN 119 gespeichert ist, muss die TFT wenigstens einen gültigen Paketfilter speichern. Wenn der gültige Paketfilter nicht in der gespeicherten TFT existiert, schlägt die UE 111 bei der Durchführung der UE-ausgelösten PDP-Kontext-Veränderungsprozedur fehl. Der GGSN 119 sendet an die UE 111 einen Fehlercode, der das Fehlschlagen der UE-veranlassten PDP-Kontext-Veränderungsprozedur für den TFT anzeigt. Gleichzeitig wird die TFT gelöscht, wenn ein PDP-Kontext mit Bezug auf die TFT deaktiviert wird.
  • Als nächstes werden IP-Adressen im Einzelnen im Folgenden beschrieben.
  • Die IP-Adressen sind gemäß Adressenversionen in IPv4-Adressen und IPv6-Adressen eingeteilt. Ein Netzwerk, das die IPv4-Adressen verwendet, wird als "IPv4-Netzwerk" bezeichnet, und ein Netzwerk, das IPv6-Adressen verwendet, wird als "IPv6-Netzwerk" bezeichnet. Das UMTS benutzt eine IPv6-eingebettete IPv6-Adresse, so dass IP-Kommunikation zwischen dem IPv4-Netzwerk und dem IPv6-Netzwerk stattfinden kann. Hier enthält die IPv4-eingebettete IPv6-Adresse eine IPv4-kompatible IPv6-Adresse und eine IPv4-abgebildetete IPv6-Adresse. Die IPv4-kompatible IPv6-Adresse und die IPv4-abgebildete IPv6-Adresse werden nun beschrieben.
  • (1) IPv4-kompatible IPv6-Adresse
  • Eine IPv4-kompatible IPv6-Adresse wird wahlweise benutzt, wenn ein gegenüberliegendes Netzwerk IPv6-Adressen unterstützen kann, eine gegenüberliegende oder Ziel-IPv4-Adresse erkannt werden kann, und Kommunikation über das IPv6-Netzwerk stattfindet. Ein Format der IPv4-kompatiblen IPv6-Adresse wird mit Bezug auf 11 beschrieben.
  • 11 zeigt ein Blockdiagramm, das ein Format einer herkömmlichen IPv4-kompatiblen IPv6-Adresse veranschaulicht.
  • Mit Bezug auf 11 wird die IPv4-kompatible IPv6-Adresse durch 128 Bits ausgedrückt, weil die IPv4-kompatible IPv6-Adresse im Grunde eine IPv6- Adresse ist. Eine IPv4-Adresse wird in die 32 Bits niedriger Ordnung der IPv4-kompatiblen IPv6-Adresse eingefügt. In anderen Worten wird eine Ziel-IPv4-Adresse in die 32 Bits niedriger Ordnung der IPv4-kompatiblen IPv6-Adresse eingefügt und Nullen werden in die verbleibenden 96 Bits der IPv4-kompatiblen IPv6-Adresse eingefügt.
  • Die Architektur eines Netzwerkes, in welchem die IPv4-kompatiblen IPv6-Adressen wird mit Bezug auf 12 beschrieben.
  • 12 zeigt ein Blockdiagramm, welches die Architektur eines Netzwerkes, in welchem IPv4-kompatible IPv6-Adressen verwendet werden, veranschaulicht.
  • Mit Bezug auf 12 verwenden Netzwerke 1211 und 1213 beide IPv4-Adressen und IPv6-Adressen. Wo eine Zieladresse von Paketdaten, die übertragen werden sollen, die IPv4-Adresse ist, fügt das Netzwerk 1211 die IPv4-Adresse in die 32 Bits niedriger Ordnung der IPv4-kompatiblen IPv6-Adresse ein, wie in 11 gezeigt, und überträgt die IPv4-kompatible IPv6-Adresse an das Netzwerk 1213. Wenn dem so ist, erhält das Netzwerk 1213 die Paketdaten von der IPv4-kompatiblen IPv6-Adresse vom Netzwerk 1211 und das Netzwerk 1213 erkennt die IPv4-Adresse, die in den 32 Bits niedriger Ordnung der IPv4-kompatiblen IPv6-Adresse enthalten ist. Hier muss die IPv4-Adresse eindeutig sein und eine eindeutige IPv4-Adresse muss sichergestellt sein. Die IPv4-kompatible IPv6-Adresse wird wie im Folgenden ausgedrückt.
    0:0:0:0:0:0:165.213.138.35 .::165.213.138.35
  • Die IPv4-kompatbile IPv6-Adresse hält die IPv4-Adresse eingefügt in die 32 Bits niedriger Ordnung der IPv4-kompatiblen IPv6-Adresse. In ähnlicher Weise hat die IPv4-kompatible IPv6-Adresse einen eindeutige Adresse.
  • (2) IPv4-abgebildete IPv6-Adresse
  • Eine IPv4-abgebildete IPv6-Adresse wird wahlweise benutzt, wo ein gegenüberliegendes Netzwerk IPv6-Adressen nicht unterstützt, aber Kommunikation unter Benutzung der IPv6-Adresse stattfindet. Ein Format der IPv4-abgebildeten IPv6-Adresse wird mit Bezug auf 13 beschrieben.
  • 13 zeigt ein Blockdiagramm, welches das Format einer herkömmlichen IPv4-abgebildeten IPv6-Adresse veranschaulicht.
  • Mit Bezug auf 13 wird die IPv4-abgebildete IPv6-Adresse ausgedrückt zu 128 Bits, weil die IPv4-kompatible IPv6-Adresse im Grunde eine IPv6-Adresse ist. Eine IPv4-Adresse wird eingefügt in die 32 Bits niedriger Ordnung der IPv4-abgebildeten IPv6-Adresse. In andern Worten wird die Ziel-IPv4-Adresse in die 32 Bits niedriger Ordnung der IPv4-abgebildeten IPv6-Adresse eingefügt, Einsen werden eingefügt in die 16 Bits höherer Ordnung der IPv4-abgebildeten IPv6-Adresse nach den eingefügten 32 Bits niedriger Ordnung der IPv4-Adresse und Nullen werden eingefügt in die verbleibenden 80 Bits der IPv4-abgebildeten IPv6-Adresse.
  • Die Architektur eines Netzwerks, in dem die IPv4-abgebildete IPv6-Adresse benutzt wird, wird mit Bezug auf 14 beschrieben.
  • 14 ist ein Blockdiagramm, welches die Architektur eines Netzwerks, in welchem die IPv4-abgebildete IPv6-Adresse verwendet wird, veranschaulicht.
  • Mit Bezug auf 14 benutzt ein Netzwerk 1411 beides, eine IPv4-Adresse und eine IPv6-Adresse, und ein Netzwerk 1413 benutzt lediglich IPv4-Adressen. Wo eine Zieladresse von Paketdaten, die durch das Netzwerk 1411 übertragen werden sollen, eine IPv4-Adresse ist, fügt das Netzwerk 1411 eine IPv4-Adresse in die 32 Bits niedriger Ordnung der IPv4-abgebildeten IPv6-Adresse ein, wie in der IPv4-kompatiblen IPv6-Adresse, die in 13 gezeigt ist, und überträgt die IPv4- abgebildete IPv6-Adresse an das Netzwerk 1413. Wenn dem so ist, erhält das Netzwerk 1413 die Paketdaten der IPv4-abgebildeten IPv6-Adresse vom Netzwerk 1411 und das Netzwerk 1413 detektiert die IPv4-Adresse, die in den 32 Bits niedriger Ordnung der IPv4-abgebildeten IPv6-Adresse enthalten ist. Hier wird die IPv4-abgebildete IPv6-Adresse ausgedrückt wie im Folgenden:
    0:0:0:0:0:0:FFFF:165.213.138.35 .::FFFF:165.213.138.35
  • Die IPv4-abgebildete IPv6-Adresse hält die IPv4-Adresse eingefügt in die 32 Bits niedriger Ordnung der IPv4-abgebildeten IPv6-Adresse. Die IPv4-abgebildete IPv6-Adresse ist verschieden von der IPv4-kompatiblen IPv6-Adresse indem "0xFFFF" in die 16 Bits höherer Ordnung der IPv4-abgebildeten IPv6-Adresse eingefügt wird in Abfolge auf die 32 Bits niedriger Ordnung der IPv4-Adresse.
  • In Verbindung mit den oben beschriebenen TFT-Paketfilter-Arten verkörpert eine IPv4-Quellenadresse eine 32 Bit Adresse unter Verwendung der IPv4-Adresse. Da die Anzahl der Teilnehmer der gegenwärtigen mobilen Kommunikationssystemen mit geometrischer Progression ansteigt, werden IPv6-Adressen breit angewendet werden, damit die IP-Adressen entsprechend zugeordnet werden können. Aus diesem Grund wurden TFT-Paketfilter-Komponentenarten vorgeschlagen zur Filterung der Paketdaten, die mit den IPv6-Adressen korrespondieren. Da jedoch IPv6-Adressen durch 128 Bits ausgedrückt werden, bewirkt dies eine beträchtliche Last in Bezug auf die Bitberechnungen im Vergleich mit den IPv4-Adressen, die durch 32 Bits ausgedrückt werden.
  • Paketdaten, die von einem externen Netzwerk in den GGSN 119 eingegeben werden, überstehen die Paketfilterungs-Bearbeitungsschritte durch die TFTs, die in dem GGSN 119 gespeichert sind, und die Paketfilterungen durch die TFT werden nacheinander von der niedrigsten Paketfilter-Bewertungspriorität bis zur höchsten Paketfilter-Bewertungspriorität in Bezug auf ein oder mehr Paketfilter, die in der TFT gespeichert sind, ausgeführt. Wo beispielsweise fünf TFTs in dem GGSN 119 gespeichert sind und eine der TFTs vier Paketfilter speichert, überstehen Paketdaten, die vom externen Netzwerk, d. h. dem Internet 121, empfangen werden, einen Paketfilterbetrieb verbunden mit vier Paketfiltern der ersten TFT der fünf TFTs. Dann überstehen die Paketdaten, weil die Paketfilterung nicht erfolgreich ist, eine Paketfilterung verbunden mit den vier Filtern der zweiten TFT der fünf TFTs. Wo die Anzahl der TFTs, die in dem GGSN 119 gespeichert sind, abrupt ansteigt oder die Menge von Paketdaten, die vom externen Netzwerk 121 empfangen wird, abrupt ansteigt, bis die Paketfilterung erfolgreich ist, vermindert die 128 Bit-Berechnung in Verbindung mit den IPv6-Adressen die Leistungsfähigkeit des TFT-Paketfilterns. Die herabgesetzte Paketfilterungsleistung kann das UMTS-Kernnetzwerk nachteilig beeinflussen.
  • Zusammenfassung der Erfindung
  • Daher wurde die vorliegende Erfindung gemacht und es ist eine Aufgabe der vorliegenden Erfindung eine Einrichtung und ein Verfahren zur Durchführung von Verkehrsflussschablonen (TFT) Paketfilterung gemäß den IP-Versionen von IP-Adressen in einem mobilen Kommunikationssystem zur Verfügung zu stellen.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, eine Einrichtung und ein Verfahren zur Verfügung zu stellen, die TFT-Paketfilterung durchführen, indem sie gemeinschaftlich benutzte Information in verschiedenen IP-Adressen basierend auf verschiedenen IP-Versionen in einem mobilen Kommunikationssystem verwenden.
  • Es ist noch eine weitere Aufgabe der vorliegenden Erfindung, eine Einrichtung und ein Verfahren bereitzustellen, die TFT-Paketfilterung durchführen, welche die benötigte Menge an Berechnungen zur Durchführung der Paketfilterung gemäß den IP-Versionen von IP-Adressen verbunden mit den Eingangs-Paketdaten in einem mobilen Kommunikationssystem minimieren.
  • Diese und andere Aufgaben der vorliegenden Erfindung werden gelöst durch ein Verfahren zur Durchführung von Verkehrsflussschablonen-Filterung (TFT) in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem und eine Einrichtung zur Durchführung von Verkehrsflussschablonen-(TFT)-Filterung in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem wie jeweils definiert in den unabhängigen Ansprüchen 1, 2, 8 und 10. Weitere bevorzugte Ausfürhungsformen sind in den abhängigen Ansprüche 3 bis 7, 9 und 11 bis 15 dargelegt.
  • Kurze Beschreibung der Zeichnungen
  • Die obigen Aufgaben, Merkmale und andere Vorteile der vorliegenden Erfindung werden viel klarer verstanden werden aus der folgenden detaillierten Beschreibung gegeben in Verbindung mit den begleitenden Zeichnungen, in welchen:
  • 1 ein Blockdiagramm zur Veranschaulichung der Architektur eines herkömmlichen universellen mobilen Telekommunikationssystems-(UMTS)-Netzwerks zeigt;
  • 2 ein Blockdiagramm zur Veranschaulichung eines UMTS-Kernnetzwerks basierend auf einer herkömmlichen Verkehrsflussschablone (TFT) zeigt;
  • 3 ein Blockdiagramm zeigt, welches das Format der herkömmlichen TFT veranschaulicht;
  • 4 ein Ablaufdiagramm zeigt, welches Nachrichten veranschaulicht, die in einem GPRS-(Allgemeiner Paketfunkdienst)-Tunnel-Protokoll-(GTP)-Tunnelerzeugungsprozess gemäß einer ersten Paketdatenprotokoll-(PDP)-Kontext-Aktivierung erzeugt werden;
  • 5 ein Ablaufdiagramm zur Veranschaulichung von Nachrichten zeigt, die in einem GTP-Tunnel-Erzeugungsprozess gemäß der sekundären PDP-Kontext-Aktivierung erzeugt werden;
  • 6 ein Blockdiagramm zur Veranschaulichung des Formats einer neuen TFT zeigt;
  • 7 ein Blockdiagramm zur Veranschaulichung des Formats einer herkömmlichen IPv6-Adresse zeigt;
  • 8 ein Blockdiagramm zur Veranschaulichung der benötigten TFT-Informationen zur Löschung einer gespeicherten TFT, Hinzufügung von Paketfiltern zur gespeicherten TFT oder Ersetzen von Paketfiltern in gespeicherten TFT, zeigt;
  • 9 ein Blockdiagramm zur Veranschaulichung von benötigten TFT-Informationen zur Löschung von Paketfiltern aus einer gespeicherten TFT zeigt;
  • 10 ein Blockdiagramm zur Veranschaulichung eines TFT-Paketfilterungsablaufs zeigt, der mit einem herkömmlichen UMTS-Kernnetzwerk durchgeführt wurde;
  • 11 ein Blockdiagramm zur Veranschaulichung des Formats einer herkömmlichen IPv4-kompatiblen IPv6-Adresse zeigt;
  • 12 ein Blockdiagramm zur Veranschaulichung der Architektur eines Netzwerks zeigt, in welchem die IPv4-kompatible IPv6-Adresse verwendet wird;
  • 13 ein Blockdiagramm zur Veranschaulichung des Formats einer herkömmlichen IPv4-abgebildeten IPv6-Adresse zeigt;
  • 14 ein Blockdiagramm zur Veranschaulichung der Architektur eines Netzwerks zeigt, in welchem die IPv4-abgebildete IPv6-Adresse verwendet wird;
  • 15 ein Blockdiagramm zur Veranschaulichung der Architektur eines UMTS-Netzwerkes zur Durchführung der Funktion in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 16 ein Blockdiagramm zur Veranschaulichung der internen Struktur einer TFT-Paketfilterungseinrichtung zur Durchführung einer Funktion in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 17 eine Ansicht zur Veranschaulichung von TFT-Informationen zeigt, die in einer TFT-Tabelle 1651 gezeigt in 16 gespeichert ist;
  • 18A und 18B Ablaufdiagramme zur Veranschaulichung von TFT-Paketfilterungs-Arbeitsschritten sind, wenn ein IPv6-Quellen-Adressenarten-Verfahren verwendet wird;
  • 19A und 19B Ablaufdiagramme zur Veranschaulichung eines TFT-Paketfilterungs-Ablaufes sind, wenn ein IPv4-abgebildetes IPv6-Quellen-Adressenarten-Verfahren verwendet wird;
  • 20 ein Blockdiagramm zur Veranschaulichung eines allgemeinen TFT-Paketfilterungs-Ablaufes durchgeführt durch ein TFT-Filterungsverfahren 1611 zeigt, welches in 16 gezeigt ist;
  • 21 ein Blockdiagramm zur Veranschaulichung eines TFT-Paket-Filterungs-Arbeitsablaufes zeigt, welcher das IPv4-Quellen-Adressenarten-Verfahren ausgeführt durch den TFT-Paketfilterungsprozess 1611 verwendet, der in 16 gezeigt ist;
  • 22 ein Blockdiagramm zur Veranschaulichung des TFT-Paketfilterungs-Ablaufes zeigt, der das IPv4-abgebildete IPv6-Quellen-Adressenarten-Verfahren, durchgeführt durch den TFT-Paketfilterungsprozess 1611, welcher in 16 gezeigt ist, verwendet;
  • 23 eine Tabelle zur Veranschaulichung einer Menge von Bit-Berechnungen gemäß einem TFT-Paketfilterungsablauf zeigt, wenn das IPv6-Quellen-Adressenarten-Verfahren und IPv4-eingebettete IPv6-Quellen-Adressenverfahren benutzt werden, im Vergleich zu der Menge von Bit-Berechnungen gemäß dem allgemeinen TFT-Paket-Filterungsablauf in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung; und
  • 24 ein Ablaufdiagramm zur Veranschaulichung eines TFT-Paketfilterungs-Erzeugungsprozesses zeigt, wenn das IPv4- abgebildete IPv6-Quellen-Adressenarten-Verfahren verwendet wird.
  • Detaillierte Beschreibung der bevorzugten Ausführungsformen
  • Ausführungsformen der vorliegenden Erfindung werden im Einzelnen mit Bezug auf die beigefügten Zeichnungen beschrieben. In der vorliegenden Beschreibung werden lediglich Funktionen und Aufbauten beschrieben, die zum Verständnis der vorliegenden Erfindung nötig sind. Darüber hinaus wird eine Beschreibung im Einzelnen von bekannten Funktionen und Aufbauten, die hierin enthalten sind, wegen der Übersichtlichkeit unterlassen.
  • 15 ist ein Blockdiagramm zur Veranschaulichung der Architektur eines universellen mobilen Telekommunikationssystems-(UMTS)-Netzwerkes zur Durchführung einer Funktion in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
  • Mit Bezug auf 15 enthält das UMTS-Netzwerk ein IPv6-Netzwerk 1500, das eine IPv6-Internet-Protokoll-(IP)-Version-6-(IPv6)-Adresse verwendet, ein IPv4-Netzwerk 1550, das eine IP-Version-4-(IPv4)-Adresse verwendet, und ein IPv6-Netzwerk 1570, das eine IPv6-Adresse verwendet Beispielsweise wird das IPv6-Netzwerk 1500, das im UMTS-Netzwerk enthalten ist, beschrieben.
  • Zunächst verarbeitet eine Benutzereinrichtung (UE) 1511, verbunden mit einem UMTS-erdgebundenen Funkzugriffsnetzwerk (UTRAN) 1513 einen Ruf, und unterstützt beides, einen Schaltungsdienst (CS) und einen Paketdienst (PS). Die UE 1511 ist eine Dual-Mode-basierende UE, die in der Lage ist, beide, die IPv4-Adressen und die IPv6-Adressen in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zu unterstützen. Die UE 1511 konfiguriert Verkehrsflussschablonen-(TFT)-Information, wie in der Beschreibung des Standes der Technik oben erwähnt ist. In Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung erzeugt die UE 1511 wenigstens einen TFT-Paketfilter unter Verwendung der gesamten oder eines Teils der IP-Adresse. Ein Ablauf zur Erzeugung des TFT-Paketfilters unter Verwendung der gesamten oder eines Teils der IP-Adresse wird im Folgenden im Einzelnen beschrieben.
  • Das UTRAN 1513 ist aus wenigstens einem Knoten B und wenigstens einer Funknetzwerksteuerung (RNC (nicht gezeigt)) aufgebaut. Der Knoten B ist mit der UE 1511 über eine Uu-Schnittstelle verbunden, und die RNC ist mit einem dienenden GPRS-Unterstützungsknoten (SGSN) 1515 über eine Iu-Schnittstelle verbunden. Ein allgemeiner Paket-Funkdienst (GPRS) ist ein Paket-Datendienst, der durch das UMTS-Netzwerk zur Verfügung gestellt wird. Das UTRAN 1513 führt einen Protokoll-Umwandlungs-Arbeitsschritt durch, um Funkdaten oder Steuerungsnachrichten zu übertragen, die durch das Kernnetzwerk (CN) unter Verwendung eines GPRS-Tunnel-Protokolls (GTP) erhalten werden. Hier wird auf das CN als Gesamtheit aus SGSN 1515 und GGSN 1519 Bezug genommen.
  • Der SGSN 1515 ist ein Netzwerkknoten zur Handhabung von Teilnehmerinformationen und Ortsinformationen der UE 1511. Der SGSN 1515 ist mit dem UTRAN 1513 über die Iu-Schnittstelle verbunden und ist mit dem GGSN 1519 über eine Gn-Schnittstelle derart verbunden, dass Daten und Steuernachrichten gesendet und empfangen werden. Der SGSN 1515 ist verbunden mit einem Home-Location-Register (HLR) 1517 über eine Gr-Schnittstelle zur Handhabung von Teilnehmerinformationen und Ortsinformationen.
  • Das HLR 1517 speichert Teilnehmerinformationen und Wegeinformationen in Verbindung mit einer Paketdomäne etc. Das HLR 1517 ist verbunden mit dem SGSN 1515 über eine Gr-Schnittstelle und ist verbunden mit dem GGSN 1519 über eine Gc-Schnittstelle. Natürlich kann das HLR 1517 in einem öffentlichen mobilen Netzwerk (PLMN) angeordnet sein, wenn Roaming der UE 1511 in Be tracht gezogen wird. Der GGSN 1519 entspricht einem Endpunkt verbunden mit dem GTP mit dem UMTS-Netzwerk, und dem GGSN 1519 verbunden mit einem externen Netzwerk über eine Gi-Schnittstelle und von ihm aus kann transparent auf das Internet, ein Paket-Domänennetzwerk (PDN) oder ein PLMN zugegriffen werden. Das IPv6-Netzwerk 1500 ist mit dem IPv4-Netzwerk 1550 über ein erstes Grenz-Gateway 1500 verbunden. Das erste Grenz-Gateway 1520, welches an einem Endpunkt des IPv6-Netzwerkes 1500 angeordnet ist, führt eine Nachrichtenfilterungsfunktion aus, eine Netzwerk-Adressen-Übersetzungsfunktion (NAT), usw.
  • In Übereinstimmung mit dieser Ausführungsform der vorliegenden Erfindung übertragt das erste Grenz-Gateway 1520 Paketdaten, die vom IPv6-Netzwerk 1500 erhalten werden, an das zweite Grenz-Gateway 1530. Hier haben die Paketdaten, die vom IPv6-Netzwerk 1500 empfangen werden, eine IPv6-Adresse, aber das IPv4-Netzwerk 1550 verbunden mit dem zweiten Grenz-Gateway 1530 unterstützt lediglich IPv4-Adressen. Daher extrahiert das erste Grenz-Gateway 1520 die 32 Bit IPv6-Adresse niedriger Ordnung aus den Paketdaten, die vom IPv6-Netzwerk 1500 erhalten werden, um einen IPv4-Dateikopf zu erzeugen. Das erste Grenz-Gateway 1520 fügt den erzeugten IPv4-Dateikopf zu den Daten hinzu, um die Paketdaten an das IPv4-Netzwerk 1550 zu übertragen. Wie oben bei der Beschreibung des Standes der Technik beschrieben, verwendet das UMTS eine IPv4-eingebettete IPv6-Adresse, damit IP-Kommunikation zwischen dem IPv4-Netzwerk und dem IPv6-Netzwerk stattfinden kann. Hier enthält die IPv4-eingebettete IPv6-Adresse eine IPv4-kompatible IPv6-Adresse und eine IPv4-abgebildete IPv6-Adresse. Das IPv4-Netzwerk 1550 entfernt den IPv4-Dateikopf aus den Paketdaten, die vom zweiten Grenz-Gateway 1530 empfangen werden und überträgt durch das dritte Grenz-Gateway 1540 Paketdaten, von denen der IPv4-Dateikopf entfernt wurde. Wenn dem so ist, transferiert das dritte Grenz- Gateway 1540 die Paketdaten durch das vierte Grenz-Gateway 1560. Daraufhin empfängt das IPv6-Netzwerk 1570 Paketdaten, die eine IPv6-Adresse haben. Wie oben beschrieben wurde das Verfahren zur externen Übertragung von Paketdaten vom IPv6-Netzwerk 1500 beschrieben. Wenn das IPv6-Netzwerk 1500 Paketdaten erhält, die von einem externen Netzwerk zugehen, werden die Paketdaten eingekapselt oder entkapselt gemäß den IP-Adressen-Versionen. In der Folge werden Paketdaten, die eine IPv4-Adresse haben, als "IPv4-Paketdaten" bezeichnet und die Paketdaten, die eine IPv6-Adresse haben, werden als "IPv6-Paketdaten" wegen der Zweckdienlichkeit der Erklärung bezeichnet.
  • Ferner führt das zweite Grenz-Gateway 1530 die Funktion eines Grenz-Vermittlungsknotens des IPv4-Netzwerks 1550 aus und führt ebenso eine generelle IPv4-Vermittlungsfunktion aus. Das dritte Grenz-Gateway 1540 führt die Funktion eines Grenz-Vermittlungsknotens für das IPv4-Netzwerk 1550 aus und führt ebenso die Funktion eines allgemeinen IPv4-Vermittlungsknotens aus. Das vierte Grenz-Gateway 1560 führt die Funktion eines Grenz-Vermittlungsknotens für das IPv6-Netzwerk 1570 aus und führt dieselbe Funktion wie das erste Grenz-Gateway 1520 aus. Ein IPv4/IPv6-Server 1580 ist ein Dual-Mode-Server, der in der Lage ist, beiden, den IPv4-Paketdaten und den IPv6-Paketdaten, Rechnung zu tragen. Der IPv4-/IPv6-Server 1580 benutzt eine IPv4-kompatible IPv6-Adresse oder eine IPv4-abgebildete IPv6-Adresse, um mit der UE 1511 des UMTS-Netzwerks über das UPv4-Netzwerk 1550 zu kommunizieren.
  • Der interne Aufbau der TFT-Paket-Filterungseinrichtung zur Durchführung einer Funktion in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung wird mit Bezug auf 16 beschrieben.
  • 16 ist ein Blockdiagramm zur Veranschaulichung des internen Aufbaus der TFT-Paket-Filterungseinrichtung zur Durchführung einer Funktion in Übereinstimmung mit der Ausführungsform der vorliegenden Erfindung.
  • Mit Bezug auf 16 enthält die TFT-Paket-Filterungseinrichtung eine zentrale Verarbeitungseinheit (CPU) 1600, einen wahlfreien Zugriffsspeicher (RAM) 1650 und ein Segmentierungs- und wieder Zusammenfügungs-(SAR)-Modul 1670 sowie einen Duplexer 1690. Die CPU 1600 verarbeitet Paketdaten, die vom externen Netzwerk durch die Gi-Schnittstelle des GGSN zugehen, d. h. das Internet, und führt eine gesamte Steuerungsfunktion, verbunden mit einem mathematischen Berechnungsbetrieb, einem Ablaufbetrieb, einer Aufgabenhandhabungsfunktion usw. durch. In Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung handhabt die CPU 1600 eine Paketdienst-Scheibenblock-(PSSB)-Aufgabe 1610. Ein gestrichelter Bereich, der in 16 gezeigt ist, stellt eine S-Interprozess-Kommunikationsaufgabe (SIPC) dar. Da die SIPC-Augabe nicht direkt mit der vorliegenden Erfindung in Verbindung steht, wird eine Beschreibung der SIPC-Aufgabe im Einzelnen unterlassen. Hier empfängt die PSSB-Aufgabe 1610 GTP- und Paketdaten, die durch einen GTP-Tunnel übertragen werden, oder empfängt IP-Paketdaten von einem externen Netzwerk, d. h. dem Internet, und führt verschiedene Protokollabläufe durch.
  • Die PSSB-Aufgabe 1610 enthält einen TFT-Paket-Filterungsablauf 1611 und einen Paket-Prozessor 1613. Der TFT-Paket-Filterungsablauf 1611 führt Paketfilterungen in Verbindung mit TFTs durch. Der Paket-Prozessor 1613 verarbeitet ein Paket gemäß einem Ergebnis der TFT-Paketfilterung durch den TFT-Paket-Filterungsablauf 1611. Der RAM 1615 enthält eine TFT-Tabelle 1651 und eine Ressourcen-Tabelle 1653. Die TFT-Tabelle 1651 speichert Informationen in Verbindung mit den TFTs, die im GGSN gespeichert sind. Der TFT-Paket-Filterungsablauf 1611 greift in Verbindung mit Paketdaten auf die TFT-Tabelle 1651 zu, die vom GGSN eintreffen, und führt die Paketfilterung durch. Hier verwenden die TFT-Paketfilter, die in der TFT-Tabelle 1651 gespeichert sind, IPv4-kompatible IPv6-Adressen und eine IPv4-abgebildete IPv6-Adresse und halten folglich eine 32 Bit IPv4-Adresse in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Hier wird die IPv4-kompatible IPv6-Adresse wahlweise benutzt, wenn ein gegenüberliegendes Netzwerk die IPv6-Adressen unterstützen kann, eine gegenüberliegende oder Bestimmungs-IPv4-Adresse erkannt werden kann, und Kommunikation durch das IPv6-Netzwerk durchgeführt wird. Die IPv4-abgebildete IPv6-Adresse wird wahlweise benutzt, wenn ein gegenüberliegendes Netzwerk eine IPv6-Adresse nicht unterstützt, jedoch Kommunikation unter Benutzung der IPv6-Adresse durchgeführt wird.
  • Das SAR-Modul 1670 fügt die asynchrone Transfermodus-(ATM)-Zellen wieder zusammen, die vom externen Netzwerk erhalten werden, und transferiert die wieder zusammengefügten ATM-Zellen zu einem IN-Pfad innerhalb der PSSB-Aufgabe 1610. Das SAR-Modul 1670 segmentiert Paketdaten, die von dem GGSN an das externe Netzwerk übertragen werden sollen, d. h. Paketdaten, die über den IN-, P- und S-Pfad oder die PSSB-Aufgabe 1610 übertragen werden sollen, in Einheiten von ATM-Zellen und gibt die segmentierten Paketdaten an den Duplexer 1690 aus. Der Duplexer 1690 empfängt wahlweise Paketdaten aus dem externen Netzwerk und überträgt Paketdaten vom GGSN an alle Funktionsblöcke, die physikalisch mit dem Duplexer 1690 verbunden sind.
  • Die TFT-Paket-Filterungseinrichtung, die in 16 gezeigt ist, muss eine sekundäre PDP-Kontext-Aktivierungsprozedur und eine TFT-Informations-Speicherungsprozedur berücksichtigen, damit TFT-Paketfilterung für die ankommenden Paketdaten durchgeführt werden kann. Die sekundäre PDP-Kontext-Aktivierungsprozedur und der TFT-Informations-Speicherungsprozess, der für die Paketfilterung berücksichtigt werden muss, wird beschrieben. Die Architektur des UMTS-Netzwerks und des CN (Core Network) sind fast identisch mit denen aus 1 und 2, die oben bei der Beschreibung des Standes der Technik bereits erwähnt sind. Lediglich die TFT-Paket-Filterungseinrichtung in Übereinstimmung mit der Ausführungsform der vorliegenden Erfindung beruht auf einer anderen Architektur. Es sei angenommen, dass die vorliegende Erfindung eine IPv4-kompatible IPv6-Adresse verwendet, und eine IPv4-abgebildete IPv6-Adresse, die eine IPv4-eingebettete IPv6-Adresse darstellt. Demnach führen die TFT-Paketfilter TFT-Paketfilter-Arbeitsabläufe unter Verwendung von lediglich der IPv4-Adresse, die in der IPv4-eingebetteten IPv6-Adresse enthalten ist, durch. Es sollte angemerkt werden, dass Arbeitsabläufe zur Aktivierung von Paketdaten-Protokoll-(PDP)-Kontexten, d. h. primäre PDP-Kontexte und sekundäre PDP-Kontexte dieselben sind wie in den Prozeduren, die in 4 und 5 gezeigt sind.
  • Um die TFT-Paketfilterung in Übereinstimmung mit der Ausführungsform der vorliegenden Erfindung durchzuführen, muss die sekundäre PDP-Kontext-Aktivierungsprozedur als erstes ausgeführt werden. Die sekundäre PDP-Kontext-Aktivierungsprozedur muss ausgeführt werden, weil TFTs eher in der sekundären PDP-Kontext-Aktivierungsprozedur erzeugt werden als in der primären PDP-Kontext-Aktivierungsprozedur. Mit Bezug auf 5 und 15 sendet die UE 1511 eine "Aktiviere sekundäre PDP-Kontext-Anforderung"-Nachricht an den SGSN 1515 und der SGSN 1515 sendet eine "Erzeuge PDP-Kontext-Anforderung"-Nachricht an den GGSN 1519, so dass die sekundäre PDP-Kontext-Aktivierungsprozedur ausgelöst wird. Wie in Verbindung mit 5 beschrieben, wird in der UE 1511 TFT-Information erzeugt und die "Aktiviere sekundäre PDP-Kontext-Anforderung"-Nachricht, welche die TFT-Information enthält, wird an den GGSN 1519 gesendet. Dann aktiviert der GGSN 1519 sekundäre PDP-Kontexte unter Verwendung der TFT-Informationen, die in der "Aktiviere sekundäre PDP-Kontext-Anforderung"-Nachricht enthalten ist und erzeugt sekundäre GTP-Tunnel, so dass Paketdaten verarbeitet werden können, die vom externen Netzwerk durch die sekundären GTP-Tunnel eintreffen.
  • Als nächstes muss die TFT-Informations-Speicherprozedur durchgeführt werden, damit die TFT-Paketfilterung in Übereinstimmung mit der vorliegenden Erfindung durchgeführt werden kann.
  • Wie oben beschrieben wird die TFT-Information, die von der UE 1511 gesendet wird, in der GGSN 1519 gespeichert. Zur gleichen Zeit werden notwendige Informationselemente der TFT-Information, sowie die Anzahl der Paketfilter, Paketfilterinhalte usw. gespeichert, so dass TFT-Paketfilterung für Paketdaten, die vom externen Netzwerk eintreffen, durchgeführt werden kann. In anderen Worten ist die TFT-Information enthalten in der "Aktiviere sekundäre PDP-Kontext-Anforderung"-Nachricht und wird an den SGSN 1515 übertragen. Weiterhin ist die TFT-Information enthalten in der "Erzeuge PDP-Kontext-Anforderung"-Nachricht und wird an den GGSN 1519 übertragen. Der GGSN 1519 extrahiert und speichert lediglich benötigte TFT-Information.
  • In der Ausführungsform der vorliegenden Erfindung werden zwei Informationsspeicherverfahren wie folgt vorgeschlagen.
  • (1) IPv6-Quellen-Adressenarten-Verfahren
  • Wie oben beschrieben wird die TFT-Information, die durch die UE 1511 erzeugt wurde, in dem GGSN 1519 gespeichert. Der GGSN 1519 extrahiert benötigte TFT-Information aus der Information, die von der UE 1511 übertragen wird und speichert die extrahierte Information als TFT-Information. In anderen Worten speichert der GGSN 1519 die TFT-Information, indem er die Anzahl der Paketfilter konfiguriert, die Paketfilterinhalte, usw., so dass die TFT-Paketfilterung einfach durchgeführt werden kann. Zu diesem Zeitpunkt, wo TFT-Paketfilter einer IPv6-Quellen-Adressenart entsprechen, und ein korrespondierender Filterkoeffizient einer IPv4-eingebetteten IPv6-Adresse entspricht, speichert der GGSN 1519 keinen 128 Bit-Adressenwert und 128 Bit-Maskenwert, der einer IPv4-eingebetteten IPv6-Adresse zugeordnet ist, wählt 32 niedrige Ordnungsbits, die eine IPv4-Adresse anzeigen, aus der IPv4-eingebetteten IPv6-Adresse aus, und speichert lediglich einen 32 Bit-Adressenwert und einen 32 Bit-Maskenwert als die TFT-Information. Die TFT-Paketfilter basieren auf einer IPv6-Quellen-Adressenart, aber Filterkoeffizienten, die in dem TFT-Paketfilter gespeichert werden, basieren auf einem IPv4-Adressenformat.
  • Der GGSN 1519 speichert die TFT-Informationen, indem er lediglich benötigte Informationen aus der TFT-Information verwendet, die in der "Aktiviere sekundä re PDP-Kontext-Anforderung"-Nachricht enthalten sind, welche von der UE 1511 gesendet wird. Die TFT-Information, die im GGSN 1519 gespeichert ist, d. h. die TFT-Information, die im RAM 1650 der TFT-Paket-Filterungseinrichtung gespeichert ist, wird im Folgenden mit Bezug auf 17 beschrieben.
  • 17 zeigt ein Blockdiagramm zur Veranschaulichung der TFT-Information, die in der Tabelle 1651 gezeigt in 16 gespeichert ist.
  • Mit Bezug auf 17 wird die TFT-Information eingeteilt in ein "Anzahl von Paketfilter"-Feld 1711, "Paketfilter-Bezeichner"-Feld 1713, 1723, 1733, 1743 und 1753, "Paketfilter-Bewertungspriorität"-Felder (nicht gezeigt), und "Paketfilter-Inhalt"-Felder 1715, 1725, 1735, 1745 und 1755. Das "Anzahl von Paketfilter"-Feld 1711 gibt die Anzahl von Paketfiltern an, die in einem entsprechenden TFT gespeichert sind. Die "Paketfilter-Bezeichner"-Felder 1713, 1723, 1733, 1743 und 1753 zeigen Paketfilter-IDs an zur Bezeichnung von Paketfiltern, die in der TFT gespeichert sind. Die "Paketfilter-Bezeichner"-Felder 1713, 1723, 1733, 1743 und 1753 haben eine 1:1-Entsprechung mit den "Paketfilter-Bewertungsprioritäts"-Feldern (nicht gezeigt) oder den "Paketfilter-Inhalt"-Feldern 1715, 1725, 1735, 1745 und 1755. Die oben beschriebenen Felder werden auf der Basis einer 1:1-Entsprechung gespeichert. Die gespeicherte TFT-Information, welche in 17 gezeigt wird, ist allgemeine TFT-Information, d. h. Information, die benötigt wird zur TFT-Paketfilterung, welche separat ausgewählt wird von der TFT-Information, die in 6 gezeigt ist. Weil die TFT-Paketfilterung in Verbindung mit der IPv4-eingebetteten IPv6-Adresse in Übereinstimmung mit der Ausführungsform der vorliegenden Erfindung durchgeführt wird, werden Quellen- und Zieladresseninhalte als wichtig erachtet.
  • Zum Beispiel erzeugt, wo die IPv4-eingebettete IPv6-Adresse "::3.2.2.1" lautet und die Protokollart UDP ist in dem ersten "Paketfilter-Inhalt"-Feld 1715, enthalten in der TFT-Information, die von der UE 1511 erhalten wird, die GGSN 1519 wenigstens einen Paketfilter, der die IPv6-Quellenadresse von "::3.2.2.1" und den UDP-Inhalt aufweist, unter Verwendung des IPv6-Quellen-Adressenarten-Verfahrens und speichert den erzeugten Paketfilter in der TFT-Tabelle 1651 des RAM 1650 enthalten in der TFT-Paket-Filterungseinrichtung.
  • Wenn die TFT-Information unter Verwendung des IPv6-Quellen-Adressenarten-Verfahrens, das zuvor beschrieben wurde gespeichert wird. Als nächstes wird der Fall beschrieben, bei dem die TFT-Information unter Verwendung eines IPv4-eingebundenen IPv6-Quellen-Adressenarten-Verfahrens gespeichert wird.
  • (2) IPv4-eingebundenes IPv6-Quellen-Adressenarten-Verfahren
  • Falls die IP-Adresse eine IPv4-eingebettete IPv6-Quellen-Adresse ist, wenn die UE 1511 TFT-Information erzeugt, setzt die UE 1511 dann eine TFT-Paketfilterart auf eine IPv4-eingebettete IPv6-Quellen-Adressenart und extrahiert lediglich eine 32-Bit-IPv6-Adresse niedriger Ordnung. Die UE 1511 konfiguriert wenigstens einen neuen TFT-Paketfilter unter Verwendung der 32-Bits niedriger Ordnung, extrahiert aus der IPv4-eingebetteten IPv6-Quellen-Adresse und überträgt den neuen Paketfilter an den GGSN 1519. Das IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren ist ein Verfahren, das es der UE 1511 ermöglicht, die 32 Bits niedriger Ordnung aus den IPv4-eingebetteten IPv6-Quellen-Adressen zu extrahieren, einen TFT-Paketfilter zu konfigurieren und den neuen TFT-Paketfilter zu senden. Damit das IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren unterstützt werden kann, muss ein Element der IPv4-eingebetteten IPv6-Quellen-Adressenart zu den Elementen der Paketfilter-Komponentenarten, die in der obigen Tabelle 2 gezeigt werden, hinzugefügt werden. Wir nehmen an, dass eine Paketfilter-Komponententypen-ID, die mit der IPv4-eingebetteten IPv6-Quellen-Adressenart korrespondiert, zu "00100001" gesetzt wird. Hier ist "00100001" ein Wert, der zuvor unter den Paketfilter-Komponentenarten-ID reserviert ist.
  • In der Folge, wo das IPv6-Quellen-Adressenarten-Verfahren verwendet wird, entspricht der TFT-Paketfilter einer IPv6-Quellen-Adressenart und die Länge des gespeicherten TFT-Paketfilters ist 32 Bit. Wo jedoch das IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren verwendet wird, entspricht der TFT-Paketfilter einer IPv4-eingebetteten IPv6-Adressenart und die Länge des gespeicherten TFT-Paketfilters ist 32 Bit.
  • Die TFT-Paketfilterung für den Fall, bei dem das IPv6-Quellen-Adressenarten-Verfahren verwendet wird, wird mit Bezug auf 18A und 18B beschrieben.
  • Mit Bezug auf 18A erhält der GGSN 1519 IP-Paketdaten durch die Gi-Schnittstelle im Schritt 1811, der GGSN 1519 schreitet zu Schritt 1813 vor. Im obigen Schritt 1813 bestätigt der GGSN 1519 die Zieladresse der empfangenen IP-Paketdaten und bestimmt, ob ein zweiter Aufruf getätigt wird zur Überprüfung der Übereinstimmung einer PDP-Adresse. Hier ist der Grund, warum ein zweiter Aufruf aufgesetzt wird, um zu bestimmen, ob ein sekundärer GTP-Tunnel existiert. In anderen Worten wird eine Bestimmung gemacht ob ein zweiter Aufruf vorliegt, weil TFT-Paketfilterung deaktiviert ist, wo ein zweiter GTP-Tunnel nicht vorliegt. Falls ein zweiter Aufruf nicht eingerichtet ist als ein Ergebnis der Bestimmung, schreitet der GGSN 1519 zu Schritt 1827 vor. Der GGSN 1519 wählt einen primären GTP-Tunnel im obigen Schritt 1827 aus und schreitet zu Schritt 1821 voran.
  • Falls ein sekundärer Aufruf eingerichtet ist als das Ergebnis der Bestimmung des obigen Schrittes 1813, schreitet der GGSN 1519 zu Schritt 1815 vor. Der GGSN 1519 wählt im obigen Schritt 1815 den sekundären GTP-Tunnel aus und wählt ein TFT-Paketfilter aus, welches die höchste Bewertungspriorität der ersten TFT-Information hat, und der GGSN 1519 schreitet zu Schritt 1851 voran. Der GGSN 1519 bestimmt im Schritt 1851 ob der TFT-Paketfilter, der die höchste Bewertungspriorität hat, einer IPv6-Quellen-Adressenart entspricht. Falls der TFT-Paketfilter, der die höchste Bewertungspriorität hat, nicht einer IPv6-Quellen- Adressenart entspricht, schreitet der GGSN 1519 nach Schritt 1867 voran. Der GGSN 1519 führt im Schritt 1867 einen allgemeine Paketfilterungsfunktion aus und der GGSN 1519 schreitet nach Schritt 1869 voran. Falls der TFT-Paketfilter, welcher die höchste Bewertungspriorität aufweist, einer IPv6-Quellen-Adressenart entspricht als Ergebnis der Bestimmung in Schritt 1851, schreitet der GGSN 1519 nach Schritt 1853 voran. Der GGSN 1519 bestimmt im Schritt 1853, ob eine IP-Version der IP-Paketdaten, die durch die Gi-Schnittstelle empfangen werden, und eine IP-Version einer Quellenadresse eine IPv6 sind. Falls die IP-Version der empfangenen IP-Paketdaten nicht die IPv6 sind, schreitet der GGSN 1519 zu Schritt 1855 voran. Im Schritt 1855 bestimmt der GGSN 1519, ob andere TFT-Paketfilter in der ersten TFT-Information vorhanden sind. Falls als Resultat der Überprüfung andere TFT-Paketfilter in der ersten TFT-Information vorhanden sind, schreitet der GGSN 1519 zu Schritt 1857 voran. Der GGSN 1519 wählt in Schritt 1857 einen TFT-Filter aus, der die höchste Bewertungspriorität unter den anderen Paketfiltern hat und kehrt zum obigen Schritt 1851 zurück. Falls andere TFT-Paketfilter als Ergebnis der Überprüfung in Schritt 1855 nicht existieren, schreitet der GGSN 1519 zu Schritt 1825 voran. Der GGSN 1519 bestimmt in Schritt 1825, ob die nächste TFT-Information vorliegt. Falls die nächste TFT-Information vorliegt als Ergebnis der Überprüfung, schreitet der GGSN 1519 zu Schritt 1823 voran. Der GGSN 1519 wählt in Schritt 1823 die nächste TFT-Information aus und kehrt dann zu Schritt 1815 zurück. Falls die nächste TFT-Information als Ergebnis der Überprüfung im obigen Schritt 1825 nicht existiert, schreitet der GGSN 1519 zu Schritt 1827 voran. Der GGSN 1519 wählt im obigen Schritt den primären GTP-Tunnel aus und schreitet zu Schritt 1821 voran.
  • Falls die IP-Version der empfangenen IP-Paketdaten IPv6 ist als Ergebnis der Überprüfung in Schritt 1853, schreitet der GGSN 1519 zu Schritt 1859 voran. Der GGSN 1519 bestimmt im Schritt 1859, ob die Länge des TFT-Paketfilters 32 Bits beträgt. Falls als Ergebnis der Überprüfung die Länge des TFT-Paketfilters nicht 32 Bits beträgt, schreitet der GGSN 1519 zu Schritt 1867 voran. Weil die Tatsache, dass die Länge des TFT-Paketfilters nicht 32 Bits beträgt, anzeigt, dass die Quellenadresse eine allgemeine 128 Bit IPv6-Adresse ist, schreitet der GGSN 1519 zu Schritt 1867 voran, um die allgemeine TFT-Paketfilterfunktion durchzuführen. Falls die Länge des TFT-Paketfilters als Ergebnis der Überprüfung in Schritt 1859 32 Bits beträgt, schreitet der GGSN 1519 zu Schritt 1861 voran. Der GGSN 1519 bestimmt im Schritt 1861, ob die Quellenadresse der empfangenen IP-Paketdaten eine IPv4-eingebettete IPv6-Adresse ist. Falls die Quellenadresse keine IPv4-eingebettete IPv6-Adresse ist als Ergebnis der Überprüfung, schreitet der GGSN 1519 zu Schritt 1867 voran. Die Tatsache, dass die Quellenadresse keine IPv4-eingebettete IPv6-Adresse darstellt, zeigt an, dass die Quellenadresse eine 32 Bit IPv4-Adresse darstellt. Der GGSN 1519 führt im obigen Schritt 1867 eine allgemeine TFT-Paketfilterungsfunktion durch.
  • Falls die Quellenadresse als Ergebnis der Überprüfung im obigen Schritt 1861 eine IPv4-eingebettete IPv6-Adresse darstellt, schreitet der GGSN 1519 zu Schritt 1863 voran. Der GGSN 1519 extrahiert 32 Bit Quellenadressen niedriger Ordnung und schreitet zu Schritt 1865 voran. Der GGSN 1519 führt im Schritt 1865 TFT-Paketfilterung durch unter Verwendung der extrahierten 32 Bits und schreitet dann nach Schritt 1869 voran. Die TFT-Paketfilterung, die im Schritt 1865 durchgeführt wird, benutzt das vorgeschlagene IPv4-Quellen-Adressenarten-Verfahren. Der GGSN 1519 bestimmt in Schritt 1869, ob die TFT-Paketfilterung erfolgreich ist. Falls die TFT-Paketfilterung nicht erfolgreich ist als Ergebnis der Überprüfung, schreitet der GGSN 1519 zu Schritt 1855 voran. Falls die TFT-Paketfilterung als Ergebnis der Überprüfung in Schritt 1869 erfolgreich ist, schreitet der GGSN 1519 zum obigen Schritt 1817 voran.
  • Der GGSN 1519 wählt im Schritt 1817 einen GTP-Tunnel aus, welcher der gegenwärtigen TFT-Information entspricht und schreitet dann zu Schritt 1821 voran. Der GGSN 1519 führt im Schritt 1821 eine Paketfilterfunktion durch, um die empfangenen IP-Paketdaten zu verarbeiten und beendet die Paketfilterfunktion.
  • Die TFT-Paketfilter unter Verwendung des IPv6-Quellen-Adressenarten-Verfahrens wurden mit Bezug auf 18A und 18B beschrieben. Als nächstes wird die TFT-Paketfilterung unter Verwendung des IPv4-eingebetteten IPv6-Quellen-Adressenarten-Verfahrens mit Bezug auf 19A und 19B beschrieben.
  • 19A und 19B zeigen Ablaufdiagramme, welche die Paketfilterung veranschaulichen, wenn das IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren verwendet wird.
  • Mit Bezug auf 19A, falls der GGSN 1519 IP-Paketdaten über die Gi-Schnittstelle im Schritt 1911 erhält, schreitet der GGSN 1519 zu Schritt 1913 voran. Im Schritt 1913 bestätigt der GGSN 1519 eine Zieladresse der empfangenen IP-Paketdaten und bestimmt, ob ein zweiter Aufruf gesetzt ist zur Überprüfung einer PDP-Adresse. Hier wird der sekundäre Aufruf eingerichtet, um zu bestimmen, ob der sekundäre GTP-Tunnel vorliegt. In anderen Worten wird die Bestimmung gemacht, ob ein sekundärer Aufruf vorliegt, weil die TFT-Paketfilterung deaktiviert ist, wo ein sekundärer GTP-Tunnel nicht existiert. Falls als Ergebnis der Überprüfung ein sekundärer Aufruf nicht gesetzt ist, schreitet der GGSN 1519 nach Schritt 1927 voran. Der GGSN 1519 wählt einen primären GTP-Tunnel in Schritt 1927 aus und schreitet zu Schritt 1921 voran. Falls der sekundäre Aufruf als Ergebnis der Überprüfung in Schritt 1913 eingerichtet ist, schreitet der GGSN 1519 zu Schritt 1915 voran. Der GGSN 1519 wählt den sekundären GTP-Tunnel aus und wählt in Schritt 1915 das TFT-Paketfilter aus, welches die höchste Bewertungspriorität aus den TFT-Informationen hat und der GGSN 1519 schreitet zu Schritt 1951 voran. Der GGSN 1519 bestimmt in Schritt 1951, ob der TFT-Paketfilter, welcher die höchste Bewertungspriorität aufweist, einer IPv4-eingebetteten IPv6-Adressenart entspricht. Falls der TFT-Paketfilter, welcher die höchste Bewertungspriorität aufweist, keiner IPv4-eingebetteten IPv6-Adressenart entspricht, schreitet der GGSN 1519 zu Schritt 1953 voran. Der GGSN 1519 führt eine allgemeine Paketfilterung im Schritt 1953 durch und der GGSN 1519 schreitet zum Schritt 1965 voran. Falls der TFT-Paketfilter, der die höchste Bewertungspriorität aufweist, als Ergebnis der Überprüfung in Schritt 1951 einer IPv4-eingebettete IPv6-Adressenart entspricht, schreitet der GGSN 1519 nach Schritt 1955 voran. Der GGSN 1519 bestimmt in Schritt 1955, ob die Quellenadresse der empfangenen IP-Paketdaten eine IPv4-eingebettete IPv6-Adresse ist. Falls die Quellenadresse der empfangenen IP-Paketdaten keine IPv4-eingebettete IPv6-Adresse ist als Ergebnis der Bestimmung, schreitet der GGSN 1519 nach Schritt 1957 voran. Der GGSN 1519 bestimmt in Schritt 1957, ob andere Paketfilter in der ersten TFT-Information vorliegen. Falls andere Paketfilter in der ersten TFT-Information vorliegen als Ergebnis der Überprüfung, schreitet der GGSN 1519 nach Schritt 1959 voran. Der GGSN 1519 wählt in Schritt 1959 ein TFT-Paketfilter aus, welches die höchste Bewertungspriorität unter den anderen Paketfiltern hat und kehrt zu Schritt 1951 zurück. Falls andere Paketfilter als Ergebnis der Überprüfung in Schritt 1957 nicht existieren, schreitet der GGSN 1519 nach Schritt 1925 voran. Der GGSN 1519 bestimmt in Schritt 1925, ob die nächste TFT-Information vorliegt. Falls die nächste TFT-Information vorliegt als Ergebnis der Überprüfung, schreitet der GGSN 1519 zu Schritt 1923 voran. Der GGSN 1519 wählt die nächste TFT-Information bei 1923 aus und kehrt dann zu Schritt 1915 zurück. Falls als Ergebnis der Überprüfung im Schritt 1925 die nächste TFT-Information nicht existiert, schreitet der GGSN 1519 zu Schritt 1927 voran. Der GGSN 1519 wählt in Schritt 1927 den primären GTP-Tunnel aus und schreitet zu Schritt 1921 voran.
  • Falls die Quellenadresse der empfangenen IP-Paketdaten eine IPv4-eingebettete IPv6-Adresse darstellt als Ergebnis der Überprüfung im Schritt 1955, schreitet der GGSN 1519 nach Schritt 1961 voran. Der GGSN 1519 extrahiert 32 Bit niedriger Ordnung von der IPv4-eingebetteten IPv6-Adresse und schreitet dann nach Schritt 1963 voran. Der GGSN 1519 führt im Schritt 1963 TFT-Paketfilterung durch unter Verwendung der extrahierten 32 Bits und schreitet dann nach Schritt 1965 voran. Der GGSN 1519 bestimmt in Schritt 1965, ob die TFT-Paketfilterung erfolgreich ist. Falls die TFT-Paketfilterung nicht erfolgreich ist als Ergebnis der Überprüfung, schreitet der GGSN 1519 nach Schritt 1957 voran. Falls die TFT- Paketfilterung erfolgreich ist als Ergebnis der Überprüfung in Schritt 1965, schreitet der GGSN 1519 nach Schritt 1917 voran. Der GGSN 1519 wählt in Schritt 1917 einen GTP-Tunnel aus, welcher der gegenwärtigen TFT-Information entspricht und schreitet dann nach Schritt 1921 voran. Der GGSN 1519 führt eine Paket-Filterungsprozedur zur Verarbeitung der empfangenen Paketdaten in Schritt 1921 aus und beendet die TFT-Paket-Filterungsfunktion.
  • Die allgemeine TFT-Paket-Filterungsfunktion wird mit Bezug auf 20 beschrieben.
  • 20 zeigt ein Blockdiagramm, das die allgemeine TFT-Paket-Filterungsfunktion darstellt, die durch das TFT-Paket-Filterungsverfahren 1611 gezeigt in 16 durchgeführt wird.
  • Mit Bezug auf 20, wenn IP-Paketdaten 2000 von einem externen Netzwerk durch die Gi-Schnittstelle des GGSN 1519 erhalten werden, d. h., wenn die IP-Paketdaten 2000 durch den Duplexer 1690 eingegeben werden, werden die eingegebenen IP-Paketdaten 2000 an das TFT-Paket-Filterungsverfahren 1611 durch das SAR-Modul 1670 weitergeleitet. Das TFT-Paket-Filterungsverfahren 1611 fuhrt die TFT-Paketfilterung unter Verwendung der TFT-Informationen durch, die in der Tabelle 1651 des RAM 16540 gespeichert sind. Falls die TFT-Tabelle 1651 zwei TFT-Informationseinheiten von TFT 1 und TFT 2 speichert, wie in 20 gezeigt, versucht die TFT-Paket-Filterprozedur 1611 zunächst, die Paketfilterung der IP-Paketdaten 2000 in Verbindung mit dem ersten Paketfilter 1 von TFT 1 durchzuführen. In den IP-Paketdaten 2000 ist eine Diensteart (TOS) auf "0x1F", ein Protokoll TCP (6), eine Quellenadresse "2.2.2.2", eine Zieladresse "3.3.3.3", eine Quellen-Portnummer 5000 und eine Zielportnummer 50.
  • Wenn die TFT-Paketfilterung, die den Paketfilter 1 des TFT 1 zugeordnet ist, für die IP-Paketdaten 2000 durchgeführt wird, wird die TFT-Paketfilterung nicht erfolgreich sein, weil die Quellenadresse des Paketfilters 1 von TFT 1 "1.1.1.1" ist.
  • Dann führt die TFT-Paket-Filterungsprozedur 1611 die Paketfilterung in Verbindung mit dem Paketfilter 2 der TFT 1 durch. Weil jedoch der Quellenportbereich, der dem Paketfilter 2 der TFT 1 zugeordnet ist, zwischen 100 und 1000 liegt, ist die Quellenportzahl 5000 von den IP-Paketdaten 2000 nicht im Quellenportbereich enthalten, so dass die TFT-Paketfilterung nicht erfolgreich ist. Daher wird ein TFT-Paketfilter gesucht, der auf die eingegebenen IP-Paketdaten 2000 abgebildet werden kann. Die Paketfilterung wird mit dem TFT-Paketfilter durchgeführt, der auf die IP-Paketdaten 2000 abgebildet werden kann, und die IP-Paketdaten 2000 werden an den SGSN 1515 durch einen zugeordneten Tunnel übertragen. In 20, da der Zielport der IP-Paketdaten im Zielportbereich des Paketfilters 5 von TFT 2 enthalten ist, benutzten die IP-Paketdaten 2000 den GTP-Tunnel, welcher der TFT 2 entspricht. Die TFT-Paket-Filterungsfunktion für die Paketdaten, die von einem externen Netzwerk eintreffen, ist dieselbe wie oben bei der Beschreibung des Standes der Technik in 10 erwähnt.
  • Die TFT-Paketfilterung unter Verwendung des IPv6-Quellenadressen-Verfahrens wird mit Bezug auf 21 beschrieben.
  • 21 zeigt ein Blockdiagramm, welches die Paketfilterungsfunktion unter Verwendung des IPv6-Quellenandressen-Verfahrens veranschaulicht, durchgeführt durch die TFT-Paketfilterprozedur 1611, gezeigt in 16.
  • Mit Bezug auf 21, wenn die IP-Paketdaten 2100 vom externen Netzwerk durch die Gi-Schnittstelle des GGSN 1519 empfangen werden, d. h. wenn IP-Paketdaten 2100 durch den Duplexer 1690 eingegeben werden, werden dann die eingegebenen IP-Paketdaten 2100 an die TFT-Paketfilterungsprozedur 1611 durch das SAR-Modul 1670 weitergeleitet. Die TFT-Paketfilterungsprozedur 1611 führt die TFT-Paketfilterung unter Verwendung der TFT-Informationen, die in der Tabelle 1651 des RAM 1650 gespeichert sind, aus. Falls die TFT-Tabelle 1651 zwei TFT-Informationselemente für TFT 1 und TFT 2 speichert, wie in 21 gezeigt, versucht die TFT-Paketfilterungsprozedur 1611 zunächst, die Paketfilte rung der IP-Paketdaten 2100 in Verbindung mit dem Paketfilter 1 des TFT 1 durchzuführen. In den IP-Paketdaten 2100 ist eine TOS "0x1F", ein Protokoll ist TCP (6), eine Quellenadresse ist "::10.3.8.112", eine Zieladresse ist "::10.2.3.54", eine Quellenportnummer ist 5000 und eine Zielportnummer ist 50. Hier sind die Quellenadresse und die Zieladresse IPv4-kompatible IPv6-Adressen und werden jeweils durch 32 Bit niedriger Ordnung ausgedrückt.
  • Wenn TFT-Paketfilterung in Verbindung mit dem Paketfilter 1 von TFT 1 für die IP-Paketdaten 2100 durchgeführt wird, dann wird die TFT-Paketfilterung erfolgreich sein, weil die Quellenadresse des Paketfilters 1 von TFT 1 "10.3.8.1.112" ist. Dann führt die TFT-Paketfilterungsprozedur 1611 die Paketfilterung durch, indem der Paketfilter verwendet wird, der an die IP-Paketdaten 2100 angepasst ist und leitet dann die Paketdaten 2100 an den SGSN 1515 durch den zugeordneten GTP-Tunnel weiter. Weil die Quellenadresse der Paketdaten 2100 mit der Quellenadresse in Verbindung mit dem Paketfilter 1 von TFT 1 übereinstimmt, benutzen die Paketdaten 2100 den GTP-Tunnel, welcher der TFT 1 entspricht.
  • Die TFT-Paketfilterung unter Verwendung des IPv4-eingebetteten IPv6-Quellen-Adressenarten-Verfahrens wird mit Bezug auf 22 beschrieben.
  • 22 ist ein Blockdiagramm, das die Paketfilterung unter Verwendung des IPv4-eingebetteten IPv6-Quellen-Adressenarten-Verfahrens veranschaulicht, durchgeführt durch die TFT-Paketfilterungsprozedur 1611 gezeigt in 16.
  • Mit Bezug auf 22, wenn Paketdaten 2200 vom externen Netzwerk durch die Gi-Schnittstelle von GGSN 1519 empfangen werden, d. h. wenn die IP-Paketdaten 2200 in den Duplexer 1690 eingegeben werden, werden die IP-Paketdaten 2200 an die TFT-Paketfilterungsprozedur 1611 durch das SAR-Modul 1670 weitergeleitet. Die TFT-Paketfilterungsprozedur 1611 führt die TFT-Paketfilterung unter Verwendung der TFT-Informationen durch, die in der Tabelle 1651 vom RAM 1650 gespeichert sind. Falls die TFT-Tabelle 1651 zwei TFT- Informationselemente von TFT 1 und TFT 2 speichert, wie in 22 gezeigt, versucht die TFT-Paketfilterprozedur 1611 zunächst, die Paketfilterung der IP-Paketdaten 2200 in Verbindung mit dem Paketfilter 1 des TFT 1 durchzuführen. In den IP-Paketdaten 2200 ist eine TOS "0x1F", ist ein Protokoll TCP (6), ist eine Quellenadresse "::FFFF:10.3.2.1", ist eine Zieladresse "::FFFF:10.2.3.54", ist eine Quellenportnummer 5000 und ein Zielportnummer 50. Hier sind die Quellenadresse und die Zieladresse eine IPv4-abgebildetete IPv6-Adresse und werden jeweils durch 32 Bits niedriger Ordnung ausgedrückt.
  • Wenn die TFT-Paketfilterungsprozedur 1611 die TFT-Paketfilterung in Verbindung mit Paketfilter 1 von TFT 1 für die IP-Paketdaten 2000 ausführt, wird die Paketfilterung nicht erfolgreich sein, weil die Quellenadresse von Paketfilter 1 von TFT 1 "2002::AF10:E9" ist. Weiterhin ist die TFT-Paketfilterung nicht erfolgreich, weil ein Quellenportbereich verbunden mit dem Paketfilter 2 von TFT 1 zwischen 100 und 1000 liegt,. Darüber hinaus, weil das Protokoll verbunden mit dem Paketfilter 3 von TFT 1 ICMP (1) ist, wird die TFT-Paketfilterung nicht erfolgreich sein. Wenn die TFT-Paketfilterungsprozedur 1611 die TFT-Paketfilterung in Verbindung mit dem Paketfilter 1 von TFT 2 durchführt, wird die TFT-Paketfilterung erfolgreich sein, weil ein IPv4-eingebetteter Typ 1" 10.3.2.1" entspricht. Dann führt die Paket-Filterungsprozedur 1611 die Paketfilterung unter Verwendung des TFT-Paketfilters abgestimmt auf die IP-Paketdaten 2200 durch und transferiert die IP-Paketdaten 2200 an die SGSN 1515 durch einen korrespondierenden GTP-Tunnel. In 22, da die Quellenadresse der IP-Paketdaten 2200 mit einem eingebetteten IPv4-Typ 1 übereinstimmen, der Paketfilter 1 von TFT 2 zugeordnet ist, benutzen die IP-Paketdaten 2200 den GTP-Tunnel, der dem TFT 2 zugeordnet ist.
  • Ein Vergleich zwischen der Menge von Bitberechnungen gemäß der TFT-Paket-Filterfunktion, wo das IPv6-Quellen-Adressenarten-Verfahren und das IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren in Übereinstimmung mit der vorliegenden Erfindung verwendet wird, und eine Menge von Bitberechnungen gemäß der allgemeinen TFT-Paket-Filterungsfunktion wird mit Bezug auf 23 beschrieben.
  • 23 zeigt eine Tabelle zur Veranschaulichung der Anzahl von Bitberechnungen gemäß einer TFT-Paketfilterung, wenn das IPv6-Quellen-Adressenarten-Verfahren und IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren verwendet werden, im Vergleich mit der Menge von Bitberechnungen gemäß der allgemeinen TFT-Paketfilterung in Übereinstimmung mit der vorlegenden Erfindung.
  • Mit Bezug auf 23 wird dort eine Menge von Bitberechnungen gezeigt wenn eine 128 Bit IPv6-Adresse verwendet wird, und eine Menge von Bitberechnungen, wenn 32 Bit extrahiert werden von der 128 Bit IPv6-Adresse gemäß der Anzahl von TFT-Paketfilterungen. Es wird dort eine Menge von Bitberechnungen gezeigt, eine Menge von 32 Bitberechnungen, wo die Anzahl von TFT-Paketfilterungen 1000, 100 000 und 1 000 000 ist. Wie in 23 gezeigt, ist ein Unterschied zwischen einer Menge von Bitberechnungen, bei der 128 Bits verwendet werden, und einer Menge von Bitberechnungen, bei der 32 Bits verwendet werden, bemerkenswert groß.
  • In dem IPv4-eingebetteten IPv6-Quellen-Adressenarten-Verfahren setzt die UE 1511 die TFT-Paketfilterart auf die IPv4-eingebettete IPv6-Quellen-Adressenart, extrahiert eine 32 Bit IPv6-Adresse niedriger Ordnung aus der IPv4-eingebetteten IPv6-Quellenadresse und konfiguriert wenigstens einen neuen TFT-Paketfilter unter Verwendung der extrahierten 32 Bit IPv6-Adresse niedriger Ordnung. In anderen Worten ist die TFT-Konfiguration durch die UE 1511 im IPv4-eingebetteten IPv6-Quellen-Adressenarten-Verfahren verschieden von demjenigen in dem IPv6-Quellen-Adressenarten-Verfahren. Der oben beschriebene Unterschied wird mit Bezug auf 24 beschrieben.
  • 24 zeigt ein Ablaufdiagramm zur Veranschaulichung eines TFT Paketfilter Erzeugungsprozesses bei dem das IPv4-eingebettete IPv6-Quellen-Adressenarten-Verfahren durchgeführt wird.
  • Mit Bezug auf 24 setzt die UE 1511 einen beliebigen Parameter i auf "0" (i = 0) und setzt einen beliebigen Parameter Max_filter auf "x" bei Schritt 2411 und schreitet zu Schritt 2413 voran. Hier gibt "x" die Anzahl von Paketfiltern an, die in der Lage sind, innerhalb eines TFT konfiguriert zu werden. Beispielsweise, da die maximale Anzahl von Paketfiltern, die konfiguriert werden können, 8 ist, wie oben beschrieben, hat "x" einen Wert zwischen 1 und 8. Die Anzahl von Paketfiltern "x", die in der Lage sind, innerhalb einer TFT konfiguriert zu werden, wird durch eine vorbestimmte Anwendung der UE 1511 bestimmt. Die UE 1511 bestimmt im obigen Schritt 2413, ob i < Max_filter. Wenn i ≥ Max_filter ein Ergebnis der Bestimmung ist, beendet die UE 1511 den Prozess. Falls i < Max_filter ein Ergebnis der Bestimmung ist, schreitet die UE 1511 zu Schritt 2415 voran. Die UE 1511 bestimmt in Schritt 2415, ob eine IP-Adresse, die einem TFT-Paketfilter zugeordnet ist, einer IPv4-eingebettete IPv6-Quellen-Adressenart entspricht. Falls die IP-Adresse, die einem TFT-Paketfilter zugeordnet ist, keiner IPv4-eingebettete IPv6-Quellen-Adressenart entspricht, schreitet die UE 1511 zu Schritt 2417 voran. Die UE 1511 konfiguriert TFT-Paketfilter unter Verwendung des allgemeinen TFT-Paketfilter-Erzeugungsverfahrens im obigen Schritt 2417 und schreitet zu Schritt 2423 voran. Falls die IP-Adresse, die einem TFT-Paketfilter zugeordnet ist, einer IPv4-eingebetteten IPv6-Quellen-Adressenart entspricht, schreitet die UE 1511 zu Schritt 2419 voran.
  • Die UE 1511 setzt in Schritt 2419 eine Art von Paketfilter, der erzeugt werden soll, auf eine IPv4-eingebettete IPv6-Quellen-Adressenart und schreitet dann zu Schritt 2421 voran. Die UE 1511 extrahiert im Schritt 2421 32 Bit niedriger Ordnung aus der IPv4-eingebetteten IPv6-Adresse und schreitet dann weiter zu Schritt 2423 voran. Die UE 1511 erzeugt den Paketfilter unter Verwendung der 32 Bit und speichert den erzeugten Paketfilter in einer entsprechenden TFT im Schritt 2423 und schreitet zu Schritt 2425 voran. Die UE 1511 inkrementiert den Wert des Parameters i um "1" (d. h. i = i + 1) im Schritt 2425 und schreitet dann zu Schritt 2413 voran.
  • Wie von der obigen Beschreibung erkannt werden kann, stellt die vorliegende Erfindung eine Einrichtung und ein Verfahren zur Durchführung von TFT-Paketfilterung bereit, die eine Menge von Berechnungen verbunden mit der Paketfilterung minimieren kann, indem lediglich 32 Bit niedriger Ordnung verwendet werden, gewählt aus einer IPv4-eingebetteten IPv6-Adresse, die aus 128 Bits besteht, wenn eine Art einer IP-Adresse von Paketdaten, die über ein externes Netzwerk eintreffen, der IPv4-eingebetteten IPv6-Adresse in einem mobilen Kommunikationssystem entsprechen. In anderen Worten, da eine Berechnungsfunktion für die verbleibenden 96 Bit außer den gewählten 32 Bit niedriger Ordnung nicht durchgeführt wird, kann die Menge der Berechnungen jedes Mal verringert werden, wenn TFT-Paketfilterung durchgeführt wird.
  • Darüber hinaus kann die Einrichtung und das Verfahren die Größe eines Elements zur Speicherung von TFT-Paketfiltern minimieren, weil lediglich 32 Bits anstatt 128 Bits benutzt werden, wenn wenigstens ein Paketfilter in Verbindung mit einer IPv4-eingebetteten IPv6-Adresse konfiguriert ist, so dass die gesamte Ressourcenwirksamkeit in einem mobilen Kommunikationssystem erweitert werden kann.
  • Obwohl die Ausführungsformen der vorliegenden Erfindung zu Erklärungszwecken offenbart worden sind, werden jene Fachleute würdigen, dass verschiedene Modifikationen, Hinzufügungen oder Ersetzungen möglich sind, ohne vom Schutzbereich der Erfindung abzuweichen. Daher ist die vorliegende Erfindung nicht auf die oben beschriebenen Ausführungsformen begrenzt, sondern die vorliegende Erfindung wird durch die folgenden Ansprüche angegeben gemeinsam mit dem vollen Bereich ihrer Äquivalente.

Claims (15)

  1. Verfahren zur Durchführung von Verkehrsflussschablonen-Filterung (TFT) in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem, wobei das Verfahren die folgenden Schritte aufweist: Extrahieren einer ersten IP-Versionsadresse aus einer zweiten IP-Versions-Quellenadresse, worin die zweite IP-Versionsadresse eine erste IP-Versionsadresse enthält; Erzeugen von TFT-Information auf der Basis der ersten IP-Versionsadresse, worin die TFT Information eine Angabe enthält, dass die zweite IP Versionsadresse eine erste IP-Versionsadresse enthält; und Übertragen der TFT-Information an einen Gateway-GPRS-(Allgemeiner Paketfunkdienst)-Unterstützungsknoten (GGSN).
  2. Verfahren zur Durchführung von Verkehrsflussschablonen-(TFT)-Filterung in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem, wobei das Verfahren folgende Schritte aufweist: Empfangen einer ersten TFT-Information, welche eine zweite IP Versionsadresse enthält, von einer Mobilstation, worin die zweite IP Versionsadresse eine erste IP Versionsadresse enthält; Erzeugen einer zweiten TFT-Information unter Verwendung der ersten IP-Versionsadresse; und Filtern eines empfangenen Pakets unter Verwendung der zweiten TFT-Information.
  3. Verfahren nach Anspruch 1, worin es Benutzereinrichtungen (UE) gestattet wird, die Schritte des Extrahierens, Erzeugens von TFT-Information und Sendens der erzeugten TFT-Information an einen Gateway-GPRS-(Allgemeiner Paketfunkdienst)-Unterstützungsknoten (GGSN) auszuführen; es dem GGSN gestattet wird, die TFT-Information zu speichern, welche vom UE empfangen werden, und die erste IP Versionsadresse aus der zweiten IP Versionsadresse zu extrahieren, wenn in die zweite IP Versionsadresse die erste IP Versionsadresse eingefügt ist; und worin dem GGSN gestatten wird, TFT-Paketfilterung unter Verwendung der extrahierten ersten IP-Versionsadresse durchzuführen.
  4. Verfahren nach einem der Ansprüche 1, 2 oder 3, bei welchem die zweite IP Versionsadresse, in welche die erste IP Versionsadresse eingefügt ist, eine erste IP-Versions-kompatible zweite IP Versionsadresse oder eine erste IP-Versions-abgebildete zweite IP Versionsadresse darstellt.
  5. Verfahren nach Anspruch 4, bei welchem die erste IP-Versions-kompatible zweite IP Versionsadresse eine Adresse darstellt, die zwischen Netzwerken verwendet wird, die dazu in der Lage sind, beides zu unterstützen, ein erstes IP der ersten IP-Version und ein zweites IP der zweiten IP-Version.
  6. Verfahren nach Anspruch 4, bei welchem die erste IP-Versions-abgebildete zweite IP Versionsadresse eine Adresse darstellt, die zwischen einem Netzwerk verwendet wird, das dazu in der Lage ist, lediglich ein erstes IP der ersten IP-Version zu unterstützen und einem Netzwerk, das dazu in der Lage ist, beides zu unterstützen, die erste IP der ersten IP-Version und eine zweite IP der zweiten IP-Version.
  7. Verfahren nach einem der Ansprüche 1, 2 oder 3, bei welchem die erste IP-Version eine IP Version 4 (IPv4) und die zweite IP-Version eine IP Version 6 (IPv6) ist.
  8. Einrichtung zur Durchführung von Verkehrsflussschablonen-(TFT)-Filterung in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem, wobei die Einrichtung umfasst: Empfangsmittel zum Empfangen von einer Mobilstation einer ersten TFT Information, welche eine zweite IP-Versionsadresse enthält, worin die zweite IP-Versionsadresse eine erste IP-Versionsadresse enthält; Mittel zum Erzeugen einer zweiten TFT Information unter Verwendung der ersten IP-Versionsadresse; und Filtermittel zum Filtern eines empfangenen Pakets unter Verwendung der zweiten TFT Information.
  9. Einrichtung nach Anspruch 8, bei welcher die Filtermittel umfassen: eine TFT-Paketfilterungsprozedur zur Extrahierung der ersten IP-Versionsadresse aus der zweiten IP-Versionsadresse, wenn eine IP-Adresse von empfangenen Paketdaten der zweiten IP-Version entspricht und die IP-Adresse die zweite IP-Versionsadresse ist, in welche die erste IP-Versionsadresse eingefügt ist, und zur Durchführung der Paketfilterung unter Verwendung der zweiten TFT-Information.
  10. Einrichtung zur Durchführung von Verkehrsflussschablonen-(TFT)-Filterung in Übereinstimmung mit Internet-Protokoll-(IP)-Versionen in einem mobilen Kommunikationssystem, wobei die Einrichtung umfasst: eine Steuereinrichtung zur Extraktion der ersten IP-Versionsadresse aus einer zweiten IP-Versions-Quellenadresse, worin die zweite IP-Versionsadresse eine erste IP-Versionsadresse enthält, und zur Erzeugung von TFT-Informationen unter Verwendung der ersten IP-Versionsadresse, worin die TFT-Information eine Angabe enthält, dass die zweite IP-Verswionsadresse eine erste IP-Versionsadresse enthält; und Übertragungsmittel zur Übertragung der erzeugten TFT-Informationen an einen Gateway-GPRS-(Allgemeiner Paketfunkdienst)-Unterstützungsknoten (GGSN).
  11. Einrichtung nach Anspruch 10, umfassend den Gateway-GPRS-(Allgemeiner Paketfunkdienst)-Unterstützungsknoten GGSN, welcher umfasst: eine TFT-Paketfilterungsprozedur zur Extraktion der ersten Bits, welche der ersten IP-Versionsadresse entsprechen, aus der zweiten IP-Versionsadresse, wenn die IP-Adresse von den empfangenen Paketdaten der zweiten IP-Version entspricht und die IP-Adresse die zweite IP-Versionsadresse ist, in welche die erste IP-Versionsadresse eingefügt ist, und zur Durchführung von TFT-Paketfilterung unter Verwendung der ersten Bits, die aus den empfangenen Paketdaten extrahiert wurden; und einen Speicher zur Speicherung der TFT-Informationen, die von der UE empfangen werden.
  12. Einrichtung nach einem der Ansprüche 8 oder 10, bei welcher die zweite IP-Versionsadresse, in welche die erste IP-Versionsadresse eingefügt ist, eine erste IP-Versions-kompatible zweite IP-Versionsadresse oder eine erste IP-Versions-abgebildete zweite IP-Versionsadresse darstellt.
  13. Einrichtung nach Anspruch 12, bei welcher die erste IP-Versions-kompatible zweite IP-Versionsadresse eine Adresse darstellt, die zwischen Netzwerken benutzt wird, die dazu in der Lage sind, beides zu unterstützen, ein erstes IP der ersten IP-Version und eines zweites IP der zweiten IP-Version.
  14. Einrichtung nach Anspruch 12, bei welcher die erste IP-Versions-abgebildete zweite IP-Versionsadresse eine Adresse ist, die zwischen einem Netzwerk verwendet wird, das dazu in der Lage ist, lediglich ein IP der ersten IP-Version zu unterstützen und einem Netzwerk, das dazu in der Lage ist, beides zu unterstützen, das erste IP der ersten IP-Version und ein zweites IP der zweiten IP-Version.
  15. Einrichtung nach einem der Ansprüche 8 oder 10, bei welcher die erste IP-Version eine IP Version 4 (IPv4) und die zweite IP-Version eine IP Version 6 (IPv6) ist.
DE200410008720 2003-02-21 2004-02-23 Vorrichtung und Verfahren zur Durchführung von Verkehrsflussschablonen-Paketfilterung gemäß Internet-Protokollversionen in einem mobilen Kommunikationssystem Expired - Fee Related DE102004008720B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR20030011133A KR100886551B1 (ko) 2003-02-21 2003-02-21 이동통신시스템에서 인터넷 프로토콜 버전에 따른 트래픽플로우 탬플릿 패킷 필터링 장치 및 방법
KR2003/11133 2003-02-21
KR11133/2003 2003-02-21

Publications (2)

Publication Number Publication Date
DE102004008720A1 DE102004008720A1 (de) 2004-09-16
DE102004008720B4 true DE102004008720B4 (de) 2009-03-19

Family

ID=32041031

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200410008720 Expired - Fee Related DE102004008720B4 (de) 2003-02-21 2004-02-23 Vorrichtung und Verfahren zur Durchführung von Verkehrsflussschablonen-Paketfilterung gemäß Internet-Protokollversionen in einem mobilen Kommunikationssystem

Country Status (8)

Country Link
US (1) US20040205247A1 (de)
JP (1) JP4006407B2 (de)
KR (1) KR100886551B1 (de)
CN (1) CN1279731C (de)
DE (1) DE102004008720B4 (de)
FR (1) FR2852472B1 (de)
GB (1) GB2400278B (de)
IT (1) ITMI20040297A1 (de)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI116186B (fi) * 2003-12-19 2005-09-30 Nokia Corp Tiedonsiirron järjestäminen langattomassa pakettivälitteisen datan siirtoa tarjoavassa järjestelmässä
US20050268331A1 (en) * 2004-05-25 2005-12-01 Franck Le Extension to the firewall configuration protocols and features
US8175534B2 (en) * 2004-09-03 2012-05-08 Cisco Technology, Inc. RF-aware packet filtering in radio access networks
GB2422272A (en) * 2005-01-14 2006-07-19 King S College London Network mobility
EP1705859A1 (de) * 2005-03-24 2006-09-27 Orange SA Verfahren und System zur Aktivierung eines Kontextes für ein Packetdatenprotokoll
EP1705858A1 (de) * 2005-03-24 2006-09-27 Orange SA Verfahren und System zur Aktivierung eines Kontextes für ein Paketdatenprotokoll
GB2425015A (en) * 2005-04-07 2006-10-11 Symbian Software Ltd Quality of service in networked computing devices
US7826418B2 (en) * 2005-06-27 2010-11-02 Qualcomm Incorporated Block-based assignment of quality of service precedence values
KR100757874B1 (ko) 2006-02-18 2007-09-11 삼성전자주식회사 ＤＳＴＭ 환경의 ＩＰｖ６-ＩＰｖ４ 네트워크에서의ＩＰｖ６ 패킷 위조 방지 방법 및 그 시스템
US20070195801A1 (en) * 2006-02-23 2007-08-23 Nokia Corporation Context-based processing of data flows
US8332926B2 (en) * 2006-05-12 2012-12-11 Qualcomm Incorporated Efficient modification of packet filters in a wireless communication network
KR100821152B1 (ko) * 2006-06-23 2008-04-11 주식회사 케이티프리텔 Ｗｃｄｍａ망에서 트래픽 플로우 템플릿 설정 방법 및시스템
US7870231B2 (en) * 2006-07-21 2011-01-11 Qualcomm Incorporated Efficiently assigning precedence values to new and existing QoS filters
CN101128043B (zh) 2006-08-15 2011-02-02 华为技术有限公司 系统间切换或者改变时的数据处理方法
FI20075305L (fi) * 2007-05-02 2008-11-03 Eads Secure Networks Oy Datavirtojen hallinta tietoliikennejärjestelmässä
KR100953453B1 (ko) 2007-11-27 2010-04-20 한국전자통신연구원 이동단말에서의 상향링크 ｉｐ 패킷 필터링 제어방법
US8190734B2 (en) * 2008-05-21 2012-05-29 Mcafee, Inc. System and method for network monitoring of internet protocol (IP) networks
US20090323965A1 (en) * 2008-06-27 2009-12-31 Telefonaktiebolaget Lm Ericsson (Publ) Systems and Methods for Monitoring Performance of a Communication System
US20100124223A1 (en) * 2008-11-18 2010-05-20 Andrew Gibbs Selective paging in wireless networks
US8428625B2 (en) 2009-02-27 2013-04-23 Cisco Technology, Inc. Paging heuristics in packet based networks
US8938068B2 (en) * 2009-08-03 2015-01-20 Nippon Telegraph And Telephone Corporation Functional encryption applied system, information output apparatus, information processing apparatus, encryption protocol execution method, information output method, information processing method, program and recording medium
CN101800967B (zh) * 2009-12-30 2012-12-12 华为技术有限公司 一种实现策略与计费控制的方法、网关和移动终端
US20130021905A1 (en) * 2010-01-12 2013-01-24 Nokia Siemens Networks Oy Controlling traffic flow template generation
US8448221B2 (en) * 2010-03-12 2013-05-21 Mcafee, Inc. System, method, and computer program product for displaying network events in terms of objects managed by a security appliance and/or a routing device
US8531947B2 (en) * 2010-03-31 2013-09-10 Qualcomm Incorporated Single and dual internet protocol bearer support
US8861535B2 (en) 2010-05-21 2014-10-14 Cisco Technology, Inc. Multi-tiered paging support using paging priority
US8537829B2 (en) 2010-09-15 2013-09-17 Cisco Technology, Inc. Paging control in communication networks
KR101228089B1 (ko) * 2012-09-10 2013-02-01 한국인터넷진흥원 Ｉｐ 스푸핑 탐지 장치
US9060347B2 (en) 2012-11-30 2015-06-16 Cisco Technology, Inc. Subscriber-aware paging
KR101469244B1 (ko) * 2013-02-06 2014-12-12 한밭대학교 산학협력단 수신된 데이터에서의 불필요한 패킷 제거 장치 및 방법
US20150215840A1 (en) * 2014-01-30 2015-07-30 Intel IP Corporation Systems, methods and devices for application specific routing in dual connectivity
KR102183978B1 (ko) * 2014-06-30 2020-11-27 애플 인크. Lte용 서비스 품질 아키텍쳐를 향상시키는 장치 및 방법
US10469379B2 (en) 2017-02-17 2019-11-05 Cisco Technology, Inc. System and method to facilitate content delivery to multiple recipients in a network environment
US10404592B2 (en) 2017-03-24 2019-09-03 Cisco Technology, Inc. System and method to facilitate content forwarding using bit index explicit replication (BIER) in an information-centric networking (ICN) environment
US11095507B2 (en) 2017-05-09 2021-08-17 Proofpoint, Inc. Globally-distributed secure end-to-end identity-based overlay network
US10986019B2 (en) * 2017-05-09 2021-04-20 Proofpoint, Inc. IP address and routing schemes for overlay network
CN108200138A (zh) * 2017-12-26 2018-06-22 广东欧珀移动通信有限公司 专用承载的建立方法及相关设备
KR20200033048A (ko) * 2018-09-19 2020-03-27 삼성전자주식회사 패킷을 필터링하는 전자 장치 및 그 작동 방법
US11689498B1 (en) * 2022-02-09 2023-06-27 Rakuten Mobile, Inc. Internet protocol address generation

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002073989A1 (en) * 2001-03-14 2002-09-19 Nokia Corporation Method for activating a connection in a communications system, mobile station, network element and packet filter
WO2003032668A1 (en) * 2001-10-05 2003-04-17 Nokia Corporation Method and system for hand off in a gprs network with nodes supporting different ip versions
WO2003069842A1 (en) * 2002-02-13 2003-08-21 Nokia Corporation Filtering of data packets in a communication network according to interface identifiers

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6690669B1 (en) * 1996-11-01 2004-02-10 Hitachi, Ltd. Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus
FI108601B (fi) 1999-01-05 2002-02-15 Nokia Corp QoS-kartoitustiedon välitys pakettiradioverkossa
FI106762B (fi) * 1999-02-16 2001-03-30 Nokia Mobile Phones Ltd Menetelmä ja järjestelmä eräiden neuvottelujen toteuttamiseksi pakettidataverkossa
US6845091B2 (en) * 2000-03-16 2005-01-18 Sri International Mobile ad hoc extensions for the internet
US20020038419A1 (en) * 2000-03-20 2002-03-28 Garrett John W. Service selection in a shared access network using tunneling
US6621793B2 (en) * 2000-05-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Application influenced policy
WO2002069519A1 (en) 2001-02-23 2002-09-06 Nokia Inc. System and method for fast gprs for ipv6 communications
JP4075318B2 (ja) * 2001-04-18 2008-04-16 株式会社日立製作所 プロトコル変換方法，及びアドレス変換サーバ
US7145919B2 (en) * 2001-06-01 2006-12-05 Telefonaktienbolaget Lm Ericsson (Publ) Method and apparatus for transporting different classes of data bits in a payload over a radio interface
JP3881198B2 (ja) 2001-07-04 2007-02-14 株式会社エヌ・ティ・ティ・ドコモ モバイルｉｐ通信システム、モバイルｉｐ通信方法、ネットワーク中継装置及び移動体端末
WO2003007544A2 (en) * 2001-07-10 2003-01-23 Telefonaktiebolaget Lm Ericsson (Publ) Traffic flow template for managing packet data flows
US20030026230A1 (en) 2001-08-02 2003-02-06 Juan-Antonio Ibanez Proxy duplicate address detection for dynamic address allocation
CN100542165C (zh) * 2001-10-05 2009-09-16 诺基亚公司 提供地址转换以及消息相关的方法和系统
US7286536B2 (en) * 2002-10-28 2007-10-23 Nokia Corporation Method and system for early header compression

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002073989A1 (en) * 2001-03-14 2002-09-19 Nokia Corporation Method for activating a connection in a communications system, mobile station, network element and packet filter
WO2003032668A1 (en) * 2001-10-05 2003-04-17 Nokia Corporation Method and system for hand off in a gprs network with nodes supporting different ip versions
WO2003069842A1 (en) * 2002-02-13 2003-08-21 Nokia Corporation Filtering of data packets in a communication network according to interface identifiers

Also Published As

Publication number Publication date
ITMI20040297A1 (it) 2004-05-20
DE102004008720A1 (de) 2004-09-16
FR2852472A1 (fr) 2004-09-17
KR100886551B1 (ko) 2009-03-02
US20040205247A1 (en) 2004-10-14
CN1279731C (zh) 2006-10-11
JP4006407B2 (ja) 2007-11-14
FR2852472B1 (fr) 2006-02-10
GB2400278B (en) 2006-06-21
GB2400278A (en) 2004-10-06
KR20040075582A (ko) 2004-08-30
GB0403484D0 (en) 2004-03-24
CN1531287A (zh) 2004-09-22
JP2004260818A (ja) 2004-09-16

Similar Documents

Publication Publication Date Title
DE102004008720B4 (de) Vorrichtung und Verfahren zur Durchführung von Verkehrsflussschablonen-Paketfilterung gemäß Internet-Protokollversionen in einem mobilen Kommunikationssystem
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60008735T2 (de) Steuerung von pdp-kontexten in mobilstationen
DE60225892T2 (de) Firewall zur Filtrierung von getunnelten Datenpaketen
DE69533740T2 (de) TCP/IP-Kopfendekompression in X.25-Netzwerken
DE60106457T2 (de) Zuteilung von datenübertragungsbetriebsmitteln bei der paketvermittelten datenübertragung
DE69729040T2 (de) Netzwerkübertragung
DE19950653B4 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE60031566T2 (de) Signalisierungsverfahren und apparate in einem zellularen netz
DE602004003146T2 (de) System und verfahren für telekommunikation
DE102004058752A1 (de) Identifizieren von Diensten, die über IP und ähnliche Paketnetzwerke bereitgestellt werden, und Dienstverwendungsaufzeichnungen für derartige Dienste
DE60031163T2 (de) Verfahren und vorrichtungen zum bereitstellen einer wohldefinierten servicequalität in einem paketvermittelten kommunikationsnetz
DE69937185T2 (de) Verfahren und vorrichtung zum paketbeförderungsnachschlagen mit einer reduzierten anzahl von speicherzugriffen
EP1438829B1 (de) Verfahren und vorrichtung zur abbildung von netzwerk-headern auf mpls-header in bearer-architekturen
DE60018723T2 (de) Adressierungsschema für ein IP basiertes funkzugriffsnetz
DE69925744T2 (de) Verbindungsaufbau in einem drahtlosen telekommunikationsnetz
DE60221295T2 (de) System auf der basis des internet-protokolls
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
DE69922369T2 (de) Verfahren und vorrichtung zur erhöhung eines datendurchsatzes
EP1266493A1 (de) Verfahren und anordnung zum übertragen eines datenpakets von einer ersten vermittlungseinheit an eine zweite vermittlungseinheit in einem datennetz
DE60320567T2 (de) Adressenverwaltungsverfahren
DE60317503T2 (de) Lastausgleicher für mehrprozessorplattformen
DE60130678T2 (de) Verfahren zum senden von paketen über leitungsvermittelte netzwerke
DE102005014852A1 (de) Entscheidung zur Zuordnung und Ressourcenvergabe für mindestens einem Datenstrom und mindestens eine Nutzverbindung
DE19944334C1 (de) Verfahren zum Betreiben eines Mobilfunknetzes

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
R082 Change of representative

Representative=s name: GRUENECKER, KINKELDEY, STOCKMAIR & SCHWANHAEUSSER,

Representative=s name: GRUENECKER, KINKELDEY, STOCKMAIR & SCHWANHAEUS, DE

Representative=s name: GRUENECKER PATENT- UND RECHTSANWAELTE PARTG MB, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012560000

Ipc: H04L0012741000