Brevet FR3102906A1 — publié le 20210507

La présente invention concerne un procédé de traitement d’un incident réseau caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (31) d’un serveur (3) d’étapes de : (a) Obtention depuis une pluralité d’équipements réseau (1a, 1b, 2a, 2b, 2c) d’enregistrements de données, dit CDR, chacun descriptif d’une procédure réseau du point de vue dudit équipement réseau (1a, 1b, 2a, 2b, 2c) ; (b) Pour au moins une procédure réseau cible liée audit incident réseau, identification de l’ensemble des CDR descriptifs de ladite procédure réseau cible ; (c) Analyse du ou des ensembles de CDR identifiés. Figure de l’abrégé : Fig 1 procédé de traitement d’un incident réseau DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine de la gestion de la qualité de service d’un réseau opérateur. Plus précisément, elle concerne un procédé de traitement d’un incident réseau. ETAT DE L’ART On appelle CDR (call detail record) les statistiques d'appel c’est à dire un fichier de données recueillies par un opérateur réseau concernant un appel (fixe, VoIP, mobile) ou tout autre procédure réseau (SMS, data). Des CDR sont émis par tous les équipements de télécommunications impliqués dans les événements. Ces données sont généralement utilisées pour l'optimisation du réseau, la facturation et également la détection d'incident. Dans le cadre du suivi de la qualité de service, il est en effet important de monitorer et de comprendre les événements réseau, avec une vision la plus fine possible. Une analyse des CDR permet en effet en cas de pannes de trouver les origines des pannes pour rétablir au plus vite le réseau et dégrader le moins possible l’expérience utilisateur. La difficulté est que justement, en cas d’incident réseau, les CDR qui parviennent ne sont que parcellaires, ce qui complique ce travail d’analyse. De surcroit, le volume de données ne fait qu’augmenter avec le développement des infrastructures réseau. En particulier, en France, un opérateur a plus de 20 milliards d’événements réseau à traiter. Il serait par conséquent souhaitable de disposer d’une nouvelle solution universelle, fiable, et sensiblement plus efficace d’analyse des CDR pour traiter les incidents réseaux. Selon un premier aspect, la présente invention se rapporte donc à un procédé de traitement d’un incident réseau caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données d’un serveur d’étapes de : (a) Obtention depuis une pluralité d’équipements réseau d’enregistrements de données, dit CDR, chacun descriptif d’une procédure réseau du point de vue dudit équipement réseau ; (b) Pour au moins une procédure réseau cible liée audit incident réseau, identification de l’ensemble des CDR descriptifs de ladite procédure réseau cible ; (c) Analyse du ou des ensembles de CDR identifiés. Selon des caractéristiques avantageuses et non-limitatives : Chaque CDR descriptif d’une procédure réseau comprend une pluralité de paramètres, dont au moins un paramètre lié à un abonné et au moins un paramètre de la procédure réseau. Deux CDR sont identifiés comme descriptifs de la même procédure réseau cible si lesdits paramètres lié à un abonné et paramètre de la procédure réseau présentent une corrélation. Deux CDR sont identifiés comme descriptifs de la même procédure réseau cible en utilisant au moins un arbre décisionnel. L’étape (b) comprend en outre, pour chaque ensemble identifié de CDR descriptifs de la même procédure réseau, la génération d’un enregistrement de données global, dit Meta-CDR, combinant les données de tous les CDR de l’ensemble, l’étape (c) étant mise en œuvre sur la base du ou des Meta-CDR générés. L’étape (c) comprend une classification de causes possibles d’incident et/ou une analyse géospatiale de l’incident en fonction de la localisation desdits équipements réseaux ayant fourni les CDR du ou des ensembles de CDR identifiés. Ladite pluralité d’équipements réseau comprend au moins un équipement opérateur et au moins un terminal mobile d’un abonné dudit opérateur. Chaque équipement réseau est configuré pour générer au moins un CDR pour chaque procédure réseau l’impliquant. Selon un deuxième aspect, est proposé un serveur de traitement d’un incident réseau caractérisé en ce qu’il comprend des moyens de traitement de données configurés pour : - Obtenir depuis une pluralité d’équipements réseau d’enregistrements de données, dit CDR, chacun descriptif d’une procédure réseau du point de vue dudit équipement réseau ; - Pour au moins une procédure réseau cible liée audit incident réseau, identifier l’ensemble des CDR descriptifs de ladite procédure réseau cible ; - Analyser le ou les ensembles de CDR identifiés. Selon un deuxième et un troisième aspect, sont proposés un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de traitement d’un incident réseau ; et des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon le premier aspect de traitement d’un incident réseau. D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : la figure 1 représente un mode de réalisation préféré d’une architecture pour la mise en œuvre du procédé selon l’invention ; la figure 2 illustre un mode de réalisation du procédé selon l’invention ; la figure 3 représente schématiquement un exemple de génération d’un Meta-CDR lors d’une procédure réseau. Architecture globale En référence à la figure 1 , est proposé un procédé de traitement d’un incident réseau dans un réseau 20. Par « incident réseau », on entend n’importe quel événement réseau potentiellement impactant la qualité de service et l’expérience utilisateur lors d’une procédure réseau, et qu’il est souhaitable de traiter, c’est-à-dire de détecter, identifier, caractériser et/ou résoudre, au plus vite. Par exemple, un mauvais handover (i.e. le changement de cellule lors du déplacement d’un utilisateur) peut entraîner une coupure inopinée d’un appel. Le traitement d’un incident peut ainsi être vu comme la détection, l’identification, la caractérisation et/ou la résolution de l’incident réseau. De manière générale, au moins une action pourra être automatiquement détectée selon l’incident réseau. Les procédures réseau dont il est question sont généralement un appel, mais également un SMS, un MMS, une transmission de données internet (data), etc. Dans chaque procédure réseau, une pluralité d’équipement réseau 1a, 1b, 2a, 2b, 2c sont toujours impliqués, que ce soit des équipements personnels 1a, 1b à un abonné (en général les « terminaux », c’est-à-dire les équipements d’origine ou de destination de la procédure réseau, en particulier des terminaux mobiles de type smartphone détenus par des abonnés), et les équipements opérateur 2a, 2b, 2c qui sont des équipements intermédiaires de type routeur, antenne relais, etc. impliqués dans la transmission et le routage du signal pour ladite procédure réseau. Par exemple, dans la figure 1, deux terminaux mobiles 1a, 1b sont connectés au réseau internet 20 via un réseau opérateur 21 grâce à des antennes relais 2a, 2b. Un réseau télécom composé d’équipements d’agrégation, de routeurs 2c et d’équipement de « coeur » (voix, data, etc.) ainsi que des plateformes de services interconnecte les antennes relais ou d’autres routeurs de sorte qu’un appel entre les terminaux 1 implique cinq équipements réseau 1a, 1b, 2a, 2b, 2c. Dans l’exemple représenté, l’antenne 2b a un problème interrompant la connexion avec le terminal 1b. Un serveur distant 3, typiquement un serveur de l’opérateur est disposé dans le réseau internet 20 ou le réseau opérateur 21 et est ainsi connecté à chacun des équipements 1a, 1b, 2a, 2b, 2c. Comme l’on verra ce serveur 3 est destiné à la collecte et au traitement d’enregistrement de données de procédure réseau, dits CDR pour Call Detail Record. A noter que le terme CDR a été créé à une époque où les procédures réseau n’étaient que des appels (il n’y avait pas de SMS, etc.), mais aujourd’hui le terme est bien applicable à toute procédure et pas seulement un appel. De manière classique, chaque équipement 1a, 1b, 2a, 2b, 2c et le serveur 3 comprennent des moyens de traitement de données respectifs de type processeur (notés 31 pour le serveur 3), et le cas échéant des moyens de stockages de données (une mémoire, notée 32 pour le serveur 3), par exemple un disque dur. CDR De manière classique, chaque CDR est associé à : une procédure réseau ; un équipement réseau 1a, 1b, 2a, 2b, 2c. Plus précisément, le CDR est descriptif de cette procédure réseau du point de vue dudit équipement réseau 1, 2a, 2b. Par « de son point de vue » on entend tel que la procédure se déroule pour lui. Il est en effet possible que deux équipements impliqués dans une même procédure n’aient pas du tout le même « ressenti » (c’est-à-dire la perception d’anomalie) en particulier en cas d’incident. Cela signifie que pour une procédure réseau donnée, il y a une pluralité de CDR générés par les différents équipements réseau 1a, 1b, 2a, 2b, 2c impliqués de bout-en-bout (par exemple 5 dans le cas de l’appel téléphonique représenté sur la figure 1). Il peut néanmoins y avoir au final moins de CDR obtenus que d’équipements impliqués si un équipement 1a, 1b, 2a, 2b, 2c est en panne (dans la figure 1, l’antenne relais 2b est en panne), l’équipement en panne n’ayant potentiellement plus la capacité de générer et/ou transmettre les CDR. On note qu’il peut éventuellement y avoir plus d’un CDR par équipement pour une procédure réseau, si celle-ci dure, ou implique des sous-événements (par exemple, au milieu d’un appel téléphonique, un handover ou une activation d’une visioconférence via IP), mais par commodité on supposera dans la suite de la description que pour une procédure donnée chaque équipement envoie un unique CDR. On suppose que la procédure de génération automatique de CDR par chaque équipements 1a, 1b, 2a, 2b, 2c est connue et l’homme du métier pourra utiliser les mécanismes et les formats de CDR connus. De manière générale, un CDR descriptif d’une procédure réseau donnée contient tous les renseignements relatifs à cette procédure sauf le contenu. En particulier le CDR comprend une pluralité de paramètres, dont au moins un paramètre lié à un abonné (en l’espèce l’abonné à l’origine de la procédure réseau) et au moins un paramètre de la procédure réseau. Par exemple, le paramètre lié à l’abonné peut être un identifiant de type : IMSI/TIMSI ; MSISDN ; IMEI. Le paramètre lié à l’abonné peut quant à lui être : Un identifiant du destinataire ; Un horodatage ; Une durée d’appel, etc. On note qu’il n’y a pas de paramètre identifiant de manière explicite la procédure réseau associée. Procédé En référence à la figure 2 , le procédé commence par une étape (a) d’obtention depuis la pluralité d’équipements réseau 1a, 1b, 2a, 2b, 2c des CDR. Typiquement cette collecte et passive et continue, chaque équipement réseau 1a, 1b, 2a, 2b, 2c se contenant de pousser régulièrement ses CDR. On note qu’à ce stade les CDR sont obtenus de manière indifférenciée, le serveur 3 sachant seulement de quel équipement 1a, 1b, 2a, 2b, 2c provient chaque CDR. Dans une étape (b), pour au moins une procédure réseau cible liée audit incident réseau, l’ensemble des CDR descriptifs de ladite procédure réseau cible est identifiée. Plus précisément, par « ensemble », on désigne tous les CDR associés à la même procédure réseau (ladite procédure cible), quel que soit l’équipement réseau 1a, 1b, 2a, 2b, 2c d’origine. L’idée est de reconstituer une procédure grâce aux points de vue des différents équipements. Comme l’on verra, cette étape (b) est dite de « corrélation multi-équipement ». Par « procédure réseau cible liée audit incident », on entend une procédure impactée par l’incident, et avantageusement quelques procédures précédentes (par exemple les 10 dernières). En effet, à ce stade on ne sait pas encore nécessairement l’existence d’un incident, et ce dernier peut être détecté par la présence d’un ou plusieurs CDR représentatifs d’un incident. Il suffit alors d’identifier les autres CDR associés à la même procédure. A noter que là l’étape (b) peut même être mise en œuvre pour d’autres procédure réseau que la ou les procédures cible, voire toutes les procédures réseau (i.e. tous les CDR disponibles vont être regroupés en ensembles) si la puissance de calcul du serveur 3 est suffisante. Préférentiellement, deux CDR sont identifiés comme descriptifs de la même procédure réseau cible si lesdits paramètres liés à un abonné et/ou paramètres de la procédure réseau présentent une corrélation. Il est en effet important de comprendre que les paramètres de deux CDR vont rarement coïncider exactement. Par exemple, les identifiants IMSI/TIMSI, MSISDN, IMEI utilisés ne sont pas les mêmes selon l’équipement. De plus, l’horodatage peut être différent si les équipements n’ont pas la même horloge ou prennent des points de référence différents (par exemple, lors d’un appel, on aura pour le terminal 1a appelant l’heure où l’abonné appuie sur le bouton d’appel, pour un routeur 2c l’heure à laquelle l’appel est reçu, et pour le terminal 1b destinataire l’heure à laquelle il décroche). Ainsi, on vérifie que les paramètres présentent une corrélation c’est-à-dire sont susceptibles de correspondre à la même procédure, grâce à des règles de conversion en fonction de l’équipement réseau 1a, 1b, 2a, 1b, 2c associé. Par exemple, à partir d’un premier CDR d’appel et d’une logique, on peut déterminer des fenêtres d’horodatage possibles pour les autres CDR corrélés, en fonction de leur équipement d’origine. Par ailleurs, on peut utiliser au moins un arbre décisionnel permettant une priorisation des CDR et des données qu’ils contiennent en fonction du schéma de procédure dans lequel on se trouve et de la différence de qualité d’information offerte par les équipements 1a, 1b, 2a, 2b, 2c. De manière préférée, l’étape (b) comprend, pour chaque ensemble de CDR descriptifs de la même procédure réseau (i.e. déterminés comme corrélés), la génération d’un enregistrement de données global, dit Meta-CDR, combinant les données de tous les CDR de l’ensemble. En d’autres termes, chaque paramètre d’un CDR de l’ensemble est renseigné comme paramètre du Meta-CDR. On peut ainsi voir le Meta-CDR comme un CDR multi-équipements permettant d’avoir une vue d’ensemble d’une procédure réseau. De plus cette vue d’ensemble est à des niveaux très différents puisqu’elle peut aller jusqu’aux terminaux 1a, 1b des abonnés et de modéliser un ressenti de l’expérience perçue et pas seulement la QoS constatée dans le réseau opérateur. Un exemple de génération d’un Meta-CDR est illustré par la figure 3 . On voit que sur l’ensemble de la procédure réseau cible les CDR 1 à 12 sont des CDR déterminés comme corrélés bien qu’ils proviennent d’équipements 1a, 1b, 2a, 2b, 2c différents et présentent des horodatages différents. Le Meta-CDR regroupe tous les paramètres de ces différents CDR. Dans une étape (c) finale, le ou les ensembles de CDR identifiés (le cas échéant sous la forme de Meta-CDR) sont analysés, en particulier de sorte à, comme expliqué, détecter, identifier, caractériser et/ou résoudre l’incident. On note qu’un ou plusieurs ensembles de CDR sont impliqués selon le nombre de procédures réseau cibles. Cette étape (c) peut être faite de nombreuses manières différentes, mais dans tous les cas on comprend qu’analyser que les CDR associés à des procédures cibles permet de réduire fortement le nombre d’analyses (plus précisément on n’analyse plus tous les CDR à l’aveugle, mais seulement ceux pertinents et corrélés) et donc d’augmenter la capacité de traitement. Avantageusement, l’étape (c) comprend une classification des causes possibles d’incident, en particulier sur la base de ladite pluralité de procédures cibles, notamment de sorte à établir une chronologie de l’incident réseau, mais aussi afin de mieux identifier la vraie raison qui est à l’origine du problème. Avantageusement, l’étape (c) comprend une analyse géospatiale, c’est-à-dire portant sur la localisation des équipements réseaux 1a, 1b, 2a, 2b, 2c concernés par les CDR associés aux procédures cibles, que ce soit une localisation connue du fait du caractère fixe de l’équipement par exemple pour une antenne relais 2a, 2b), ou grâce à des moyens de géolocalisation (position GPS d’un terminal 1a, 1b). En particulier, il est possible de créer des « zones de chaleurs » permettant d’observer l’impact d’un incident réseau sur une carte, mais aussi de détecter de faux-positifs liés à des impossibilités géographiques dues à des problèmes de la qualité des données des équipements réseau 1a, 1b, 2a, 2b, 2c. Serveur et produit programme d’ordinateur Selon un deuxième aspect, l’invention concerne un serveur 3 configuré pour la mise en œuvre du présent procédé. En particulier, ce serveur 3 comprend des moyens de traitement de données 31 configurés pour obtenir depuis une pluralité d’équipements réseau 1a, 1b, 2a, 2b, 2c d’enregistrements de données, dit CDR, chacun descriptif d’une procédure réseau du point de vue dudit équipement réseau 1a, 1b, 2a, 2b, 2c ; puis pour au moins une procédure réseau cible liée audit incident réseau, identifier l’ensemble des CDR descriptifs de ladite procédure réseau cible (le cas échéant générer un Meta-CDR par ensemble de CDR identifié) ; et analyser le ou les ensembles de CDR identifiés Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (en particulier sur les moyens de traitement de données 31 du serveur 3) du procédé de traitement d’un incident réseau, ainsi que des moyens de stockage lisibles par un équipement informatique (notamment des moyens de stockage de données 32 du serveur 3) sur lequel on trouve ce produit programme d’ordinateur. Procédé de traitement d’un incident réseau caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (31) d’un serveur (3) d’étapes de : (a) Obtention depuis une pluralité d’équipements réseau (1a, 1b, 2a, 2b, 2c) d’enregistrements de données, dit CDR, chacun descriptif d’une procédure réseau du point de vue dudit équipement réseau (1a, 1b, 2a, 2b, 2c) ; (b) Pour au moins une procédure réseau cible liée audit incident réseau, identification de l’ensemble des CDR descriptifs de ladite procédure réseau cible ; (c) Analyse du ou des ensembles de CDR identifiés. Procédé selon la revendication 1, dans lequel chaque CDR descriptif d’une procédure réseau comprend une pluralité de paramètres, dont au moins un paramètre lié à un abonné et au moins un paramètre de la procédure réseau. Procédé selon la revendication 2, dans lequel deux CDR sont identifiés comme descriptifs de la même procédure réseau cible si lesdits paramètres lié à un abonné et paramètre de la procédure réseau présentent une corrélation. Procédé selon la revendication 3, dans lequel deux CDR sont identifiés comme descriptifs de la même procédure réseau cible en utilisant au moins un arbre décisionnel. Procédé selon l’une des revendications 1 à 4, dans laquelle l’étape (b) comprend en outre, pour chaque ensemble identifié de CDR descriptifs de la même procédure réseau, la génération d’un enregistrement de données global, dit Meta-CDR, combinant les données de tous les CDR de l’ensemble, l’étape (c) étant mise en œuvre sur la base du ou des Meta-CDR générés. Dispositif selon l’une des revendications 1 à 5, dans lequel l’étape (c) comprend une classification de causes possibles d’incident et/ou une analyse géospatiale de l’incident en fonction de la localisation desdits équipements réseaux (1a, 1b, 2a, 2b, 2c) ayant fourni les CDR du ou des ensembles de CDR identifiés. Procédé selon l’une des revendications 1 à 6, dans lequel ladite pluralité d’équipements réseau (1a, 1b, 2a, 2b, 2c) comprend au moins un équipement opérateur (2a, 2b, 2c) et au moins un terminal mobile (1a, 1b) d’un abonné dudit opérateur. Procédé selon l’une des revendications 1 à 7, dans lequel chaque équipement réseau (1a, 1b, 2a, 2b, 2c) est configuré pour générer un ou plusieurs CDR pour chaque procédure réseau l’impliquant. Serveur (3) de traitement d’un incident réseau caractérisé en ce qu’il comprend des moyens de traitement de données (31) configurés pour : - Obtenir depuis une pluralité d’équipements réseau (1a, 1b, 2a, 2b, 2c) d’enregistrements de données, dit CDR, chacun descriptif d’une procédure réseau du point de vue dudit équipement réseau (1a, 1b, 2a, 2b, 2c) ; - Pour au moins une procédure réseau cible liée audit incident réseau, identifier l’ensemble des CDR descriptifs de ladite procédure réseau cible ; - Analyser le ou les ensembles de CDR identifiés. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 8 de traitement d’un incident réseau, lorsque ledit programme est exécuté par un ordinateur Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 8 de traitement d’un incident réseau.