Brevet FR2963196A1 — publié le 20120127

SYSTEME POUR GERER L'ALLOCATION DES RESSOURCES D'UN LIEN SATELLITE DANS UN RESEAU DE TELECOMMUNICATION L'invention concerne un système permettant à un réseau utilisateur d'attribuer les ressources d'un lien satellite dans un réseau de télécommunication de façon à assurer une excellente qualité de service tout en réduisant le coût du service. Le système selon l'invention permet notamment d'allouer de 10 manière dynamique (automatiquement) des canaux de dimensions optimisées à débit garanti d'Inmarsat BGAN par exemple. De manière plus générale, le système peut être mis en oeuvre dans tout réseau de télécommunication utilisant des règles TFT ayant pour fonction d'affecter des trames identifiées par des discriminateurs vers des 15 contextes PDP (initiales de protocole de paquets de données ou en anglo-saxon « packet data protocol ») secondaires de type « streaming », par exemple GPRS abréviation anglo-saxonne de General Packet Radio Service. Les initiales TFT plus connues par l'expression « anglo-saxonne » Trafic Flow Template » désignent une série de filtres qui assure un chemin 20 déterminé pour des applications dont le flux est identifié par les filtres TFT. Dans la description qui suit le mot « streaming » désigne une classe de services satcom garantissant un débit garanti (utilisé principalement pour les applications temps réel). Le mot « transceiver » est utilisé pour désigner un transcepteur ayant notamment pour fonction de 25 diffuser un signal d'entrée vers plusieurs sorties. Le système se présente sous la forme d'une plate-forme embarquée qui peut être à bord d'un aéronef, d'un navire, d'un véhicule ou dans une valise et d'une plate-forme sol qui s'interface avec les réseaux publics ou privés. La plate-forme embarquée sert un réseau utilisant le 30 protocole Internet IP sur lequel sont connectés des équipements informatiques (données, voix ou phonie, vidéo etc...). Dans les réseaux de télécommunication utilisant un satellite, deux types de catégorie de services sont proposés : - Un service de type best effort où l'utilisateur paye au Méga octet consommé, mais il n'a pas de garantie de qualité de service. C'est-à-dire que s'il y a beaucoup d'utilisations simultanées sur le lien satellite, la qualité est fortement dégradée. Pour des services de téléphonie sur IP (Internet Protocol) ou pour de la visioconférence, cela est rédhibitoire. - Un service de type streaming pour lequel l'utilisateur paye à la durée de connexion (prix très élevé), mais qui, en contrepartie, a une garantie de service qui lui permet d'assurer des services temps réels, comme la voix ou la vidéo ou encore une utilisation prioritaire de la ressource satellite Ces services sont actuellement ouverts de façon manuelle en fonction du besoin d'un utilisateur. Une session dans le mode Best Effort est initialisée pour les transmissions sans garantie de bande passante et si un besoin de garantie de bande passante est nécessaire, alors la session Best effort est arrêtée au profit de l'ouverture d'une session « streaming ». Ce mode de fonctionnement est contraignant, imposant de fait pour les utilisateurs de rester pour des raisons de simplicité dans le mode Best Effort. Ajouter à cela, il faut choisir la taille du streaming que l'on veut ouvrir. Dans le cas de Services qui peuvent fluctuer (comme la téléphonie par exemple pour laquelle il est difficilement concevable de savoir combien de personnes vont appeler, quand et pour quelle durée), la ressource doit rester ouverte quasi en permanence. Cela engendre des coûts de communication prohibitifs (par exemple, un streaming de 128 kbps possède un coût d'exploitation très élevé). Les solutions proposées sur le marché sont : - Soit très onéreuses, car la ressource streaming est surdimensionnée par rapport au besoin (en temps de connexion et en taille de streaming), donc avec un coût d'utilisation très grand, - Soit de mauvaise qualité. En utilisant le Best Effort, il n'y a pas de qualité de service, au bout de quelques communications, la qualité se dégrade de façon significative. D'autre part, ces méthodes ne résolvent pas, notamment, l'identification des besoins et la mise en oeuvre de l'ouverture et de la fermeture des ressources de façon dynamique. L'objet de la présente invention concerne un système qui est applicable notamment à des transmissions de données qui nécessitent une bande passante garantie et dont on ne connaît ni le volume à transmettre, ni la durée. La solution proposée permet d'ouvrir et de fermer ces ressources de façon dynamique, en fonction du besoin d'un utilisateur donné. La solution permet d'ouvrir un canal streaming dès que l'utilisateur passe une communication ou transmet des données nécessitant une bande garantie, et libère le canal dès que la communication est terminée. L'objet de l'invention concerne un gestionnaire de service destiné à être positionné dans un réseau de télécommunications mettant en oeuvre un satellite et un ou plusieurs réseaux utilisateurs, le protocole de communication s'appuyant sur la norme 3G ou mettant en oeuvre des règles TFT et PDP, caractérisé en ce qu'il comporte au moins les modules suivants : - un module de configuration de lien qui contient une ou plusieurs configurations statiques, pouvant être modifiées par un utilisateur, - une première entrée qui permet à un utilisateur de spécifier des données TFT à utiliser, - quatre sorties : une première sortie qui est reliée à un gestionnaire des évènements externes, une deuxième sortie, reliée au gestionnaire de TFT, une troisième sortie, reliée à un module détecteur de trafic, une quatrième sortie, reliée à un gestionnaire de contexte secondaire PDP. - un module gestionnaire des évènements externes comprenant : - une entrée recevant des informations du module configuration des liens, - une sortie transmettant des informations vers le gestionnaire des TFT, - un module détecteur de trafic qui scanne chaque paquet IP transmis entre un réseau utilisateur et un satellite, ledit détecteur comprenant les 35 sous-modules suivants : - un module conteneur de plugins de création/suppression de règles TFTs comportant une entrée, recevant des informations du module configuration des liens, une sortie transmettant des informations sur les paramètres de trafic détecté, la classe, etc. vers le gestionnaire des TFT, - un module ou « plug-in » détecteur de trafic de TFTs configurés qui comporte : - une entrée recevant les informations du module de configuration des liens, - une sortie qui transmet des informations vers le gestionnaire de contexte secondaire PDP, telles que les TFT activées qui sont détectées dans le flux, le contexte secondaire des PDP, - un module de gestion des TFT comportant : - trois entrées : une première entrée recevant les informations du module de configuration des liens, une deuxième entrée qui reçoit des informations du gestionnaire d'évènement externe, une troisième entrée qui des informations sur les paramètres de trafic analysé, la classe, etc, - deux entrées/sorties : Une première entrée/sortie en liaison avec le transceiver qui permet la communication des « get created status », une deuxième entrée/sortie vers le gestionnaire de manager des contextes secondaires PDP qui échange des informations de type Get/release free PDP contents, - une sortie vers le transceiver T qui va créer des TFT et les lier à un contexte disponible ou bien supprimer des TFT, - un module de gestion de contexte secondaire des PDP; le module comprend : - trois entrées : une première entrée qui reçoit des informations du module de configuration, une deuxième entrée qui reçoit des informations du gestionnaire des TFT, une troisième entrée qui reçoit des informations de la part du plugin détecteur de trafic de TFTs configurés, - une sortie qui transmet les ordres d'activation ou de désactivation au transceiver pour tous les contextes PDP secondaires, - une entrée/sortie en liaison avec le transceiver pour les statuts de requête/réponse pour les contextes. Le module détecteur de trafic comprend, par exemple, au moins un des sous-modules suivants : - le plugin de détection de paquets spécifiques ; détecte un paquet simple qui correspond à un diagramme ou pattern, le plugin de détection de type de trafic, détecte la présence d'un flux de trafic d'un type spécifié, - le plugin de détection d'autres trafics ; détecte d'autres critères caractérisant un trafic. Ces dispositifs étant connus de l'Homme du métier sous les abréviations anglo-saxonnes suivantes : "Specific packet detection plugin, trafic type detection plugin, other trafic specification detection plugin." Le gestionnaire de service selon l'invention est, par exemple, utilisé dans un système de télécommunications Inmarsat ou dans un système de télécommunications mobile. D'autres caractéristiques et avantages du dispositif selon l'invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : - La figure 1, un exemple d'architecture d'un système de télécommunication avec satellite, - La figure 2, un schéma de « streaming », - La figure 3, un exemple d'un exemple d'architecture du système selon l'invention disposé entre un réseau utilisateur LAN et un système émetteur/récepteur, routeur. Afin de mieux faire comprendre l'objet de la présente invention, la description qui suit va être donnée dans le cadre d'une utilisation dans un système Inmarsat BGAN, fonctionnant avec le protocole de communication 3GPP qui permet d'assurer une maintenance et un développement des spécifications techniques pour les normes mobiles GSM (abréviation anglo- saxonne de Global System Mobile), GPRS (General Packet Radio Service) , EDGE (Enhanced Data Rate), par exemple. L'idée de la présente invention repose sur l'utilisation d'un serveur ajouté à un réseau de télécommunication par satellite existant de type Inmarsat BGAN. Celui-ci est embarqué dans la plate-forme servant les communications (avion, bateau, etc.). Ce serveur a notamment pour fonction de gérer l'ouverture et la fermeture des canaux streaming d'Inmarsat BGAN. De manière plus générale, elle s'applique dans tous les réseaux de télécommunications qui utilisent un mécanisme de gestion de contexte PDP primaires et secondaires et sur le mécanisme TFT. La figure 1 décrit un exemple d'architecture de télécommunications comprenant un réseau Inmarsat BGAN, 1, qui communique avec une plate-forme embarquée E dans laquelle se trouve un module Satcom 2, relié un réseau 3 de données et de transport IP, l'ensemble étant géré par le serveur 4 de gestion satcom. Sur le réseau de transport sont par exemple connectés un dispositif de visio conférence VC, un PC standard, un dispositif Voix sur IP ou VIP. Le réseau Inmarsat BGAN 1 est aussi relié dans cet exemple de mise en oeuvre à une plate-forme sol 6 qui sert un réseau IP sur lequel sont connectés des services de type VIP office, Internet, Visio conférence. Sur la figure 1, le schéma I correspond au service vidéo streaming à 128 K permettant la communication entre les systèmes de visio conférence, le schéma Il pour le service Best Effort utilisé pour le transport et l'échange de données, le schéma III étant réservé aux communications de type voix sur IP ou VIP. La plate-forme embarquée E peut se trouver à bord d'un aéronef, d'un navire, d'un véhicule ou dans une valise et la plate-forme sol s'interface avec les réseaux publics ou privés selon des techniques connues de 3o l'Homme du métier. Les explications qui vont suivre peuvent être mises en oeuvre dans tout type de réseau de télécommunication satellitaire fonctionnant avec le protocole de communication 3GPP. Le service de communication Inmarsat BGAN, permet de créer 35 plusieurs liens réseau entre un terminal Satcom et le réseau Inmarsat terrestre. Pour ce faire, il est possible d'affecter plusieurs adresses IP pour un même terminal satcom, chaque adresse IP étant affectée à un lien. Ce lien est appelé « link » par Inmarsat et est associé à un contexte primaire. Le terme « contexte » désigne l'environnement dans lequel se déroulent les transmissions de données. Chaque type de trafic que l'on souhaite différencier est associé à un contexte PDP secondaire par les règles TFT. La règle TFT qui permet d'activer les canaux de streaming pour transmettre les communications est une règle définie par la taille des trames traitées. Tous les canaux d'un même « lien » ont une même adresse, celle du « lien » ou « link ». Cette solution est adaptable pour chaque type de trafic identifiable dans les règles TFT (ex : la voix sur IP VoIP, données vidéo, etc...). Elle permet pour les données d'avoir des transmissions en bande non garantie et des transmissions en bande garantie avec activation et libération du canal de façon dynamique. La figure 2 est un exemple de schéma de service « streaming ». L'implémentation mise en oeuvre s'appuie, par exemple, sur le mécanisme Inmarsat BGAN de gestion des contextes PDP primaires et secondaires et sur le mécanisme de TFT. Le réseau Inmarsat BGAN gère, par exemple, les ressources au moyen des contextes Packet Data Protocol ou PDP. Chaque connexion de données entre le terminal Satcom de la plate-forme mobile et le réseau Inmarsat est décrite par son PDP. Le contexte PDP qui est négocié entre le terminal et le réseau Inmarsat BGAN contient les éléments de description de la connexion et en particulier le routage par l'Access Point Name ou APN qui est le point de sortie du réseau Inmarsat BGAN, la qualité de service QoS, Best Effort, Streaming, et la facturation associée à ces données. Un ou des contextes primaires Inmarsat BGAN sont ouverts avec la qualité de service BestEffort pour les trafics ne nécessitant pas de bande garantie. Un ou des contextes secondaires sont créés mais non activé pour chaque type de trafic nécessitant un mode Streaming. Les contextes secondaires d'un même contexte PDP primaire partagent le même APN et la même adresse IP que le lien primaire auquel ils sont attachés, en revanche, leur qualité de service peut être différente. Le contexte Inmarsat BGAN primaire, Link, est activé au démarrage. Les contextes Inmarsat BGAN secondaires, canaux, sont créés juste après l'établissement du contexte primaire mais ne sont pas activés. Règles TFT Le TFT est une série de filtre qui assure un chemin déterminé pour des applications dont le flux est identifié par les filtres TFT. L'application des règles TFT est basée sur la connaissance : des caractéristiques du ou des trafics qui utiliseront le streaming utilisées pour transporter les appels. Par exemple, au plus 8 règles TFT peuvent être définies par contexte PDP dans le système et 11 contextes PDP peuvent être activés simultanément par terminal. Chaque règle TFT peut utiliser un ou plusieurs critères parmi la liste disponible. Ces critères sont applicables en liaison montante « uplink » ou descendante « downlink ». Les règles TFT peuvent être créées de manière dynamique et les caractéristiques de création de ces règles sont dans un fichier de configuration de l'application de gestion du satcom. La figure 3 décrit les différents modules implémentés dans le gestionnaire de la qualité de Service permettant d'assurer une qualité de service pour un utilisateur réseau LAN. Le gestionnaire de qualité de service 10 selon l'invention est disposé entre le réseau LAN d'un utilisateur et le transceiver T (figure 3) du 25 réseau de télécommunication satellitaire. Ce gestionnaire de service 10 comporte au moins les éléments suivants : un module 11 de configuration de lien qui contient la configuration statique, pouvant être modifiée par un utilisateur. Le module 11 de configuration de 30 liens comprend, par exemple, - une entrée 11 i qui permet à un utilisateur de spécifier des données TFT à utiliser - 4 sorties : une première sortie 112 qui est reliée à un gestionnaire des évènements externes, une deuxième sortie 113, reliée au gestionnaire 35 de TFT, une troisième sortie 114, reliée à un module détecteur de trafic 13, une quatrième sortie115, reliée à un gestionnaire de contexte secondaire PDP. Le module de configuration des liens contient les informations suivantes : - le mode création TFT : soit via des informations d'un détecteur de trafic ou d'un évènement externe, - la spécification d'évènements externes : si le mode création TFT est généré par un évènement externe, alors le module de configuration de lien contient la spécification de l'évènement, - le « plugin » de création de mode TFT utilisé : si le mode création TFT est généré par l'détecteur de trafic alors la spécification du « plugin »utilisé est présente, - le modèle de création TFT : squelette du TFT avec la spécification de paramètres dynamiques pour laquelle la valeur sera définie jusqu'à détection de trafic ou d'autres moyens ... - les IDs alloués pour le contexte secondaire - le mode de suppression de TFT soit via l'détecteur de trafic ou au moyen d'un évènement externe - l'évènement de suppression de TFT : si le mode de suppression TFT est généré par l'évènement externe, alors la spécification de l'évènement - un plugin d'effacement de TFT utilisé si le mode suppression de TFT est généré par l'détecteur de trafic, alors le module de configuration des liens contient la spécification du plugin de l'détecteur de trafic utilisé (ref TFT création/suppression ci-dessous). Ce fichier est configuré, par exemple, à l'initialisation du système. Il est aussi possible de spécifier des éléments du TFT comme des éléments dynamiques qui vont dépendre du trafic ou du flux de trafic analysé. Ainsi, on peut avoir des TFT statiques ou des TFT dynamiques. A l'initialisation du gestionnaire dynamique de la qualité de service, la configuration du système, contenant la qualité de service (QoS) à appliquer en fonction du trafic comme indiqué ci-dessus, va être transmise aux différents modules. Un module gestionnaire des évènements externes 12 qui a notamment pour fonction de gérer les évènements spécifiés en fonction d'une configuration donnée et qui va requérir la création ou la suppression d'un TFT, Le module gestionnaire des évènements externes comporte, par exemple, - une entrée 121 recevant des informations du module configuration des 5 liens, - une sortie 122 transmettant des informations vers le gestionnaire des TFT Un module détecteur de trafic 13 qui scanne chaque paquet IP transmis au sein du système. L'détecteur de trafic IP contient les sous-modules suivants : 10 Un module 14 « conteneur » de plugins de création/suppression de TFTs Des plugins de création/suppression de TFT combinent la configuration des liens avec des filtres prédéfinis pour créer un diagramme de trafic spécifique qui peut être détecté dans le flux de trafic IP. Dès détection, il générera des requêtes pour la création ou la suppression des TFTs pour un contexte 15 spécifique. Le plugin peut être pris dans la liste suivante - Le plugin de détection de paquets spécifiques ; détecte un paquet simple qui correspond à un diagramme ou pattern, 20 - Le plugin de détection de type de trafic, détecte la présence d'un flux de trafic d'un type spécifié, 21 20 - Le plugin de détection d'autres trafics ; détecte d'autres critères caractérisant un trafic (par exemple, la taille d'un paquet), 22 Le module 14 comporte une entrée 141, recevant des informations du module configuration des liens, une sortie 142 transmettant des informations sur les paramètres de trafic analysé, la classe, etc. vers le gestionnaire des 25 TFT 16 Le plugin détecteur de trafic de TFTs configurés 15 ; détecte le trafic correspondant au diagramme de trafic spécifié dans les TFTs créés et informe le gestionnaire de contexte secondaire PDP de cette détection Le détecteur de trafic de TFT configurés comporte, par exemple, 30 - une entrée 151 qui reçoit les informations du module de configuration des liens, - une sortie 152 qui transmet des informations vers le gestionnaire de contexte secondaire PDP, telles que les TFT activés qui sont détectées dans le flux, le contexte secondaire des PDP. Un module de gestion des TFT 16: crée et supprime les TFTs ; gère le statut des TFTs des contextes au niveau du récepteur/émetteur et informe le plug-in détecteur de trafic des TFTs configurés du statut des contextes. Le module de gestion 16 comporte : - trois entrées : 161 recevant les informations du module de configuration des liens, une entrée 162 qui reçoit des informations du gestionnaire d'évènement externe, une entrée 163 qui des informations sur les paramètres de trafic analysé, la classe, etc, - deux entrées/sorties 165 en liaison avec le transceiver qui permet la communication des « get created status », 164 vers le gestionnaire de manager des contextes secondaires PDP qui échange des informations de type Get/release free PDP contents, - une sortie 167 vers le transceiver T qui va créer des TFTS et les lier à un contexte disponible ou bien supprimer des TFTs Un module secondaire de gestion de contexte des PDP, 17; active et désactive les contextes, gère le statut du contexte du transceiver. Le module 17 comprend trois entrées : - 171 qui reçoit des informations du module de configuration, - 172 qui reçoit des informations du gestionnaire des TFT, - 173 qui reçoit des informations de la part du plugin détecteur de trafic de TFTs configurés, une sortie 175 qui transmet les ordres d'activation ou de désactivation au 25 transceiver pour tout les contextes PDP secondaires, une entrée/sortie 174 en liaison avec le transceiver pour les status de requête/réponse pour les contextes. La flèche F désigne un trafic bidirectionnel des données ou des flux d'information entre un réseau utilisateur LAN et le transceiver T. 30 Le fonctionnement du système décrit à la figure 3 peut comporter les étapes listées ci-après. Au démarrage, la configuration du système est distribuée dans les modules du gestionnaire de la qualité de service selon l'invention. II existe 35 donc une préconfiguration en statique. Dans le cas où des TFTs devraient être créés en fonction de l'analyse du flux, alors l'détecteur de trafic sera configuré pour détecter le trafic correspondant en utilisant des plugins d'analyse de flux adaptés. Dès détection d'un trafic correspondant à un critère de creation de TFT, alors l'détecteur de trafic informe le module de gestion des TFT. Cette information peut comporter des paramètres TFT et la classe de trafic ; Le gestionnaire TFT va demander au gestionnaire de contexte PDP secondaire, un contexte PDP disponible et il va créer un ou plusieurs TFTs, selon une configuration donnée, et va lier ces TFTs au contexte PDP alloué à une classe spécifiée. Le gestionnaire TFT va contrôler le statut du transceiver pour assurer la persistance des TFTs sensés être créées. Le plugin de détection des TFT configurés détectera le trafic sur 15 les TFTs créés et dès détection, informera le gestionnaire du contexte secondaire PDP. Le gestionnaire du contexte secondaire PDP va activer ensuite le contexte pertinent, de manière à avoir le trafic correspondant à la TFT identifiée, dirigé vers ce contexte. 20 Dès détection d'un trafic correspondant à une TFT en place par le plugin de détection des TFTs configurés, l'détecteur de trafic informera le module de gestion des TFTs, et de manière optionnelle spécifiera des paramètres des TFTs. Le plugin de détection des règles TFTs configurées détectera 25 l'absence prolongée de trafic présent précédemment et informera le gestionnaire des contextes PDP secondaires qui désactivera le contexte correspondant. Le gestionnaire des TFTs supprimera les TFTs pertinents. Une autre manière de procéder, sans sortir du cadre de 3o l'invention, consiste à utiliser le gestionnaire d'évènement à la place de l'détecteur de trafic IP. Le système selon l'invention permet à un utilisateur de réseau de télécommunication de type Satcom Inmarsat BGAN de ne plus se soucier de l'ouverture ou de la fermeture des ressources Satcom, tout en ayant une garantie d'optimisation de ces ressources et une garantie de qualité de service. Le système selon l'invention permet de : Transmettre du trafic dans le best effort : - Internet - FTP - Signalisation de type téléphonie (SIP) D'affecter la communication à un canal ayant une qualité de service garantie dès que le besoin est établi et correspond à une règle TFT Le paiement à la minute du débit garanti n'est déclenché qu'à l'établissement de la transmission Transmettre du trafic en streaming - Vidéo - Voix (SIP) - Data prioritaire (VIP) - Données sensibles avec garantie d'acheminement De libérer la ressource garantie dès que la communication est raccrochée, le paiement à la minute du débit garanti est arrêté REVENDICATIONS1 - Gestionnaire de service (10) destiné à être positionné dans un réseau de télécommunications mettant en oeuvre un satellite et un ou plusieurs réseaux utilisateurs, le protocole de communication s'appuyant sur la norme 3G ou mettant en oeuvre des règles TFT et PDP, caractérisé en ce qu'il comporte au moins les modules suivants : - un module (11) de configuration de lien qui contient une ou plusieurs 10 configurations statiques, pouvant être modifiées par un utilisateur, - une entrée (11 I) qui permet à un utilisateur de spécifier des données TFT à utiliser, - quatre sorties : une première sortie (112) qui est reliée à un gestionnaire des évènements externes, une deuxième sortie (113), 15 reliée au gestionnaire de TFT, une troisième sortie (114), reliée à un module détecteur de trafic (13), une quatrième sortie (115), reliée à un gestionnaire de contexte secondaire PDP, - un module gestionnaire des évènements externes (12) comprenant une entrée (121) recevant des informations du module configuration des 20 liens, une sortie (122) transmettant des informations vers le gestionnaire des TFT, - un module détecteur de trafic (13) qui scanne chaque paquet IP transmis au sein du système entre un réseau utilisateur et un satellite, ledit détecteur comprenant les sous-modules suivants : 25 - un module (14) conteneur de plugins de création/suppression de TFTs comportant une entrée (141), recevant des informations du module configuration des liens, une sortie (142) transmettant des informations sur les paramètres de trafic analysé, la classe, etc. vers le gestionnaire des TFT (16), 30 - un plugin détecteur de trafic de TFTs configurés (15) qui comporte : - une entrée (151) qui reçoit les informations du module de configuration des liens, - une sortie (152) qui transmet des informations vers le gestionnaire de contexte secondaire PDP, telles que les TFT activées qui sont 35 détectées dans le flux, le contexte secondaire des PDP, - un module de gestion des TFT (16) comportant - trois entrées : une première entrée (161) recevant les informations du module de configuration des liens, une deuxième entrée (162) qui reçoit des informations du gestionnaire d'évènement externe, une troisième entrée (163) qui des informations sur les paramètres de trafic analysé, la classe, etc, - deux entrées/sorties : (165) en liaison avec le « transceiver » qui permet la communication des créations de statut ou « get created status », (164) vers le gestionnaire de manager des contextes secondaires PDP qui échange des informations de type Get/release free PDP contents, - une sortie (167) vers le « transceiver » T qui va créer des règles TFTS et les lier à un contexte disponible ou bien supprimer des TFTs - un module de gestion de contexte secondaire des PDP, (17), ledit module (17) comprend - trois entrées : une première entrée (171) qui reçoit des informations du module de configuration, une deuxième entrée (172) qui reçoit des informations du gestionnaire des TFT, une troisième entrée (173) qui reçoit des informations de la part du plugin détecteur de trafic de TFTs configurés, - une sortie (175) qui transmet les ordres d'activation ou de désactivation au transceiver pour tous les contextes PDP secondaires, - une entrée/sortie (174) en liaison avec le transceiver pour les statuts de requête/réponse pour les contextes. 2 - Système selon la revendication 1 caractérisé en ce que le module détecteur de trafic (13) comprend au moins un des sous-modules suivants : - un plugin de détection de paquets spécifiques qui détecte un paquet simple qui correspond à un diagramme ou pattern, (20), - un plugin de détection de type de trafic, détectant la présence d'un flux de trafic d'un type spécifié, (21), - un plugin de détection d'autres trafics détectant d'autres critères caractérisant un trafic, (22). 3 - Système selon l'une des revendications 1 ou 2 caractérisé en ce qu'il est utilisé dans un système de télécommunications Inmarsat. 4 - Système selon l'une des revendications 1 ou 2 caractérisé en ce qu'il est utilisé dans un système de télécommunications mobile.