INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
PROCEDE DE TEST D'UN SYSTEME DE COMMUTATION, ET DISPOSITIF D'INSERTION UTILISABLE DANS CE PROCEDE La présente invention concerne les réseaux de télécommunications utilisant des transmissions de données par paquets. Un domaine d'application principal, mais non exclusif, est celui du test et de la métrologie effectués sur les équipements constituant de tels réseaux, aussi bien en laboratoire qu'en conditions opérationnelles. Un exemple d'application, illustré par la figure 1, est celui du test d'équipements de réseau (par exemple des routeurs, des commutateurs ou des multiplexeurs). Un système en test (SET), composé d'un ou plusieurs équipements de commutation, est connecté à un équipement de test appelé ici source de trafic (SDT). La SDT injecte du trafic (données et contrôle) vers le SET à travers une interface J1, et observe le trafic relayé par le SET vers l'interface J2. De plus en plus de protocoles utilisés dans les réseaux de communication par paquets, en particulier les réseaux de type IP ( Internet Protocol ) ou ATM ( Asynchronous Transfer Mode ), nécessitent pour être testés une cohérence entre les informations fournies dans le plan de contrôle, autrement dit les états établis dans le SET, et le contenu du trafic de test injecté vers le SET. Ces protocoles peuvent être par exemple LDP ( Label Distribution Protocol ), TDP ( Tag Distribution Protocol ), RSVP ( Resource reSerVation Protocol ), PIM ( Protocol Independent Multicast IGMP ( Internet Group Membership Protocol ), PNNI ( Private Network Network Interface ), etc. Dans une solution naturelle permettant d'assurer cette cohérence faut implanter ces protocoles dans les équipements de test jouant le rôle SDT. Ceci pose plusieurs difficultés - la nécessité de s'assurer de l'interopérabilité entre l'implantation du protocole dans le SET et dans la SDT ; - l'impossibilité de tester des SET utilisant des protocoles propriétaires, c'est-à-dire dont les spécifications ne sont donc pas accessibles fabricants de SDT ; - l'accroissement du coût des équipements de test dû aux volumineux développements logiciels nécessaires pour implanter les protocoles contrôle ; - le temps de développement nécessaire pour implanter dans la SDT ces protocoles de contrôle.
Un contournement possible du problème exposé ci-dessus illustré par la figure 2. II consiste à multiplexer vers le SET deux flux de trafic sur la même interface 11 - le trafic de test issu de la SDT ; - des données et informations issues d'un équipement de réseau noté C1, situé en amont du SET. C'est alors ce dernier qui a pour rôle créer les états dans le SET à travers les protocoles de contrôle.
De plus, si l'équipement C1 et le SET sont issus du même constructeur, les problèmes d'interopérabilité entre les différentes implantations des protocoles disparaissent.
II est aisé d'insérer du trafic sur une interface en service d'un équipement de commutation quand celle-ci supporte un protocole de couche liaison conçu pour résoudre les collisions, ce qui est le cas des interfaces de type LAN ( Local Area Network ), par exemple Ethernet 10 ou 100 Mbitls. Dans le cas d'une interface Ethernet à 1 Gbitls, il devient impératif d'insérer un commutateur de trames de couche liaison.
L'augmentation des débits et l'évolution des techniques fait que les interfaces utilisées dans les coeurs de réseau sont de type point à point , c'est-à-dire qu'elles incluent pas de multiplexage dans une couche de contrôle d'accès au médium (MAC, Médium Access Control ). Tel est cas des interfaces ATM, POS ( Packet Over Sonet ) ou encore IP WDM ( 11Vavelength Division Multiplexing ). La délimitation des paquets est effectuée par des protocoles de couche liaison spécifiques à chaque norme d'interface (ATM, POS, etc.). Ces interfaces ne permettent pas d'insérer des paquets directement sur le médium physique selon la configuration présentée sur la figure 2 (insertion du flux en provenance de la SDT sur l'interface 11). En conséquence, le contournement évoqué ci-dessus n'est plus possible, et on est ramené à la solution initiale (implantation des protocoles de contrôle dans la SDT) avec les inconvénients mentionnés.
Un but de l'invention est de proposer une solution au problème d'insertion de paquets sur un lien de transmission de type point à point, solution qui soit de préférence simple et de faible coût.
L'invention propose ainsi un procédé de test d'un système de commutation recevant des unités de données selon un format d'interface de transmission point à point en provenance d'un équipement de réseau externe, les unités de données transportant des paquets d'un protocole de couche supérieure. Selon ce procédé, on traite des premières unités de données provenant de l'équipement de réseau externe pour récupérer des premiers paquets transportés par les premières unités de données, on génère un trafic de test porté par des seconds paquets dudit protocole de couche supérieure, on multiplexe les premiers et seconds paquets pour former un flux de paquets multiplexés, on convertit le flux de paquets multiplexés en secondes unités de données selon ledit format d'interface de transmission point à point; on transmet les secondes unités de données vers le système de commutati Les unités de données sont traitées entre le système en test et l'équipement externe au moyen de modules d'interface standards disponibles à faible coût. Le multiplexage est effectué au niveau des paquets du protocole de couche supérieure, ce qui évite les problèmes de délimitation des éléments d'information. Ce protocole est typiquement de couche réseau (couche du modèle ISO), par exemple un protocole IP ( Internet Protocol , Request for Comments 791 publiée par l'Internet Engineering Task Force, septembre 1981). L'insertion du trafic de test peut être effectuée directement à partir de paquets générés par la source de trafic si le multiplexeur de paquets la source de trafic appartiennent à la même unité. Dans une autre réalisation, la source de trafic est une unité séparée du dispositif d'insertion. La génération du trafic de test comprend alors la production d'un flux d'unités de données selon un format d'interface déterminé, transportant lesdits seconds paquets, et un traitement dudit flux d'unités de données pour récupérer les seconds paquets.
L'équipement de réseau externe sert avantageusement d'intermédiaire pour commander des états du système de commutation en test. Ceci contourne le problème posé par certains protocoles de signalisation, notamment ceux utilisés dans les architectures MPLS ( Multi-Protocol Label Switching ) ou de multidiffusion ( multicast ), qui ne permettent pas de créer directement des états de commutation dans le système en test. Le procédé permet d'obtenir des états de test dans de bonnes conditions de coûts, de délais et de productivité, et sans dépendre des détails de réalisation des outils de test.
Un autre aspect de la présente invention se rapporte à un dispositif d'insertion de trafic comprenant des premier et second modules d'interface supportant un format d'interface de transmission point à point pour transférer des unités de données transportant des paquets d'un protocole couche supérieure, le premier module d'interface étant prévu pour recevoir des premières unités de données en provenance d'un équipement de réseau et le second module d'interface étant prévu pour émettre des secondes ités de données vers un système de commutation. Le dispositif comprend en outre des moyens de multiplexage pour former un flux de paquets multiplexés comprenant des premiers paquets récupérés par le premier module d'interface à partir des premières unités de données et des seconds paquets dudit protocole de couche supérieure portant un trafic supplémentaire. Les secondes unités de données sont produites par le second module d'interface la base du flux de paquets multiplexés.
Les usages possibles de ce dispositif s'étendent au delà contexte de test mentionné précédemment, et couvrent généralement tous les besoins d'insertion de trafic sur un lien point à point de transmission de données.
groupe de tables spécifiques PACKAGE appartient au deuxième ensemble de tableaux (1102, fig. 3B et 3D) et contient des informations relatives à des regroupements de programmes installés sur les juke-box. La constitution de ces regroupements est contenue dans le groupe de tables spécifiques PACKAGE DEF.
groupe de tables spécifiques PHONE, fig. 3A contient tous les numéros téléphone utiles à la gestion des juke-box. Chaque table de ce groupe de tables comprend, le numéro de téléphone (PHO_NUMBER), l'identification du titulaire du numéro (PHO OBJECT SOURCE), l'identifiant du tableau contenant les informations relatives au titulaire (PHO OBJECT ID), le genre la ligne correspondant au numéro (PHO TYPE) c'est-à-dire si le numéro un numéro de téléphone fixe, de fax, ou de télephone portable.
groupe de tables spécifiques PLAY LOG appartient au huitième ensemble tableaux (1108, fig. 3A et 3E) et permet d'archiver toutes les diffusions chansons sur les juke-box. Les tables de groupe de tables sont mises jour chaque fois qu'un juke-box envoie un fichier de compte rendu au serveur. Chaque table correspond à la diffusion d'une chanson.
Le groupe de tables spécifiques PROGRAM appartient au deuxième ensemble de tableaux (1102, fig. 3B et 3E) et contient toutes les versions de tous les programmes utilisés. Chaque table de ce groupe de tables contient notamment le nom (PGD NAM), et la version (PGM VERSION) du programme mais également le programme lui-même (PGM CODE SOURCE). Chaque table correspond à la version d'un programme. Les programmes conçus pour fonctionner sur les juke-box sont décrits dans le groupe tables spécifiques PROGRAM DEF. Le groupe de tables spécifiques PROMOTION appartient au onzième ensemble de tableaux (1111, fig. 3B) et permet de décrire des promotions susceptibles d'intervenir sur un juke-box. On entend par promotion, par exemple, une réduction du coût ou une gratuité d'une ou plusieurs chansons déterminées. Les chansons concernées par la promotion sont listées dans le groupe de tables spécifiques PRO-PACKAGE-CATALOGUE. La promotion peut s'étendre à toutes les chansons d'un artiste déterminé. Dans ce cas, les identifiants des artistes (ART ID) concernés par la promotion sont contenus dans le groupe de tables spécifiques PRO_PACKAGE ARTIST. De même, une promotion peut regrouper à la fois des promotions sur des chansons déterminées sur toutes les chansons d'un artiste, dans ce cas un tableau PRO-PACKAGE contient un argument permettant de lier tables PRO PACKAGE ARTIST et PRO-PACKAGE-CATALOGUE tables PROMOTION. De même, un groupe de tables PRO_PRICING comprend également argument permettant de lier le groupe de tables spécifiques PROMOTION avec le groupe de tables spécifiques PRICING contenant une définition précise des périodes pendant lesquelles la promotion est validée.
Le groupe de tables spécifiques PUBLISHER (non représentée) appartient au neuvième ensemble de tableaux (1109, fig. 3F) et contient toutes les informations relatives aux éditeurs.
Le groupe de tables spécifiques PUBLISHER_ROYALTY appartient au neuvième ensemble de tableaux (1109, fig. 3F) et contient toutes les informations relatives au paiement des redevances aux éditeurs chansons diffusées ou copiées sur un juke-box.
Le groupe de tables spécifiques REPLACEMENT _PROGRAM appartient au neuvième ensemble de tableaux (1102, fig. 3B et et permet d'indiquer qu'un programme (PGD NAME) est remplacé un autre programme (REP PGD NAME) à partir d'une date déterminée (REP START DT).
Le groupe de tables spécifiques SOFTWARE appartient au deuxième ensemble de tableaux (1102, fig. 3B et 3D) et permet de faire le lien entre un programme et un juke-box sur lequel est installé le programme. Chaque table de ce groupe de tables permet d'affecter un programme (PGD-NAME) à un juke-box determiné par son numéro (JUK ID). Chaque table permet également d'archiver différentes installations de programmes qui été validées sur un juke- , mais qui ne sont plus autorisées. En effet, configuration en cours validité pour un juke-box déterminé (JUK ID) contenue dans la table specifique pour laquelle la date (SOF START DT) est la plus récente. Les autres tables sont conservées comme archives.
Le groupe de tables spécifiques SONG appartient au quatrième ensemble de tableaux (1104, fig. 2 et 3A) et permet de faire le lien entre des chansons téléchargées et un juke-box sur lequel sont téléchargées les chansons. Chaque table de ce groupe de tables permet d'affecter une chanson (CLT_ID) à un juke-box déterminé par son numéro (JUK ID). Ce groupe de tables permet d'obtenir un historique de téléchargement chansons et de déterminer redevances à verser pour chaque téléchargement. Ce groupe de tables permet également d'archiver les différentes chansons qui ont été installées un juke-box.
Le groupe de tables spécifiques SYSTEM_LOG appartient au huitième ensemble de tableaux (1108, fig. 3A et 3E) et contient toutes les informations transmises par les juke-box dans les fichiers de compte rendu, hormis les informations concernant les diffusions de chansons qui sont contenues dans le groupe de tables spécifiques PLAY LOG.
Le groupe de tables spécifiques WAREHOUSE appartient au septième ensemble de tableaux (1107, fig. 3A) et permet d'affecter un ou plusieurs juke- box à une entreprise d'un opérateur. En effet, un opérateur peut posséder plusieurs entreprises. Il est donc plus simple, pour la gestion des juke-box loués par cet opérateur, d'affecter chaque juke-box à une entreprise.
Les figures 5A à 5H représentent différentes fenetres permettant de visualiser les informations des tableaux de la base données. Afin de manipuler de façon plus simple, les informations contenues dans les ensembles de tableaux de la base de données du système selon l'invention, le serveur comprend un module de présentation constituant une interface utilisateur. Ce module permet non seulement de présenter de manière conviviale les informations de la base de données mais également de collecter de manière sélective ces informations de sorte que même du serveur l'utilisateur ne possédant pas de connaissances de l'architecture de la base de données puisse avoir accès à certaines informations. De plus, ce module permet également de modifier, ajouter ou supprimer des informations de base de données.
Ce module permet essentiellement la visualisation sur un moniteur d'une pluralité d'écran ou fenêtre comprenant chacun, soit des zones d'affichage d'informations, soit des zones de saisie d'informations, soit zones boutons de sélection. Les zones de sélection sont, en général, liées des procédures provoquant notamment, la collecte d'informations et leur stockage dans la base de données ou la validation des informations saisies dans zones de saisie.
Un premier écran (200) représenté figure 5A, est destiné à visualiser manipuler toutes les informations relatives à un juke-box. Cet écran (200) comprend une pluralité de zones (201.1 à 201.22) pouvant être des zones d'affichage ou des zones de saisie. Chacune de ces zones (201.1 à 201.22) correspond à un argument du tableau JUKE-BOX, fig. 3A. Lorsqu'un utilisateur souhaite consulter les informations relatives à un juke-box existant, il suffit de saisir le numéro d'identification du juke-box souhaité dans une première zone (201.1) de saisie et de valider cette saisie en sélectionnant une première zone (202) de sélection. Cette sélection déclenche une recherche dans le groupe de tables spécifiques JUKEBOX, fig. 3A de la base de données parmi toutes les valeurs des arguments, celles dont le numéro d'identification correspond à celui saisi. Une fois collectées, ces informations sont affichées dont des zones (201.2 à 201.22) d'affichage correspondantes. Lorsque l'utilisateur souhaite créer un nouveau juke-box, il suffit de saisir dans la première zone (201.1) correspondant au numéro d'identification, un numéro qui n'est pas encore utilisé, puis de valider ce choix en sélectionnant une deuxième zone (203) de sauvegarde. Cette sauvegarde déclenche la création d'une nouvelle table dans le groupe de tables spécifiques JUKEBOX, fig. 3A, et la génération d'un mot de passe nécessaire pour le fonctionnement du nouveau juke-box qui est affiché dans la zone (201.2) d'affichage correspondant. Hormis les zones (201.1 201 d'affichage correspondant au numéro de juke-box et au mot de passe, les autres zones (201. 3 à 201.22) de saisie sont vierges. Le premier tableau (200) comprend également une pluralité de séries de boutons (204 à 207) sélection provoquant chacun l'affichage d'un nouvel écran. Ces nouveaux écrans permettent de visualiser les informations sur la constitution, la mise jour, le fonctionnement du juke-box identifié par le numéro saisi dans la zone (201.1) correspondante du premier écran (200).
Une première série (204) de boutons permet de configurer un juke- avec les paramètres par défaut définis préalablement. La sélection d'un premier bouton (204.1) provoque l'initialisation du I-button du juke-box correspondant au numéro saisi ou affiché dans la première zone (201.1), ainsi, cette opération permet d'affecter pour chaque paramètre de fonctionnement du juke-box valeur par défaut. Un deuxième bouton (204.2) affiche un écran (non représenté) permettant d'affecter au juke-box une liste prédéfinie de chanson qui seront ensuite installées sur le juke-box pour constituer la liste des chansons disponibles sur le juke-box. Un troisième bouton (204.3) affiche un écran (non représenté) permettant d'affecter au juke-box une liste prédéfinie de programmes qui seront utilisés pour faire fonctionner le juke-box.
Une deuxième série (205) de boutons permet d'afficher la description des éléments constitutifs du juke-box. Un premier bouton (205.1) provoque l'affichage d'un écran (non représenté) comprenant une pluralité de champs utilisés pour afficher les informations relatives à l'opérateur. Ces informations sont collectées dans le groupe de tables OPERATOR , fig. 3A pour l'identifiant de l'opérateur locataire ou propriétaire du juke-box. Un deuxième bouton (205.2) provoque l'affichage d'un écran (non représenté) comprenant pluralité de champs utilisés pour afficher les informations relatives programmes installés sur le juke-box. Ces informations sont collectées dans le groupe de tables SOFTWARE, fig. 3B et dans le groupe de tables PROGRAM DEF, fig. 3D. Un troisième bouton (205.3) provoque l'affichage d'un écran (non représenté) comprenant une pluralité de champs utilisés pour afficher les informations relatives aux composants matériels installés sur le juke-box. Ces informations sont collectées, dans le groupe de tables COMPONENT, fig. 3B et dans le groupe de tables COMPONENT DEF, fig. 3B. Un quatrième bouton (205.4) provoque l'affichage d'un écran (non représenté) comprenant une pluralité de champs utilisés pour afficher la liste des chansons actuellement commandées pour le juke-box. Ces informations sont collectées, dans le groupe de tables ORDERING, fig. 3A. Un cinquième bouton (205.5) provoque l'affichage d'un deuxième écran, représenté figure 5B. L'affichage de cette écran est précédé d'une collecte d'informations dans les tableaux SONG, 3A et CATALOGUE, fig. 3B pour afficher dans une fenêtre déroulante (211) deuxième écran (210), la liste des chansons disponibles sur le juke-box designé par son identifiant. Les chansons sont identifiées par leur numéro 2) et leur titre (213). Le numéro de toutes les chansons est collecté dans groupe de tables spécifiques SONG et pour chaque chanson du juke-box serveur comporte des moyens d'afficher la date d'achat, la date de livraison, temps de transfert, la date de suppression de la chanson, et le titre de chanson, ces éléments étant collectés dans les tables spécifiques CATALOGUE. Ce deuxième écran (210) est uniquement destiné à la consultation, il ne comprend pas de zone de saisie.
# mélange de C, C, C-triméthylhexane diamine-1,6 , de xylylènediamine et de para-tertiobutylphénol (6) 10 # palmitate d'isopropyle 15 # alcool laurique éthoxylé (4 OE) (8) 13
Les compositions A et B présentent une viscosité de 110 x 10-3 Pa s (110 cP) et 48,8 x 10-3 Pa. s (48,8 cP) à 25 C, respectivement, le rapport r étant égal à 1,36.
EXEMPLE 15 A partir des fils obtenus à l'exemple 14, on réalise des plaques composites dans les conditions décrites dans l'exemple 2.
EXEMPLE 16 Des filaments obtenus dans les conditions de l'exemple 1 sont revêtus d'une première composition A puis d'une deuxième composition B suivantes (en pourcentage pondéral) : Composition A
# polyester tétraacrylate de masse moléculaire = 1000 (1) 20 # polyuréthane aromatique hexaacrylate de masse moléculaire = 1000 ( 2) 10 # gamma-méthacryloxypropyl triméthoxysilane ( 3) 11 # gamma-glycidoxypropyl triméthoxysilane (4) 10 # 4-octylphényl éthyl éther (5) 5 Composition B
# mélange de C, C, C-triméthylhexane diamine-1,6 ), de xylylènediamine et de para-tertiobutylphénol (6) 10 # palmitate d'isopropyle 12 # alcool laurique éthoxylé (4 DE) (8) 10 # dérivé aromatique alkoxylé (9) 8 # alkylimidazoline en C16 (10) 4
Les compositions A et B présentent une viscosité de 73,4 x 10-3 Pa. s (73,4 cP) et 75,2 x 10-3 Pa. s (75,2 cP) à 22 C, respectivement, le rapport r étant égal à 1,36.
EXEMPLE 17 A partir des fils obtenus à l'exemple 16, on réalise des plaques composites dans les conditions décrites dans l'exemple 2.
De préférence, la souche utilisée pour la fermentation est une souche microbienne appartenant au genre Candida, et en particulier la Candida tropicales.
Ainsi, les souches des micro-organismes utilisés, et en particulier les souches de Candida tropicales ayant la capacité d'effectuer la production d'acides a-co dicarboxyliques saturés ou insaturés, sont cultivées sur un milieu contenant des sources de carbone, d'azote, de phosphore et de facteurs de croissance (extraits de levures ou corn steep liquors).
On va donner ci-après trois exemples de composition de milieux utilisés, ceci à titre d'exemple illustratif mais non limitatif.
Exemple 1 Les esters méthyliques issus d'huile de colza à 50 grammes par litre (g/1) sont additionnés à un milieu de fermentation contenant 6,5 g/1 de Na2HP04, 0,25 g/1 de KH2P04, 1,0 g/1 d'extrait de levures, 1,0 g/1 de corn steep liquor. Ce milieu est stérilisé à 121 C pendant 20 minutes, puis additionné d'urée et de MgS04, stérilisés à part, à une concentration finale de 0,3 et 0,1 g/1 respectivement. Après inoculation à l'aide d'un inoculum préparé sur le même milieu avec une souche de Candida tropicalis adaptée à la production d'acides a-w dicarboxyliques, le milieu de culture est maintenu à 32 C et à un pH voisin de 4,5. L'aération est réglée de façon à obtenir une concentration en oxygène dissous supérieure ou égale à 10 de saturation. Une aération de 1 volume d'air par volume de milieu de culture et par minute est en général suffisante dans la pratique. Après la phase de croissance des levures, on obtient en général 15 à 20 g/1 de biomasse poids sec, le pH étant amené à 7,8 par addition de soude, et l'on ajoute avec un débit de 2 grammes/litre/heure, un total de 160 g/1 d'esters méthyliques d'huile de colza. Le pH est régulé à 7,8 par addition de soude. La concentration en oxygène dissous est maintenue au-dessus de 30 % de saturation, par variation de la vitesse d'agitation. La fin de la biotransformation est caractérisée par l'arrêt de l'ajout de soude.
Les concentrations en acides #-w dicarboxyliques et les rendements de transformation des principaux esters méthyliques sont indiqués dans le tableau qui suit.
Ester méthylique et Acide a-w Rendement de quantité engagée (en dicarboxylique transformation 0 g/1) correspondant (en (en o) g/1) C 16:0 10,9 8,2 75 C 18:1 123,9 94,6 76 C 18:2 44,1 34,5 78 C 18:3 20,8 15,1 73 Exemple 2 La même expérience que la précédente a été menée en remplaçant les esters méthyliques issus d'huile de colza par des esters méthyliques issus d'huile de tournesol. Le milieu de culture, la souche, et les paramètres physico- chimiques sont strictement les mêmes que ceux de l'Exemple 1. La quantité totale d'esters méthyliques d'huile de tournesol introduite selon le même protocole que celui décrit dans l'Exemple 1, est de 210 g/1.
Les concentrations en acides oc-û) dicarboxyliques et les rendements de transformation des principaux esters mméthyliques sont indiqués dans le tableau qui suit