FR2852472A1 - Appareil et procede pour le filtrage par modele de flux de trafic dans un systeme de communication mobile - Google Patents
Appareil et procede pour le filtrage par modele de flux de trafic dans un systeme de communication mobile Download PDFInfo
- Publication number
- FR2852472A1 FR2852472A1 FR0401709A FR0401709A FR2852472A1 FR 2852472 A1 FR2852472 A1 FR 2852472A1 FR 0401709 A FR0401709 A FR 0401709A FR 0401709 A FR0401709 A FR 0401709A FR 2852472 A1 FR2852472 A1 FR 2852472A1
- Authority
- FR
- France
- Prior art keywords
- version
- address
- tft
- packet
- bits
- 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.)
- Granted
Links
- 238000001914 filtration Methods 0.000 title claims abstract description 159
- 238000010295 mobile communication Methods 0.000 title claims abstract description 20
- 238000000034 method Methods 0.000 title claims description 159
- 239000000284 extract Substances 0.000 claims description 11
- 230000004913 activation Effects 0.000 description 41
- 238000010586 diagram Methods 0.000 description 37
- 230000008569 process Effects 0.000 description 37
- 238000011156 evaluation Methods 0.000 description 22
- 230000006870 function Effects 0.000 description 17
- 238000012546 transfer Methods 0.000 description 12
- 238000004891 communication Methods 0.000 description 11
- 230000004044 response Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000005641 tunneling Effects 0.000 description 5
- 101100138706 Cricetulus griseus PTDSS2 gene Proteins 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 4
- PZINFSHCXYXHOY-UHFFFAOYSA-N (2,5-dioxopyrrolidin-1-yl) 5-iodopyridine-3-carboxylate Chemical compound IC1=CN=CC(C(=O)ON2C(CCC2=O)=O)=C1 PZINFSHCXYXHOY-UHFFFAOYSA-N 0.000 description 3
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- PCTMTFRHKVHKIS-BMFZQQSSSA-N (1s,3r,4e,6e,8e,10e,12e,14e,16e,18s,19r,20r,21s,25r,27r,30r,31r,33s,35r,37s,38r)-3-[(2r,3s,4s,5s,6r)-4-amino-3,5-dihydroxy-6-methyloxan-2-yl]oxy-19,25,27,30,31,33,35,37-octahydroxy-18,20,21-trimethyl-23-oxo-22,39-dioxabicyclo[33.3.1]nonatriaconta-4,6,8,10 Chemical compound C1C=C2C[C@@H](OS(O)(=O)=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H]([C@H](C)CCCC(C)C)[C@@]1(C)CC2.O[C@H]1[C@@H](N)[C@H](O)[C@@H](C)O[C@H]1O[C@H]1/C=C/C=C/C=C/C=C/C=C/C=C/C=C/[C@H](C)[C@@H](O)[C@@H](C)[C@H](C)OC(=O)C[C@H](O)C[C@H](O)CC[C@@H](O)[C@H](O)C[C@H](O)C[C@](O)(C[C@H](O)[C@H]2C(O)=O)O[C@H]2C1 PCTMTFRHKVHKIS-BMFZQQSSSA-N 0.000 description 1
- 101000718497 Homo sapiens Protein AF-10 Proteins 0.000 description 1
- 102100026286 Protein AF-10 Human genes 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
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
- 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
- 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
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un système de communication mobile effectuant un filtrage par Modèle de Flux de Trafic (ou TFT) conformément à des versions de Protocole Internet (IP), supporte une adresse d'une première version d'IP incluant des premiers bits et une adresse d'une seconde version d'IP incluant des seconds bits contenant les premiers bits. Une information basée sur la version d'IP est extraite de l'adresse IP de source. Une information de TFT contenant l'information extraite est générée et l'information de TFT générée est transmise à un Noeud de Support GPRS de Passerelle (ou GGSN) (1519).
Description
La présente invention concerne un système de
communication mobile, et plus particulièrement un appareil et un procédé pour effectuer un filtrage de paquets d'après un Modèle de Flux de Trafic ou TFT pour "Traffic Flow 5 Template", conformément à des versions du Protocole Internet, ou IP pour "Internet Procotol", dans un système de communication mobile.
Un système de communication mobile appelé Universal Mobile Telecommunication System (UMTS) est un système pour 10 mettre en oeuvre la communication mobile de troisième génération. L'UMTS supporte des services de données en mode de paquets ainsi que des services de communication vocale, et supporte des transmissions de données rapides, des transmissions d'images animées, et autres. On décrira 15 l'architecture schématique du réseau UMTS en se référant à la figure 1.
La figure 1 est un schéma synoptique illustrant l'architecture d'un réseau UMTS classique.
En se référant à la figure 1, on note qu'un 20 Equipement d'Utilisateur (UE pour "User Equipment") 111 couplé à un Réseau d'Accès Radio Terrestre UMTS (UTRAN pour "UMTS Terrestrial Radio Access Network") 113 traite un appel et supporte à la fois un Service de Circuits (CS pour "Circuit Service") et un Service de Paquets (PS pour 25 "Packet Service"). L'UTRAN 113 est configuré par au moins une station de base appelée Node-B (non représentée) et au moins un Contrôleur de Réseau Radio (RNC pour "Radio Network Controller") (non représenté). Le Node-B est couplé à l'UE 111 sur une interface Uu, et le RNC est couplé à un 30 Noeud de Support GPRS de Desserte (SGSN pour "Serving GPRS Support Node") 115 sur une interface Iu. Un Service Radio en Mode Paquets Général (GPRS pour "General Packet Radio Service") est un service de données en mode paquets fourni par le réseau UMTS. L'UTRAN 113 effectue une opération de 35 conversion de protocole pour transférer vers un Réseau d'Infrastructure (CN pour "Core Network"), en utilisant un Protocole de Tunnel GPRS (GTP pour "GPRS Tunnelling Protocol") des messages radio de données ou de commande, reçus sur une interface hertzienne. Ici, le CN est considéré comme un ensemble du SGSN 115 et d'un Noeud de 5 Support GPRS de Passerelle (GGSN pour "Gateway GPRS Support Node") 119.
Le SGSN 115 est un noeud de réseau pour gérer de l'information d'abonnés et de l'information de positions de l'UE 111. Le SGSN 115 est couplé à l'UTRAN 113 sur 10 l'interface Iu et est couplé au GGSN 119 sur une interface Gn, de façon que des messages de données et de commande soient émis et reçus. Le SGSN 115 est couplé à un Enregistreur de Localisation Nominal (HLR pour "Home Location Register") 117 sur une interface Gr, pour gérer 15 l'information d'abonné et l'information d'emplacement.
Le HLR 117 stocke de l'information d'abonnés et de l'information de routage associées à un domaine de paquets, et autres. Le HLR 117 est couplé au SGSN 115 sur l'interface Gr, et est couplé au GGSN 119 sur une interface 20 Gc. Bien entendu, le HLR 117 peut être placé à l'intérieur d'un Réseau Mobile Terrestre Public (PLMN pour "Public Land Mobile Network") lorsqu'on considère l'itinérance de l'UE 111. Le GGSN 119 correspond à un point d'extrémité associé au GTP dans le réseau UMTS, et le GGSN 119 couplé à un 25 réseau externe sur une interface Gi peut être exploité en interopération avec l'Internet 121, un Réseau de Domaine de Paquets (PDN pour "Packet Domain Network") ou un PLMN.
On décrira schématiquement en référence à la figure 2 l'architecture d'un réseau d'infrastructure UMTS dans 30 lequel un Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") est utilisé.
La figure 2 est un schéma synoptique illustrant le réseau d'infrastructure UMTS basé sur un TFT classique.
Avant de décrire le réseau d'infrastructure UMTS en 35 référence à la figure 2, on notera qu'une opération de filtrage de paquets est effectuée en utilisant le TFT, et que le réseau d'infrastructure UMTS utilise le TFT.
L'utilisation du TFT est décrite dans ce qui suit. Des contextes de Protocole de Données en Mode de Paquets (PDP pour "Packet Data Protocol") comprennent deux types de 5 contextes de PDP qui sont les types primaire et secondaire.
Le contexte de PDP secondaire a la même information que le contexte de PDP primaire et peut exister seulement à un endroit auquel le contexte de PDP primaire est présent. Du fait que le contexte de PDP secondaire utilise 10 l'information du contexte de PDP primaire telle quelle, le contexte de PDP secondaire est généré après que le contexte de PDP primaire a été généré. Les contextes de PDP primaire et secondaire utilisent en réalité la même information, et seulement des éléments de données de paquets associés aux 15 contextes de PDP primaire et secondaire sont transmis à travers différents tunnels de GTP.
Le réseau d'infrastructure UMTS utilise l'information de TFT comme des filtres pour indiquer les contextes de PDP primaire et secondaire lorsque le contexte 20 de PDP secondaire est activé. Comme représenté sur la figure 2, il y a un réseau d'infrastructure UMTS 200, c'est-à-dire un réseau d'infrastructure 200 à Accès Multiple par Répartition par Code à Large Bande (WCDMA pour "Wideband Code Division Multiple Access"), dans lequel sept 25 TFT sont stockés, et un total de 8 tunnels de GTP sont générés en relation avec des contextes de PDP secondaires correspondant aux sept TFT et un contexte de PDP primaire.
Des données en mode de paquets IP arrivant sur le réseau externe, par exemple l'Internet 121, sont introduites dans 30 le GGSN 119 sur l'interface Gi. Le GGSN 119 stocke les sept TFT, incluant TFT 1 à TFT 7. Un itinéraire utilisé pour des données en mode de paquets IP introduites sur l'interface Gi est déterminé par une opération de filtrage de paquets à travers les sept TFT. Les données en mode de paquets IP 35 filtrées par le GGSN 119 en utilisant les TFT sont transférées vers le SGSN 115 à travers l'interface Gn associée à l'itinéraire déterminé, c'est-à-dire le tunnel de GTP déterminé. Le SGSN 115 transfère les données en mode de paquets IP reçues du GGSN 119 vers un Réseau d'Accès Radio (RAN pour "Radio Access Network") 211 à travers une interface Iu utilisant un tunnel de GTP correspondant.
On va maintenant décrire un format du TFT en référence à la figure 3.
La figure 3 est un schéma synoptique illustrant le format d'un TFT classique.
Le TFT est généré par l'UE 111, et le TFT généré est transféré vers le GGSN 119 à travers l'UTRAN 113 et le SGSN 115. Le GGSN 119 filtre des données en mode de paquets introduites à travers le réseau externe, c'està-dire l'Internet 121, en utilisant le TFT pour indiquer un tunnel 15 de GTP primaire et un tunnel de GTP secondaire, et recherche un tunnel de GTP sur lequel les données en mode de paquets filtrées sont transmises. Lorsque aucun TFT n'est présent du fait que le tunnel de GTP primaire utilisant le contexte de PDP primaire et le tunnel de GTP 20 secondaire utilisant le contexte de PDP secondaire ont la même adresse de PDP, on ne peut pas déterminer un tunnel de GTP sur lequel des données en mode de paquets reçues du réseau externe sont transmises, c'est-à-dire si les données en mode de paquets sont transmises sur le tunnel de GTP 25 primaire ou le tunnel de GTP secondaire.
Le TFT a une multiplicité de filtres de paquets, c'est-à-dire 8 filtres de paquets, capables d'être identifiés par des identificateurs (ID) de filtres de paquets spécifiques. Les filtres de paquets ont des index 30 de priorité d'évaluation spécifiques pour tous les TFT associés aux contextes de PDP partageant la même adresse de PDP. Chacun des index de priorité d'évaluation a une valeur entre 0 et 255. L'UE 111 gère un ID de filtre de paquets et un index de priorité d'évaluation associé à un filtre de 35 paquets, et génère un contenu d'un filtre de paquets réel.
En outre, le TFT a une correspondance un à un avec un contexte de PDP au moment de l'activation du contexte de PDP secondaire. En d'autres termes, le TFT peut être généré en plus dans une procédure de modification de contexte de PDP lancée par l'UE 111, en plus du contexte de PDP généré 5 dans la procédure d'activation de contexte de PDP. Le TFT peut être corrigé au moyen de la procédure de modification de contexte de PDP lancée par l'UE 111. Un contexte de PDP ne peut pas être associé à plus d'un TFT.
En se référant à la figure 3, on note que le TFT 10 comprend un champ "TYPE DE MODELE DE FLUX DE TRAFIC", un champ "LONGUEUR DE MODELE DE FLUX DE TRAFIC", un champ "CODE D'OPERATION DE TFT", un champ "NOMBRE DE FILTRES DE PAQUETS" et un champ "LISTE DE FILTRES DE PAQUETS". Le champ "TYPE DE MODELE DE FLUX DE TRAFIC" indique un type du 15 TFT utilisé. Une valeur du champ "TYPE DE MODELE DE FLUX DE TRAFIC" est fixée de façon caractéristique à "137" dans le réseau d'infrastructure UMTS 200 et peut être fixée différemment conformément à des réseaux. Le champ "LONGUEUR DE MODELE DE FLUX DE TRAFIC" indique la longueur du TFT 20 utilisé, a une longueur prédéterminée, par exemple 2 octets, et indique la longueur des champs restants, à l'exception du champ "TYPE DE MODELE DE FLUX DE TRAFIC" et du champ "LONGUEUR DE MODELE DE FLUX DE TRAFIC". Le champ "CODE D'OPERATION DE TFT" indique un code d'opération de 25 TFT. Une valeur indiquée par le champ "CODE D'OPERATION DE TFT" est analysée et la manière selon laquelle le TFT reçu de l'UE 111 est traité est déterminée conformément à un résultat de l'analyse. Des codes pouvant être indiqués dans le champ "CODE D'OPERATION DE TFT" sont indiqués dans le 30 Tableau 1 suivant.
Tableau 1
Bits (765) Description
000 Inutilisé 001 Création d'un nouveau TFT Suppression d'un TFT stocké 011 Ajout de filtres de paquets à un TFT stocké Remplacement de filtres de paquets dans un TFT stocké 101 Suppression de filtres de paquets d'un TFT stocké Réservé 111 Réservé Comme indiqué dans le Tableau 1 ci-dessus, le code d'opération de TFT "000" indique une valeur inutilisée, le code d'opération de TFT "001" indique une opération de 5 création d'un nouveau TFT, le code d'opération de TFT "011" indique une opération d'ajout de filtres de paquets à un TFT stocké, le code d'opération de TFT "100" indique une opération de remplacement de filtres de paquets dans le TFT stocké, le code d'opération de TFT "101 indique une 10 opération de suppression de filtres de paquets dans le TFT stocké, et les codes d'opération de TFT "110" et "111" indiquent des valeurs réservées, respectivement. Le GGSN 119 lit le champ "CODE D'OPERATION DE TFT" et effectue une opération correspondante.
Le champ "NOMBRE DE FILTRES DE PAQUETS" indique le nombre de filtres de paquets établis dans le TFT utilisé, c'est-à-dire le nombre de filtres de paquets qui existent dans une liste de filtres de paquets du TFT. Par exemple, lorsqu'une valeur de "010" est stockée pour le "code 20 d'opération de TFT", c'est-à-dire lorsque le TFT stocké est supprimé, une valeur du champ "NOMBRE DE FILTRES DE PAQUETS" est fixée à "0". Sauf dans le cas o le TFT stocké est supprimé, le nombre de filtres de paquets est supérieur à 0 et inférieur ou égal à 8, c'est-à-dire qu'on a 0 < 25 nombre de filtres de paquets < 8. La raison pour laquelle le nombre de filtres de paquets est supérieur à 0 et inférieur ou égal à 8 consiste en ce que le nombre maximal de filtres de paquets est de 8 dans le réseau d'infrastructure UMTS 200. L'information de TFT peut avoir depuis au moins un filtre de paquets jusqu'à un maximum de 5 8 filtres de paquets. Les filtres de paquets sont classés en un filtre de paquets à un seul champ, basé sur un seul contenu, et un filtre de paquets à champs multiples, basé sur des contenus multiples. Ici, le filtre de paquets à un seul champ correspond à un contenu à filtrer par ce filtre, 10 par exemple une adresse de source, tandis que le filtre de paquets à champs multiples correspond à de multiples contenus à filtrer par ce filtre, les multiples contenus incluant par exemple une adresse de source, un contenu de protocole, une adresse de destination, etc. Le champ "LISTE 15 DE FILTRES DE PAQUETS" indique un contenu associé à l'information de filtres de paquets qui est réellement utilisée, fixé dans le TFT.
Le TFT basé sur le format représenté sur la figure 3 est stocké dans le GGSN 119. Lorsque des données en mode 20 de paquets IP sont reçues à partir de l'Internet 121 externe, les données en mode de paquets IP sont filtrées par des filtres de paquets stockés dans le TFT. Ici, les données en mode de paquets IP filtrées par les filtres de paquets dans le TFT permettent à un TFT correspondant 25 d'utiliser un contexte de PDP stocké. Par conséquent, lorsque des données en mode de paquets IP d'entrée ne peuvent pas être appliquées au premier filtre de paquets dans le cas o trois filtres de paquets incluant les premier à troisième filtres de paquets existent à 30 l'intérieur du TFT, les données en mode de paquets IP d'entrée sont appliquées au second filtre de paquets. De cette manière, si les données en mode de paquets IP d'entrée ne peuvent pas être appliquées au dernier filtre de paquets, c'est-à-dire ne peuvent être appliquées à aucun 35 des filtres de paquets, les données en mode de paquets IP d'entrée utilisent un autre tunnel de GTP et l'opération de filtrage de paquets suivante est essayée en utilisant le TFT suivant au lieu du TFT associé à une opération de filtrage de paquets terminée.
Ensuite, on décrira en référence à la figure 4 une 5 procédure de génération de tunnel de GTP correspondant à une activation de contexte de PDP.
La figure 4 est un organigramme illustrant des messages générés dans la procédure de génération de tunnel de GTP correspondant à une activation de contexte de PDP 10 primaire.
Pour transmettre des données associées à un domaine de paquets UMTS, c'est-à-dire des données en mode de paquets, il est nécessaire de générer un tunnel de GTP pour transmettre les données en mode de paquets. Des itinéraires 15 pour générer le tunnel de GTP sont classés en un itinéraire correspondant au fait que l'UE 111 émet une demande vers le réseau d'infrastructure, c'est-à-dire une activation lancée par l'UE, et un itinéraire correspondant au fait que le réseau externe envoie une demande vers le réseau 20 d'infrastructure UMTS, c'est-à-dire une activation demandée par le réseau.
En se référant à la figure 4, on note que l'UE 111 détecte des données en mode de paquets générées et génère donc au moins un tunnel de GTP pour transmettre les données 25 en mode de paquets. L'UE 111 émet vers le SGSN 115 un message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP" pour générer le tunnel de GTP à l'étape 411. Le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP" contient des paramètres associés à un Identificateur de Point d'Accès de Service de 30 Couche Réseau (NSAPI pour "Network Layer Service Access Point Identifier"), un Identificateur de Transaction (TI pour "Transaction Identifier"), un type de PDP, une adresse de PDP, un Nom de Point d'Accès (APN pour "Access Point Name"), une Qualité de Service (QoS pour "Quality of 35 Service"), et autres.
Le NSAPI est une information générée par l'UE 111 et peut utiliser un total de 11 valeurs incluant des valeurs n' 5 à n0 15. Une valeur du NSAPI a une correspondance un à un avec une adresse de PDP et un ID de 5 contexte de PDP. L'adresse de PDP indique une adresse IP de l'UE 111 utilisée dans un domaine de paquets UMTS, et configure l'information de contexte de PDP. Ici, le contexte de PDP a divers éléments d'information du tunnel de GTP, et il est géré par l'ID de contexte de PDP. Le TI 10 est utilisé entre l'UE 111, l'UTRAN 113 et le SGSN 115.
Chaque tunnel de GTP est désigné comme une valeur spécifique pour indiquer des tunnels de GTP. Le TI et le NSAPI sont basés sur un concept presque identique, à l'exception du fait que le TI est utilisé entre l'UE 111, 15 l'UTRAN 114 et le SGSN 115, et le NSAPI est utilisé entre l'UE 111, le SGSN 115 et le GGSN 119. Le type de PDP indique un type d'un tunnel de GTP à générer par l'intermédiaire du message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP". Ici, des types de tunnels de GTP 20 comprennent des tunnels associés à un IP, un PPP (Protocole de Point à Point), un IP mobile, etc. Le nom de point d'accès indique un point d'accès d'un réseau de service auquel doit accéder au moment présent l'UE 111 effectuant une demande de génération de canal de GTP. Le paramètre QoS 25 indique la qualité de données en mode de paquets à transmettre à travers le tunnel de GTP généré au moment présent. En d'autres termes, les données en mode de paquets utilisant le tunnel de GTP ayant une QoS élevée sont traitées plus tôt que celles utilisant le tunnel de GTP 30 ayant une faible QoS.
Le SGSN 115 recevant le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP" émet un message "ETABLISSEMENT DE SUPPORT D'ACCES RADIO" vers l'UTRAN 113, de façon qu'un support d'accès radio entre le SGSN 115 et 35 l'UTRAN 113 puisse être établi à l'étape 413. En outre, l'UTRAN 113 envoie le message "ETABLISSEMENT DE SUPPORT D'ACCES RADIO" vers l'UE 111, de façon qu'un support d'accès radio entre l'UTRAN 113 et l'UE 111 puisse être établi à l'étape 413 ci-dessus. Lorsque le support d'accès radio entre le SGSN 115 et i'UTRAN 113 et le support 5 d'accès radio entre l'UTRAN 113 et l'UE 111 sont établis, l'assignation de ressources nécessaires pour transmettre des données en mode de paquets sur une interface hertzienne est achevée. Un message "APPEL DE TRACAGE" représenté sur la figure 4 sera décrit dans ce qui suit. Lorsqu'une 10 fonction de traçage est activée dans l'UTRAN 113, le SGSN transfère vers l'UTRAN 113 le message "APPEL DE TRACAGE", conjointement à une information de trace reçue d'un Enregistreur de Localisation Nominal (HLR pour "Home Location Registrer") (non représenté) ou d'un Centre 15 d'Exploitation et de Maintenance (OMC pour "Operation and Maintenance Center") (non représenté), à l'étape 415. Ici, la fonction de traçage est utilisée pour le traçage du flux de données.
Si le support d'accès radio entre le SGSN 115 et 20 l'UTRAN 113 est établi, le SGSN 115 émet un message "DEMANDE DE CREATION DE CONTEXTE DE PDP" vers le GGSN 119 à l'étape 417. A ce moment, de nouveaux Identificateurs de Points d'Extrémité de Tunnel (TEID pour "Tunnel Endpoint ID") sont fixés entre le SGSN 115 et le GGSN 119, et les 25 TEID sont fixés de façon que des données en mode de paquets puissent être transmises entre des noeuds de réseau en utilisant les tunnels de GTP. En d'autres termes, le SGSN 115 garde en mémoire le TEID du GGSN 119, et le GGSN 119 garde en mémoire le TIED du SGSN 115. Par conséquent, le 30 message "DEMANDE DE CREATION DE CONTEXTE DE PDP" contient le TEID à utiliser lorsque le GGSN 119 émet les données en mode de paquets vers le SGSN 115.
En réponse au message "DEMANDE DE CREATION DE CONTEXTE DE PDP", le GGSN 119 émet un message "REPONSE DE 35 CREATION DE CONTEXTE DE PDP" si la création d'un contexte de PDP est achevée de façon appropriée à l'étape 419. Par conséquent, la génération de tunnel de GTP entre le SGSN 115 et le GGSN 119 est achevée, et de ce fait des données en mode de paquets sont transmises. En réponse au message "REPONSE DE CREATION DE CONTEXTE DE PDP", le SGSN 115 émet 5 un message "ACCEPTATION D'ACTIVATION DE CONTEXTE DE PDP" vers l'UE 111 à l'étape 421. Lorsque l'UE 111 reçoit le message "ACCEPTATION D'ACTIVATION DE CONTEXTE DE PDP", un canal radio entre l'UE 111 et î'UTRAN 113 est généré, de façon qu'au moins un tunnel de GTP soit entièrement généré 10 entre l'UTRAN 113, le SGSN 115 et le GGSN 119. En d'autres termes, l'UE 111 peut émettre et recevoir tous les éléments de données en mode de paquets transférés à sa propre adresse. D'autre part, le tunnel de GTP généré dans les processus liés au contexte de PDP décrits ci-dessus a une 15 correspondance un à un avec un contexte de PDP. Du fait que des contextes de PDP sont différents si les tunnels de GTP sont différents, les contextes de PDP ont différents éléments d'information de tunnel.
Le processus de génération de tunnel de GTP 20 conforme à l'activation de contexte de PDP classique, c'est-à-dire la procédure d'activation de contexte de PDP primaire, a été décrit en référence à la figure 4. On va maintenant décrire en référence à la figure 5 un autre processus de génération de tunnel de GTP conformément à une 25 activation de contexte de PDP secondaire.
La figure 5 est un organigramme illustrant des messages qui sont générés dans le processus de génération de tunnel de GTP conforme à l'activation de contexte de PDP secondaire.
La procédure d'activation de contexte de PDP secondaire est un processus de génération d'au moins un tunnel de GTP par la réutilisation de l'information de tunnel de GTP du contexte de PDP primaire activé précédemment. En d'autres termes, le tunnel de GTP généré 35 par la procédure d'activation de contexte de PDP secondaire est appelé le tunnel de GTP secondaire. Le tunnel de GTP secondaire utilise l'information de contexte de PDP primaire telle quelle.
En se référant à la figure 5, on note que l'UE 111 émet un message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP 5 SECONDAIRE" vers le SGSN 115 pour générer le tunnel de GTP secondaire, à l'étape 511. Le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE" contient des paramètres associés à un NSAPI, un TI lié, un type de PDP, une adresse de PDP, un Nom de Point d'Accès ou APN ("Access Point 10 Name"), une QoS, etc. Ici, le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE", qui diffère du message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP", contient le TI lié et utilise l'information de contexte de PDP primaire activé précédemment, c'est-à-dire l'information de tunnel 15 de GTP primaire telle quelle. Du fait que le TI est utilisé pour indiquer des tunnels de GTP entre l'UE 111, l'UTRAN 113 et le SGSN 115, comme décrit ci-dessus en relation avec la figure 4, le TI lié est utilisé de façon qu'un ou plusieurs tunnels de GTP secondaires puissent utiliser la 20 même information que le tunnel de GTP primaire.
En réponse au message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE", le SGSN 115 émet un message "ETABLISSEMENT DE SUPPORT D'ACCES RADIO" vers l'UTRAN 113, de façon qu'un support d'accès radio entre l'UTRAN 113 et 25 le SGSN 115 puisse être établi à l'étape 513. L'UTRAN 113 émet le message "ETABLISSEMENT DE SUPPORT D'ACCES RADIO" vers l'UE 111, de façon qu'un support d'accès radio entre l'UTRAN 113 et l'UE 111 puisse être établi à l'étape 515.
Lorsque le support d'accès radio entre le SGSN 115 et 30 l'UTRAN 113 et le support d'accès radio entre l'UTRAN 113 et l'UE 111 sont établis, l'assignation de ressources nécessaires pour transmettre par radio des données en mode de paquets est achevée.
Si le support d'accès radio entre 1'UTRAN 113 et le 35 SGSN 115 est établi, le SGSN 115 émet un message "DEMANDE DE CREATION DE CONTEXTE DE PDP" vers le GGSN 119 à l'étape 517. A ce moment, le SGSN 115 émet un NSAPI primaire pour indiquer que des tunnels de GTP devant être générés sont des tunnels de GTP secondaires. Une valeur du NSAPI primaire a une correspondance une à une avec l'information 5 de contexte de PDP primaire activé précédemment. Par conséquent, l'information de contexte de PDP primaire peut être utilisée en faisant référence à la valeur de NSAPI primaire. En outre, le SGSN 115 émet le message "DEMANDE DE CREATION DE CONTEXTE DE PDP" contenant un TFT. Le but du 10 TFT est d'indiquer les tunnels de GTP primaire et secondaire. En d'autres termes, le TFT n'est pas stocké dans le tunnel de GTP primaire et le TFT est stocké seulement dans les tunnels de GTP secondaires. Comme dans le processus de génération de tunnel de GTP primaire, de 15 nouveaux TEID sont fixés entre le SGSN 115 et le GGSN 119, et les TEID sont fixés de façon que des données en mode de paquets puissent être transmises entre les noeuds de réseau sur les tunnels GTP. En d'autres termes, le SGSN 115 conserve en mémoire le TEID du GGSN 119, et le GGSN 119 20 conserve en mémoire le TEID du SGSN 115. Par conséquent, le message "DEMANDE DE CREATION DE CONTEXTE DE PDP" contient le TEID à utiliser lorsque le GGSN 119 émet les données en mode de paquets vers le SGSN 115.
Si une création de contexte de PDP est achevée de 25 façon appropriée en réponse au message "DEMANDE DE CREATION DE CONTEXTE DE PDP", le GGSN 119 émet un message "REPONSE DE CREATION DE CONTEXTE DE PDP" à l'étape 519. Par conséquent, la génération de tunnels de GTP secondaires entre le SGSN 115 et le GGSN 119 est achevée, et de ce fait 30 des données en mode de paquets peuvent être transmises sur des tunnels de GTP secondaires. En réponse au message "REPONSE DE CREATION DE CONTEXTE DE PDP", le SGSN 115 émet un message "ACCEPTATION D'ACTIVATION DE CONTEXTE DE PDP" vers l'UE 111 à l'étape 521. Lorsque l'UE 111 reçoit le 35 message "ACCEPTATION D'ACTIVATION DE CONTEXTE DE PDP", un canal radio entre l'UE 111 et l'UTRAN 113 est généré, de façon que le tunnel de GTP secondaire soit entièrement généré entre l'UTRAN 113, le SGSN 115 et le GGSN 119. En d'autres termes, l'UE peut émettre et recevoir tous les éléments de données en mode de paquets transférés à sa 5 propre adresse. D'autre part, un tunnel de GTP secondaire généré dans les processus liés au contexte de PDP décrits ci-dessus a une correspondance un à un avec un contexte de PDP.
On va maintenant décrire une opération de 10 traitement de TFT conformément aux codes d'opérations de TFT décrits en relation avec la figure 3. Premièrement, on va maintenant décrire un processus de création d'un nouveau TFT, en référence à la figure 6.
La figure 6 est un schéma synoptique illustrant 15 l'information de TFT nécessaire pour créer un nouveau TFT.
Lorsque le code d'opération de TFT est fixé à "001" comme décrit cidessus en relation avec la figure 3, le nouveau TFT est créé. D'autre part, un champ indiqué par "0" comme représenté sur la figure 6 est inutilisé, et ce 20 champ est non spécifié. Le champ non spécifié est fixé à "0". Le champ "LISTE DE FILTRES DE PAQUETS" représenté sur la figure 3 sera décrit en détail en référence à la figure 6. En se référant à la figure 6, on note que chaque champ "IDENTIFICATEUR DE FILTRE DE PAQUETS" contenu dans le champ 25 "LISTE DE FILTRES DE PAQUETS" est utilisé pour indiquer un filtre de paquets correspondant, parmi les filtres de paquets fixés dans le TFT. Comme décrit ci-dessus, du fait que le nombre maximal de filtres de paquets qui peuvent être fixés dans le TFT est de 8, à titre d'exemple, le 30 nombre maximal d'identificateurs (ID) de filtres de paquets est de 8. Sur la figure 6, les identificateurs de filtres de paquets sont exprimés par les bits 0 - 2, et les bits restants 4 - 7 sont inutilisés.
Ensuite, chaque champ "PRIORITE D'EVALUATION DE 35 FILTRE DE PAQUETS" contenu dans le champ "LISTE DE FILTRES DE PAQUETS" indique la priorité pour un filtre de paquets parmi tous les filtres de paquets fixés dans le TFT. En d'autres termes, le champ "PRIORITE D'EVALUATION DE FILTRE DE PAQUETS" indique l'ordre d'opérations de filtrage de paquets pour des données en mode de paquets reçues du 5 réseau externe. Plus la valeur du champ "PRIORITE D'EVALUATION DE FILTRE DE PAQUETS" est faible, plus la priorité du filtre de paquets pour les données en mode de paquets reçues du réseau externe est élevée. Si les données en mode de paquets sont reçues à partir du réseau externe, 10 un filtre de paquets ayant la plusfaible valeur du champ "PRIORITE D'EVALUATION DE FILTRE DE PAQUETS" parmi des filtres de paquets de TFT stockés dans le GGSN 119, est appliqué en premier aux données en mode de paquets. Lorsque le filtre de paquets ayant la plus faible valeur du champ 15 "PRIORITE D'EVALUATION DE FILTRE DE PAQUETS" ne concorde pas avec un en-tête des données en mode de paquets reçues, un filtre de paquets ayant la seconde plus faible valeur du champ "PRIORITE D'EVALUATION DE FILTRE DE PAQUETS" est appliqué aux données en mode de paquets reçues. Chaque 20 champ "LONGUEUR DE CONTENU DE FILTRE DE PAQUETS" qui est contenu dans le champ "LISTE DE FILTRES DE PAQUETS" indique la longueur du contenu de filtre de paquets correspondant.
Enfin, chaque champ "CONTENU DE FILTRE DE PAQUETS" qui est contenu dans le champ "LISTE DE FILTRES DE PAQUETS" 25 contient un identificateur (ID) de type de composant de filtre de paquets, et la longueur du contenu de filtre de paquets est variable. La longueur du champ "CONTENU DE FILTRE DE PAQUETS" est variable du fait que les longueurs de filtres de paquets sont différentes les unes des autres 30 et le nombre de filtres de paquets fixés dans le TFT est variable. Après que l'identificateur de type de composant de filtre de paquets a été utilisé une fois, il ne peut pas être utilisé pour tout autre filtre de paquets. Les filtres de paquets ne peuvent pas être configurés sur la base à la 35 fois d'un type correspondant à une adresse de source IP version 4 (IPv4) et d'un type correspondant à une adresse de source IP version 6 (IPv6) dans le TFT. Un type correspondant à un port de destination unique et un type correspondant à une plage de ports de destination ne peuvent pas être utilisés ensemble pour les filtres de 5 paquets. Les types de composants de filtres de paquets et les identificateurs de types de composants de filtres de paquets, décrits ci-dessus, sont indiqués dans le Tableau 2 suivant.
Tableau 2
Bits (76543210) Description
00010000 Type "Adresse de source IPv4" 00100000 Type "Adresse de source IPv6" 00110000 Type "Identificateur de Protocole / En-tête suivant" 01000000 Type "Port de destination unique" 01000001 Type "Plage de ports de destination" 01010000 Type "Port de source unique" 01010001 Type "Plage de ports de source" 01100000 Type "Index de paramètre de sécurité" 01110000 Type "Type de service / Classe de trafic" 10000000 Type "Etiquette de flux" Toutes les autres Réservé valeurs Comme indiqué dans le Tableau 2, un filtre de paquets consiste en une multiplicité de composants de filtre de paquets. Cependant, l'UMTS actuel n'utilise pas tous les types de filtres de paquets. Par exemple, une plage de ports de Protocole de Commande de Transmission / 15 Protocole de Datagramme d'Utilisateur (TCP/UDP pour "Transmission Control Protocol / User Datagram Protocol") est utilisée comme un composant de filtre de paquets, mais chaque port de TCP/UDP n'est pas utilisé comme le composant de filtre de paquets. La multiplicité de composants de 20 filtre de paquets peut configurer le filtre de paquets. Par exemple, un Equipement Terminal (TE pour "Terminal Equipment") peut classer des données en mode de paquets IPv6 ayant une plage de ports de TCP entre 4500 et 5000 à une adresse de "::172.168.8. 0/96", et peut configurer un filtre de paquets de façon à avoir: Identificateur de 5 Filtre de Paquets = 1; Adresse de Source IPv6 = {::172.168.8.0[FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:0:0]}; Numéro de Protocole TCP = 6; et Plage de Ports de Destination = 4500 à 5000. Une opération de classification de données en mode de paquets utilisant une multiplicité de paramètres 10 est appelée une classification multi-champ. On va maintenant décrire les types de composants de filtre de paquets.
Premièrement, on décrira le champ "type adresse de source IPv4" indiqué dans le Tableau 2 ci-dessus.
Le "type adresse de source IPv4" contient un champ d'adresse IPv4 à quatre octets et un champ de masque d'adresse IPv4 à quatre octets. Le champ d'adresse IPv4 est transmis en premier, avant le champ de masque d'adresse IPv4. Ici, une adresse IPv4 est exprimée avec 32 bits. Par 20 exemple, l'adresse IPv4 est exprimée sous la forme "10.2.10.3".
Il peut y avoir un cas dans lequel le champ d'adresse IPv4 ne peut pas être fixé dans le TFT transporté par un message de demande de contexte de PDP secondaire 25 utilisé pour accéder à un réseau de service associé à un Nom de Point d'Accès (APN pour "Access Point Name"), etc. En d'autres termes, lorsque le contexte de PDP secondaire est activé initialement, l'UE 111 reçoit une adresse IP sur un serveur de Service de Noms de Domaines (DNS pour "Domain 30 Name Service"), en relation avec un réseau de service auquel il a été accédé initialement. Du fait qu'un message d'activation de contexte de PDP secondaire à transférer est déjà dans un état d'attente, le contenu de filtre de paquets du TFT ne peut pas être changé. Du fait que l'UE 35 111 reconnaît une adresse IP d'un service correspondant reçue du serveur de DNS au prochain accès à la suite de l'accès initial, le contenu du filtre de paquets de TFT peut utiliser le champ "type adresse de source IPv4". En outre, si l'UE n'accède pas initialement à un nouveau réseau de service, mais émet le message de demande 5 d'activation de contexte de PDP secondaire pour communiquer avec un autre UE, le contenu du filtre de paquets basé sur le champ "type adresse de source IPv4" dans le TFT peut être utilisé.
Secondement, on décrira le champ "type adresse de 10 source IPv6" indiqué dans le Tableau 2. Le champ "type adresse de source IPv6" contient un champ d'adresse IPv6 à seize octets et un champ de masque d'adresse IPv6 à seize octets. Le champ d'adresse IPv6 est transmis en premier avant le champ de masque d'adresse IPv6. Une adresse IPv6 15 est exprimée sous la forme de 128 bits. Lorsque l'adresse IPv6 est utilisée, un système basé sur l'adresse IPv6 peut accepter le nombre d'abonnés correspondant à 296 fois le nombre d'abonnés pouvant être acceptés dans un système basé sur l'adresse IPv4 décrite ci-dessus. Du fait que le 20 système basé sur l'adresse IPv6 peut accepter davantage un grand nombre d'abonnés en comparaison avec le système basé sur l'adresse IPv4, l'utilisation de l'adresse IPv6 augmente.
On va maintenant décrire une structure de l'adresse 25 IPv6 en référence à la figure 7.
La figure 7 est un schéma synoptique illustrant l'adresse IPv6 classique.
En se référant à la figure 7, on note que l'adresse IPv6 est exprimée sous la forme de 128 bits, et une adresse 30 de noeud est exprimée sous la forme de 128 bits.
Le plus grave inconvénient associé à l'adresse IPv6 est que la longueur de l'adresse IPv6 est très grande. Par exemple, l'adresse IPv4 peut être exprimée sous la forme "10.2.10.3", tandis que l'adresse IPv6 est exprimée sous la 35 forme "ABCD:1234:EF12:5678:2456:9ABC". Du fait que l'adresse IPv6 est très longue, il est difficile pour des abonnés de se souvenir de l'adresse IPv6. En outre, il y a un autre problème consistant en ce qu'une forte charge du système et un coût supplémentaire se manifestent du fait qu'un processus de calcul pour les 128 bits est accompli en relation avec l'adresse IPv6.
On va maintenant décrire le champ "type Identificateur de protocole / Entête suivant" indiqué dans le Tableau 2. Le champ "type Identificateur de protocole / En-tête suivant" contient un identificateur de protocole à 10 un octet, indiquant par exemple "IPv4", ou un type En-tête suivant, indiquant par exemple "IPv6'. Le champ "type Port de destination unique" indiqué dans le Tableau 2 contient un numéro de port de destination à 2 octets. Une valeur du champ "type Port de destination unique" peut être une 15 valeur de port d'UDP ou de TCP, conformément à une valeur de champ de protocole d'un en-tête IP. Le champ "type Plage de ports de destination" indiqué dans le Tableau 2 contient un champ de limite inférieure de plage de ports de destination à 2 octets, et un champ de limite supérieure de 20 plage de ports de destination à 2 octets. Une valeur indiquée par le champ "type Plage de ports de destination" peut être une plage de ports d'UDP ou de TCP conformément à une valeur de champ de protocole d'un en-tête IP.
Le champ "type Port de source unique" indiqué dans 25 le Tableau 2 contient un numéro de port de source à 2 octets. Le numéro de port de source peut être une valeur de port d'UDP ou de TCP conformément à une valeur de champ de protocole d'un en-tête IP. Le champ "type Plage de ports de source" indiqué dans le Tableau 2 contient un champ de 30 limite inférieure de plage de ports de source à 2 octets et un champ de limite supérieure de plage de ports de source à 2 octets. Une valeur indiquée par le champ "type Plage de ports de source" peut être une plage de ports d'UDP ou de TCP conformément à la valeur de champ de protocole d'un en35 tête IP. Le champ "type Index de paramètre de sécurité" indiqué dans le Tableau 2 contient un Index de Paramètre de Sécurité (SPI pour "Security Parameter Index") IPSec à 4 octets. Le champ "type Type de service / Classe de trafic" indiqué dans le Tableau 2 ci-dessus contient un champ de Type de Service (IPv4) / Classe de Trafic (IPv6) à 1 octet, 5 et un champ de masque de Type de Service (IPv4) / masque de Classe de Trafic (IPv6). Enfin, le champ "type Etiquette de flux" contient une étiquette de flux IPv6 à trois octets.
Les bits 7 à 4 du premier octet sont inutilisés, et les 20 bits restants contiennent une étiquette de flux IPv6.
Le processus de création de nouveau TFT correspondant au code d'opération de TFT "001" a été décrit en référence à la figure 6. On décrira ensuite en référence à la figure 8 un processus de suppression d'un TFT stocké, correspondant au code d'opération de TFT "010", un 15 processus d'ajout de filtres de paquets au TFT stocké, correspondant au code d'opération de TFT "011", et un processus de remplacement de filtres de paquets dans le TFT stocké, correspondant au code d'opération de TFT "100".
La figure 8 est un schéma synoptique illustrant une 20 information de TFT nécessaire pour supprimer un TFT stocké, ajouter des filtres de paquets au TFT stocké ou remplacer des filtres de paquets dans le TFT stocké.
En se référant à la figure 8, on note qu'après qu'un champ "CODE D'OPERATION DE TFT" a été confirmé 25 indépendamment d'une liste de filtres de paquets lorsqu'un TFT est supprimé, le GGSN 119 supprime le TFT ayant un type de TFT qu'on désire supprimer, parmi les TFT stockés dans le GGSN 110, si le champ "CODE D'OPERATION DE TFT" indique "010" qui est une valeur représentant une suppression de 30 TFT fixée à l'avance. Lorsque des filtres de paquets sont ajoutés au TFT stocké, le processus d'ajout de filtres de paquets utilise la même information que le processus de suppression de TFT. Dans le processus d'ajout de filtres de paquets, le contenu d'une liste de filtres de paquets 35 correspondante est ajouté au TFT stocké. Lorsque des filtres de paquets dans le TFT stocké sont remplacés, le processus de remplacement de filtres de paquets utilise la même information que le processus de suppression de TFT et le processus d'ajout de filtres de paquets. Après que les filtres de paquets ont été retirés du TET stocké, le 5 contenu d'une liste de filtres de paquets correspondante est inséré.
Le processus de suppression d'un TFT stocké, correspondant au code d'opération de TFT "010", le processus d'ajout de filtres de paquets au TFT stocké, 10 correspondant au code d'opération de TFT "011", et le processus de remplacement de filtres de paquets dans le TFT stocké, correspondant au code d'opération de TFT "100", ont été décrits en référence à la figure 8. On décrira ensuite en référence à la figure 9 un processus de suppression de 15 filtres de paquets dans le TFT stocké, correspondant au code d'opération de TFT "101".
La figure 9 est un schéma synoptique illustrant l'information de TFT nécessaire pour supprimer des filtres de paquets du TFT stocké.
Comme représenté sur la figure 9, on considère seulement des identificateurs (ID) de filtres de paquets, indépendamment d'une liste de filtres de paquets, lorsque les filtres de paquets sont supprimés du TFT stocké. Le GGSN 119 supprime des filtres de paquets correspondant aux 25 ID de filtres de paquets contenus dans l'information de TFT reçue de l'UE 111, parmi les filtres de paquets du TFT stocké. La figure 9 montre le cas dans lequel un nombre N de filtres de paquets, comprenant les filtres allant d'un 1er filtre de paquets jusqu'à un N-ième filtre de paquets, 30 sont supprimés du TFT.
On décrira ensuite une opération de filtrage de paquets de TFT en référence à la figure 10.
La figure 10 est un schéma synoptique illustrant l'opération de filtrage de paquets de TFT d'un réseau 35 d'infrastructure UMTS classique.
Nous supposons que chaque TFT a seulement un seul filtre de paquets, pour la commodité de l'explication lorsqu'on décrit l'opération de filtrage de paquets de TFT en référence à la figure 10. Le GGSN 119 du réseau 5 d'infrastructure UMTS 200 stocke un total de quatre TFT, et chacun des TFT contient un seul filtre de paquets. Le fait que les quatre TFT soient stockés signifie que le GGSN 119 est couplé à cinq tunnels de GTP comprenant un tunnel de GTP primaire pour un contexte de PDP primaire et quatre 10 tunnels de GTP secondaires pour des contextes de PDP secondaires, conjointement au SGSN 115, et les cinq tunnels de GTP partagent le même contexte de PDP. Les cinq tunnels de GTP sont indiqués par les TFT.
Si l'opération de filtrage de paquets basée sur les 15 quatre TFT pour des données en mode de paquets reçues du réseau externe, par exemple l'Internet 121, ne réussit pas, les données en mode de paquets introduites à partir de l'Internet 121 sont transmises au SGSN 115 seulement par le tunnel de GTP primaire pour le contexte de PDP primaire. 20 Par exemple, si on suppose qu'un Type de Service (TOS pour "Type Of Service") est "0x30", un protocole est TCP, une Adresse de Source (SA pour "Source Address") est "1.1.1.1", une Adresse de Destination (DA pour "Destination Address") est "2.2.2.2", un numéro de Port de Source (SP pour "Source 25 Port") est "200" et un numéro de Port de Destination (DP pour "Destination Port") est "50", en relation avec les données en mode de paquets reçues de l'Internet 121, les données en mode de paquets ne concordent pas avec le contenu de filtre de paquets pour TFT 1 et TFT 2, ce qui 30 fait que l'opération de filtrage de paquets pour les données en mode de paquets n'est pas effectuée en relation avec les TFT 1 TFT 2. Cependant, du fait que les données en mode de paquets coïncident avec le contenu de filtre de paquets pour TFT 3, l'opération de filtrage de paquets pour 35 les données en mode de paquets est effectuée en relation avec le TFT 3, et un résultat de l'opération de filtrage de paquets est transmis au SGSN 115 à travers un tunnel de TGP correspondant au TFT 3. Les données en mode de paquets reçues de l'Internet 121 ne peuvent pas être filtrées en relation avec les TFT 1 et TFT 2, du fait que la SA 5 associée au contenu de filtre de paquets pour le TFT 1 est 3.3.3.3 et ne concorde pas avec la SA de "1.1.1.1" contenue dans les données en mode de paquets reçues, et du fait qu'un protocole associé au contenu de filtre de paquets pour le TFT 2 est le protocole Internet Control 10 Message Protocol (ICMP) et ne concorde pas avec le TCP qui est un protocole des données en mode de paquets reçues. En outre, les données en mode de paquets reçues de l'Internet 121 sont filtrées en relation avec le TFT 3 du fait que le TOS associé au contenu de filtre de paquets de TFT est 15 "0x30" et il concorde avec "0x30" qui est le TOS contenu dans les données en mode de paquets reçues.
Comme décrit ci-dessus, le TFT est généré en relation avec le contexte de PDP (ou tunnel de GTP) dans la procédure d'activation de contexte de PDP secondaire. Par 20 l'intermédiaire d'une procédure de modification de contexte de PDP lancée par 1'UE, l'UE 111 peut effectuer des opérations d'ajout / modification / suppression dans le contexte de PDP associé au TFT généré dans la procédure d'activation de contexte de PDP. Comme décrit ci-dessus, un 25 contexte de PDP a un seul TFT. Ici, lorsque l'UE 111 génère un nouveau TFT ou modifie un TFT stocké dans le GGSN 119, le TFT doit stocker au moins un filtre de paquets valide.
Si le filtre de paquets valide n'existe pas dans le TFT stocké, l'UE 111 est incapable d'accomplir la procédure de 30 modification de contexte de PDP lancée par l'UE. Le GGSN 119 émet, vers l'UE 111, un code d'erreur indiquant l'échec dans la procédure de modification de contexte de PDP lancée par l'UE pour le TFT. A ce moment, le TFT est supprimé si un contexte de PDP associé au TFT est désactivé.
Ensuite, on décrira en détail des adresses IP dans ce qui suit.
Les adresses IP sont classées en une adresse IPv4 et une adresse IPv6 conformément à des versions d'adresse.
Un réseau utilisant l'adresse IPv4 est appelé un "réseau IPv4", et un réseau utilisant l'adresse IPv6 est appelé un 5 "réseau IPv6". L'UMTS utilise une adresse IPv6 avec une adresse IPv4 incorporée, de façon qu'une communication IP puisse être effectuée entre le réseau IPv4 et le réseau IPv6. Ici, l'adresse IPv6 avec adresse IPv4 incorporée comprend une adresse IPv6 compatible avec IPv4 et une adresse IPv6 mappée en 10 IPv4. On va maintenant décrire l'adresse IPv6 compatible avec IPv4 et l'adresse IPv6 mappée en IPv4.
(1) Adresse IPv6 compatible avec IPv4 Une adresse IPv6 compatible avec IPv4 est utilisée sélectivement lorsqu'un réseau opposé peut supporter 15 l'adresse IPv6, une adresse IPv4 opposée ou de destination peut être reconnue, et une communication est effectuée à travers le réseau IPv6. On décrira en référence à la figure 11 un format de l'adresse IPv6 compatible avec IPv4.
La figure 11 est un schéma synoptique illustrant un 20 format de l'adresse IPv6 compatible avec IPv4 classique.
En se référant à la figure 11, on note que l'adresse IPv6 compatible avec IPv4 est exprimée sous la forme de 128 bits du fait que l'adresse IPv6 compatible avec IPv4 est fondamentalement une adresse IPv6. Une 25 adresse IPv4 est insérée dans 32 bits d'ordre inférieur de l'adresse IPv6 compatible avec IPv4. En d'autres termes, une adresse IPv4 de destination est insérée dans les 32 bits d'ordre inférieur de l'adresse IPv6 compatible avec IPv4, et des 0 sont insérés dans les 96 bits restants de 30 l'adresse IPv6 compatible avec IPv4.
On décrira en référence à la figure 12 l'architecture d'un réseau dans lequel l'adresse IPv6 compatible avec IPv4 est utilisée.
La figure 12 est un schéma synoptique illustrant 35 l'architecture d'un réseau dans lequel l'adresse IPv6 compatible avec IPv4 est utilisée.
En se référant à la figure 12, on note que des réseaux 1211 et 1213 utilisent à la fois une adresse IPv4 et une adresse IPv6. Lorsqu'une adresse de destination de données en mode de paquets à émettre est l'adresse IPv4, le 5 réseau 1211 insère une adresse IPv4 dans 32 bits d'ordre inférieur de l'adresse IPv6 compatible avec IPv4, comme représenté sur la figure 11, et émet l'adresse IPv6 compatible avec IPv4 vers le réseau 1213. Dans ce cas, le réseau 1213 reçoit les données en mode de paquets de 10 l'adresse IPv6 compatible avec IPv4 provenant du réseau 1211, et le réseau 1213 détecte l'adresse IPv4 contenue dans les 32 bits d'ordre inférieur de l'adresse IPv6 compatible avec IPv4. Ici, l'adresse IPv4 doit être spécifique, et une adresse IPv4 spécifique doit être 15 garantie. L'adresse IPv6 compatible avec IPv4 est exprimée de la façon suivante.
0:0:0:0:0:0:165.213.138.35 - ::165.213.138.35 L'adresse IPv6 compatible avec IPv4 contient l'adresse IPv4 insérée dans les 32 bits d'ordre inférieur 20 de l'adresse IPv6 compatible avec IPv4. De façon similaire, l'adresse IPv6 compatible avec IPv4 est une adresse spécifique.
(2) Adresse IPv6 mappée en IPv4 Une adresse IPv6 mappée en IPv4 est utilisée sélectivement lorsqu'un réseau opposé ne supporte pas une 25 adresse IPv6, mais la communication est effectuée en utilisant l'adresse IPv6. Un format de l'adresse IPv6 mappée en IPv4 sera décrit en référence à la figure 13.
La figure 13 est un schéma synoptique illustrant le format d'une adresse IPv6 mappée en IPv4 classique.
En se référant à la figure 13, on note que l'adresse IPv6 mappée en IPv4 est exprimée sous la forme de 128 bits du fait que l'adresse IPv6 compatible avec IPv4 est fondamentalement une adresse IPv6. Une adresse IPv4 est insérée dans 32 bits d'ordre inférieur de l'adresse IPv6 35 mappée en IPv4. En d'autres termes, une adresse IPv4 de destination est insérée dans les 32 bits d'ordre inférieur de l'adresse IPv6 mappée en IPv4, des 1 sont insérés dans 16 bits d'ordre supérieur de l'adresse IPv6 mappée en IPv4 à la suite des 32 bits d'ordre inférieur insérés de 5 l'adresse IPv4, et des 0 sont insérés dans les 80 bits restants de l'adresse IPv6 mappée en IPv4.
On décrira en référence à la figure 14 l'architecture d'un réseau dans lequel l'adresse IPv6 mappée en IPv4 est utilisée.
La figure 14 est un schéma synoptique illustrant l'architecture d'un réseau dans lequel l'adresse IPv6 mappée en IPv4 est utilisée.
En se référant à la figure 14, on note qu'un réseau 1411 utilise à la fois une adresse IPv4 et une adresse 15 IPv6, et un réseau 1413 utilise seulement une adresse IPv4.
Lorsqu'une adresse de destination de données en mode de paquets à émettre par le réseau 1411 est l'adresse IPv4, le réseau 1411 insère une adresse IPv4 dans 32 bits d'ordre inférieur de l'adresse IPv6 mappée en IPv4, comme dans 20 l'adresse IPv6 compatible avec IPv4 représentée sur la figure 13, et il émet vers le réseau 1413 l'adresse IPv6 mappée en IPv4. Dans ce cas, le réseau 1413 reçoit les données en mode de paquets de l'adresse IPv6 mappée en IPv4 provenant du réseau 1411, et le réseau 1413 détecte 25 l'adresse IPv4 contenue dans les 32 bits d'ordre inférieur de l'adresse IPv6 mappée en IPv4. Ici, l'adresse IPv6 mappée en IPv4 est exprimée de la façon suivante.
0:0:0:0:0:0:FFFF:165.213.138.35 - ::FFFF:165.213.138.35 L'adresse IPv6 mappée en IPv4 contient l'adresse 30 IPv4 insérée dans les 32 bits d'ordre inférieur de l'adresse IPv6 mappée en IPv4. L'adresse IPv6 mappée en IPv4 diffère de l'adresse IPv6 compatible avec IPv4 par le fait que "0xFFFF" est inséré dans 16 bits d'ordre supérieur de l'adresse IPv6 mappée en IPv4 à la suite des 32 bits 35 d'ordre inférieur de l'adresse IPv4 qui sont insérés.
En relation avec les types de composants de filtres de paquets de TFT décrits ci-dessus, on note qu'une adresse de source IPv4 représente une adresse à 32 bits utilisant l'adresse IPv4. Avec l'augmentation en progression 5 géométrique du nombre d'abonnés du système de communication mobile actuel, les adresses IPv6 seront largement utilisées, de façon que les adresses IP puissent être assignées de manière appropriée. Pour cette raison, des types de composants de filtres de paquets de TFT 10 nécessaires pour filtrer des données en mode de paquets associées aux adresses IPv6 ont été proposés. Cependant, du fait que l'adresse IPv6 est exprimée avec 128 bits, elle occasionne une charge notable en termes de calculs de bits, en comparaison avec l'adresse IPv4 exprimée avec 32 bits.
Des données en mode de paquets introduites dans le GGSN 119 à partir du réseau externe subissent des opérations de filtrage de paquets par des TFT stockés dans le GGSN 119, et les opérations de filtrage de paquets par les TFT sont effectuées séquentiellement à partir de la 20 priorité d'évaluation de filtre de paquets la plus basse jusqu'à la priorité d'évaluation de filtre de paquets la plus élevée, en relation avec un ou plusieurs filtres de paquets stockés dans chaque TFT. Par exemple, lorsque cinq TFT sont stockés dans le GGSN 119 et chacun des TFT stocke 25 quatre filtres de paquets, des données en mode de paquets reçues du réseau externe, c'est-à-dire l'Internet 121, subissent une opération de filtrage de paquets associée à quatre filtres de paquets du premier TFT parmi les cinq TFT. Ensuite, si l'opération de filtrage de paquets ne 30 réussit pas, les données en mode de paquets subissent une opération de filtrage de paquets associée à quatre filtres du second TFT parmi les cinq TFT. Lorsque le nombre de TFT stockés dans le GGSN 119 augmente de façon abrupte ou lorsqu'une quantité de données en mode de paquets reçues du 35 réseau externe 121 augmente de façon abrupte avant que l'opération de filtrage de paquets pour les données en mode de paquets réussisse, un calcul à 128 bits associé à l'adresse IPv6 dégrade les performances du filtrage de paquets de TFT. Les performances de filtrage de paquets dégradées peuvent affecter défavorablement le réseau d'infrastructure UMTS.
Par conséquent, la présente invention a été faite et un but de la présente invention est de procurer un appareil et un procédé pour effectuer un filtrage de paquets par Modèle de Flux de Trafic (TFT pour "Traffic 10 Flow Template") conformément aux versions d'IP d'adresses IP dans un système de communication mobile.
Un autre but de la présente invention est de procurer un appareil et un procédé pour effectuer un filtrage de paquets par TFT utilisant une information 15 utilisée en commun dans des adresses IP basées sur différentes versions d'IP dans un système de communication mobile.
Un autre but encore de la présente invention est de procurer un appareil et un procédé pour effectuer un 20 filtrage de paquets par TFT, qui puisse minimiser un volume de calcul exigé pour effectuer le filtrage de paquets conformément aux versions d'IP d'adresses IP associées à des données d'entrée en mode de paquets dans un système de communication mobile.
Conformément à un premier mode de réalisation de la présente invention, les buts ci-dessus, ainsi que d'autres, peuvent être atteints par un appareil pour effectuer un filtrage par TFT conformément à des versions de Protocole Internet (IP) dans un système de communication mobile qui 30 est capable de supporter une adresse d'une première version d'IP consistant en premiers bits et une adresse d'une seconde version d'IP consistant en seconds bits contenant les premiers bits. L'appareil comprend une unité de commande pour extraire les premiers bits de l'adresse de la 35 première version d'IP à partir de l'adresse de la seconde version d'IP, lorsqu'une information de TFT est reçue et l'information de TFT reçue correspond à l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, et pour générer une nouvelle information de TFT à partir des premiers bits extraits de 5 l'adresse de la première version d'IP; et une mémoire pour stocker l'information de TFT reçue, comme la nouvelle information de TFT.
Conformément à un second mode de réalisation de la présente invention, les buts ci-dessus, ainsi que d'autres, 10 peuvent être atteints par un appareil pour effectuer un filtrage par TFT conformément à des versions d'IP dans un système de communication mobile, qui est capable de supporter une adresse d'une première version d'IP consistant en premiers bits et une adresse d'une seconde 15 version d'IP consistant en seconds bits contenant les premiers bits. L'appareil comprend un Equipement d'Utilisateur (UE) pour extraire les premiers bits de l'adresse de la première version d'IP, à partir de l'adresse de la seconde version d'IP, lorsqu'une adresse IP 20 de source est l'adresse de la seconde version d'IP dans laquelle lapremière adresse IP est insérée, pour générer une information de TFT à partir des premiers bits extraits de l'adresse de la première version d'IP, et pour émettre l'information de TFT générée vers un Noeud de Support GPRS 25 (General Packet Radio Service) de Passerelle, GGSN; et le GGSN pour stocker l'information de TFT reçue de 1'UE, pour extraire les premiers bits représentant l'adresse de la première version d'IP, à partir de l'adresse de la seconde version d'IP, lorsqu'une adresse IP de données en mode de 30 paquets reçue correspond à la seconde version d'IP et l'adresse IP est l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, et pour effectuer le filtrage de paquets par TFT en utilisant les premiers bits extraits des données en mode de 35 paquets reçues.
Conformément à l'autre mode de réalisation de la présente invention, les buts ci-dessus, ainsi que d'autres, peuvent être atteints par un procédé pour effectuer un filtrage par TFT conformément à des versions d'IP dans un 5 système de communication mobile capable de supporter une adresse d'une première version d'IP consistant en premiers bits et une adresse d'une seconde version d'IP consistant en seconds bits contenant les premiers bits. Le procédé comprend les étapes suivantes: lorsqu'une information de 10 TFT est reçue et l'information de TFT reçue correspond à l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, on extrait les premiers bits de l'adresse de la première version d'IP, à partir de l'adresse de la seconde version 15 d'IP; on génère une nouvelle information de TFT à partir des premiers bits extraits de l'adresse de la première version d'IP; lorsqu'une adresse IP de données en mode de paquets reçues correspond à la seconde version d'IP et l'adresse IP est l'adresse de la seconde version d'IP dans 20 laquelle l'adresse de la première version d'IP est insérée, on extrait les premiers bits représentant l'adresse de la première version d'IP, à partir de l'adresse de la seconde version d'IP; et on effectue le filtrage de paquets par TFT en utilisant les premiers bits extraits des données en mode 25 de paquets reçues.
Conformément à un mode de réalisation supplémentaire de la présente invention, les buts ci-dessus, ainsi que d'autres, peuvent être atteints par un procédé pour effectuer un filtrage par TFT conformément à des versions 30 d'IP dans un système de communication mobile capable de supporter une adresse d'une première version d'IP consistant en premiers bits, et une adresse d'une seconde version d'IP consistant en seconds bits contenant les premiers bits. Le procédé comprend les étapes suivantes: 35 lorsqu'une adresse IP de source est la seconde adresse IP dans laquelle l'adresse de la première version d'IP est insérée, on permet à un Equipement d'Utilisateur (UE) d'extraire les premiers bits de l'adresse de la première version d'IP, à partir de l'adresse de la seconde version d'IP; on permet à l'UE de générer un contenu de filtre de 5 paquets à partir des premiers bits extraits de l'adresse de la première version d'IP, de générer une information de TFT contenant le contenu de filtre de paquets, et d'émettre l'information de TFT générée vers un Noeud de Support GPRS (General Packet Radio Service) de Passerelle (GGSN); on 10 permet au GGSN de stocker l'information de TFT reçue à partir de l'UE et d'extraire les premiers bits représentant l'adresse de la première version d'IP, à partir de l'adresse de la seconde version d'IP, lorsqu'une adresse IP de données en mode de paquets reçue correspond à la seconde 15 version d'IP et l'adresse IP est l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée; et on permet au GGSN d'effectuer le filtrage de paquets par TFT en utilisant les premiers bits extraits des données en mode de paquets reçues.
D'autres caractéristiques et avantages de l'invention seront mieux compris à la lecture de la description détaillée qui va suivre de modes de réalisation, donnés à titre d'exemples non limitatifs. La suite de la description se réfère aux dessins annexés, dans 25 lesquels: la figure 1 est un schéma synoptique illustrant l'architecture d'un réseau Universal Mobile Telecommunication System (UMTS) classique; la figure 2 est un schéma synoptique illustrant un 30 réseau d'infrastructure UMTS basé sur un Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") classique; la figure 3 est un schéma synoptique illustrant un format du TFT classique; la figure 4 est un organigramme illustrant des 35 messages générés dans un processus de génération de tunnel du Protocole de Génération de Tunnel GPRS (General Packet Radio Service) (GTP pour "GPRS Tunnelling Protocol"), conformément à une activation de contexte de Protocole de Données en Mode de Paquets (PDP pour "Packet Data Protocol") primaire; la figure 5 est un organigramme illustrant des messages générés dans un processus de génération de tunnel de GTP conformément à l'activation de contexte de PDP secondaire; la figure 6 est un schéma synoptique illustrant le 10 format d'un nouveau TFT; la figure 7 est un schéma synoptique illustrant le format d'une adresse IPv6 classique; la figure 8 est un schéma synoptique illustrant l'information de TFT nécessaire pour supprimer un TFT 15 stocké, ajouter des filtres de paquets au TFT stocké ou remplacer des filtres de paquets dans le TFT stocké; la figure 9 est un schéma synoptique illustrant l'information de TFT nécessaire pour supprimer des filtres de paquets dans le TFT stocké; la figure 10 est un schéma synoptique illustrant une opération de filtrage de paquets par TFT effectuée par le réseau d'infrastructure UMTS classique; la figure Il est un schéma synoptique illustrant le format d'une adresse IPv6 compatible avec IPv4 classique; la figure 12 est un schéma synoptique illustrant l'architecture d'un réseau dans lequel l'adresse IPv6 compatible avec IPv4 est utilisée; la figure 13 est un schéma synoptique illustrant le format d'une adresse IPv6 mappée en IPv4 classique; la figure 14 est un schéma synoptique illustrant l'architecture d'un réseau dans lequel l'adresse IPv6 mappée en IPv4 est utilisée; la figure 15 est un schéma synoptique illustrant l'architecture d'un réseau UMTS pour accomplir une fonction 35 conformément à un mode de réalisation de la présente invention; la figure 16 est un schéma synoptique illustrant la structure interne d'un dispositif de filtrage de paquets par TFT pour accomplir une fonction conformément à un mode de réalisation de la présente invention; la figure 17 est une représentation illustrant une information de TFT stockée dans une table de TFT 1651 représentée sur la figure 16; les figures 18A et 18B sont des organigrammes illustrant une opération de filtrage de paquets par TFT 10 lorsqu'un procédé de type adresse source IPv6 est utilisé; les figures 19A et 19B sont des organigrammes illustrant une opération de filtrage de paquets par TFT lorsqu'un procédé de type adresse source IPv6 avec adresse IPv4 incorporée est utilisé; la figure 20 est un schéma synoptique illustrant une opération de filtrage de paquets par TFT générale, exécutée par une procédure de filtrage de paquets par TFT 1611 représentée sur la figure 16; la figure 21 est un schéma synoptique illustrant 20 une opération de filtrage de paquets par TFT utilisant le procédé de type adresse de source IPv6 exécuté par la procédure de filtrage de paquets par TFT 1611 représentée sur la figure 16; la figure 22 est un schéma synoptique illustrant 25 une opération de filtrage de paquets par TFT utilisant le procédé de type adresse source IPv6 avec adresse IPv4 incorporée, exécuté par la procédure de filtrage de paquets par TFT 1611 représentée sur la figure 16; la figure 23 est un tableau illustrant un volume de 30 calcul sur des bits conformément à une opération de filtrage de paquets par TFT lorsque le procédé de type adresse de source IPv6 et le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée sont utilisés, en comparaison avec un volume de calcul sur des bits conformément 35 à l'opération de filtrage de paquets par TFT générale, d'après un mode de réalisation de la présente invention; et la figure 24 est un organigramme illustrant un processus de génération de filtre de paquets par TFT lorsque le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée est utilisé.
Dans la description suivante de modes de réalisation de la présente invention, on décrira seulement des fonctions et des configurations nécessaires à la compréhension de la présente invention. En outre, une description détaillée de fonctions et de configurations 10 connues incorporées ici sera omise, pour la concision.
La figure 15 est un schéma synoptique illustrant l'architecture d'un réseau Universal Mobile Telecommunication System (UMTS) pour accomplir une fonction conformément à un mode de réalisation de la présente invention.
En se référant à la figure 15, on note que le réseau UMTS comprend un réseau IPv6 1500 utilisant une adresse Internet Protocol (IP) version 6 (IPv6), un réseau IPv4 1550 utilisant une adresse IP version 4 (IPv4), et un réseau IPv6 1570 utilisant une adresse IPv6. On décrira à 20 titre d'exemple le réseau IPv6 1500 contenu dans le réseau UMTS.
Premièrement, un Equipement d'Utilisateur (UE) 1511 couplé à un Réseau d'Accès Radio Terrestre UMTS (UTRAN) 1513 traite un appel et supporte à la fois un Service de 25 Circuits (SC) et un Service de Paquets (PS). L'UE 1511 est un UE à double mode capable de supporter à la fois l'adresse IPv4 et l'adresse IPv6, conformément à un mode de réalisation de la présente invention. L'UE 1511 configure une information de Modèle de Flux de Trafic (TFT), comme 30 mentionné au paragraphe ci-dessus concernant la description de l'art antérieur. Conformément à un mode de réalisation de la présente invention, l'UE 1511 génère au moins un filtre de paquets par TFT utilisant la totalité ou une partie de l'adresse IP. On décrira en détail une procédure 35 de génération du filtre de paquets par TFT utilisant la totalité ou une partie de l'adresse IP.
L'UTRAN 1513 est configuré par au moins un Node-B (non représenté) et au moins un Contrôleur de Réseau Radio (RNC) (non représenté). Le Node-B est couplé à l'UE 1511 sur une interface Uu, et le RNC est couplé à un Noeud de 5 Support GPRS de Desserte (SGSN) 1515 sur une interface Iu.
Un service General Packet Radio Service (GPRS) est un service de données en mode de paquets fourni par le réseau UMTS. L'UTRAN 1513 accomplit une opération de conversion de protocole pour transférer vers un Réseau d'Infrastructure 10 (CN pour "Core Network") des messages de commande ou de données radio, reçus par radio, en utilisant un Protocole de Génération de Tunnel GPRS (GTP pour "GPRS Tunnelling Protocol"). Ici, le CN est considéré comme un ensemble du SGSN 1515 et d'un GGSN 1519.
Le SGSN 1515 est un noeud de réseau pour gérer de l'information d'abonnés et de l'information d'emplacements de l'UE 1511. Le SGSN 1515 est couplé à l'UTRAN 1513 sur l'interface Iu et est couplé au GGSN 1519 sur une interface Gn, de façon que des messages de données et de commande 20 soient émis et reçus. Le SGSN 1515 est couplé à un Enregistreur de Localisation Nominal (HLR) 1517 sur une interface Gr pour gérer l'information d'abonné et l'information d'emplacement.
Le HLR 1517 stocke de l'information d'abonnés et de 25 l'information de routage associées à un domaine de paquets, etc. Le HLR 1517 est couplé au SGSN 1515 sur l'interface Gr, et est couplé au GGSN 1519 sur une interface Gc. Bien entendu, le HLR 1517 peut être placé à l'intérieur d'un Réseau Mobile Terrestre Public (PLMN pour "Public Land 30 Mobile Network") lorsqu'on considère l'itinérance de l'UE 1511. Le GGSN 1519 correspond à un point d'extrémité associé au GTP dans le réseau UMTS, et le GGSN 1519 est couplé à un réseau externe sur une interface Gi et peut être exploité en interopération avec l'Internet, un Réseau 35 de Domaine de Paquets (PDN) ou un PLMN. Le réseau IPv6 1500 est couplé au réseau IPv4 1550 à travers la première passerelle de frontière 1520. La première passerelle de frontière 1520 placée à un point d'extrémité du réseau IPv6 1500 accomplit une fonction de filtrage de messages, une fonction de Traduction d'Adresse de Réseau (NAT pour "Network Address Translation"), etc. Conformément à ce mode de réalisation de la présente invention, la première passerelle de frontière 1520 transfère vers la seconde passerelle de frontière 1530 des données en mode de paquets reçues du réseau IPv6 1500. 10 Ici, les données en mode de paquets reçues du réseau IPv6 1500 ont une adresse IPv6, mais le réseau IPv4 1550 couplé à la seconde passerelle de frontière 1530 supporte seulement une adresse IPv4. Par conséquent, la première passerelle de frontière 1520 extrait une adresse IPv6 à 32 15 bits d'ordre inférieur des données en mode de paquets reçues du réseau IPv6 1500, pour générer un en-tête IPv4.
La première passerelle de frontière 1520 ajoute aux données en mode de paquets l'en-tête IPv4 généré, pour émettre les données en mode de paquets vers le réseau IPv4 1550. Comme 20 décrit au paragraphe ci-dessus concernant la description de l'art antérieur, l'UMTS utilise une adresse IPv6 avec une adresse IPv4 incorporée de façon à pouvoir effectuer une communication IP entre le réseau IPv4 et le réseau IPv6.
Ici, l'adresse IPv6 avec l'adresse IPv4 incorporée comprend 25 une adresse IPv6 compatible avec IPv4 et une adresse IPv6 mappée en IPv4. Le réseau IPv4 1550 supprime l'en-tête IPv4 dans les données en mode de paquets qui sont reçues de la seconde passerelle de frontière 1530, et transfère, à travers la troisième passerelle de frontière 1540, des 30 données en mode de paquets desquelles l'en-tête IPv4 a été supprimé. Dans ce cas, la troisième passerelle de frontière 1540 transfère les données en mode de paquets à travers la quatrième passerelle de frontière 1560. Ensuite, le réseau IPv6 1570 reçoit des données en mode de paquets ayant 35 l'adresse IPv6. Conformément à la description ci-dessus, on a décrit la procédure consistant à transmettre vers l'extérieur les données en mode de paquets provenant du réseau IPv6 1500. Lorsque le réseau IPv6 1500 reçoit les données en mode de paquets arrivant d'un réseau externe, le paquet est encapsulé ou décapsulé conformément à des 5 versions d'adresse IP. Dans ce qui suit, les données en mode de paquets ayant une adresse IPv4 sont appelées "données de paquets IPv4", et les données en mode de paquets ayant une adresse IPv6 sont appelées "données de paquets IPv6", pour la commodité de l'explication.
En outre, la seconde passerelle de frontière 1530 accomplit une fonction d'un routeur de limite pour le réseau IPv4 1550 et accomplit également une fonction de routeur IPv4 général. La troisième passerelle de frontière 1540 accomplit une fonction d'un routeur de frontière du 15 réseau IPv4 1550 et accomplit également une fonction de routeur IPv4 général. La quatrième passerelle de frontière 1560 accomplit une fonction d'un routeur de limite pour le réseau IPv6 1570 et accomplit la même fonction que la première passerelle de frontière 1520. Un serveur IPv4 / 20 IPv6 1580 est un serveur à double mode capable d'accepter à la fois les données de paquets IPv4 et les données de paquets IPv6. Le serveur IPV4 / IPv6 1580 utilise une adresse IPv6 compatible avec IPv4 ou une adresse IPv6 mappée en IPv4 pour communiquer avec l'UE 1511 du réseau 25 UMTS, par l'intermédiaire du réseau IPv4 1550.
On décrira en référence à la figure 16 la structure interne d'un dispositif de filtrage de paquets par TFT pour accomplir une fonction conforme à un mode de réalisation de la présente invention.
La figure 16 est un schéma synoptique illustrant la structure interne du dispositif de filtrage de paquets par TFT pour accomplir une fonction conforme au mode de réalisation de la présente invention.
En se référant à la figure 16, on note que le 35 dispositif de filtrage de paquets par TFT comprend une Unité Centrale de Traitement (UC) 1600, une Mémoire Vive (RAM) 1650 et un module de Segmentation et Réassemblage (SAR) 1670, et un duplexeur 1690. L'UC 1600 traite des données de paquets qui arrivent du réseau externe, c'est-àdire l'Internet, à travers l'interface Gi du GGSN, et 5 accomplit une opération de commande d'ensemble associée à une opération de calcul mathématique, une opération d'ordonnancement, une opération de gestion de tâches, etc. Conformément à un mode de réalisation de la présente invention, l'UC 1600 gère une tâche de Bloc de Tranches de 10 Service de Paquets (PSSB pour "Packet Service Slice Block") 1610. Une région hachurée indiquée sur la figure 16 représente une tâche de Communication Inter-Processus S (SIPC pour "S Inter Process Communication"). Du fait que la tâche SIPC n'est pas directement associée à la présente 15 invention, une description détaillée de la tâche SIPC sera omise. Ici, la tâche PSSB 1610 reçoit des données de paquets de GTPu transférées à travers un tunnel de GTP, ou reçoit des données de paquets IP provenant du réseau externe, par exemple l'Internet, et effectue divers 20 processus de protocole.
La tâche PSSB 1610 comprend une procédure de filtrage de paquets par TFT 1611 et un processeur de paquets 1613. La procédure de filtrage de paquets par TFT 1611 accomplit un filtrage de paquets associé aux TFT. Le 25 processeur de paquets 1613 traite un paquet correspondant à un résultat du filtrage de paquets par TFT, accompli par la procédure de paquets de TFT 1611. La mémoire vive 1650 contient une table de TFT 1651 et une table de ressources 1653. La table de TFT 1651 stocke de l'information associée 30 aux TFT stockés dans le GGSN. La procédure de filtrage de paquets par TFT 1611 fait référence à la table de TFT 1651 associée aux données de paquets qui arrivent du GGSN et effectue le filtrage de paquets. Ici, des filtres de paquets par TFT stockés dans la table de TFT 1651 utilisent 35 une adresse IPv6 compatible avec IPv4 et une adresse IPv6 mappée en IPv4, et conservent donc une adresse IPv4 à 32 bits, conformément à un mode de réalisation de la présente invention. Ici, l'adresse IPv6 compatible avec IPv4 est utilisée sélectivement lorsqu'un réseau opposé peut supporter l'adresse IPv6, une adresse IPv4 opposée ou de 5 destination peut être reconnue, et une communication est effectuée à travers le réseau IPv6. L'adresse IPv6 mappée en IPv4 est utilisée sélectivement lorsque le réseau opposé ne supporte pas une adresse IPv6, mais une communication est effectuée en utilisant l'adresse IPv6.
Le module SAR 1670 réassemble des cellules de Mode de Transfert Asynchrone (ATM) reçues du réseau externe, et transfère les cellules ATM réassemblées vers un chemin IN à l'intérieur de la tâche PSSB 1610. Le module SAR 1670 segmente des données de paquets à transférer à partir du 15 GGSN vers le réseau externe, c'est-à-dire des données de paquets à transférer par les chemins IN, P et S de la tâche PSSB 1610, en unités de cellules ATM, et émet vers le duplexeur 1690 les données de paquets segmentées. Le duplexeur 1690 reçoit sélectivement des données de paquets 20 provenant du réseau externe et émet des données de paquets provenant du GGSN vers tous les blocs fonctionnels couplés physiquement au duplexeur 1690.
Le dispositif de filtrage de paquets par TFT représenté sur la figure 16 doit considérer une procédure 25 d'activation de contexte de PDP secondaire et une procédure de stockage d'information de TFT, pour que le filtrage de paquets par TFT pour les données de paquets entrantes puisse être effectué. On va décrire la procédure d'activation de contexte de PDP secondaire et le processus 30 de stockage d'information de TFT à considérer pour le filtrage de paquets par TFT. Les architectures du réseau UMTS et du CN (Réseau d'Infrastructure) sont presque identiques à celles des figures 1 et 2 envisagées au paragraphe ci-dessus concernant la description de l'art 35 antérieur. Seul le dispositif de filtrage de paquets par TFT conforme au mode de la présente invention est basé sur une architecture différenciée. On suppose que la présente invention utilise une adresse IPv6 compatible avec IPv4 et une adresse IPv6 mappée en IPv4, qui sont des adresses IPv6 avec adresse IPv4 incorporée. Par conséquent, les filtres 5 de paquets par TFT accomplissent des opérations de filtrage de paquets par TFT en utilisant seulement l'adresse IPv4 contenue dans l'adresse IPv6 avec l'adresse IPv4 incorporée. Il faut noter que des procédures d'activation de contextes de Protocole de Données de Paquets (PDP), 10 c'est-à-dire un contexte de PDP primaire et des contextes de PDP secondaires, sont les mêmes que les procédures représentées sur les figures 4 et 5.
Pour que le filtrage de paquets par TFT soit accompli conformément au mode de réalisation de la présente 15 invention, la procédure d'activation de contexte de PDP secondaire doit être accomplie en premier. La procédure d'activation de contexte de PDP secondaire doit être accomplie du fait que des TFT sont générés dans la procédure d'activation de contexte de PDP secondaire et non 20 dans la procédure d'activation de contexte de PDP primaire.
En se référant aux figures 5 et 15, on note que l'UE 1511 émet un message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE" vers le SGSN 1515, et le SGSN 1515 émet un message "DEMANDE DE CREATION DE CONTEXTE DE PDP" vers le 25 GGSN 1519, de façon que la procédure d'activation de contexte de PDP secondaire soit lancée. Comme décrit en relation avec la figure 5, une information de TFT est générée dans l'UE 1511, et le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE" contenant l'information de 30 TFT est transféré vers le GGSN 1519. Ensuite, le GGSN 1519 active des contextes de PDP secondaires en utilisant l'information de TFT contenue dans le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE" et génère des tunnels de GTP secondaires, de façon que des données de 35 paquets qui arrivent du réseau externe à travers les tunnels de GTP secondaires puissent être traitées.
Ensuite, la procédure de stockage d'information de TFT doit être accomplie pour que le filtrage de paquets de TFT soit accompli conformément à la présente invention.
Comme décrit ci-dessus, l'information de TFT 5 transférée à partir de l'UE 1511 est stockée dans le GGSN 1519. A ce moment, des éléments d'information nécessaires de l'information de TFT, comme le nombre de filtres de paquets, les contenus de filtres de paquets, etc., sont stockés de façon que le filtrage de paquets par TFT pour 10 des données de paquets arrivant du réseau externe puisse être effectué. En d'autres termes, l'information de TFT est contenue dans le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE", et est transférée au SGSN 1515. En outre l'information de TFT est contenue dans le message 15 "DEMANDE DE CREATION DE CONTEXTE DE PDP", et est transférée au GGSN 1519. Le GGSN 1519 extrait et stocke seulement l'information de TFT nécessaire.
Dans le mode de réalisation de la présente invention, deux procédés de stockage de l'information de 20 TFT sont proposés dans ce qui suit.
(1) Procédé de type adresse de source IPv6 Comme décrit ci-dessus, l'information de TFT générée par l'UE 1511 est stockée dans le GGSN 1519. Le GGSN 1519 extrait l'information de TFT nécessaire de 25 l'information qui est émise par l'UE 1511, et stocke l'information extraite comme l'information de TFT. En d'autres termes, le GGSN 1519 stocke l'information de TFT configurant le nombre de filtres de paquets, les contenus de filtres de paquets, etc., de façon que le filtrage de 30 paquets par TFT puisse être effectué aisément. A ce moment, lorsque des filtres de paquets par TFT correspondent à un type adresse de source IPv6, et un coefficient de filtre correspondant correspond à une adresse IPv6 avec adresse IPv4 incorporée, le GGSN 1519 ne stocke pas une valeur 35 d'adresse à 128 bits et une valeur de masque à 128 bits associées à l'adresse IPv6 avec adresse IPv4 incorporée, sélectionne 32 bits d'ordre inférieur indiquant une adresse IPv4 de l'adresse IPv6 avec adresse IPv4 incorporée, et stocke seulement une valeur d'adresse à 32 bits et une valeur de masque à 32 bits, pour l'information de TFT. Les 5 filtres de paquets par TFT sont basés sur un type adresse de source IPv6, mais des coefficients de filtres stockés dans les filtres de paquets par TFT sont basés sur un format d'adresse IPv4.
Le GGSN 1519 stocke l'information de TFT en 10 utilisant seulement l'information nécessaire dans l'information de TFT contenue dans le message "DEMANDE D'ACTIVATION DE CONTEXTE DE PDP SECONDAIRE" émis par l'UE 1511. L'information de TFT stockée dans le GGSN 1519, c'est-à-dire l'information de TFT stockée dans la mémoire 15 vive 1650 du dispositif de filtrage de paquets par TFT, sera décrite en référence à la figure 17.
La figure 17 est un schéma synoptique illustrant l'information de TFT stockée dans la table de TFT 1651 représentée sur la figure 16.
En se référant à la figure 17, on note que l'information de TFT est classée en un champ "NOMBRE DE FILTRES DE PAQUETS" 1711, en champs "IDENTIFICATEUR DE FILTRE DE PAQUETS" 1713, 1723, 1733, 1743 et 1753, en champs "PRIORITE D'EVALUATION DE FILTRE DE PAQUETS" (non 25 représentés), et en champs "CONTENU DE FILTRE DE PAQUETS" 1715, 1725, 1735, 1745 et 1755. Le champ "NOMBRE DE FILTRES DE PAQUETS3 1711 indique le nombre de filtres de paquets stockés dans un TFT correspondant. Les champs "IDENTIFICATEUR DE FILTRE DE PAQUETS" 1713, 1723, 1733, 30 1743 et 1753 indiquent des identificateurs (ID) de filtre de paquets pour indiquer les filtres de paquets stockés dans le TFT. Les champs "IDENTIFICATEUR DE FILTRE DE PAQUETS" 1713, 1723, 1733, 1743 et 1753 ont une correspondance un à un avec les champs "PRIORITE D'EVALUA35 TION DE FILTRE DE PAQUETS" (non représentés) ou les champs "CONTENU DE FILTRE DE PAQUETS" 1715, 1725, 1735, 1745 et 1755. Les champs décrits ci-dessus sont stockés sur la base de la correspondance un à un. L'information de TFT stockée représentée sur la figure 17 est de l'information de TFT générale, c'est-à-dire de l'information nécessaire pour le 5 filtrage de paquets par TFT sélectionnée séparément de l'information de TFT représentée sur la figure 6. Du fait que le filtrage de paquets par TFT associé à l'adresse IPv6 avec adresse IPv4 incorporée est effectué conformément au mode de réalisation de la présente invention, des contenus 10 d'adresses de source et de destination sont considérés comme importants.
Par exemple, lorsque l'adresse IPv6 avec adresse IPv4 incorporée est "::3. 2.2.1" et le type de protocole est UDP dans le premier champ "CONTENU DE FILTRE DE PAQUETS" 15 1715 contenu dans l'information de TFT reçue de l'UE 1511, le GGSN 1519 génère au moins un filtre de paquets ayant l'adresse de source IPv6 de "::3.2.2.1" et le contenu d'UDP en utilisant un procédé de type adresse de source IPv6, et stocke le filtre de paquets généré dans la table de TFT 20 1651 de la mémoire vive 1650 contenue dans le dispositif de filtrage de paquets par TFT.
L'information de TFT est stockée en utilisant le procédé de type adresse de source IPv6 décrit précédemment.
On décrira ensuite le cas dans lequel l'information de TFT 25 est stockée en utilisant un procédé de type adresse de source IPv6 avec adresse IPv4 incorporée.
(2) Procédé de type adresse de source IPv6 avec adresse IPv4 incorporéeLorsqu'une adresse IP est une adresse de source 30 IPv6 avec adresse IPv4 incorporée quand l'UE 1511 génère une information de TFT, l'UE 1511 fixe un type de filtre de paquets par TFT à un type adresse de source IPv6 avec adresse IPv4 incorporée, et extrait seulement une adresse IPv6 à 32 bits d'ordre inférieur. L'UE 1511 configure au 35 moins un nouveau filtre de paquets par TFT en utilisant les 32 bits d'ordre inférieur extraits de l'adresse de source IPv6 avec adresse IPv4 incorporée, et émet le nouveau filtre de paquets par TFT vers le GGSN 1519. Le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée est un procédé pour permettre à l'UE 1511 d'extraire les 32 5 bits d'ordre inférieur de l'adresse de source IPv6 avec adresse IPv4 incorporée, de configurer le nouveau filtre de paquets par TFT et d'émettre le nouveau filtre de paquets par TFT. Pour que le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée soit supporté, un élément du 10 type adresse de source IPv6 avec adresse IPv4 incorporée doit être ajouté à des éléments des types de composants de filtre de paquets indiqués dans le Tableau 2 ci-dessous.
Nous supposons qu'un identificateur (ID) de type de composant de filtre de paquets associé au type adresse de 15 source IPv6 avec adresse IPv4 incorporée est fixé à "00100001". Ici, "001000l" est une valeur qui est réservée préalablement parmi les ID de type de composant de filtre de paquets.
Ensuite, lorsque le procédé de type adresse de 20 source IPv6 est utilisé, le filtre de paquets par TFT correspond à un type adresse de source IPv6, et la longueur du filtre de paquets par TFT stocké est de 32 bits.
Cependant, lorsqu'un procédé de type adresse de source IPv6 avec adresse IPv4 incorporée est utilisé, le filtre de 25 paquets par TFT correspond à un type adresse de source IPv6 avec adresse IPv4 incorporée, et la longueur du filtre de paquets par TFT stocké est de 32 bits.
On décrira en référence aux figures 18A et 18B le filtrage de paquets par TFT dans le cas o on utilise le 30 procédé de type adresse de source IPv6.
Les figures 18A et 18B sont des organigrammes illustrant l'opération de filtrage de paquets par TFT dans le cas o on utilise le procédé de type adresse de source IPv6.
En se référant à la figure 18A, on note que si le GGSN 1519 reçoit des données de paquets IP par l'intermédiaire de l'interface Gi à l'étape 1811, le GGSN 1519 passe à l'étape 1813. A l'étape 1813 ci-dessus, le GGSN 1519 vérifie une adresse de destination des données de paquets IP reçues et détermine si un appel secondaire est 5 établi pour de l'information coïncidant avec une adresse de PDP. Ici, la raison pour laquelle l'appel secondaire est établi est de déterminer si un tunnel de GTP secondaire est présent. En d'autres termes, du fait que le filtrage de paquets par TPF est désactivé lorsque le tunnel de GTP 10 secondaire n'existe pas, il est déterminé si l'appel secondaire est présent ou non. Si l'appel secondaire n'est pas établi, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1827. Le GGSN 1519 sélectionne un tunnel de GTP primaire à l'étape 1827 ci-dessus, et passe à 15 l'étape 1821.
Si l'appel secondaire est établi d'après le résultat de la détermination à l'étape 1813 ci-dessus, le GGSN 1519 passe à l'étape 1815. Le GGSN 1519 sélectionne le tunnel de GTP secondaire et sélectionne dans la première 20 information de TFT un filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée, à l'étape 1815 cidessus, et le GGSN 1519 passe à l'étape 1851. A l'étape 1851, le GGSN 1519 détermine si le filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée 25 correspond à un type adresse de source IPv6. Si le filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée ne correspond pas au type adresse de source IPv6, le GGSN 1519 passe à l'étape 1867. Le GGSN 1519 effectue à l'étape 1867 une opération de filtrage de paquets par TFT 30 de type général, et le GGSN 1519 passe à l'étape 1869. Si le filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée correspond au type adresse de source IPv6, d'après le résultat de la détermination à l'étape 1851, le GGSN 1519 passe à l'étape 1853. A l'étape 1853, le GGSN 35 1519 détermine si une version d'IP des données de paquets IP reçues par l'intermédiaire de l'interface Gi et une version d'IP d'une adresse de source sont une version IPv6.
Si la version d'IP des données de paquets IP reçues n'est pas la version IPv6, le GGSN 1519 passe à l'étape 1855. A l'étape 1855, le GGSN 1519 détermine si d'autres filtres de 5 paquets par TFT sont présents dans la première information de TFT. Si d'autres filtres de paquets par TFT sont présents dans la première information de TFT, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1857. Le GGSN 1519 sélectionne un filtre de paquets par TFT 10 ayant la priorité d'évaluation la plus élevée, parmi d'autres filtres de paquets à l'étape 1857, et retourne à l'étape 1851 ci-dessus. Si d'autres filtres de paquets par TFT n'existent pas, d'après un résultat de la détermination à l'étape 1855, le GGSN 1519 passe à l'étape 1825. A 15 l'étape 1825, le GGSN 1519 détermine si l'information de TFT suivante est présente. Si l'information de TFT suivante est présente, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1823. Le GGSN 1519 sélectionne l'information de TFT suivante à l'étape 1823 et retourne 20 ensuite à l'étape 1815. Si l'information de TFT suivante n'existe pas, d'après le résultat de la détermination à l'étape 1825 ci-dessus, le GGSN 1519 passe à l'étape 1827.
Le GGSN 1519 sélectionne le tunnel de GTP primaire à l'étape 1827 cidessus, et passe à l'étape 1821.
Si la version d'IP des données de paquets IP reçues est la version IPv6, d'après le résultat de la détermination à l'étape 1853, le GGSN 1519 passe à l'étape 1859. A l'étape 1859, le GGSN 1519 détermine si la longueur du filtre de paquets par TFT est de 32 bits. Si la longueur 30 du filtre de paquets par TFT n'est pas de 32 bits d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1867. Comme le fait que la longueur du filtre de paquets par TFT ne soit pas de 32 bits indique qu'une adresse de source est une adresse IPv6 à 128 bits générale, 35 le GGSN 1519 passe à l'étape 1867 pour accomplir une opération de filtrage de paquets par TFT de type général.
Si la longueur du filtre de paquets par TFT est de 32 bits d'après le résultat de la détermination à l'étape 1859, le GGSN 1519 passe à l'étape 1861. A l'étape 1861, le GGSN 1519 détermine si l'adresse de source des données de 5 paquets IP reçues est une adresse IPv6 avec adresse IPv4 incorporée. Si l'adresse de source n'est pas une adresse IPv6 avec adresse IPv4 incorporée, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1867. Le fait que l'adresse de source ne soit pas une adresse IPv6 10 avec adresse IPv4 incorporée indique que l'adresse de source est une adresse IPv4 à 32 bits. Le GGSN 1519 effectue une opération de filtrage de paquets par TFT de type général à l'étape 1867 ci-dessus.
Si l'adresse de source est une adresse IPv6 avec 15 adresse IPv4 incorporée, d'après le résultat de la détermination à l'étape 1861 cidessus, le GGSN 1519 passe à l'étape 1863. Le GGSN 1519 extrait une adresse de source à 32 bits d'ordre inférieur, et passe à l'étape 1865. Le GGSN 1519 effectue un filtrage de paquets par TFT en 20 utilisant les 32 bits extraits à l'étape 1865 ci-dessus et passe ensuite à l'étape 1869. Le filtrage de paquets par TFT effectué à l'étape 1865 utilise le procédé de type adresse source IPv6 proposé. A l'étape 1869, le GGSN 1519 détermine si le filtrage de paquets par TFT a réussi. Si le 25 filtrage de paquets par TFT n'a pas réussi, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1855. Si le filtrage de paquets par TFT a réussi, d'après le résultat de la détermination à l'étape 1869, le GGSN 1519 passe à l'étape 1817 ci-dessus.
Le GGSN 1519 sélectionne un tunnel de GTP correspondant à l'information de TFT présente, à l'étape 1817, et passe ensuite à l'étape 1821. A l'étape 1821, le GGSN 1519 exécute une procédure de filtrage de paquets pour traiter les données de paquets IP reçues, et termine 35 l'opération de filtrage de paquets par TFT.
On a décrit en référence aux figures 18A et 18B le filtrage de paquets par TFT lorsqu'on utilise le procédé de type adresse source IPv6. On décrira ensuite le filtrage de paquets par TFT lorsqu'on utilise le procédé de type 5 adresse source IPv6 avec adresse IPv4 incorporée en référence aux figures 19A et 19B.
Les figures 19A et 19B sont des organigrammes illustrant une opération de filtrage de paquets par TFT lorsque le procédé de type adresse source IPv6 avec adresse 10 IPv4 incorporée est utilisé.
En se référant à la figure 19A, on note que si le GGSN 1519 reçoit des données de paquets IP par l'intermédiaire de l'interface Gi à l'étape 1911, le GGSN 1519 passe à l'étape 1913. A l'étape 1913 ci-dessus, le 15 GGSN 1519 vérifie une adresse de destination des données de paquets IP reçues et détermine si un appel secondaire est établi ou non pour de l'information coïncidant avec une adresse de PDP. Ici, l'appel secondaire est établi pour déterminer si un tunnel de GTP est présent. En d'autres 20 termes, du fait que le filtrage de paquets par TFT est désactivé lorsque le tunnel de GTP secondaire n'existe pas, il est déterminé si l'appel secondaire est présent ou non.
Si l'appel secondaire n'est pas établi d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1927. Le 25 GGSN 1519 sélectionne un tunnel de GTP primaire à l'étape 1927 et passe à l'étape 1921.
Si l'appel secondaire est établi d'après le résultat de la détermination à l'étape 1913 ci-dessus, le GGSN 1519 passe à l'étape 1915. Le GGSN 1519 sélectionne le 30 tunnel de GTP secondaire et sélectionne dans la première information de TFT un filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée, à l'étape 1915, et le GGSN 1519 passe à l'étape 1951. A l'étape 1951, le GGSN 1519 détermine si le filtre de paquets par TFT ayant la 35 priorité d'évaluation la plus élevée correspond à un type adresse IPv6 avec adresse IPv4 incorporée. Si le filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée ne correspond pas à un type adresse IPv6 avec adresse IPv4 incorporée, le GGSN 1519 passe à l'étape 1953. 5 A l'étape 1953 le GGSN 1519 effectue une opération de filtrage de paquets par TFT de type général, et le GGSN 1519 passe à l'étape 1965. Si le filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée correspond au type adresse IPv6 avec adresse IPv4 incorporée, d'après le 10 résultat de la détermination à l'étape 1951, le GGSN 1519 passe à l'étape 1955. A l'étape 1955, le GGSN 1519 détermine si l'adresse de source des données de paquets IP reçues est une adresse IPv6 avec adresse IPv4 incorporée.
Si l'adresse de source des données de paquets IP reçues 15 n'est pas une adresse IPv6 avec adresse IPv4 incorporée, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1957. A l'étape 1957, le GGSN 1519 détermine si d'autres filtres de paquets par TFT sont présents dans la première information de TFT. Si d'autres filtres de paquets 20 par TFT sont présents dans la première information de TFT d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1959. Le GGSN 1519 sélectionne un filtre de paquets par TFT ayant la priorité d'évaluation la plus élevée, parmi d'autres filtres de paquets à l'étape 1959, 25 et retourne à l'étape 1951. Si d'autres filtres de paquets par TFT n'existent pas d'après un résultat de la détermination à l'étape 1957, le GGSN 1519 passe à l'étape 1925. A l'étape 1925, le GGSN 1519 détermine si l'information de TFT suivante est présente. Si 30 l'information de TFT suivante est présente d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1923. Le GGSN 1519 sélectionne l'information de TFT suivante à l'étape 1923 et retourne ensuite à l'étape 1915.
Si l'information de TFT suivante n'existe pas d'après un 35 résultat de la détermination à l'étape 1925 ci-dessus, le GGSN 1519 passe à l'étape 1927. Le GGSN 1519 sélectionne le tunnel de GTP primaire à l'étape 1927 et passe à l'étape 1921.
Si l'adresse de source des données de paquets IP reçues est une adresse IPv6 avec adresse IPv4 incorporée, 5 d'après le résultat de la détermination à l'étape 1955, le GGSN 1519 passe à l'étape 1961. Le GGSN 1519 extrait 32 bits d'ordre inférieur de l'adresse IPv6 avec adresse IPv4 incorporée et passe ensuite à l'étape 1963. Le GGSN 1519 effectue un filtrage de paquets par TFT en utilisant les 32 10 bits extraits, à l'étape 1963, et passe ensuite à l'étape 1965. A l'étape 1965, le GGSN 1519 détermine si le filtrage de paquets par TFT a réussi. Si le filtrage de paquets par TFT n'a pas réussi, d'après un résultat de la détermination, le GGSN 1519 passe à l'étape 1957. Si le 15 filtrage de paquets par TFT a réussi d'après le résultat de la détermination à l'étape 1965, le GGSN 1519 passe à l'étape 1917. Le GGSN 1519 sélectionne un tunnel de GTP correspondant à l'information de TFT présente, à l'étape 1917, et passe ensuite à l'étape 1921. Le GGSN 1519 exécute 20 une procédure de filtrage de paquets pour traiter les données de paquets IP reçues à l'étape 1921, et termine l'opération de filtrage de paquets par TFT.
On décrira l'opération de filtrage de paquets par TFT de type général en se référant à la figure 20.
La figure 20 est un schéma synoptique illustrant l'opération de filtrage de paquets par TFT de type général qui est effectuée par la procédure de filtrage de paquets par TFT 1611 représentée sur la figure 16.
En se référant à la figure 20, on note que si des 30 données de paquets IP 2000 sont reçues du réseau externe par l'intermédiaire de l'interface GI du GGSN 1519, c'està-dire si les données de paquets IP 2000 sont introduites par l'intermédiaire du duplexeur 1690, les données de paquets IP d'entrée 2000 sont transférées à la procédure de 35 filtrage de paquets par TFT 1611, par l'intermédiaire du module de SAR 1670. La procédure de filtrage de paquets par TFT 1611 effectue le filtrage de paquets par TFT en utilisant de l'information de TFT stockée dans la table de TFT 1651 de la mémoire vive 1650. Si la table de TFT 1651 stocke deux éléments d'information de TFT, qui sont TFT 1 5 et TFT 2, comme représenté sur la figure 20, la procédure de filtrage de paquets par TFT 1611 tente en premier d'effectuer un filtrage de paquets par TFT pour les données de paquets IP 2000 en relation avec un filtre de paquets 1 de TFT 1. Dans les données de paquets IP 2000, un Type de 10 Service (TOS pour "Type Of Service") est "OxlF", un protocole est TCP (6), une adresse de source est "2.2.2.2", une adresse de destination est "3.3.3.3", un numéro de port de source est 5000, et un numéro de port de destination est 50.
Lorsque le filtrage de paquets par TFT associé au 15 filtre de paquets 1 de TFT 1 pour les données de paquets 2000 sera effectué, le filtrage de paquets par TFT ne réussira pas, du fait que l'adresse de source du filtre de paquets 1 de TFT 1 est "1.1.1. 1". Ensuite, la procédure de filtrage de paquets de TFT 1611 effectue le filtrage de 20 paquets associé à un filtre de paquets 2 de TFT 1.
Cependant, du fait qu'une plage de ports de source associée au filtre de paquets 2 de TFT 1 est entre 100 et 1000, le numéro de port de source 5000 des données de paquets IP 2000 n'est pas contenu dans la plage de ports de source, ce 25 qui fait que le filtrage de paquets par TFT ne réussit pas.
Par conséquent, un filtre de paquets par TFT capable d'être mappé vers les données de paquets IP d'entrée 2000 est recherché. Le filtrage de paquets est effectué par le filtre de paquets de TFT mappé vers les données de paquets 30 IP 2000, et les données de paquets IP 2000 sont transférées vers le SGSN 1515 à travers un tunnel correspondant. Sur la figure 20, du fait que le port de destination des données de paquets IP est contenu dans une plage de ports de destination pour un filtre de paquets 5 de TFT 2, les 35 données de paquets IP 2000 utilisent un tunnel de GTP correspondant à TFT 2. L'opération de filtrage de paquets par TFT pour les données de paquets qui arrivent à partir du réseau externe est la même que sur la figure 10, comme mentionné au paragraphe ci-dessus concernant la description de l'art antérieur.
On va maintenant décrire en référence à la figure 21 le filtrage de paquets par TFT utilisant le procédé de type adresse de source IPv6.
La figure 21 est un schéma synoptique illustrant une opération de filtrage de paquets par TFT utilisant le 10 procédé de type adresse de source IPv6 qui est effectuée par la procédure de filtrage de paquets par TFT 1611 représentée sur la figure 16.
En se référant à la figure 21, on note que si des données de paquets IP 2100 sont reçues à partir du réseau 15 externe par l'intermédiaire de l'interface Gi du GGSN 1519, c'est-à-dire si les données de paquets IP 2100 sont introduites par l'intermédiaire du duplexeur 1690, les données de paquets IP d'entrée 2100 sont transférées à la procédure de filtrage de paquets par TFT 1611 par 20 l'intermédiaire du module de SAR 1670. La procédure de filtrage de paquets par TFT 1611 exécute le filtrage de paquets par TFT en utilisant une information de TFT stockée dans la table de TFT 1651 de la mémoire vive 1650. Si la table de TFT 1651 stocke deux éléments d'information de TFT 25 qui sont TFT 1 et TFT 2, comme représenté sur la figure 21, la procédure de filtrage de paquets par TFT 1611 tente en premier d'effectuer un filtrage de paquets par TFT pour les données de paquets IP 2100 en relation avec un filtre de paquets 1 du TFT 1. Dans les données de paquets IP 2100, un 30 TOS est "OxlF", un protocole est TCP (6), une adresse de source est "::10.3.8.112", une adresse de destination est "::10.2.3.54", un numéro de port de source est 5000 et un numéro de port de destination est 50. Ici, l'adresse de source et l'adresse de destination sont des adresses IPv6 35 compatibles avec IPv4 et sont exprimées respectivement sous la forme de 32 bits d'ordre inférieur.
Lorsqu'un filtrage de paquets par TFT associé au filtre de paquets 1 du TFT 1 pour les données de paquets IP 2100 sera effectué, le filtrage de paquets par TFT réussira du fait que l'adresse de source du filtre de paquets 1 du 5 TFT 1 est "10.3.8.112". Ensuite, la procédure de filtrage de paquets par TFT 1611 exécute le filtrage de paquets en utilisant le filtre de paquets adapté aux données de paquets IP 2100 et transfère ensuite les données de paquets 2100 vers le SGSN 1515 à travers un tunnel de GTP 10 correspondant. Du fait que l'adresse de source des données de paquets 2100 coïncide avec l'adresse de source associée au filtre de paquets 1 du TFT 1, les données de paquets IP 2100 utilisent le tunnel de GTP correspondant au TFT 1.
On décrira en référence à la figure 22 le filtrage 15 de paquets par TFT utilisant le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée.
La figure 22 est un schéma synoptique illustrant une opération de filtrage de paquets par TFT utilisant le procédé de type adresse source IPv6 avec adresse IPv4 20 incorporée qui est effectuée par la procédure de filtrage de paquets par TFT 1611 représentée sur la figure 16.
En se référant à la figure 22, on note que si des données de paquets IP 2200 sont reçues à partir du réseau externe par l'intermédiaire de l'interface Gi du GGSN 1519, 25 c'est-à-dire si les données de paquets IP 2200 sont introduites par l'intermédiaire du duplexeur 1690, les données de paquets IP 2200 introduites sont transférées à la procédure de filtrage de paquets par TFT 1611 par l'intermédiaire du module de SAR 1670. La procédure de 30 filtrage de paquets par TFT 1611 exécute le filtrage de paquets par TFT en utilisant de l'information de TFT stockée dans la table de TFT 1651 de la mémoire vive 1650.
Si la table de TFT 1651 stocke deux éléments d'information de TFT qui sont TFT 1 et TFT 2, comme représenté sur la 35 figure 22, la procédure de filtrage de paquets par TFT 1611 tente en premier d'effectuer un filtrage de paquets par TFT pour les données de paquets IP 2200 en relation avec le filtre de paquets 1 du TFT 1. Dans les données de paquets IP 2200, un TOS est "OxlF", un protocole est TCP (6), une adresse de source est "::FFFF:10.3.2.1", une adresse de 5 destination est "::FFFF:10.2.3.54", un numéro de port de source est 5000 et un numéro de port de destination est 50.
Ici, l'adresse de source et l'adresse de destination sont des adresses IPv6 mappées en IPv4, et sont exprimées respectivement sous la forme de 32 bits d'ordre inférieur. 10 Lorsque la procédé de filtrage de paquets par TFT 1611 exécutera un filtrage de paquets par TFT associé à un filtre de paquets 1 du TFT 1 pour les données de paquets 2200, le filtrage de paquets par TFT ne réussira pas du fait que l'adresse de source du filtre de paquets 1 du TFT 15 1 est "2002::AF10:E9". En outre, du fait qu'une plage de ports de source associée au filtre de paquets 2 du TFT 1 est entre 100 et 1000, le filtrage de paquets par TFT ne réussit pas. En outre, du fait que le protocole associé au filtre de paquets 3 du TFT 1 est ICMP (1), le filtrage de 20 paquets par TFT ne réussira pas. Lorsque la procédure de filtrage de paquets par TFT 1611 exécutera le filtrage de paquets par TFT associé au filtre de paquets 1 du TFT 2, le filtrage de paquets par TFT réussira du fait qu'un type 1 avec adresse IPv4 incorporée correspond à "10.3.2.1". 25 Ensuite, la procédure de filtrage de paquets 1611 exécute le filtrage de paquets en utilisant le filtre de paquets par TFT adapté aux données de paquets IP 2200, et transfère les données de paquets IP 2200 vers le SGSN 1515 à travers un tunnel de GTP correspondant. Sur la figure 22, du fait 30 que l'adresse de source des données de paquets IP 2200 coïncide avec un type 1 avec adresse IPv4 incorporée associé au filtre de paquets 1 du TFT 2, les données de paquets IP 2200 utilisent un tunnel de GTP correspondant au TFT 2.
On décrira en référence à la figure 23 une comparaison entre un volume de calcul sur des bits correspondant à une opération de filtrage de paquets par TFT lorsque le procédé de type adresse de source IPv6 et le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée conformes à la présente invention sont utilisés, 5 et un volume de calcul sur des bits correspondant à l'opération de filtrage de paquets par TFT générale.
La figure 23 est un tableau illustrant un volume de calcul sur des bits correspondant à une opération de filtrage de paquets par TFT lorsque le procédé de type 10 adresse de source IPv6 et le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée sont utilisés, en comparaison avec un volume de calcul sur des bits correspondant à l'opération de filtrage de paquets par TFT générale, d'après la présente invention.
En se référant à la figure 23, on voit un volume de calcul sur des bits correspondant au cas dans lequel une adresse IPv6 à 128 bits est utilisée, et un volume de calcul sur des bits correspondant au cas dans lequel 32 bits sont extraits de l'adresse IPv6 à 128 bits, d'après le 20 nombre d'opérations de filtrage de paquets par TFT. La figure montre un volume de calcul à 128 bits et un volume de calcul à 32 bits dans des cas dans lesquels le nombre d'opérations de filtrage de paquets par TFT est de 1000, 100 000 et 1 000 000. Comme représenté sur la figure 23, 25 une différence entre un volume de calcul sur des bits lorsque 128 bits sont utilisés et un volume de calcul sur des bits lorsque 32 bits sont utilisés est remarquablement élevée.
Dans le procédé de type adresse de source IPv6 avec 30 adresse IPv4 incorporée, l'UE 1511 fixe le type de filtre de paquets par TFT au type adresse de source IPv6 avec adresse IPv4 incorporée, extrait une adresse IPv6 à 32 bits d'ordre inférieur d'une adresse de source IPv6 avec adresse IPv4 incorporée, et configure au moins un nouveau filtre de 35 paquets par TFT en utilisant l'adresse IPv6 à 32 bits d'ordre inférieur extraite. En d'autres termes, la configuration du TFT par l'UE 1511 dans le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée est différente de celle dans le procédé de type adresse de source IPv6. On décrira la différence précitée en se référant à la figure 24.
La figure 24 est un organigramme illustrant un processus de génération de filtre de paquets par TFT dans lequel le procédé de type adresse de source IPv6 avec adresse IPv4 incorporée est mis en oeuvre.
En se référant à la figure 24, on note que 1'UE 1511 fixe un paramètre arbitraire i à "0" (i = 0) et fixe un paramètre arbitraire Maxfiltre à "x" à l'étape 2411, et passe à l'étape 2413. Ici, "x" indique le nombre de filtres de paquets qui peuvent être configurés dans un seul TFT. 15 Par exemple, du fait que le nombre maximal de filtres de paquets qui peuvent être configurés est 8, comme décrit cidessus, "x" est un entier entre 1 et 8. Le nombre de filtres de paquets "x" pouvant être configurés dans un seul TFT est déterminé par une application prédéterminée de l'UE 20 1511. L'UE 1511 détermine, à l'étape 2413 ci-dessus, si i < Maxfiltre. Si 2 max filtre d'après un résultat de la détermination, 1'UE 1511 met fin au processus. Si i < Maxfiltre d'après le résultat de la détermination, l'UE 1511 passe à l'étape 2415. A l'étape 2415, l'UE 1511 25 détermine si une adresse IP associée à un filtre de paquets par TFT correspond à un type adresse de source IPv6 avec adresse IPv4 incorporée. Si l'adresse IP associée à un filtre de paquets par TFT ne correspond pas à un type adresse de source IPv6 avec adresse IPv4 incorporée, l'UE 30 1511 passe à l'étape 2417. L'UE 1511 configure des filtres de paquets par TFT en utilisant le procédé de génération de filtre de paquets par TFT général, à l'étape 2417 cidessus, et passe à l'étape 2423. Si l'adresse IP associée à un filtre de paquets par TFT correspond à un type adresse 35 de source IPv6 avec adresse IPv4 incorporée, l'UE 1511 passe à l'étape 2419.
A l'étape 2419, l'UE 1511 fixe un type adresse de source IPv6 avec adresse IPv4 incorporée pour un type du filtre de paquets à générer, et passe ensuite à l'étape 2421. L'UE 1511 extrait 32 bits d'ordre inférieur de 5 l'adresse IPv6 avec l'adresse IPv4 incorporée à l'étape 2421, et passe ensuite à l'étape 2423. L'UE 1511 génère le filtre de paquets en utilisant les 32 bits extraits et stocke le filtre de paquets généré dans un TFT correspondant, à l'étape 2423, et passe à l'étape 2425. 10 L'UE 1511 incrémente de "1l" une valeur du paramètre i (c'est-à-dire i = i+1) à l'étape 2425 et passe ensuite à l'étape 2413.
Comme il ressort de la description ci-dessus, la présente invention procure un appareil et un procédé pour 15 accomplir un filtrage de paquets par TFT, qui peuvent minimiser un volume de calcul associé au filtrage de paquets, en utilisant seulement 32 bits d'ordre inférieur sélectionnés dans une adresse IPv6 avec adresse IPv4 incorporée consistant en 128 bits, lorsqu'un type d'une 20 adresse IP pour des données de paquets arrivant à partir d'un réseau externe correspond à l'adresse IPv6 avec adresse IPv4incorporée, dans un système de communication mobile. En d'autres termes, du fait qu'une opération de calcul pour les 96 bits restants, autres que les 32 bits 25 d'ordre inférieur sélectionnés, n'est pas effectuée, un volume de calcul sur des bits peut être réduit chaque fois qu'un filtrage de paquets par TFT est effectué.
En outre, l'appareil et le procédé peuvent minimiser la taille d'un élément pour stocker des filtres 30 de paquets par TFT, du fait que 32 bits seulement, au lieu de 128 bits, sont utilisés lorsque au moins un filtre de paquets est configuré en relation avec une adresse IPv6 avec adresse IPv4 incorporée, ce qui permet d'améliorer l'efficacité globale d'utilisation des ressources dans le 35 système de communication mobile.
Il va de soi que de nombreuses modifications peuvent être apportées à l'appareil et au procédé décrits et représentés, sans sortir du cadre de l'invention.
Claims (28)
1. Procédé pour effectuer un filtrage par Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") conformément à des versions de Protocole Internet (IP pour 5 "Internet Protocol") dans un système de communication mobile capable de supporter une adresse d'une première version d'IP incluant des premiers bits et une adresse d'une seconde version d'IP incluant des seconds bits contenant les premiers bits, le procédé étant caractérisé 10 en ce qu'il comprend les étapes suivantes: on extrait d'une adresse IP de source une information basée sur la version d'IP; et on génère une information de TFT contenant l'information extraite et on émet l'information de TFT générée vers un Noeud de Support GPRS de Passerelle (GGSN 15 pour "Gateway GPRS (General Packet Radio Service) Support Node").
2. Procédé selon la revendication 1, caractérisé en ce que l'étape consistant à extraire de l'adresse IP de source l'information basée sur la version d'IP est effectuée en extrayant de l'adresse de la seconde version 20 d'IP les premiers bits de l'adresse de la première version d'IP constituant l'information basée sur la version d'IP, lorsque l'adresse IP de source est l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée.
3. Procédé selon la revendication 1, caractérisé en ce que l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée est une adresse de la seconde version d'IP compatible avec la première version d'IP, ou une adresse de la seconde version 30 d'IP mappée vers la première version d'IP.
4. Procédé selon la revendication 3, caractérisé en ce que l'adresse de la seconde version d'IP compatible avec la première version d'IP est une adresse utilisée entre des réseaux capables de supporter à la fois un premier IP de la 35 première version d'IP et un second IP de la seconde version d'IP.
5. Procédé selon la revendication 3, caractérisé en ce que l'adresse de la seconde version d'IP mappée vers la première version d'IP est une adresse utilisée entre un réseau capable de supporter seulement un premier IP de la 5 première version d'IP et un réseau capable de supporter à la fois le premier IP de la première version d'IP et un second IP de la seconde version d'IP.
6. Procédé selon la revendication 1, caractérisé en ce que la première version d'IP est une version IPv4 (IP 10 version 4) et la seconde version d'IP est une version 6 d'IP (IPv6).
7. Procédé pour effectuer un filtrage par Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") conformément à des versions de Protocole Internet (IP pour 15 "Internet Protocol") dans un système de communication mobile capable de supporter une adresse d'une première version d'IP incluant des premiers bits et une adresse d'une seconde version d'IP incluant des seconds bits contenant les premiers bits, le procédé étant caractérisé 20 en ce qu'il comprend les étapes suivantes: lorsqu'une information de TFT est reçue et l'information de TFT reçue correspond à l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, on extrait de l'adresse de la seconde version d'IP les 25 premiers bits de l'adresse de la première version d'IP; on génère une nouvelle information de TFT à partir des premiers bits extraits de l'adresse de la première version d'IP; lorsqu'une adresse IP de données de paquets reçues correspond à la seconde version d'IP et l'adresse IP est 30 l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, on extrait de l'adresse de la seconde version d'IP les premiers bits représentant l'adresse de la première version d'IP; et on effectue le filtrage de paquets par TFT en 35 utilisant les premiers bits extraits des données de paquets reçues.
8. Procédé selon la revendication 7, caractérisé en ce que l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée est une adresse de la seconde version d'IP compatible avec la 5 première version d'IP, ou une adresse de la seconde version d'IP mappée vers la première version d'IP.
9. Procédé selon la revendication 8, caractérisé en ce que l'adresse de la seconde version d'IP compatible avec la première version d'IP est une adresse utilisée entre des 10 réseaux capables de supporter à la fois un premier IP de la première version d'IP et un second IP de la seconde version d'IP.
10. Procédé selon la revendication 8, caractérisé en ce que l'adresse de la seconde version d'IP mappée vers la première version d'IP est une adresse utilisée entre un 15 réseau capable de supporter seulement un premier IP de la première version d'IP et un réseau capable de supporter à la fois le premier IP de la première version d'IP et un second IP de la seconde version d'IP.
11. Procédé selon la revendication 7, caractérisé 20 en ce que la première version d'IP est une version IPv4 (IP version 4) et la seconde version d'IP est une version 6 d'IP (IPv6).
12. Procédé pour effectuer un filtrage par Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") 25 conformément à des versions de Protocole Internet (IP pour "Internet Protocol") dans un système de communication mobile capable de supporter une adresse d'une première version d'IP incluant des premiers bits et une adresse d'une seconde version d'IP incluant des seconds bits 30 contenant les premiers bits, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes: lorsqu'une adresse IP de source est la seconde adresse IP dans laquelle l'adresse de la première version d'IP est insérée, on permet à un Equipement d'Utilisateur (UE pour "User 35 Equipment") (1511) d'extraire de l'adresse de la seconde version d'IP les premiers bits de l'adresse de la première version d'IP; on permet à l'UE de générer un contenu de filtre de paquets à partir des premiers bits extraits de l'adresse de la première version d'IP, de générer une information de TFT contenant le contenu de filtre de 5 paquets et d'émettre l'information de TFT générée vers un Noeud de Support GPRS de Passerelle (GGSN pour "Gateway GPRS (General Packet Radio Service) Support Node") (1519); on permet au GGSN (1519) de stocker l'information de TFT reçue de l'UE (1511) et d'extraire de l'adresse de la 10 seconde version d'IP les premiers bits représentant l'adresse de la première version d'IP, lorsqu'une adresse IP de données de paquets reçue correspond à la seconde version d'IP, et l'adresse IP est l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version 15 d'IP est insérée; et on permet au GGSN (1519) d'effectuer le filtrage de paquets par TFT en utilisant les premiers bits extraits des données de paquets reçues.
13. Procédé selon la revendication 12, caractérisé en ce que l'adresse de la seconde version d'IP dans 20 laquelle l'adresse de la première version d'IP est insérée est une adresse de la seconde version d'IP compatible avec la première version d'IP ou une adresse de la seconde version d'IP mappée vers la première version d'IP.
14. Procédé selon la revendication 13, caractérisé 25 en ce que l'adresse de la seconde version d'IP compatible avec la première version d'IP est une adresse utilisée entre des réseaux capables de supporter à la fois un premier IP de la première version d'IP et un second IP de la seconde version d'IP
15. Procédé selon la revendication 13, caractérisé en ce que l'adresse de la seconde version d'IP mappée vers la première version d'IP est une adresse utilisée entre un réseau capable de supporter seulement un premier IP de la première version d'IP et un réseau capable de supporter à 35 la fois le premier IP de la première version d'IP et un second IP de la seconde version d'IP.
16. Procédé selon la revendication 12, caractérisé en ce que la première version d'IP est une version IPv4 (IP version 4) et la seconde version d'IP est une version 6 d'IP (IPv6).
17. Appareil pour effectuer un filtrage par Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") conformément à des versions de Protocole Internet (IP pour "Internet Protocol") dans un système de communication mobile capable de supporter une adresse d'une première 10 version d'IP incluant des premiers bits et une adresse d'une seconde version d'IP incluant des seconds bits contenant les premiers bits, l'appareil étant caractérisé en ce qu'il comprend: une unité de commande (1600) pour extraire de l'adresse de la seconde version d'IP les 15 premiers bits de l'adresse de la première version d'IP lorsqu'une information de TFT est reçue et l'information de TFT reçue correspond à l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, et pour générer une nouvelle information de TFT à 20 partir des premiers bits extraits de l'adresse de la première version d'IP; et une mémoire (1650) pour stocker l'information de TFT reçue comme la nouvelle information de TFT.
18. Appareil selon la revendication 17, caractérisé 25 en ce que l'unité de commande (1600) comprend une procédure de filtrage de paquets par TFT (1611) pour extraire de l'adresse de la seconde version d'IP les premiers bits représentant l'adresse de la première version d'IP, lorsqu'une adresse IP de données de paquets reçues 30 correspond à la seconde version d'IP et l'adresse IP est l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, et pour effectuer le filtrage de paquets par TFT en utilisant les premiers bits extraits des données de paquets reçues.
19. Appareil selon la revendication 17, caractérisé en ce que l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée est une adresse de la seconde version d'IP compatible avec la première version d'IP, ou une adresse de la seconde version d'IP mappée vers la première version d'IP.
20. Appareil selon la revendication 19, caractérisé en ce que l'adresse de la seconde version d'IP compatible avec la première version d'IP est une adresse utilisée entre des réseaux capables de supporter à la fois un premier IP de la première version d'IP et un second IP de 10 la seconde version d'IP
21. Appareil selon la revendication 19, caractérisé en ce que l'adresse de la seconde version d'IP mappée vers la première version d'IP est une adresse utilisée entre un réseau capable de supporter seulement un premier IP de la 15 première version d'IP et un réseau capable de supporter à la fois le premier IP de la première version d'IP et un second IP de la seconde version d'IP.
22. Appareil selon la revendication 18, caractérisé en ce que la première version d'IP est une version 4 d'IP (IPv4) 20 et la seconde version d'IP est une version 6 d'IP (IPv6).
23. Appareil pour effectuer un filtrage par Modèle de Flux de Trafic (TFT pour "Traffic Flow Template") conformément à des versions de Protocole Internet (IP pour "Internet Protocol") dans un système de communication 25 mobile capable de supporter une adresse d'une première version d'IP incluant des premiers bits et une adresse d'une seconde version d'IP incluant des seconds bits contenant les premiers bits, l'appareil étant caractérisé en ce qu'il comprend: un Equipement d'Utilisateur (UE pour 30 User Equipment") (1511) pour extraire de l'adresse de la seconde version d'IP les premiers bits de l'adresse de la première version d'IP lorsqu'une adresse IP de source est l'adresse de la seconde version d'IP dans laquelle la première adresse IP est insérée, pour générer une 35 information de TFT à partir des premiers bits extraits de l'adresse de la première version d'IP et pour émettre l'information de TFT générée vers un Noeud de Support GPRS de Passerelle (GGSN pour '"Gateway GPRS (General Packet Radio Service) Support Node") (1519); et le GGSN (1519) pour stocker l'information de TFT reçue de l'UE (1511), 5 pour extraire de l'adresse de la seconde version d'IP les premiers bits représentant l'adresse de la première version d'IP, lorsqu'une adresse IP de données de paquets reçues correspond à la seconde version d'IP et l'adresse IP est l'adresse de la seconde version d'IP dans laquelle 10 l'adresse de la première version d'IP est insérée, et pour effectuer le filtrage de paquets par TFT en utilisant les premiers bits extraits des données de paquets reçues.
24. Appareil selon la revendication 23, caractérisé en ce que le GGSN (1519) comprend une procédure de 15 filtrage de paquets par TFT (1611) pour extraire de l'adresse de la seconde version d'IP les premiers bits représentant l'adresse de la première version d'IP, lorsque l'adresse IP des données de paquets reçues correspond à la seconde version d'IP et l'adresse IP est l'adresse de la 20 seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée, et pour effectuer le filtrage de paquets par TFT en utilisant les premiers bits extraits des données de paquets reçues; et une mémoire (1650) pour stocker l'information de TFT reçue de l'UE (1511).
25. Appareil selon la revendication 23, caractérisé en ce que l'adresse de la seconde version d'IP dans laquelle l'adresse de la première version d'IP est insérée est une adresse de la seconde version d'IP compatible avec la première version d'IP ou une adresse de la seconde 30 version d'IP mappée vers la première version d'IP.
26. Appareil selon la revendication 25, caractérisé en ce que l'adresse de la seconde version d'IP compatible avec la première version d'IP est une adresse utilisée entre des réseaux capables de supporter à la fois un 35 premier IP de la première version d'IP et un second IP de la seconde version d'IP.
27. Appareil selon la revendication 25, caractérisé en ce que l'adresse de la seconde version d'IP mappée vers la première version d'IP est une adresse utilisée entre un réseau capable de supporter seulement un premier IP de la 5 première version d'IP et un réseau capable de supporter à la fois le premier IP de la première version d'IP et un second IP de la seconde version d'IP.
28. Appareil selon la revendication 23, caractérisé en ce que la première version d'IP est une version 4 d'IP 10 (IPv4) et la seconde version d'IP est une version 6 d'IP (IPv6).
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR20030011133A KR100886551B1 (ko) | 2003-02-21 | 2003-02-21 | 이동통신시스템에서 인터넷 프로토콜 버전에 따른 트래픽플로우 탬플릿 패킷 필터링 장치 및 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2852472A1 true FR2852472A1 (fr) | 2004-09-17 |
| FR2852472B1 FR2852472B1 (fr) | 2006-02-10 |
Family
ID=32041031
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0401709A Expired - Fee Related FR2852472B1 (fr) | 2003-02-21 | 2004-02-20 | Appareil et procede pour le filtrage par modele de flux de trafic dans un systeme de communication mobile |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20040205247A1 (fr) |
| JP (1) | JP4006407B2 (fr) |
| KR (1) | KR100886551B1 (fr) |
| CN (1) | CN1279731C (fr) |
| DE (1) | DE102004008720B4 (fr) |
| FR (1) | FR2852472B1 (fr) |
| GB (1) | GB2400278B (fr) |
| IT (1) | ITMI20040297A1 (fr) |
Families Citing this family (39)
| 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 |
| EP1705858A1 (fr) * | 2005-03-24 | 2006-09-27 | Orange SA | Procédé et système d'activation de contexte d'un protocole de donnees par paquets |
| EP1705859A1 (fr) * | 2005-03-24 | 2006-09-27 | Orange SA | Procédé et système d'activation de contexte d'un protocole de donnees par paquets |
| 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 | 한국전자통신연구원 | 이동단말에서의 상향링크 ｉｐ 패킷 필터링 제어방법 |
| WO2009142751A2 (fr) * | 2008-05-21 | 2009-11-26 | Luis Filipe Pereira Valente | Système et procédé pour découvrir des entités de réseau |
| US20090323965A1 (en) * | 2008-06-27 | 2009-12-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Systems and Methods for Monitoring Performance of a Communication System |
| WO2010059718A1 (fr) * | 2008-11-18 | 2010-05-27 | Starent Networks, Corp | Appel sélectif dans des réseaux sans fil |
| US8428625B2 (en) | 2009-02-27 | 2013-04-23 | Cisco Technology, Inc. | Paging heuristics in packet based networks |
| CN102484586B (zh) * | 2009-08-03 | 2014-12-03 | 日本电信电话株式会社 | 函数密码应用系统及方法 |
| 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 |
| EP3162011A4 (fr) * | 2014-06-30 | 2018-02-28 | Intel IP Corporation | Appareil et procédé pour ameliorer l'architecture de qualité de service pour la technologie d'evolution a long terme |
| 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 |
| US10986019B2 (en) * | 2017-05-09 | 2021-04-20 | Proofpoint, Inc. | IP address and routing schemes for overlay network |
| US11095507B2 (en) | 2017-05-09 | 2021-08-17 | Proofpoint, Inc. | Globally-distributed secure end-to-end identity-based overlay network |
| CN108200138A (zh) * | 2017-12-26 | 2018-06-22 | 广东欧珀移动通信有限公司 | 专用承载的建立方法及相关设备 |
| KR102667260B1 (ko) * | 2018-09-19 | 2024-05-21 | 삼성전자주식회사 | 패킷을 필터링하는 전자 장치 및 그 작동 방법 |
| US11689498B1 (en) * | 2022-02-09 | 2023-06-27 | Rakuten Mobile, Inc. | Internet protocol address generation |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020012320A1 (en) * | 2000-03-16 | 2002-01-31 | Ogier Richard G. | Mobile ad hoc extensions for the internet |
| US20020150112A1 (en) * | 1996-11-01 | 2002-10-17 | Hitachi, Ltd. | Communication method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus |
| WO2003007544A2 (fr) * | 2001-07-10 | 2003-01-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Gabarit de flux de trafic pour la gestion de flux de donnees par paquets |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
| CA2403628C (fr) * | 2000-03-20 | 2007-05-01 | At&T Corp. | Selection de services dans un reseau a acces partage avec demarche de routage |
| US6621793B2 (en) * | 2000-05-22 | 2003-09-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Application influenced policy |
| US7099326B2 (en) | 2001-02-23 | 2006-08-29 | Nokia Inc. | System and method for fast GPRS for IPv6 communications |
| EP1371242A1 (fr) * | 2001-03-14 | 2003-12-17 | Nokia Corporation | Procede permettant d'activer une connexion dans un systeme de communication, station mobile, element reseau et filtre de paquets |
| 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 | 株式会社エヌ・ティ・ティ・ドコモ | モバイルｉｐ通信システム、モバイルｉｐ通信方法、ネットワーク中継装置及び移動体端末 |
| US20030026230A1 (en) | 2001-08-02 | 2003-02-06 | Juan-Antonio Ibanez | Proxy duplicate address detection for dynamic address allocation |
| DE60216791T2 (de) * | 2001-10-05 | 2007-10-18 | Nokia Corp. | Adressenübergang und korrelation von nachrichten zwischen netzknoten |
| WO2003032668A1 (fr) * | 2001-10-05 | 2003-04-17 | Nokia Corporation | Procede et systeme pour transferts dans un reseau de service general de radiocommunication en mode paquet (gprs) avec des noeuds prenant en charge differentes versions internet |
| AU2003205797A1 (en) * | 2002-02-13 | 2003-09-04 | Nokia Corporation | Filtering of data packets in a communication network according to interface identifiers |
| US7286536B2 (en) * | 2002-10-28 | 2007-10-23 | Nokia Corporation | Method and system for early header compression |
-
2003
- 2003-02-21 KR KR20030011133A patent/KR100886551B1/ko not_active IP Right Cessation
-
2004
- 2004-02-18 GB GB0403484A patent/GB2400278B/en not_active Expired - Fee Related
- 2004-02-20 JP JP2004045336A patent/JP4006407B2/ja not_active Expired - Fee Related
- 2004-02-20 US US10/781,865 patent/US20040205247A1/en not_active Abandoned
- 2004-02-20 FR FR0401709A patent/FR2852472B1/fr not_active Expired - Fee Related
- 2004-02-20 IT ITMI20040297 patent/ITMI20040297A1/it unknown
- 2004-02-21 CN CNB2004100330718A patent/CN1279731C/zh not_active Expired - Fee Related
- 2004-02-23 DE DE200410008720 patent/DE102004008720B4/de not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020150112A1 (en) * | 1996-11-01 | 2002-10-17 | Hitachi, Ltd. | Communication method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus |
| US20020012320A1 (en) * | 2000-03-16 | 2002-01-31 | Ogier Richard G. | Mobile ad hoc extensions for the internet |
| WO2003007544A2 (fr) * | 2001-07-10 | 2003-01-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Gabarit de flux de trafic pour la gestion de flux de donnees par paquets |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20040075582A (ko) | 2004-08-30 |
| US20040205247A1 (en) | 2004-10-14 |
| FR2852472B1 (fr) | 2006-02-10 |
| JP2004260818A (ja) | 2004-09-16 |
| DE102004008720B4 (de) | 2009-03-19 |
| JP4006407B2 (ja) | 2007-11-14 |
| ITMI20040297A1 (it) | 2004-05-20 |
| CN1279731C (zh) | 2006-10-11 |
| CN1531287A (zh) | 2004-09-22 |
| GB2400278B (en) | 2006-06-21 |
| GB0403484D0 (en) | 2004-03-24 |
| DE102004008720A1 (de) | 2004-09-16 |
| GB2400278A (en) | 2004-10-06 |
| KR100886551B1 (ko) | 2009-03-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2852472A1 (fr) | Appareil et procede pour le filtrage par modele de flux de trafic dans un systeme de communication mobile | |
| EP1665661B1 (fr) | Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets | |
| US7225259B2 (en) | Service tunnel over a connectionless network | |
| US8885644B2 (en) | Compressed IP flow recognition for in-line, integrated mobile DPI | |
| FR2835135A1 (fr) | Appareil et procede pour reclasser des modeles de flux de trafic dans un systeme de communication mobile | |
| EP1267530B1 (fr) | Procédé de transmission de paquets IP à travers un système cellulaire de radiocommunication, et equipements du système cellulaire pour la mise en oeuvre de ce procédé | |
| EP1808994A1 (fr) | Dispositif de commutation à transport universel de trames de paquets de données | |
| KR20060054662A (ko) | 광대역 무선 통신 시스템에서 헤더 압축 장치 및 방법 | |
| JP5426017B2 (ja) | モバイル・ブロードバンド・デバイス用の専用ゲートウェイ | |
| EP3949287B1 (fr) | Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic | |
| EP3235217B1 (fr) | Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants | |
| EP3503499B1 (fr) | Procédé d'optimisation de l'efficacité spectrale dans un contexte d'interconnexion mpls | |
| WO2010094882A1 (fr) | Procede de commutation de noeud d'acces | |
| WO2008145901A1 (fr) | Procede et dispositif d'interface entre les protocoles udp ou tcp et sctp | |
| WO2017162071A1 (fr) | Nœud de réseau, procédé et dispositif pour communiquer entre des nœuds de réseau, et support de stockage | |
| EP1055312B1 (fr) | Procede de transmission de donnees entre deux reseaux en mode paquet | |
| FR3089732A1 (fr) | Terminal pouvant être connecté simultanément à plusieurs réseaux d’accès, procédé de différentiation de trafic émis par le terminal, dispositif et procédé de gestion du trafic. | |
| EP2890026A1 (fr) | Procédé de communication mis en oeuvre par un noeud de relais | |
| EP3895477A1 (fr) | Selection d'un réseau en fonction de caractéristiques réseau temps réel | |
| FR2818064A1 (fr) | Procede pour utiliser un terminal sans fil, dans un reseau local conforme a la norme ieee 802.1q et dispositif d'interface radio pour la mise en oeuvre de ce procede | |
| JP2005057558A (ja) | 接続サーバ振り分け方法及びパケット交換装置 | |
| FR2778297A1 (fr) | Procede de transmission de donnees entre deux reseaux en mode paquet | |
| FR2947123A1 (fr) | Procedes de transmission entre un emetteur et un recepteur, et un recepteur, avec transmission d'une donnee additionnelle en fonction de la longueur d'au moins deux paquets, emetteur et recepteur correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| ST | Notification of lapse |
Effective date: 20181031 |