FR3128840A1 - Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes - Google Patents

Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes Download PDF

Info

Publication number
FR3128840A1
FR3128840A1 FR2111699A FR2111699A FR3128840A1 FR 3128840 A1 FR3128840 A1 FR 3128840A1 FR 2111699 A FR2111699 A FR 2111699A FR 2111699 A FR2111699 A FR 2111699A FR 3128840 A1 FR3128840 A1 FR 3128840A1
Authority
FR
France
Prior art keywords
service
data
supervision
technologies
data transmission
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.)
Pending
Application number
FR2111699A
Other languages
English (en)
Inventor
Fabrice Boudin
Arnaud Brun
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR2111699A priority Critical patent/FR3128840A1/fr
Publication of FR3128840A1 publication Critical patent/FR3128840A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H04L41/0843—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on generic templates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/022—Multivendor or multi-standard integration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5048—Automatic or semi-automatic definitions, e.g. definition templates

Abstract

Supervision du fonctionnement d’un service de t ransmission de données mis en œuvre selon au moins deux technologies différentes L’invention concerne un procédé de de supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes, ledit procédé comprenant ce qui suit, au niveau d’un dispositif de supervision : - recevoir (S2), en provenance de deux dispositifs de contrôle du service associés respectivement aux deux technologies, des données relatives au déroulement du service, lesdites données correspondant à des valeurs d’une pluralité de paramètres de fonctionnement du service ou d’une ressource mise en œuvre dans le service, - extraire (S3) une structure de données (STD) préalablement stockée et comprenant des identifiants associés auxdits paramètres, - à partir de ladite structure de données, générer (S4) un ou deux fichiers de données, dans lequel les identifiants desdits paramètres de fonctionnement sont associés aux valeurs de données reçues, relatives au déroulement du service mis en œuvre selon respectivement les deux technologies. Figure pour l’abrégé : figure 3

Description

Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes
Domaine de l'invention
L'invention concerne la supervision d’un service ou d’un réseau de transmission de données, nécessitant le contrôle du fonctionnement de l’ensemble des éléments, équipements, terminaux utilisés pour mettre en œuvre ce service dans le réseau. Un tel service est par exemple un service de télécommunications ou un service informatique.
Art antérieur
Un système de supervision permet de contrôler le bon fonctionnement d’un réseau de données, ou d’un service mis en œuvre dans un tel réseau, en contrôlant chacun des équipements physiques et logiciels qui le composent.
Un tel système de supervision repose le plus souvent sur l’utilisation d’un logiciel de supervision. Un tel logiciel de supervision fonctionne généralement sur un ordinateur ou plusieurs ordinateurs en communication, via un réseau local ou distant tel que l’Internet, avec un ou plusieurs équipements à superviser tels que des automates programmables, des ordinateurs, des cartes spécialisées, etc.
Dans le cadre par exemple d’une supervision active, des outils sont mis à disposition d’un superviseur ou d’une équipe de superviseurs pour lancer et automatiser des usages réels d’un service donné et ainsi modéliser les résultats obtenus suite à la mise en œuvre de ce service, selon une ou plusieurs mesures de performance souhaitée(s), par exemple un temps de réponse attendu, le contenu d’un message attendu, etc.
Dans le cadre par exemple d’une supervision passive, une ressource particulière du réseau de transmission de données, telle que par exemple un serveur Web dans un réseau informatique, un serveur vocal interactif dans un réseau de télécommunications, un terminal dans un réseau informatique ou un réseau de télécommunications, etc., transmet à un ou des outils de supervision des informations relatives à son état de fonctionnement. Ces informations sont alors analysées par un dispositif de traitement de données ou un dispositif de supervision pour en déduire si la ressource rencontre ou non une défaillance technique.
Aujourd’hui, ces systèmes reposent généralement sur des composants physiques, « hardware » qui communiquent avec un serveur de stockage, ainsi qu’une couche applicative permettant la collecte puis la modélisation des résultats obtenus suite à la mise en œuvre d’un service de transmission de données, selon une technologie donnée.
Dans le cas par exemple où le service à superviser est un service de messagerie SMS (de l’anglais «Short Message Service»), le composant physique qui est utilisé est par exemple un robot doté d’une ou de plusieurs cartes SIM (de l’anglais« Subscriber Identity Module ») et configuré pour envoyer des messages SMS. Ainsi, dans cet exemple, un dispositif de contrôle d’un tel service utilisant la technologie SMS est nécessairement développé d’une façon particulière pour mettre en œuvre la supervision de ce service et transmettre à une interface de supervision des données de service (résultats de test, analyse des échanges mis en œuvre dans le cadre de l’exécution du service, etc.), un tel développement devant être compatible avec la technologie SMS utilisée.
Selon un autre exemple, dans le cas où une supervision passive d’un service Web est mise en œuvre, des messages d’information sur l’état de fonctionnement de ce service seront envoyés selon le protocole Internet via un dispositif de contrôle d’un tel service à un dispositif de supervision ou de traitement de données en charge d’analyser les données de ces messages conformément au protocole Internet, puis de les réorganiser d’une manière particulière pour les transmettre à une interface de supervision des données compatibles avec la technologie Internet utilisée. Comme dans l’exemple précédent, un dispositif de contrôle d’un tel service Web est nécessairement développé d’une façon particulière pour mettre en œuvre la supervision de ce service et transmettre à une interface de supervision des données relatives au déroulement de ce service, un tel développement devant être compatible avec la technologie Internet utilisée.
Il en ressort que les dispositifs de contrôle de service doivent être configurés différemment selon le type de technologie imposée par le service à superviser, par exemple la technologie basée sur des applications natives API «Application Programming Interface», la technologie SMS, la technologie MMS (de l'anglais « Multimedia Messaging Service »), la technologie USSD (de l’anglais« Unstructured Supplementary Service Data »), la technologie basée sur le Web, la technique basée sur l’audio, etc. Il en résulte une grande complexité de ces systèmes de supervision.
En outre, les systèmes de supervision actuels ne sont pas toujours adaptés au contexte du superviseur ou de l’équipe de superviseurs, tel que par exemple la langue du superviseur, le pays dans lequel est mis en œuvre le service ou un élément/composant/appareil de ce service à superviser, le type de connexion de l’interface de supervision utilisée sur laquelle sont restituées les données relatives au déroulement du service, etc. De ce fait, le superviseur prend du temps à reconfigurer les données reçues en provenance du dispositif de contrôle de service, ce qui prend du temps et risque d’engendrer des erreurs.
Ainsi, en fonction de la technologie du service testé, les superviseurs sont obligés d’utiliser des systèmes de supervision différents ou de reconfigurer leur système de supervision d’une certaine façon, et ceci avec une multitude de tests de supervision configurés différemment pour s’adapter aux différents contextes de supervision possibles.
Il en résulte que les systèmes de supervision actuels sont souvent complexes à interpréter et donc à maintenir, dans le cas par exemple où une mise à jour du service supervisé est nécessaire. De tels systèmes de supervision peuvent donc rendre la supervision non optimale, engendrant par exemple une perte de temps dans le travail des superviseurs, une fatigue ou démotivation des superviseurs, en particulier lors de supervisions en horaires décalés, du retard dans la détection d’un problème sur un service supervisé, etc., et par conséquent avoir un impact négatif sur la qualité des services supervisés.
Objet et résumé de l'invention
Un des buts de l'invention est de remédier à des inconvénients de l'état de la technique précité en proposant un procédé de supervision ou contrôle du fonctionnement d’un service de transmission de données qui permet une mutualisation des données relatives au déroulement d’un service, quelle que soit la technologie qui est rattachée à ce service, de manière à optimiser les performances de supervision.
A cet effet, un objet de la présente invention concerne un procédé de de supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes, un tel procédé comprenant ce qui suit, au niveau d’un dispositif de supervision :
- recevoir, en provenance de deux dispositifs de contrôle du service associés respectivement aux deux technologies, des données relatives au déroulement du service, les données correspondant à des valeurs d’une pluralité de paramètres de fonctionnement du service ou d’une ressource mise en œuvre dans le service,
- extraire une structure de données préalablement stockée et comprenant des identifiants associés aux paramètres,
- à partir de la structure de données, générer un ou deux fichiers de données, dans lequel les identifiants des paramètres de fonctionnement sont associés aux valeurs de données reçues, relatives au déroulement du service mis en œuvre selon respectivement les deux technologies.
Selon l’invention, le dispositif de supervision qui collecte les données relatives au déroulement du service mis en œuvre selon au moins deux technologies différentes, est ainsi en mesure, dans un fichier préformaté, de mutualiser ces données qui peuvent être hétérogènes selon l’une ou l’autre des technologies mises en œuvre.
Une telle mutualisation est rendue possible grâce à la génération soit d’un seul fichier de données, dans lequel sont organisées les données du service mis en œuvre selon les deux technologies, soit de deux fichiers de données, dans lesquels sont organisées respectivement les données du service mis en œuvre selon chacune des deux technologies, chacun de ces fichiers répondant avantageusement à un même format qui est basé sur une structure de données prédéfinie et stockée au préalable.
Ce ou ces fichiers bénéficiant d’un format unique sont ainsi beaucoup plus simples à interpréter et à traiter par un dispositif de supervision en comparaison des dispositifs de supervision existants qui sont obligés de modéliser les données relatives au déroulement d’un service en fonction de la technologie selon laquelle le service est mis en œuvre. Les performances de la supervision sont donc optimisées et il en découle une meilleure qualité de service.
Selon un mode de réalisation particulier, le ou les fichiers de données sont générés en fonction d’au moins un contexte de supervision du service.
Un tel mode de réalisation permet d’adapter automatiquement le contenu du ou des fichiers générés à un contexte de supervision particulier, tel que par exemple le pays dans lequel le service est exécuté, la langue du superviseur, le type de connectivité du dispositif de supervision utilisé par le superviseur, etc.
Selon un autre mode de réalisation particulier, le dispositif de supervision est configuré selon le contexte de supervision, de manière statique et/ou dynamique.
Une configuration statique du dispositif de supervision est particulièrement intéressante dans le cas par exemple où le contexte de supervision est le pays dans lequel est exécuté le service. Ainsi, le ou les fichiers de données seront resitués au superviseur sous un format d’affichage attendu par ce dernier, ce qui évite toute manipulation fastidieuse supplémentaire de traitement, par le superviseur, du fichier généré.
Une configuration dynamique présente également de l’intérêt lorsque le dispositif de supervision est utilisé par exemple par plusieurs superviseurs différents, avec des nationalités différentes et donc des langues différentes.
Selon un autre mode de réalisation particulier, le procédé de supervision selon l’invention comprend une étape de commande de la restitution, sur une interface de supervision, du ou des fichiers de données générés.
Le fait que les fichiers de données restitués présentent un format unique rend plus facile l’analyse comparative de la façon dont s’est déroulé un service ou la façon dont s’est comporté un composant particulier de ce service, lorsque ce service a été mise en œuvre selon deux technologies différentes.
Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de supervision ou de contrôle du fonctionnement d’un service, tel que défini ci-dessus.
L'invention concerne également un dispositif de supervision adapté pour contrôler le fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes, un tel dispositif comprenant un processeur qui est configuré pour mettre en œuvre ce qui suit :
- recevoir, en provenance de deux dispositifs de contrôle du service associés respectivement aux deux technologies, des données relatives au déroulement du service, les données correspondant à des valeurs d’une pluralité de paramètres de fonctionnement du service ou d’une ressource mise en œuvre dans le service,
- extraire une structure de données préalablement stockée et comprenant des identifiants associés aux paramètres,
- à partir de la structure de données, générer un ou deux fichiers de données, dans lequel les identifiants des paramètres de fonctionnement sont associés aux valeurs de données reçues, relatives au déroulement du service mis en œuvre selon respectivement les deux technologies.
L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de supervision du fonctionnement d’un service de transmission de données conforme à l'invention, selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur.
De telles instructions peuvent être stockées durablement dans un support mémoire non transitoire du dispositif de supervision mettant en œuvre le procédé de supervision du fonctionnement d’un service de transmission de données selon l’invention.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise également un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus.
Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile, un disque dur ou un SSD.
D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par un exemple un réseau de type Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de supervision précité.
Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation particuliers de l'invention, donnés à titre d’exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La représente un système de supervision du fonctionnement d’un service de transmission de données selon un premier mode de réalisation de l'invention,
La représente un système de supervision du fonctionnement d’un service de transmission de données selon un deuxième mode de réalisation de l'invention,
La représente un dispositif de supervision du fonctionnement d’un service de transmission de données, dans un mode de réalisation de l’invention,
La représente les principales actions mises en œuvre dans le procédé de supervision du fonctionnement d’un service de transmission de données, selon un mode de réalisation particulier de l’invention,
La représente la génération d’un fichier mise en œuvre dans le cadre de l’exécution du procédé de supervision conforme à l’invention, selon un premier mode de réalisation particulier de l’invention,
La représente la génération d’un fichier mise en œuvre dans le cadre de l’exécution du procédé de supervision conforme à l’invention, selon un deuxième mode de réalisation particulier de l’invention,
La représente la génération d’un fichier mise en œuvre dans le cadre de l’exécution du procédé de supervision conforme à l’invention, selon un troisième mode de réalisation particulier de l’invention.
Description détaillé e d’un mode de réalisation de l’invention
La représente un système de supervision du fonctionnement d’un service de transmission de données selon un premier mode de réalisation de l'invention.
Un tel système comprend :
- un dispositif de supervision DSU associé à un nombre n d’utilisateurs UT1, UT2, …, UTn, tel que n≥1, ces n utilisateurs étant des agents de supervision aptes à superviser la manière dont s’est déroulée l’exécution d’un service de transmission de données dans un réseau de transmission de données RTD,
- un nombre k de dispositifs DSM1, DSM2, …, DSMkde simulation du service qui est mis en œuvre selon k technologies différentes,
- un nombre correspondant k de dispositifs DCF1, DCF2, …, DCFk, de contrôle du fonctionnement de ce service, tel que k≥2, chacun de ces k dispositifs de contrôle du fonctionnement de ce service étant apte à communiquer d’une part dans le réseau RTD avec respectivement chacun des k dispositifs DSM1, DSM2, …, DSMkde simulation du service et, d’autre part avec le dispositif de supervision DSU, via le réseau RTD ou tout autre réseau de transmission de données adapté.
Selon l’invention, le service de transmission de données qui est supervisé est par exemple un service de télécommunications (service de messagerie, consultation d’un serveur vocal interactif, transfert d’argent, etc…) ou un service informatique (Service Web, Service d’impression de documents, etc.). De tels services sont mis en œuvre dans un ou plusieurs réseaux de transmission de données désigné(s) sous la référence RTD, tel que par exemple Bluetooth, NFC, LTE, WiFi, 2G, 3G, 4G, 5G, etc.
Dans le mode de réalisation représenté, au moins deux dispositifs de simulation de ce service, parmi les k dispositifs de simulation précités, sont utilisés pour simuler une exécution de ce service selon respectivement au moins deux technologies différentes, par exemple USSD et Web. De tels dispositifs de simulation sont bien sûr variables selon le service à exécuter et comprennent par exemple un robot, un automate, un ordinateur, un terminal de communication, etc.
Dans le mode de réalisation représenté, aux moins deux dispositifs de contrôle du fonctionnement de ce service, parmi les k dispositifs de contrôle précités, sont utilisés et configurés pour recevoir/obtenir des données relatives à la façon dont s’est déroulé le service qui a été simulé selon respectivement au moins deux technologies. Au sens de l’invention, ces données relatives au déroulement du service simulé correspondent à des valeurs d’une pluralité de paramètres ou variables de fonctionnement qui sont utilisé(e)s pour mettre en œuvre le service. Il peut s’agir par exemple de l’indication de la technologie utilisée, de valeurs d’horodatage, de la valeur d’un temps de réponse attendu, d’une valeur d’état de fonctionnement du service, par exemple « 1 » pour un fonctionnement du service sans défaillance et « 0 » pour un fonctionnement du service avec défaillance, etc.
Dans le mode de réalisation représenté, le dispositif de supervision DSU est un terminal de communication, tel que par exemple un ordinateur, une tablette, un smartphone (« téléphone intelligent »). Le terminal de supervision DSU est configuré pour recevoir et analyser les données relatives au déroulement du service qui sont transmises par chacun des k dispositifs de contrôle précités, puis de restituer à l’utilisateur (superviseur) de ce dispositif DSU une modélisation de ces données sous la forme de tableaux de bord, d’alertes visuelles et/ou sonores et/ou textuelles, de manière à lancer des actions de maintenance préventive sur les éléments/composants/ressources du service supervisé, dans un souci d’améliorer la qualité de service.
La représente un système de supervision du fonctionnement d’un service de transmission de données selon un deuxième mode de réalisation de l'invention. Ce deuxième mode de réalisation utilise des éléments communs à ceux de la . Pour cette raison, ces éléments sont désignés avec les mêmes références et ne seront pas décrits à nouveau.
Dans le mode de réalisation représenté, il est question de superviser le fonctionnement d’une ressource particulière du service de transmission de données, lorsque ce service est mis en œuvre en temps réel.
A cet effet, un tel système comprend :
- un dispositif de supervision DSU associé à un nombre n d’utilisateurs UT1, UT2, …, UTn, tel que n≥1,
- une ressource particulière adaptée pour fonctionner selon k technologies différentes, et désignée par les références correspondantes RES1, RES2, …, RESk,
- un nombre correspondant k de dispositifs DCF1, DCF2, …, DCFkde contrôle du fonctionnement de cette ressource, tel que k≥2, chacun de ces k dispositifs de contrôle du fonctionnement de ce service étant apte à communiquer d’une part dans le réseau RTD avec respectivement chacune des k ressources RES1, RES2, …, RESk, et, d’autre part avec le dispositif de supervision DSU, via le réseau RTD ou tout autre réseau de transmission de données adapté.
Dans l’exemple de la , la ressource RES1, RES2, …, RESkest un élément impliqué dans le service de transmission de données tel que décrit ci-dessus en référence à la . Ainsi, dans le cas d’un même service de télécommunications à mettre en œuvre, la ressource RES1à superviser est par exemple un serveur Web avec un point d’accès WiFi, la ressource RES2à superviser est par exemple un serveur Web avec un point d’accès 4G, etc. Selon un autre exemple, la ressource RES1à superviser est par exemple un téléphone mobile fonctionnant avec la technologie USSD, la ressource RES2à superviser est par exemple un téléphone mobile fonctionnant avec la technologie basée sur des APIs, la ressource RES3 à superviser est par exemple un téléphone mobile fonctionnant avec la technologie SMS, etc. La ressource RES1, RES2, …, RESk peut également appartenir à un service informatique. Il peut s’agir par exemple d’un ordinateur dans un réseau informatique qui met en œuvre une fonctionnalité particulière telle que par exemple le lancement d’un navigateur Internet. A cet effet, la ressource RES1à superviser est par exemple un ordinateur utilisant un système d’exploitation d’un premier type, la ressource RES2à superviser est par exemple un ordinateur utilisant un système d’exploitation d’un deuxième type, etc.
On va maintenant décrire, en référence à la , la structure simplifiée d’un dispositif de supervision DSU adapté pour mettre en œuvre le procédé de supervision du fonctionnement d’un service de transmission de données selon l’invention.
Un tel dispositif de supervision comprend classiquement :
- une interface de communication MCO adaptée pour communiquer, via le réseau de transmission de données RTD et/ou tout autre réseau de communication RC adapté,
- une interface utilisateur IU apte à restituer des informations à l’utilisateur sous forme textuelle, visuelle et/ou sonore : il peut s’agir par exemple d’un écran d’affichage et/ou d’un haut-parleur intégré au dispositif de supervision DSU ou connecté à ce dernier.
Conformément à l’invention, le dispositif de supervision DSU comprend en outre un module ACC d’accès à une mémoire MEM1qui contient au moins une structure de données prédéfinie SDT, dont des exemples seront donnés plus loin dans la description. La structure de données SDT comprend des identifiants de paramètres et/ou variables de fonctionnement communs ou pas aux k technologies selon lesquelles le service est mis en œuvre. Sur la , la mémoire MEM1n’est pas contenue dans le dispositif de supervision DSU afin de préserver les ressources mémoire de celui-ci. A cet effet, la mémoire MEM1est déportée dans un réseau de communication, un nuage (« cloud » en anglais), etc. et est rendue accessible par le dispositif de supervision DSU, au moyen du module ACC dédié à cet effet. En variante, la mémoire MEM1ou une partie de celle-ci pourrait être intégrée au dispositif de supervision DSU.
Conformément à l’invention, le dispositif de supervision DSU comprend également un module GNF de génération de fichiers qui est configuré pour générer à partir de la structure de données SDT accédée :
- soit un unique fichier de données FCD, dans lequel les identifiants de la structure de données SDT sont associés aux valeurs des paramètres/variables de fonctionnement communs ou non, pour chacune des k technologies selon lesquelles le service est mis en œuvre,
- soit k fichiers de données FCD1 à FCDk, dans chacun desquels les identifiants de la structure de données SDT sont associés aux valeurs des paramètres/variables de fonctionnement du service pour chacune des k technologies selon lesquelles le service est mis en œuvre.
Selon un mode particulier de réalisation de l'invention, les actions exécutées par le dispositif de supervision DSU sont mises en œuvre par des instructions d’un programme d'ordinateur PG. Pour cela, le dispositif DSU a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM2, une unité de traitement UTR, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM2. Le programme d'ordinateur PG comprend des instructions pour effectuer les actions de réception de données relatives au déroulement du service, d’accès à la structure de données SDT et de génération du fichier de données, dans le cadre du procédé de supervision du fonctionnement de ce service qui va être décrit ci-dessous, lorsque le programme est exécuté par le processeur PROC, selon l'un quelconque des modes particuliers de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UTR met notamment en œuvre les actions précitées, selon les instructions du programme d'ordinateur PG.
On décrit maintenant, en relation avec la , le déroulement d’un procédé de supervision du fonctionnement d’un service de transmission de données, selon un mode de réalisation de l’invention.
Au cours d’une étape S1, le dispositif de supervision DSU est configuré selon un contexte particulier dans lequel la supervision est mise en œuvre. Selon un premier mode de réalisation, une telle configuration est mise en œuvre de manière statique. Par exemple, si le service à superviser est mis en œuvre dans un pays particulier, le dispositif de supervision DSU est paramétré au préalable dans la langue de ce pays. Selon un autre exemple, si le dispositif de supervision DSU doit fonctionner selon une connexion particulière, par exemple Wifi, seulement 4G, ADSL, etc., le dispositif de supervision DSU est paramétré en S1 selon cette connexion particulière. Selon un deuxième mode de réalisation, une telle configuration est mise en œuvre de manière dynamique, c’est-à-dire en fonction du superviseur qui utilise le dispositif de supervision à l’instant courant. Ainsi, par exemple, dans le cas où le superviseur est italien, le dispositif de supervision DSU est paramétré en italien par le superviseur. Selon un autre exemple, dans le cas où le superviseur est non-voyant, le dispositif de supervision DSU est paramétré de telle manière que toutes les informations relatives au déroulement du service sont restituées sous forme audio.
Une fois cette configuration S1 effectuée et suite à la mise en œuvre du service selon les k technologies différentes, l’interface de communication MCO du dispositif de supervision DSU reçoit en S2 des données relatives au déroulement du service DRS1 à DRSk, lesdites données correspondant à des valeurs d’une pluralité de paramètres de fonctionnement du service ou d’une ressource mise en œuvre dans le service. Les données DRS1à DRSk sont reçues en provenance respectivement des dispositifs de contrôle DCF1 à DCFk, via le réseau RTD ou le réseau RC.
Le dispositif de supervision DSU extrait en S3 de la mémoire M1, via le module d’accès ACC ( ), la structure de données STD correspondant au service ou à la ressource supervisé(e).
En S4, le module GNF de génération de fichier du dispositif de supervision DSU génère, à partir de la structure de données STD :
- soit un unique fichier de données FCD, dans lequel les identifiants de la structure de données SDT sont associés aux valeurs des paramètres/variables de fonctionnement communs ou pas, pour chacune des k technologies selon lesquelles le service ou la ressource est mis en œuvre,
- soit k fichiers de données FCD1 à FCDk, dans chacun desquels les identifiants de la structure de données SDT sont associés aux valeurs des paramètres/variables de fonctionnement du service pour chacune des k technologies selon lesquelles le service ou la ressource est mis en œuvre.
De manière préférentielle, le ou les fichier(s) de données précité(s) sont de type textuel de manière à pouvoir être manipulés plus facilement en vue de la restitution d’alertes sur l’interface utilisateur IU. Toutefois, de tels fichiers peuvent se présenter sous la forme d’image, de code informatique, ou de toute autre forme adaptée.
En S5, le dispositif de supervision DSU commande alors la restitution des informations contenues dans ce/ces fichiers de données sur l’interface utilisateur IU.
A titre d’exemples non limitatifs, certaines de ces informations peuvent être exploitées sous la forme d’un message textuel (ex : un tableau, une notification, une icône, etc.) qui s’affiche sur l’écran de l’interface utilisateur IU. De manière alternative ou en combinaison, certaines de ces informations peuvent être converties en données audio et formatées dans un message audio restitué par au moins un haut-parleur de l’interface utilisateur IU.
Grâce au procédé qui vient d’être décrit, la génération d’un ou plusieurs fichiers de données permet avantageusement d’unifier et de mettre en commun le traitement et l’analyse des données relatives au déroulement du service ou d’une ressource du service à superviser, en vue d’une restitution des résultats obtenus par ce service ou cette ressource dans l’interface de supervision IU, une telle restitution étant mise en œuvre de manière plus rationnelle que dans les dispositifs de supervision de l’art antérieur.
On va maintenant décrire ci-dessous, en référence aux figures 4A à 4C, différents exemples de supervision mise en œuvre selon l’invention.
Dans l’exemple de la , le service à superviser est un transfert d’argent entre deux terminaux de communication mobiles de type « smartphone ». Un tel service est mis en œuvre selon par exemple quatre technologies telles que par exemple :
- USSD,
- SMS,
- API,
- Web.
Le service est simulé par exemple en Côte d’Ivoire.
Chaque service à superviser est simulé par un robot faisant office de terminal de communication émetteur, doté d’une carte SIM à laquelle est associé un identifiant tel qu’un numéro MSISDN (de l’anglais «Mobile Station International Subscriber Directory Number»). Chaque robot est activé à différents intervalles temporels pour simuler le service de transfert d’argent, de préférence de manière périodique, toutes les 5 secondes par exemple. Chacun de ces robots peut faire office de dispositif de contrôle de fonctionnement. Dans un autre mode de réalisation, les dispositifs de contrôle de fonctionnement sont connectés à leurs robots correspondants.
Le dispositif de supervision DSU, à l’étape S2 de la , reçoit en provenance de chaque dispositif de contrôle du fonctionnement de ce service simulé les données relatives au déroulement de ce service. Plus précisément, le module de communication MCO du dispositif de supervision DSU reçoit ainsi :
- en provenance du dispositif de contrôle DCF1, les données relatives au déroulement du service de transfert d’argent dans la technologie USSD sous la forme d’un message par exemple du type : « {Type service} :Transfert d’argent vers {MSISDN 2 } en cours. {Montant} : 1000 FCFA. Vous allez recevoir une confirmation par SMS. »,
- en provenance du dispositif de contrôle DCF2, les données relatives au déroulement du service de transfert d’argent dans la technologie SMS sous la forme d’un message par exemple du type : « {Type service} :Transfert d’argent réussi du {Montant} : 1000 FCFA vers {MSISDN 2 },
Frais=150 CFA. Nouveau solde : 3000 FCFA.»,
- en provenance du dispositif de contrôle DCF3, les données relatives au déroulement du service de transfert d’argent dans la technologie API sous la forme d’une page par exemple du type : «{LOGO}{Type service} :Transfert d’argent réussi du {Montant} : 1000 FCFA vers {MSISDN 2 },
Frais=150 CFA. Nouveau solde : 3000 FCFA.»,
- en provenance du dispositif de contrôle DCF4, les données relatives au déroulement du service de transfert d’argent dans la technologie Web sous la forme d’une page Web par exemple du type : «<html> {LOGO}
Echec du{Type service} :transfert d’argent d e {Montant} : 1000 FCFA vers {MSISDN 2 },
Veuillez renouveler l’opération </html>».
Ces différents messages sont reçus par le dispositif de supervision DSU, à la suite de quoi la structure de données STD est extraite par le module ACC dans l’étape S3. Dans l’exemple représenté, la structure de données STD est configurée pour contenir les identifiants de valeurs/paramètres de fonctionnement suivants :
- Type service,
- Technologie,
- Horodatage,
- MSISDN1, qui désigne le numéro d’appel de l’utilisateur qui envoie l’argent,
- MSISDN2, qui désigne le numéro d’appel de l’utilisateur qui reçoit l’argent,
- Montant (en FCFA), où FCFA est le franc CFA qui est la devise utilisée en Côte d’Ivoire,
- Logo,
- Frais,
- Nouveau solde,
- Etat,
- Id Transaction qui désigne un identifiant de la transaction.
Bien entendu, la structure de données STD peut contenir d’autres identifiants associés à d’autres valeurs/paramètres de fonctionnement ou en contenir moins.
Les identifiants de la structure de données STD sont en français qui est la langue officielle de la Côte d’Ivoire.
Au cours de l’étape S4, le module de génération de fichier GNF génère alors au moins deux fichiers de données pivot FCD1et FCD2, c’est-à-dire étant configurés dans un même format. Sur la , le fichier FCD1est par exemple généré à l’issue de la mise en œuvre du service de transfert d’argent dans la technologie USSD et le fichier FCD2est par exemple généré à l’issue de la mise en œuvre du service de transfert d’argent dans la technologie API.
Dans le fichier FCD1, les valeurs ou paramètres de fonctionnement du service mis en œuvre selon la technologie USSD sont associés à leurs identifiants correspondants dans un format dédié. Par exemple, à l’identifiant « Horodatage » sont associées la valeur de l’instant auquel le service a été simulé ainsi que la valeur de date de cette simulation dans le format dédié : « 14:34:25.000 - 15/09/2021 ». Selon un autre exemple, à l’identifiant MSISDN2 est associée la valeur correspondant au numéro d’appel de l’utilisateur qui reçoit l’argent à l’issue de la mise en œuvre du service. Un tel numéro est inscrit dans un certain format dédié tel que par exemple l’indicatif du pays suivi des chiffres du numéro, le tout sans espace.
Dans le fichier FCD2, les valeurs ou paramètres de fonctionnement du service mis en œuvre selon la technologie API sont associés à leurs identifiants correspondants dans un format dédié, le même que le fichier FCD1. Par exemple, à l’identifiant « Horodatage » sont associées la valeur de l’instant auquel le service a été simulé dans la technologie API, ainsi que la valeur de date de cette simulation, dans le format dédié : 15:12:02.000 - 16/10/2021. Selon un autre exemple, à l’identifiant MSISDN2 est associée la valeur correspondant au numéro d’appel de l’utilisateur qui reçoit l’argent à l’issue de la mise en œuvre du service. Un tel numéro est inscrit dans un certain format dédié, le même que celui du fichier FCD1, tel que par exemple l’indicatif du pays suivi des chiffres du numéro, le tout sans espace.
Dans l’exemple de la , seulement deux fichiers de données FCD1et FCD2 ont été représentés dans un souci de clarté de la figure. Toutefois, il va de soi que des fichiers de format identique peuvent être aussi générés pour le service fonctionnant selon la technologie SMS et pour le service fonctionnant selon la technologie Web.
Dans l’exemple de la , seuls les identifiants des paramètres ou valeurs de fonctionnement communs à chacune des quatre technologies de service mises en œuvre figurent dans les fichiers données FCD1et FCD2. Bien entendu, les identifiants de tous les paramètres et leurs valeurs correspondantes, même nulle, peuvent figurer dans les fichiers de données. Par exemple le fichier FCD2pourrait contenir en plus les identifiants « Frais » et « Nouveau solde » avec leurs valeurs correspondantes « 150 » et « 3000 ». Le fichier FCD1pourrait contenir également en plus les identifiants « Frais » et « Nouveau solde » avec leurs valeurs correspondantes « Null (#N/A) » représentatives de cellules vides dans le fichier.
Dans l’exemple de la , à l’étape S5 de la , chacun des fichiers pivot FCD1et FCD2est transmis à l’interface utilisateur IU du dispositif de supervision DSU. Grâce à leur structure commune, une automatisation du traitement et de l’interprétation des données de ces fichiers pivot est avantageusement permise, sans consommation excessive des ressources en calculs, rationalisant de cette manière les informations de supervision telles que l’affichage d’alertes, l’émission d’alertes sonores, la configuration d’affichage de différents tableaux de bord, etc.
Dans l’exemple de la , le service à superviser est un suivi de consommation depuis la dernière facture émise. Un tel service requiert un terminal de communication d’un client utilisateur du service et un serveur de gestion de facturation appartenant à un opérateur de télécommunications désigné par exemple par « optel », auprès duquel est abonné le client utilisateur.
Un tel service est mis en œuvre selon par exemple deux technologies telles que par exemple :
- Audio,
- Web.
Le service est simulé par exemple en France.
Chaque service à superviser est simulé par un robot faisant office de terminal de communication émetteur, doté d’une carte SIM à laquelle est associé un identifiant tel qu’un numéro MSISDN. Chaque robot est activé à différents intervalles temporels pour simuler le service de transfert d’argent, de préférence de manière périodique, toutes les 5 secondes par exemple.
Le dispositif de supervision DSU, à l’étape S2 de la , reçoit en provenance de chaque dispositif de contrôle du fonctionnement de ce service simulé les données relatives au déroulement de ce service. Plus précisément, le module de communication MCO du dispositif de supervision DSU reçoit ainsi :
- en provenance du dispositif de contrôle DCF1, les données relatives au déroulement du service de suivi de consommation dans la technologie audio sous la forme d’un message audio par exemple du type :« Au {Date} à {Heure}, pour le {MSISDN} vous aviez consommé depuis votre dernière facture {Valeur} euro. » ,
- en provenance du dispositif de contrôle DCF2, les données relatives au déroulement du service de suivi de consommation dans la technologie Web sous la forme d’une page Web par exemple du type : «<html> {LOGO} Suivi conso {MSISDN}, Au {Date} à {Heure}, vous aviez consommé depuis votre dernière facture {Valeur} EUR </html>».
La structure de données STD est alors extraite par le module ACC dans l’étape S3. Dans l’exemple représenté, la structure de données STD est configurée pour contenir les identifiants de valeurs/paramètres de fonctionnement suivants :
- Type service,
- Technologie,
- Date,
- Heure,
- MSISDN, qui désigne le numéro d’appel de l’utilisateur qui requiert le suivi de consommation auprès du serveur de gestion de facturation,
- Valeur (en €),
- Logo.
Bien entendu, la structure de données STD peut contenir d’autres identifiants associés à d’autres valeurs/paramètres de fonctionnement ou en contenir moins.
Les identifiants de la structure de données STD sont en français.
Dans l’exemple de la , au cours de l’étape S4, le module de génération de fichier GNF génère un unique fichier de données pivot FCD, à l’issue de la mise en œuvre du service de suivi de consommation dans la technologie audio et dans la technologie Web.
Dans le fichier FCD, les valeurs ou paramètres de fonctionnement du service mis en œuvre selon les technologie audio et web sont associés à leurs identifiants correspondants dans un format dédié. Par exemple, à l’identifiant « Date » est associée la valeur de la date à laquelle le service de suivi de consommation a été simulé, «12/09/2021 » pour la technologie audio et «20/10/2021 » pour la technologie Web. Grâce à la génération de ce fichier FCD unique, le format de la date est avantageusement le même pour les deux technologies mises en œuvre.
Selon un autre exemple, la valeur associée à l’identifiant « valeur (€) » est également dans un format dédié quelle que soit la technologie audio ou Web utilisée, typiquement « 36.62 » pour la technologie audio et « 12.23 » pour la technologie Web.
Dans l’exemple de la , à l’étape S5 de la , même si plusieurs technologies sont utilisées pour mettre en œuvre le service, ici le service de suivi de consommation, un unique fichier pivot FCD, qui regroupe dans un même format les données relatives au déroulement du service selon les différentes technologies, est transmis à l’interface utilisateur IU du dispositif de supervision DSU. De manière similaire à l’exemple de la , une automatisation du traitement et de l’interprétation des données de ce fichier pivot est avantageusement permise, voire optimisée, puisqu’un unique fichier est à traiter pour générer l’affichage d’alertes, l’émission d’alertes sonores, la configuration de différents tableaux de bord, etc.
Dans l’exemple de la , le service à superviser est l’accès à une page Web. Un tel service requiert un terminal de communication TU1 ou TU2 d’un client utilisateur du service et un serveur Web SERx hébergeant la page Web requise PWy. Dans l’exemple de la , la supervision porte sur le fonctionnement du terminal de communication, en tant que ressource impliquée dans la mise en œuvre du service.
Un tel service est mis en œuvre selon par exemple deux technologies telles que par exemple :
- le protocole http,
- le protocole https.
Le service est exécuté par exemple en France. Dans l’exemple de la , le fonctionnement de deux terminaux de communication (smartphone, tablette, ordinateur, etc.) TU1 et TU2 est supervisé. Les terminaux TU1 et TU2 mettent en œuvre le service respectivement à des dates différentes, et à des instants différents.
Un dispositif de contrôle DCF1est apte à contrôler le fonctionnement du terminal TU1, tandis qu’un dispositif de contrôle DCF2est apte à contrôler le fonctionnement du terminal TU2.
Le dispositif de supervision DSU, à l’étape S2 de la , reçoit en provenance de chaque dispositif de contrôle DCF1et DCF2du fonctionnement de ce service les données relatives au déroulement de ce service, en particulier un historique des évènements créés lors de la mise en œuvre du service d’accès à une page Web PWy et contenant par exemple trois logs : log1, log2, log3 émis par chacun des terminaux TU1 et TU2 à destination du serveur Web SERx. Plus précisément, le module de communication MCO du dispositif de supervision DSU reçoit ainsi :
- en provenance du dispositif de contrôle DCF1, les données relatives au déroulement du service d’accès à une page Web dans la technologie http sous la forme des trois logs suivants :
Log1 : <http> {Horodatage1} {Adresse IP} serveur Web SERVx
Log2: <http> {Horodatage2} {URL} Page Web PWy requise sur serveur Web SERVx
Log3: <http> {Horodatage3} réception {URL} Page Web PWy requise,
- en provenance du dispositif de contrôle DCF2, les données relatives au déroulement du service d’accès à une page Web dans la technologie https sous la forme des trois logs suivants :
Log1 : <http s > {Horodatage1} {Adresse IP} serveur Web SERVx
Log2: <http s > {Horodatage2} {URL} Page Web PWy requise sur serveur Web SERVx
Log3: <http s > {Horodatage3} réception {URL} Page Web PWy requise.
La structure de données STD est alors extraite par le module ACC dans l’étape S3. Dans l’exemple représenté, la structure de données STD est configurée pour contenir les identifiants de valeurs/paramètres de fonctionnement suivants :
- Type service,
- Technologie,
- Horodatage1,
- Horodatage2,
- Horodatage3,
- MSISDN, qui désigne le numéro d’appel de l’utilisateur des terminaux TU1 et TU2 qui requiert la page Web PGy sur le serveur Web SERx,
- Adresse IP, qui désigne l’adresse IP (de l’anglais «Internet Protocol») du serveur Web SERx,
- URL (de l’anglais «Uniform Resource Locator»), qui désigne l’adresse d’accès de la page Web PWy dans le serveur Web SERx.
Bien entendu, la structure de données STD peut contenir d’autres identifiants associés à d’autres valeurs/paramètres de fonctionnement ou en contenir moins.
Les identifiants de la structure de données STD sont en français.
Dans l’exemple de la , au cours de l’étape S4, le module de génération de fichier GNF génère par exemple un unique fichier de données pivot FCD, à l’issue de la mise en œuvre du service d’accès à la page Web requise par chacun des terminaux TU1, TU2.
Dans le fichier FCD, les valeurs ou paramètres de fonctionnement du service mis en œuvre selon les technologies http et https sont associés à leurs identifiants correspondants dans un format dédié. Par exemple, à l’identifiant « Horodatage1 » est associée la valeur de la date et à la valeur de l’instant temporel en heure, minute, seconde à laquelle le service a été déclenché, «03/10/2021 - 20:35:14» pour la technologie http et «16/10/2021 - 07:53:02» pour la technologie https.
Selon un autre exemple, à l’identifiant « Horodatage2 » est associée la valeur de la date et la valeur de l’instant temporel en heure, minute, seconde auxquels les terminaux TU1 et TU2 reçoivent l’URL de la page Web PWy requise en provenance du serveur SERx, «03/10/2021 - 20:35:17» pour la technologie http et «16/10/2021 - 07:53:27» pour la technologie https.
Dans l’exemple de la , à l’étape S5 de la , même si plusieurs technologies sont utilisées pour mettre en œuvre un service en temps réel, ici le service d’accès à une page Web selon deux protocoles différents, un unique fichier pivot FCD, qui regroupe dans un même format les données relatives au déroulement du service selon les différentes technologies par chacun des terminaux de communication TU1, TU2, est transmis à l’interface utilisateur IU du dispositif de supervision DSU. De manière similaire à l’exemple de la , une automatisation du traitement et de l’interprétation des données de ce fichier pivot est avantageusement permise, voire optimisée, puisqu’un unique fichier est à traiter pour générer l’affichage d’alertes, l’émission d’alertes sonores, la configuration de différents tableaux de bord, etc.
Les exemples qui viennent d’être présentés en relation avec les figures 4A à 4C montrent que la génération d’un fichier FCD ou de plusieurs fichiers FCD1à FCDk présentant tous un même format unique permet d’accélérer favorablement l’analyse et le traitement d’informations lors de la supervision d’un service ou d’une ressource utilisée dans ce service, quand bien même différentes technologies sont mises en œuvre pour exécuter le service. Il n'est ainsi plus nécessaire de croiser des données disparates générées conformément aux types de technologies mises en œuvre, toutes les données DRS1à DRSk relatives au déroulement d’un service selon k technologies différentes étant injectées dans le même fichier FDC ou dans respectivement k fichiers de même format FCD1à FCDk. La supervision selon l’invention sera donc beaucoup moins complexe et coûteuse en termes de moyens techniques et humains. De ce fait, le procédé de supervision selon l’invention permet avantageusement de rationaliser la supervision. Par ailleurs, la supervision sera aussi mieux adaptée à des mises à jour du service ou d’une ressource du service. Par exemple, dans le cas de la , s’il est décidé par exemple d’enrichir le message à l’utilisateur par des informations du type : «Vous avez envoyé dans le mois un nombre X de messages MMS , ce qui représente une taille Y», une telle mise à jour sera répercutée de manière très simple dans le procédé de supervision de l’invention. Il suffira en effet juste de rajouter à la structure de données STD de nouveaux identifiants, par exemple «Nombre X de MMS» et «taille Y de X», ce qui permettra de générer un fichier FCD ou plusieurs fichiers FCD1à FCDk enrichis de ces nouveaux identifiants de paramètres/variables de fonctionnement et de leurs valeurs correspondantes.

Claims (7)

  1. Procédé de supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes, ledit procédé comprenant ce qui suit, au niveau d’un dispositif de supervision :
    - recevoir (S2), en provenance de deux dispositifs de contrôle du service associés respectivement aux deux technologies, des données relatives au déroulement du service, lesdites données correspondant à des valeurs d’une pluralité de paramètres de fonctionnement du service ou d’une ressource mise en œuvre dans le service,
    - extraire (S3) une structure de données (STD) préalablement stockée et comprenant des identifiants associés auxdits paramètres,
    - à partir de ladite structure de données, générer (S4) un ou deux fichiers de données, dans lequel les identifiants desdits paramètres de fonctionnement sont associés aux valeurs de données reçues, relatives au déroulement du service mis en œuvre selon respectivement les deux technologies.
  2. Procédé de supervision du fonctionnement d’un service de transmission de données selon la revendication 1, dans lequel le ou les fichiers de données sont générés en fonction d’au moins un contexte de supervision du service.
  3. Procédé de supervision du fonctionnement d’un service de transmission de données selon la revendication 2, dans lequel le dispositif de supervision est configuré (S1) selon le contexte de supervision, de manière statique et/ou dynamique.
  4. Procédé de supervision du fonctionnement d’un service de transmission de données selon l’une quelconque des revendications 1 à 3, comprenant une étape de commande (S5) de la restitution, sur une interface de supervision, du ou des fichiers de données générés.
  5. Dispositif de supervision (DSU) adapté pour contrôler le fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes, ledit dispositif comprenant un processeur (PROC) qui est configuré pour mettre en œuvre ce qui suit :
    - recevoir, en provenance de deux dispositifs de contrôle du service associés respectivement aux deux technologies, des données relatives au déroulement du service, lesdites données correspondant à des valeurs d’une pluralité de paramètres de fonctionnement du service ou d’une ressource mise en œuvre dans le service,
    - extraire une structure de données préalablement stockée et comprenant des identifiants associés auxdits paramètres,
    - à partir de ladite structure de données, générer un ou deux fichiers de données, dans lequel les identifiants desdits paramètres de fonctionnement sont associés aux valeurs de données reçues, relatives au déroulement du service mis en œuvre selon respectivement les deux technologies.
  6. Programme d'ordinateur comportant des instructions de code de programme pour la mise en œuvre du procédé de supervision du fonctionnement d’un service de transmission de données selon l’une quelconque des revendications 1 à 4, lorsqu'il est exécuté sur un ordinateur.
  7. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 6.
FR2111699A 2021-11-04 2021-11-04 Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes Pending FR3128840A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2111699A FR3128840A1 (fr) 2021-11-04 2021-11-04 Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2111699A FR3128840A1 (fr) 2021-11-04 2021-11-04 Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes
FR2111699 2021-11-04

Publications (1)

Publication Number Publication Date
FR3128840A1 true FR3128840A1 (fr) 2023-05-05

Family

ID=80786933

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2111699A Pending FR3128840A1 (fr) 2021-11-04 2021-11-04 Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes

Country Status (1)

Country Link
FR (1) FR3128840A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050246726A1 (en) * 2004-04-28 2005-11-03 Fujitsu Limited Task computing
EP2251787A2 (fr) * 2009-05-11 2010-11-17 Accenture Global Services GmbH Cadre adaptateur de réseau
EP2656544A1 (fr) * 2010-12-20 2013-10-30 Telefonaktiebolaget LM Ericsson (PUBL) Procédé et dispositif de surveillance de service et de gestion de surveillance de service

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050246726A1 (en) * 2004-04-28 2005-11-03 Fujitsu Limited Task computing
EP2251787A2 (fr) * 2009-05-11 2010-11-17 Accenture Global Services GmbH Cadre adaptateur de réseau
EP2656544A1 (fr) * 2010-12-20 2013-10-30 Telefonaktiebolaget LM Ericsson (PUBL) Procédé et dispositif de surveillance de service et de gestion de surveillance de service

Similar Documents

Publication Publication Date Title
EP1726124B1 (fr) Systeme et procede de controle d&#39;equipements a distance a l&#39;aide de commandes at, dispositif, module de radiocommunication et programme correspondants
EP2795870B1 (fr) Procede d&#39;acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP3087706B1 (fr) Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée
EP1422872B1 (fr) Procédé et dispositif modulaire de traçage d&#39;un message multimédia à travers un réseau de télécommunications
EP3119060A1 (fr) Procédé et dispositif d&#39;établissement de communications webrtc
EP2327236B1 (fr) Centre ussd générique d&#39;applications et de services réseaux
FR3128840A1 (fr) Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes
EP1935149A2 (fr) Procede et systeme de notification de reception de messages asynchrones
FR2991840A1 (fr) Procede de traitement de donnees par un module de navigation
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
EP2843923A2 (fr) Dispositif et procédé d&#39;enrichissement d&#39;une communication
EP1314109B1 (fr) Procede pour l&#39;exploitation d&#39;applications graphiques sur un terminal mobile
FR3042374A1 (fr) Aide a l&#39;etablissement d&#39;une communication telephonique par provision d&#39;informations sur l&#39;utilisateur appelant
EP4154137A1 (fr) Procede et systeme d&#39;authentification d&#39;un utilisateur aupres d&#39;un serveur d&#39;authentification
EP3110109A1 (fr) Procédé et dispositif de mise à jour des capacités d&#39;un objet connecté à un réseau de communications
WO2007116169A1 (fr) Module, procede et programme d&#39;ordinateur de generation de messages
EP3757865A1 (fr) Procédé de traitement d&#39;un message et dispositif correspondant
EP2166731B1 (fr) Système et procédé d&#39;établissement de communications.
FR3094539A1 (fr) Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication
FR3013550A1 (fr) Procede et dispositif de mise a jour de boites d&#39; emission de messages associees a un terminal de communication
WO2009013440A1 (fr) Procede d&#39;echange de messages entre serveur de donnees de session et des services clients
EP1676233A2 (fr) Procede d&#39;enquete electronique
FR3067208A1 (fr) Procede de mise a jour de messages echanges avec un agent conversationnel
da S Teófilo et al. A Mobile-Based System for Content Delivery over SMS
FR2861528A1 (fr) Procede et systeme de notification de statut entre deux terminaux

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20230505

PLFP Fee payment

Year of fee payment: 3