Brevet FR3164866A1 — publié le 20260123

L’invention concerne un procédé de prédiction d’un paramètre de qualité de service, QoS, d’un réseau de télécommunications apte à transporter des données d’application véhiculaire, le procédé comportant, pour au moins une position ou une zone d’une zone de couverture radio du réseau de télécommunications et pour au moins un horizon de prédiction : - obtention de M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone, M étant un entier supérieur ou égal à 1; - détermination (302) d’une valeur prédite du paramètre de qualité de service, pour l’horizon de prédiction et pour la position ou zone, par application d’un modèle de prédiction à des données d’entrées comprenant un identifiant de la position ou zone, l’au moins un horizon de prédiction et les M valeurs mesurées du paramètre de qualité de service. Fig.3 Prédiction d’un paramètre de qualité de service d’un réseau de télécommunications Domaine de l’invention Le domaine de l’invention est celui de la prédiction de paramètres de qualité de service, QoS, d’un réseau de télécommunications, en particulier pour l’adaptation de la mise en œuvre d’applications véhiculaires basées sur des communications Véhicule-à-tout, V2X. Art antérieur Les communications V2X sont désormais clé dans le fonctionnement des véhicules automobiles récents. Ces communications permettent aux véhicules équipés d’une interface V2X de communiquer entre eux, avec les infrastructures routières et avec les piétons, ce qui permet une amélioration de la sécurité routière, une meilleure efficacité du trafic et une meilleure expérience globale des conducteurs et des passagers. Deux technologies de communication sans fil dominent dans les communications V2X : - la technologie DSRC, pour « Dedicated Short-Range Communication » en anglais, qui est basée sur la norme IEEE 802.11p ; et - la technologie V2X cellulaire, ou C-V2X pour « Cellular-V2X » en anglais, utilisant des réseaux de télécommunications cellulaires associés aux technologies 4G et 5G. La technologie DSRC est une technologie de communication sans fil à courte portée spécialement conçue pour les communications véhicule à véhicule, V2V, et véhicule à infrastructure, V2I. Elle fonctionne dans la bande de fréquences des 5,9 GigaHertz, GHz. Elle permet ainsi aux véhicules de communiquer entre eux et avec les infrastructures routières environnantes, facilitant ainsi l’échange d’informations en temps réel qui peuvent être consommées par des fonctions du véhicule, permettant d’améliorer la sécurité routière et les performances du trafic. Les applications du DSRC incluent les systèmes de prévention des accidents, les alertes de circulation, les systèmes de gestion de la congestion et d’autres fonctionnalités visant à augmenter l’efficacité et la sécurité du réseau routier. La technologie DSRC offre des avantages tels que des latences minimales et des connexions directes, idéales pour les échanges d’informations en temps réel entre les véhicules et leur environnement. En revanche, la technologie C-V2X offre une portée plus étendue et une capacité à gérer des volumes de données plus importants, mais au détriment de latences légèrement supérieures. En plus des critères de latences et de portées, les technologies C-V2X et DSRC peuvent être comparées selon les critères additionnels suivants : - concernant leur évolutivité : comme indiqué, C-V2X utilise les réseaux cellulaires de technologies 4G et 5G pour établir des connexions, ce qui offre une grande capacité et une évolutivité vers des réseaux de plus en plus avancés au fur et à mesure qu’ils se développent. Ce n’est pas le cas de la technologie DSRC qui est basée sur une bande de fréquences dédiée, ce qui limite l’évolutivité de la technologie DSRC ; - concernant leur interopérabilité : la technologie C-V2X, étant normalisée par des organismes tels que le « 3rd Generation Partnership Project », 3GPP, bénéficie d’une interopérabilité large entre différents fabricants et infrastructures. En revanche, bien que largement utilisée dans les premières applications V2X, la technologie DSRC a rencontré des défis en termes d’interopérabilité, ce qui peut limiter son adoption à une échelle large ; - concernant leur utilisation pour des applications avancées : la technologie C-V2X offre une flexibilité et une capacité de traitement accrues par rapport à la technologie DSRC, grâce à l’utilisation des réseaux cellulaires. Cela permet des application plus avancées, telles que des mises à jour en temps réel des informations routières, des alertes de sécurité sophistiquées et des communications avec des services basés sur le cloud. Bien qu’efficace pour des applications de base, la technologie DSRC peut avoir des limitations lorsqu’il s’agit de traiter des volumes importants de données ou de gérer des applications complexes. Les applications véhiculaires sont intrinsèquement sensibles à la réactivité et requièrent des critères portant sur des paramètres de QoS plus élevés que les exigences conventionnelles des utilisateurs grand public. Ces critères garantissent des communications fiables et sécurisées au sein de l’écosystème V2X. Une QoS prédictive, ou P-QoS pour « Predictive Quality of Service » en anglais, permet théoriquement d’anticiper des capacités de connexion au réseau cellulaire, permettant ainsi à des applications C-V2X, telles que la conduite automatisée ou le système de gestion de trafic intelligent, de calculer et d’ajuster en avance leur mode de fonctionnement pour garantir la sécurité et la disponibilité continues de ces applications. Les spécifications émanant de l’organisme 3GPP définissent des paramètres de QoS et des seuils à atteindre, pour garantir une QoS adaptée aux exigences des applications véhiculaires. Les dynamiques spatio-temporelles des réseaux cellulaires et la mobilité des véhicules peuvent entraîner des changements soudains de paramètres de QoS. Un ajustement brusque de l’application véhiculaire, surtout en raison d’une dégradation de paramètres de QoS, peut affecter de manière inappropriée les performances des applications véhiculaires V2X, en causant une discontinuité de service ou une inefficacité du trafic. Afin de pouvoir anticiper de telles variations de paramètres QoS, l’organisme 3GPP a proposé, dans la spécification technique 3GPP TS 23.288, version 17.4.0 Release 17, de mai 2022, en section 6.9, un mécanisme de notification préalable de la QoS prédite, appelé « QoS Sustainability ». Un tel mécanisme repose sur une prédiction d’un changement attendu de paramètres de QoS. Les changements soudains de QoS peuvent ainsi être évités ou atténués en informant les serveurs applicatifs en charge des applications véhiculaires V2X des paramètres de connectivité et des changements imminents de QoS afin de maintenir la sécurité et l’efficacité des applications V2X. Le document « Technical Report on Predictive QoS and V2X Service Adaptation », 5GAA, Octobre 2022, a notamment identifié plusieurs cas d’utilisation bénéficiant de notifications de prédiction de paramètres de QoS, notamment la conduite téléopérée, le support téléopéré, le franchissement automatisé d’intersection, la fusion de voies coopérative, les manœuvres de conduite coordonnée, l’assistance au mouvement d’intersection, le peloton à haute densité, l’avertissement de freinage d’urgence, l’avertissement de changement de voie, la confirmation de l’attention des utilisateurs, l’assistance au virage à gauche face au trafic transversal, le stationnement latéral coopératif, la mise à jour logicielle et la cartographie haute-définition. Le document précité introduit une architecture réseau comprenant plusieurs entités, pour la mise en œuvre d’une QoS prédictive. Une telle architecture comprend : - des serveurs d’application V2X, notés AS pour « Application Server » en anglais, qui agissent comme des fonctions d’application, notées AF pour « Application Function » en anglais, et qui ont pour rôle de requérir des notifications de prédiction de paramètres de QoS ; - une fonction d’exposition de réseau, notée NEF, qui agit comme une fonction réseau, NF, pour « Network Function » en anglais, qui échange avec les serveurs d’application V2X pour fournir des notifications de prédiction de la QoS. Elle gère les requêtes et les abonnements des serveurs d’application V2X et leur transmet les réponses ou notifications ; - une fonction d’analyse de données réseau, notée NWDAF pour « Network Data Analysis Function », qui est responsable de la fourniture des analyses et des prédictions des paramètres de QoS. Elle collecte des données de performance du réseau à partir d’une entité d’administration, d’opération et de maintenance, notée OAM, pour évaluer et dériver les prédictions de changement de QoS attendus ; - l’entité OAM, qui est responsable de la surveillance des performances du réseau de télécommunications, et de la transmission des données statistiques à la fonction NWDAF. La spécification technique TS23.287 « Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services » , version 16, de janvier 2019, introduit une procédure de notification de changements potentiels de paramètres de QoS d’un réseau de télécommuncations 5G, sur requête d’un serveur d’application V2X. Selon cette procédure, le serveur d’application V2X fournit des informations de localisation sous la forme d’un chemin d’intérêt et une fenêtre temporelle indiquant une période durant laquelle s’applique le service de notification, ainsi que des seuils indiquant les niveaux de paramètres de QoS, en-deçà ou au-delà desquels une notification doit être transmise au serveur d’application V2X. De manière plus précise, la procédure décrite dans le document précédemment cité comprend les étapes suivantes : - le serveur d’application V2X obtient des informations de couche applicative telles que le service V2X, le chemin d’intérêt, une heure de début du chemin d’intérêt, des exigences et seuils de paramètres de QoS ; - le serveur d’application V2X s’abonne aux informations analytiques du service « QoS Sustainabiliy », fournies par la fonction NWDAF, via la fonction NEF. La fonction NWDAF est chargée de fournir à la demande des analyses à d’autres entités du réseau. Un message d’abonnement peut comprendre un identifiant d’information analytique requise et des informations telles que les exigences et seuils de paramètres de QoS, les informations de localisation et une période d’observation ; - la fonction NWDAF collecte des statistiques fournies par l’entité OAM, qui est en charge de la surveillance des performances du réseau de télécommunications. La fonction NWDAF vérifie si les conditions déclenchantes (pouvant inclure une comparaison avec un seuil, plusieurs comparaisons avec des seuils, ou d’autres évènements spécifiques) sont remplies et détermine les informations analytiques demandées concernant tout changement attendu d’un paramètre QoS. Selon le document "System Architecture for the 5G System Stage 2 (Release 16)", 3GPP TS 23.501 V16.7.0, Decembre 2020 , la fonction NWDAF peut notamment déterminer un besoin de notification en comparant les informations analytiques demandées avec le ou les seuils fournis de paramètres de QoS dans la période demandée ; - la fonction NWDAF fournit une notification de service « QoS sustainability » au serveur d’application V2X, via la fonction NEF, qui peut comprendre un identifiant d’une zone à laquelle s’applique les informations analytiques, une période, au sein de la période d’observation, à laquelle s’appliquent les informations analytiques, ainsi que le ou les seuils franchis par un ou plusieurs paramètres de QoS ; - en fonction de la notification reçue, le serveur d’application V2X peut ajuster l’application V2X qu’il met en œuvre. Dans les versions 17 et 18 de la spécification technique précitée « Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services », une amélioration de la qualité statistique des informations analytiques fournies est proposée, en collectant des données sur un ensemble d’équipements utilisateur desservis par une cellule du réseau de télécommunications. Toutefois une telle granularité ne permet pas une prise en compte de contexte particulier de certains équipements de la cellule qui peuvent affecter un ou plusieurs paramètres réels de QoS. La version 18 cherche à améliorer une telle granularité dans les analyses fournies par le service « QoS sustainability ». Toutefois, les techniques précitées ne prévoient pas concrètement comment prédire avec une précision élevée, l’évolution d’un paramètre de QoS à un endroit donné, ou dans une zone donnée. Or, les applications véhiculaires V2X nécessitent une précision importante dans la prédiction de paramètres QoS. En effet, le développement des applications V2X repose sur la mobilité connectée, notamment pour les niveaux d’autonomie les plus élevés selon la norme SAE J3016 décrite dans le document "Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems", J3016\_201401, SAE International, 2018. Dans cette norme, les niveaux d’autonomie 2 et 3 qui sont actuellement disponibles sur le marché, permettent la mise en œuvre de fonctions d’assistance à la conduite semi-automatisées. L’assistance du conducteur reste ainsi nécessaire, bien que le système d’assistance à la conduite, ADAS pour « Advanced Driver Assistance System », puisse exécuter certaines tâches de conduite de manière automatisée. Les véhicules de niveaux 4 et 5 impliquent des scénarios dans lesquels l’ADAS peut permettre une prise en main de tâches de conduite sans nécessiter l’intervention de l’utilisateur, y compris dans des situations complexes, comme décrit dans le document Naranjo, José, et al. "Cross-Border interoperability for Cooperative, Connected and Autonomous Driving" IEEE Intelligent Transportation Systems Magazine (2021). D’une part, dans les niveaux d’autonomie 2 et 3, l’intéraction conducteur-véhicule est fréquente et doit être prise en compte dans la prédiction d’un paramètre de QoS. D’autre part, dans les niveaux d’autonomie 4 et 5, des prédictions de paramètres de QoS très précis sont requis dans la mesure où l’ADAS pilote complétement le véhicule sans intervention humaine. En effet, bien que le système ADAS soit basé sur des capteurs tels que la détection et la télémétrie laser, le radar et les caméras, ces capteurs présentent des limitations pouvant entraîner des décisions incorrectes et des accidents graves. Les technologies de télécommunications permettent de compenser ces limitations, grâce notamment aux applications véhiculaires V2X décrites précédemment. La dépendance des fonctions ADAS aux technologies de communication véhiculaires V2X sont renforcées depuis la mise en place de réseaux mobiles de télécommunications de cinquième génération, qui offrent des bandes passantes plus larges et des latences réduites, répondant ainsi aux exigences strictes des applications véhiculaires V2X en termes de qualité de service. Cependant, même en tenant compte des avantages offerts par les réseaux mobiles 5G, les environnements routiers sont soumis à des fluctuations imprévisibles en raison de facteurs divers, tels que la congestion et les mouvements rapides des véhicules. La mobilité des utilisateurs a un impact significatif sur la qualité de service permise par le réseau mobile 5G. En outre, la popularité croissante des applications mobiles, telles que le divertissement en voiture, impose des contraintes de plus en plus importantes sur les réseaux de télécommunications, tels que les réseaux de télécommunications cellulaires notamment. Les opérateurs de réseaux mobiles, MNO pour « Mobile Network Operator » en anglais, sont ainsi contraints de collecter une grande quantité de données hétérogènes pour surveiller la performance du réseau de télécomminications et fournir une meilleure qualité de service. Dans ce but, l’utilisation de modèles d’intelligence artificielle basés sur l’apprentissage machine se développe. Leur application à des fonctions de prédiction de paramètres de QoS est toutefois limitée, du fait d’une part de l’absence de jeux de données de qualité publiquement accessibles pour l’entraînement de modèles prédictifs, et du fait de la grande variabilité des situations rencontrées par les véhicules. Le document M. Skocaj et al., "Vehicle-to-Everything (V2X) Datasets for Machine Learning-Based Predictive Quality of Service," IEEE Communications Magazine, vol. 61, no. 9, pp. 106-112, Septembre 2023, Doi: 10.1109/MCOM.004.2200723, décrit les bases de données accessibles pour une telle application. Il existe ainsi un besoin de prédire avec précision et avec une bonne granularité spatiale, les évolutions d’un ou plusieurs paramètres de QoS dans un réseau de télécommunications, afin de permettre à des applications véhiculaires V2X de tenir compte de telles évolutions, améliorant ainsi la sécurité et la qualité d’expérience des utilisateurs de véhicules bénéficiant de telles applications véhiculaires V2X. Objet et résumé de l'invention Un des buts de l'invention est de remédier à au moins l’un des inconvénients de l'état de la technique précité en proposant une nouvelle technique de prédiction d’un paramètre de QoS adaptée à une prise en compte pour une application véhiculaire basée sur une communication V2X, par exemple de type C-V2X ou de type V2X satellitaire. Il est ainsi rendu possible pour un serveur applicatif déployant une application véhiculaire V2X auprès de véhicules d’anticiper des variations de paramètre de QoS. A cet effet, un objet de la présente invention concerne un procédé de prédiction d’un paramètre de qualité de service, QoS, d’un réseau de télécommunications apte à transporter des données d’application véhiculaire, le procédé comportant, pour au moins une position ou une zone d’une zone de couverture radio du réseau de télécommunications et pour au moins un horizon de prédiction : - obtention de M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone, M étant un entier supérieur ou égal à 1; - détermination d’une valeur prédite du paramètre de qualité de service, pour l’horizon de prédiction et pour la position ou zone, par application d’un modèle de prédiction à des données d’entrées comprenant un identifiant de la position ou zone, l’au moins un horizon de prédiction et les M valeurs mesurées du paramètre de qualité de service. La prise en compte de mesures réelles de paramètres de QoS, dans la prédiction de son évolution dans un horizon de prédiction, permet de tenir compte de la forte dynamique et de la variabilité des contraintes qui s’appliquent à un réseau de télécommunications, par exemple un réseau de télécommunications cellulaire qui transporte des données d’applications véhiculaires de type C-V2X, ou un réseau de télécommunications satellitaire transportant des données d’applications véhiculaires V2X. En outre, la prédiction peut être effectuée pour un endroit donné, repéré par une position ponctuelle ou une zone, puisque le modèle de prédiction est apte à prendre en tant que donnée d’entrée un identifiant de position ou de zone. Selon des modes de réalisation, le procédé peut comprendre en outre une transmission de la valeur prédite du paramètre de qualité de service à un serveur applicatif configuré pour déployer une application véhiculaire auprès d’un ensemble de véhicules via le réseau de télécommunications. Ainsi, la valeur de paramètre de QoS prédite peut être exploitée par le serveur applicatif pour prendre une mesure anticipatoire permettant une meilleure robustesse et continuité de l’application véhiculaire. Il est ainsi permis de renforcer l’expérience utilisateur dans les véhicules bénéficiant de l’application véhiculaire, voire de renforcer la sécurité associée à la conduite des véhicules. Selon des modes de réalisation, le procédé peut comprendre en outre une publication de ladite valeur prédite du paramètre de qualité de service dans un serveur de publication de prédictions accessible via un réseau étendu. Ainsi, la publication dans un serveur de publication de prédictions permet la mise en œuvre d’un service de type « QoS sustainability », permettant aux serveurs applicatifs de formuler des requêtes uniques ou des requêtes d’abonnement pour être informés des évolutions du paramètre de QoS. Une variété importante d’applications véhiculaires V2X peut ainsi bénéficier des prédictions du paramètre de QoS. Selon des modes de réalisation, le procédé peut comprendre la détermination de plusieurs valeurs prédites du paramètre de qualité de service, pour ladite position ou zone et pour plusieurs horizons de prédiction respectifs, par plusieurs applications du modèle de prédiction à des données d’entrée respectives. Des prédictions pour une pluralité d’horizons de prédiction permettent de mieux représenter la dynamique d’évolution future du paramètre de QoS. Des mesures anticipatoires plus précises peuvent ainsi être mises en œuvre par un ou plusieurs serveurs applicatifs. Selon des modes de réalisation, le procédé peut comprendre la détermination d’au moins une valeur prédite du paramètre de qualité de service pour plusieurs positions ou zones de la zone de couverture radio et pour au moins un horizon de prédiction, par plusieurs applications du modèle de prédiction à des données d’entrée respectives. Il est ainsi rendu possible de prédire de manière différenciée sur plusieurs zones ou positions d’une zone de couverture globale du réseau de télécommunications , l’évolution de la valeur du paramètre de QoS. Il est ainsi permis de mettre à disposition des informations cartographiques représentant l’évolution du paramètre de QoS, ce qui permet à des serveurs applicatifs de préconiser certaines routes pour maintenir la qualité d’expérience utilisateur associée à une application véhiculaire V2X. En complément, pour K positions ou zones de la zone de couverture radio et pour L horizons de prédiction, K et L étant des entiers supérieurs ou égaux à 2, K*L valeurs prédites de paramètre de QoS sont obtenues pour les K positions ou zones respectives et pour les L horizons de prédiction respectifs par K*L applications du modèle de prédiction à des données d’entrée respectives. Les K*L valeurs prédites de paramètres de QoS peuvent être publiées dans le serveur de publication de prédictions. Il est ainsi rendu possible de prédire de manière différenciée sur plusieurs zones ou positions d’une zone de couverture globale du réseau de télécommunications l’évolution dans plusieurs horizons de prédiction de la valeur du paramètre de QoS. Ainsi, il est rendu possible de fournir une cartographie illustrant avec précision la dynamique d’évolution du paramètre de QoS dans le futur. Selon des modes de réalisation, la détermination de la valeur prédite, pour l’horizon de prédiction et pour la position ou zone, peut être répétée à une fréquence associée à une période supérieure à l’horizon de prédiction. Une telle période est notée T2 dans la description qui suit. Ainsi, les prédictions peuvent être répétées afin de prendre en compte de nouvelles données d’entrées (les M dernières valeurs mesurées de paramètre de QoS notamment), ce qui permet une prédiction précise dans un environnement très changeant tel qu’un réseau de télécommunications transportant des données d’applications véhiculaires V2X. Selon des modes de réalisation, le procédé peut comprendre une collecte de valeurs mesurées du paramètre de QoS depuis au moins un serveur applicatif configuré pour mettre en œuvre une application véhiculaire auprès d’un ensemble de véhicules via le réseau de télécommunications, lesdites valeurs mesurées étant horodatées et associées à au moins un identifiant de position ou de zone, et un stockage desdites valeurs mesurées du paramètre de QoS dans une base de données. Les M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone peuvent être obtenues depuis ladite base de données. Ainsi, les valeurs mesurées du paramètre de QoS peuvent être centralisées dans une base de données, et peuvent être remontées depuis les véhicules circulant dans la zone de couverture du réseau de télécommunications, notamment via des serveurs applicatifs déployant des applications véhiculaires V2X. Il est ainsi permis d’enrichir en temps réel la base de données, ce qui permet de mettre en œuvre des prédictions de la valeur de paramètre de QoS en temps réel également. Qui plus est, disposer de valeurs mesurées réelles plutôt que de valeurs estimées, permet de renforcer la précision associée aux prédictions. Selon des modes de réalisation, le modèle de prédiction peut être obtenu par apprentissage machine par entraînement sur un ensemble de données d’entraînement, l’ensemble de données d’entraînement comprenant des valeurs mesurées du paramètre de QoS associées à des identifiants respectifs de zone ou de position et à des valeurs d’horodatage respectives. L’utilisation de l’apprentissage machine permet la construction d’un modèle de prédiction complexe, avec un grand nombre de données d’entrée, apte à prédire avec précision l’évolution du paramètre de QoS pour un horizon de prédiction. En complément, le modèle de prédiction peut être un modèle de type RANdom SAmple Consensus, RANSAC, associé à un estimateur de type forêt aléatoire. Le modèle RANSAC présente une bonne robustesse face aux valeurs aberrantes (inliers et outliers). Par exemple, dans le contexte d’un réseau de télécommunications cellulaire C-V2X, dans lequel des données imprécises ou bruitées sont transportées en raison de divers facteurs environnementaux, la capacité du modèle RANSAC à filtrer ces incohérences et à se focaliser sur les tendances significatives est déterminante. Le modèle de prédiction n’est ainsi pas influencé de manière disproportionnée par des valeurs aberrantes, préservant ainsi la précision globale associée à la prédiction, de la latence ou d’un autre paramètre de QoS, tel que par exemple la bande passante ou la fiabilité de connexion au réseau de télécommunications cellulaire. En complément du modèle RANSAC, l’estimateur de type forêt aléatoire, ou Random Forest RF, en anglais, a des capacités intrinsèques à traiter des données complexes, et à construire un ensemble de nombreux arbres, chacun apprenant sur un échantillon aléatoire de l’ensemble de données d’entraînement. Une telle approche permet d’obtenir des prédictions robustes en agrégeant les résultats de multiples arbres, réduisant ainsi le risque de surapprentissage et améliorant la fiabilité des prédictions, y compris dans des environnements dynamiques et changeants comme c’est le cas pour le transport de données d’applications véhiculaires V2X. La combinaison d’un modèle de prédiction de type RANSAC avec un estimateur RF permet ainsi de prendre en compte la variabilité temporelle et spatiale des paramètres de QoS, latence notamment, d’un réseau de télécommunications transportant des données d’applications véhiculaires V2X. En complément ou en variante, le modèle de prédiction peut être mis à jour par entraînement sur un ensemble de données d’entraînement mis à jour, à une fréquence associée à une période. Une telle période est notée T1 dans ce qui suit. Ainsi, le modèle de prédiction peut lui-même être mis à jour, ce qui permet de prendre en compte la variabilité importante des données d’applications véhiculaires dans un réseau de télécommunications, que ce soit sur une journée, mais également en fonction du jour de la semaine ou de la saison. La période T1 peut avantageusement être égale à une journée. En complément, pour une mise à jour du modèle de prédiction pendant une période d’indice j, l’ensemble de données d’entraînement mis à jour peut comprendre des valeurs mesurées du paramètre de QoS collectées pendant une période précédente d’indice j-1. Ainsi, les données d’entraînement peuvent être mises à jour sur la base des données d’entraînement les plus récentes, ce qui permet d’améliorer la précision associée aux prédictions du modèle de prédiction. L’invention concerne également un serveur de prédiction d’un paramètre de qualité de service, QoS, d’un réseau de télécommunications apte à transporter des données d’application véhiculaire, le serveur comprenant un processeur configuré, pour au moins une position ou une zone d’une zone de couverture radio du réseau de télécommunications et pour au moins un horizon de prédiction, pour : - obtenir M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone, M étant un entier supérieur ou égal à 1; - déterminer une valeur prédite du paramètre de qualité de service, pour l’horizon de prédiction et pour la position ou zone, par application d’un modèle de prédiction à des données d’entrées comprenant un identifiant de la position ou zone, l’au moins un horizon de prédiction et les M valeurs mesurées du paramètre de qualité de service. Un tel serveur est notamment configuré pour mettre en œuvre le procédé de prédiction précité, selon l’un ou l’autre de ses modes de réalisation. L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de prédiction de paramètre de QoS 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 serveur de prédiction mettant en œuvre le procédé de prédiction 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 prédiction 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 « dispositif » ou « 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 FIG. 1 représente une architecture dans laquelle est mis en œuvre le procédé de prédiction d’un paramètre de qualité de service d’un réseau de télécommunications, selon un mode de réalisation particulier de l'invention, La FIG. 2 représente les étapes d’une phase d’apprentissage d’un procédé de prédiction d’un paramètre de qualité de service d’un réseau de télécommunications, selon un mode de réalisation de l’invention, tel que mis en œuvre dans l’architecture de la FIG. 1 ; La FIG. 3 représente les étapes d’une phase courante d’un procédé de prédiction d’un paramètre de qualité de service d’un réseau de télécommunications, selon un mode de réalisation de l’invention, tel que mis en œuvre dans l’architecture de la FIG. 1 ; La FIG. 4 représente une structure d’un serveur de prédiction d’un paramètre de qualité de service d’un réseau de télécommunications, selon un mode de réalisation de l’invention. Description détaillée d’un mode de réalisation de l’invention La FIG. 1 représente une architecture 10 dans laquelle est mis en œuvre un procédé de prédiction d’un paramètre de qualité de service d’un réseau de radiocommunication 120, selon un mode de réalisation de l'invention. Dans l’exemple représenté à titre illustratif sur la FIG. 1 , le réseau de télécommunications 120 est un réseau de télécommunications cellulaire, par exemple de type 3G, 4G, 5G, etc. En variante, le réseau de télécommunications 120 peut être satellitaire selon l’invention. Le réseau cellulaire 120 peut comprendre une pluralité de stations de base, dont une première station de base 121.1 et une deuxième station de base 121.2 représentées à titre illustratif sur la FIG. 1 , chaque station de base étant apte à couvrir une zone de couverture radio respective, pour communiquer de manière bidirectionnelle avec des clients situés dans la zone de couverture radio. Dans le contexte de la présente invention, les clients considérés sont un ensemble de N véhicules 110.1 à 110.N aptes à accéder au réseau cellulaire 120 par l’intermédiaire de l’une des stations de base du réseau cellulaire 120. Aucune restriction n’est attachée au nombre N de véhicules accédant au réseau cellulaire 120, qui peut comprendre, à un instant donné, plusieurs centaines ou milliers de véhicules. Le nombre N est évolutif en ce que la position de chacun des véhicules évolue de manière dynamique : un véhicule peut ainsi entrer ou sortir d’une zone de couverture radio d’une station de base, et peut ainsi entrer ou sortir d’une zone de couverture radio globale du réseau cellulaire 120, constituée par l’union des zones de couverture radio des stations de base du réseau cellulaire 120. Afin de simplifier l’exposé de l’invention dans ce qui suit, il est considéré que N est égal à 3. Les véhicules 110.1-110.N peuvent notamment accéder au réseau cellulaire 120 par la technologie C-V2X décrite précédemment, qui est connue et dont le fonctionnement n’est pas détaillé davantage dans la présente description. Les véhicules 110.1-110.N utilisent notamment le réseau cellulaire 120 comme réseau d’accès à un réseau étendu 130 pour bénéficier d’un ou de plusieurs services connectés. En particulier, les véhicules 110.1-110.N peuvent accéder à un service véhiculaire V2X mis en œuvre par un serveur applicatif 131. A noter que les véhicules 110.1 à 110.N peuvent accéder à plusieurs serveurs applicatifs 131 distincts, pour la mise en œuvre de différents services connectés. Des exemples de services véhiculaires V2X sont donnés dans ce qui suit à titre d’exemple. Dans un premier exemple d’application, les véhicules 110.1-110.N collaborent à un service de collecte et de partage de cartes HD haute définition, en collectant des données via divers capteurs. Ces données captées sont remontées vers le serveur applicatif 131 qui peut construire des cartes haute définition, régionales par exemple. Dans ce premier exemple d’application, il est très utile de prédire l’évolution d’un paramètre de qualité de service du réseau cellulaire 120, afin de réguler le nombre de véhicules impliqués dans la diffusion et la mise à jour de la carte HD pour chaque région, et d’ajuster la périodicité des messages générés. Dans un deuxième exemple d’application, l’application véhiculaire V2X est un service de conduite téléopérée permettant à un opérateur distant de contrôler un véhicule. Les données captées par le véhicule, y compris des vidéos de caméra embarquée, sont traitées dans le serveur applicatif 131. Dans ce deuxième exemple d’application, il est très utile de prédire l’évolution d’un paramètre de QoS, afin de permettre une transition vers un mode sécurisé en cas de dégradation du paramètre de QoS, adaptant ainsi la vitesse et la trajectoire du véhicule. Dans un troisième exemple d’application, l’application véhiculaire V2X est associée à un service de convoi à haute densité permettant aux véhicules de voyager en étroite proximité pour réduire la consommation de carburant et la congestion routière. Dans ce troisième exemple d’application, il est très utile de prédire l’évolution d’un paramètre de QoS, notamment dans le cas d’une dégradation de QoS, de manière à permettre une coordination autonome des véhicules ou demander une intervention humaine. D’autres applications véhiculaires V2X sont sensibles à la variation de paramètres de QoS et peuvent être mises en œuvre par un serveur applicatif 131 dans le cadre de l’invention. En particulier, d’autres cas d’application sont décrits dans ce qui suit. L’invention permet alors, comme détaillé dans ce qui suit, de fournir une prédiction d’un paramètre de QoS au serveur applicatif 131, pour mise en œuvre d’une action anticipatoire appropriée, garantissant ainsi un niveau de sécurité optimale du véhicule en toutes circonstance. Le serveur applicatif 131 peut être un serveur de type serveur d’application V2X AS défini dans les spécifications techniques précitées de l’organisme 3GPP. En se référant à nouveau à la FIG. 1 , l’architecture 10 comprend en outre un serveur d’interface 133 d’un service de prédiction de paramètre de QoS et un serveur de prédiction de paramètre de QoS 134, mettant en œuvre un modèle de prédiction comme décrit dans ce qui suit. Le serveur d’interface 133 fournit un service permettant d’accéder à des prédictions d’au moins un paramètre de QoS publiées par le serveur de prédiction 134 dans un serveur de publication de prédictions 135. Le serveur d’interface 133 peut être un serveur remplissant la fonction NEF définie dans les spécifications techniques précitées de l’organisme 3GPP. Le serveur de prédiction 134 peut être un serveur remplissant la fonction NWDAS définie dans les spécifications techniques précitées de l’organisme 3GPP. Dans ce qui suit, il est considéré, sauf mention contraire et à titre illustratif uniquement, que le paramètre de QoS est un paramètre de latence, la latence étant un paramètre particulièrement critique dans la mise en œuvre d’applications véhiculaires V2X, telles que les trois exemples d’applications listées ci-dessus, qui demandent une grande réactivité. L’invention concerne cependant de manière générale la prédiction d’un paramètre de QoS du réseau de télécommunications, notamment de type cellulaire, qui peut comprendre la bande passante, la fiabilité de connexion et/ou tout autre paramètre de qualité de service. L’architecture 10 comprend en outre une base de données 132 apte à stocker des valeurs de latence (ou d’un autre paramètre de QoS selon l’invention), mesurées par les véhicules eux-mêmes lors de l’utilisation du réseau cellulaire 120. De telles valeurs de latence sont ainsi des mesures réelles de latence remontées par les véhicules 110.1 à 110.N, par exemple de manière régulière. A titre d’exemple, les valeurs de latence sont acquises par le serveur applicatif 131, ou les serveurs applicatifs 131, et stockés dans la base de données 132 soit directement, soit par l’intermédiaire du serveur d’interface 133. Selon l’invention, toute valeur de latence stockée dans la base de données 132 est : - horodatée ; - associée à une information de position, qui peut être une position ponctuelle définie par des coordonnées GPS par exemple, ou qui peut être un identifiant d’une zone, la zone pouvant être une tuile, ou « tile » en anglais, de niveau donné (le niveau indiquant un niveau de zoom, donc une taille de la tuile). Par exemple, l’identifiant de zone peut être une chaîne numérique, appelée « quadkey » en anglais, identifiant de manière unique une tuile pour un niveau donné. Le niveau donné peut être, à titre d’exemple, le niveau 22 du système de tuilage, ou Tile System en anglais, du service web Bing Maps TM , selon lequel chaque tuile a une taille de 10 mètres sur 10 mètres par exemple. Le stockage des valeurs de latence dans la base de données 132 permet, comme expliqué dans ce qui suit : - de former des données d’entraînement pour l’apprentissage du modèle de prédiction décrit dans ce qui suit. Notamment, les données de latence accumulées peuvent être utilisées pour l’entraînement du modèle de prédiction, qui est répété à une première fréquence, correspondant à une première période T1, qui peut être d’une journée par exemple. Les paramètres du modèle de prédiction peuvent ainsi être mis à jour de manière régulière, à la première fréquence ; - de former des données d’entrée du modèle de prédiction, notamment les M dernières valeurs de latence associées à une position ou zone donnée, M pouvant être supérieur à 10, par exemple compris entre 50 et 200, par exemple égal à 100. Le modèle de prédiction peut en effet être utilisé à une deuxième fréquence donnée par le serveur de prédiction 134 pour déterminer des prédictions de latence à un ou plusieurs horizons de prédiction donnés à l’intérieur d’une deuxième période T2 associée à la deuxième fréquence. La deuxième période T2 peut être comprise entre 30 minutes et 2 heures, par exemple égale à 1 heure. La FIG. 2 présente les étapes d’une phase d’apprentissage d’un procédé de prédiction d’un paramètre de QoS selon des modes de réalisation de l’invention. A une étape 200, des valeurs de latence mesurées par un ou plusieurs véhicules, horodatées et associées à une information de position sont collectées par le serveur applicatif 131, ou par l’un des serveurs applicatifs 131. A une étape 201, les valeurs de latences ainsi collectées sont stockées dans la base de données 132 par le serveur applicatif 131, par exemple par l’intermédiaire du serveur d’interface 133. Les étapes 200 et 201 sont mises en œuvre en continue de manière à accumuler des valeurs de latence obtenues pour un grand nombre de véhicules et pour des positions ou tuiles différentes d’une région donnée. Par ailleurs, les valeurs de latence peuvent être centralisées dans la base de données 132 qui peut être commune à plusieurs serveurs applicatifs 131, dédiés à des applications véhiculaires V2X distinctes. On favorise ainsi la constitution d’une base de données riche et comprenant des valeurs de latence pour un grand nombre de positions, par exemple pour toutes les tuiles d’une région donnée. A une étape 202, le serveur de prédiction 134 peut vérifier la valeur d’un compteur. La valeur du compteur peut être réinitialisée à chaque expiration du compteur. Le compteur expire au bout d’une durée correspondant à la première période T1, qui correspond à la période de mise à jour du modèle de prédiction stocké et exploité par le serveur de prédiction 134 selon l’invention. La mise à jour du modèle de prédiction à chaque période T1 permet une prise en compte de la grande variabilité des contraintes qui s’appliquent au réseau cellulaire 120 et qui peuvent influer sur les paramètres de QoS tels que la latence. Comme indiqué précédemment, la période T1 peut être d’une journée. Ainsi, à l’issue de la période T1, la phase d’apprentissage du procédé passe à une étape 203. Les étapes 203 à 206 peuvent être mises en œuvre par le serveur de prédiction 134 décrit précédemment, ou par une autre entité apte à accéder au réseau 100. Dans ce qui suit, il est considéré à titre illustratif uniquement que les étapes 203 à 206 sont mises en œuvre par le serveur de prédiction 134. A l’étape 203, au moins une partie des données stockées dans la base de données 132 peut être traitée par le serveur de prédiction 134 afin d’obtenir un ensemble de données d’entraînement du modèle de prédiction. En outre, un même traitement peut être appliqué pour obtenir des données d’évaluation et des données de test du modèle de prédiction. Le traitement de l’étape 203 peut comprendre : - une structuration des données d’horodatage associées aux valeurs de latence, dans un format prédéfini, ce qui permet une cohérence dans le traitement des données d’horodatage ; - une extraction de caractéristiques temporelles à partir des données d’horodatage, les caractéristiques pouvant comprendre la semaine de l’année, le jour de la semaine, l’heure, la minute, la seconde, voire les millisecondes. Une telle extraction détaillée de caractéristiques temporelles permet une granularité élevée dans l’analyse des tendances temporelles, et permet de détecter des schémas saisonniers, des fluctuations horaires ou des comportements périodiques dans les données, renforçant ainsi la capacité du modèle de prédiction à appréhender la dynamique temporelle associée à la latence (ou à un autre paramètre de QoS, tel que la bande passante ou la fiabilité de connexion) ; - une gestion des valeurs manquantes de latence afin de remplacer des valeurs manquantes par une valeur nulle. Il est ainsi permis d’assurer une continuité des valeurs de latence dans le temps et pour toutes les zones ou positions : en effet, les valeurs de latence collectées sont discontinues par nature car elles dépendent de la présence ou non de véhicules à une position ou zone donnée, pendant une période donnée. Une autre gestion des valeurs manquantes peut être prévue selon l’invention, par exemple par interpolation de valeurs de latences effectivement mesurées. Selon l’invention, le modèle de prédiction entraîné prend en entrée : - un identifiant de position, tel qu’un identifiant de tuile par exemple ; - un horizon de prédiction H. L’horizon de prédiction peut prendre une valeur parmi un ensemble prédéfini de valeurs d’horizon de prédiction, par exemple 15 minutes, 30 minutes et 1 heure. Dans ce qui suit, trois valeurs d’horizon sont considérées dans l’ensemble prédéfini de valeurs d’horizon de prédiction, à titre illustratif uniquement ; - M valeurs précédentes de latence, effectivement mesurées pour la tuile identifiée, ou obtenues par interpolation spatiale entre des valeurs précédentes de latence mesurées dans deux ou plus de deux tuiles autour de la tuile identifiée. En sortie, le modèle de prédiction détermine une valeur de latence prédite pour l’identifiant de position et pour l’horizon de prédiction. La prise en compte des M valeurs précédentes de latence en entrée du modèle de prédiction permet une adaptation dynamique aux changements en temps réel, améliorant considérablement la précision associée à la prédiction de la latence. Une telle approche permet au modèle de prédiction d’apprendre et de s’ajuster en temps réel, en capturant les changements rapides et significatifs de la latence, qui pourraient avoir un impact sur les performances de l’application véhiculaire V2X. Ainsi, afin de pouvoir constituer un ensemble de données d’entraînement, les données issues de la base de données 132 et traitées lors de l’étape 203 peuvent être organisées en plusieurs lots d’entraînement (les lots d’entraînement formant l’ensemble de données d’entraînement), chaque lot d’entraînement comprenant : - un identifiant de position, une valeur d’horizon de prédiction H et M valeurs précédentes (par rapport à un instant passé donné t past ) de latence pour l’identifiant de position, pour former des données d’entrée lors de l’entraînement du modèle ; - la valeur de latence effectivement mesurée (issue de la base de données 132) pour l’identifiant de position et dans un horizon H après l’instant passé donné (donc à l’instant t past +H), la valeur de latence effectivement mesurée formant ainsi la vérité de terrain, avec laquelle la valeur de latence prédite peut être comparée pour entraîner les paramètres du modèle de prédiction. De la même manière, afin de pouvoir constituer un ensemble de données de test et un ensemble de données d’évaluation, les données issues de la base de données 132 et traitées lors de l’étape 203 peuvent être organisées en plusieurs lots de test (les lots de test formant l’ensemble de données de test) et en plusieurs lots d’évaluation (les lots d’évaluation formant l’ensemble de données d’évaluation), chaque lot de test et lot d’évaluation ayant la même composition qu’un lot d’entraînement, mais étant constitué à partir de données distinctes de la base de données 132. De manière préférentielle, les lots d’entraînement sont variés en ce que l’ensemble d’entraînement comprend plusieurs lots par horizon de prédiction et par identifiant de localisation, ainsi que pour des instants passés donnés variés (par exemple pour l’ensemble des créneaux horaires d’une journée). A une étape 204, le serveur de prédiction 134 entraîne le modèle de prédiction sur la base des données d’entraînement issues de l’étrape de traitement 203. A cet effet, les données d’entrée de chaque lot peuvent être soumises en entrée du modèle de prédiction, et les paramètres du modèle de prédiction sont ajustés en fonction d’une différence entre la prédiction de latence en sortie du modèle et la valeur de latence mesurée du lot d’entraînement (la vérité de terrain). Aucune restriction n’est attachée au modèle de prédiction qui est tout modèle défini par des paramètres qui peuvent être déterminés par apprentissage machine. De manière préférentielle, le modèle de prédiction peut être de type RANSAC, pour « RANdom SAmple Consensus » en anglais, associé à un estimateur de type forêt aléatoire, ou RF pour « Random Forest » en anglais. Une telle combinaison est particulièrement adaptée pour traiter des particularités de paramètres de QoS pour le transport de données V2X et pour assurer des performances solides et fiables. Le modèle RANSAC présente une bonne robustesse face aux valeurs aberrantes (inliers et outliers). Dans le contexte de réseau cellulaire V2X, dans lequel des données imprécises ou bruitées sont transportées en raison de divers facteurs environnementaux, la capacité du modèle RANSAC à filtrer ces incohérences et à se focaliser sur les tendances significatives est déterminante. Le modèle de prédiction n’est ainsi pas influencé de manière disproportionnée par des valeurs aberrantes, préservant ainsi la précision globale associée à la prédiction, de la latence ou d’un autre paramètre de QoS. En complément du modèle RANSAC, l’estimateur RF a des capacités intrinsèques à traiter des données complexes, et à construire un ensemble de nombreux arbres, chacun apprenant sur un échantillon aléatoire de l’ensemble de données d’entraînement. Une telle approche permet d’obtenir des prédictions robustes en agrégeant les résultats de multiples arbres, réduisant ainsi le risque de surapprentissage et améliorant la fiabilité des prédictions, y compris dans des environnements de données dynamiques et changeants comme c’est le cas pour le transport de données d’applications véhiculaires V2X. La combinaison d’un modèle de prédiction de type RANSAC avec un estimateur RF permet ainsi de prendre en compte la variabilité temporelle et spatiale des paramètres de QoS, latence notamment, d’un réseau de télécommunications transportant des données d’applications véhiculaires V2X. Suite à l’étape 204, le serveur de prédiction 134 peut évaluer le modèle de prédiction entraîné en fonction d’au moins un critère d’évaluation, à une étape 205. Un premier critère d’évaluation peut être l’erreur moyenne absolue, MAE pour « Mean Absolute Error » en anglais, qui quantifie l’erreur moyenne entre les valeurs prédites et les valeurs réelles (la vérité de terrain). Le critère MAE donne une mesure de la magnitude moyenne des erreurs dans les prédictions, permettant ainsi d’évaluer la précision globale du modèle. Le critère MAE est évalué par la formule (1) suivante : (1) Dans laquelle est la valeur prédite de latence et y i est la valeur réelle mesurée de latence, n étant un entier représentant le nombre de prédictions considéré. Un deuxième critère d’évaluation, en complément ou en variante du premier critère, peut être un pourcentage d’erreur absolue moyen ou MAPE, pour « Mean Absolute Percentage Error » en anglais. Le critère MAPE exprime l’erreur en pourcentages entre les valeurs prédites et les valeurs réelles, fournissant une évaluation de l’exactitude relative du modèle de prédiction. Le critère MAPE donne ainsi une mesure de la précision du modèle de prédiction en prenant en compte les proportions relatives des erreurs par rapport aux valeurs réelles. Le critère MAPE est évalué par la formule (2) suivante : (2) Avec les mêmes notations que dans la formule (1). Un troisième critère d’évaluation, en complément ou en variante du premier et/ou du deuxième critère d’évaluation, peut être un coefficient de détermination, aussi appelé R 2 score, qui mesure la capacité du modèle de prédiction à expliquer la variance des données autour de la moyenne. Un R 2 score proche de 1 indique que le modèle de prédiction est ajusté aux données, capturant une grande proportion de la variance des valeurs réelles. Cependant, un R 2 score élevé peut ne pas toujours signifier une prédiction précise, dans certains contextes. Pour une série de n prédictions par rapport aux valeurs réelles, le R 2 score est calculé conformément à la formule (3) ci-dessous, avec les mêmes notations que pour les formules (1) et (2) : (3) Et dans laquelle représente la moyenne des valeurs réelles y i . Ainsi, lors de l’étape 205, le serveur de prédiction 134 peut évaluer le modèle de prédiction en fonction de l’un au moins des critères d’évaluation ci-dessus, appliqué à des prédictions effectuées sur l’ensemble de données d’évaluation constitué à l’étape 203, ce qui permet d’évaluer la performance du modèle de prédiction sur des données inédites. A une étape 206, le serveur de prédiction 134 peut tester le modèle de prédiction évalué, sur l’ensemble de données de test constitué à l’étape 203, ce qui permet d’évaluer la capacité du modèle de prédiction à prédire avec précision le paramètre de QoS, latence notamment, pour de nouvelles données. Après entraînement, évaluation et test de plusieurs modèles de prédiction, le modèle de prédiction offrant les performances les plus satisfaisantes peut être choisi en tant que modèle de prédiction optimal par le serveur de prédiction 134 à une étape 207. A une étape optionnelle 208, le modèle de prédiction optimal peut être optimisé, par exemple par réentraînement sur l’ensemble complet des données traitées à l’étape 203, le réajustement des paramètres du modèle de prédiction optimal, ou toute autre optimisation pour renforcer la précision des prédictions. A une étape 209, le modèle de prédiction optimal est stocké ou installé dans le serveur de prédiction 134, pour utilisation lors de la phase courante décrite en référence à la FIG. 3 décrite ci-après. Le modèle de prédiction peut par exemple être stocké dans un format pkl. Comme indiqué sur la FIG. 2 , le modèle de prédiction peut être mis à jour à la première fréquence, c’est-à-dire à l’expiration de chaque première période T1, en fonction des données collectées et stockées aux étapes 200 et 201 pendant la première période T1 précédente. Ainsi, au début d’une première période T1 d’indice j, le modèle de prédiction stocké à l’étape 209 pendant la première période T1 d’indice j-1, est réentraîné sur la base de données d’entraînement mises à jour à partir des données de la base de données 132 qui comprend notamment les données collectées et stockées aux étapes 200 et 201 pendant la première période T1 d’indice j-1. Les critères d’évaluation décrits précédemment ont été évalués pour plusieurs valeurs de première période T1, notamment : - pour une première période T1 égale à une journée ; - pour une première période T1 égale à une semaine ; - pour une première période T1 égale à un mois. Il en ressort que les modèles de prédiction entraînés sur des durées plus courtes (une journée notamment) présentent de meilleures performances selon le critère MAE, indiquant une prédiction plus précise de la latence, par rapport aux modèles ayant bénéficié de périodes d’entraînement plus longues. La même conclusion s’applique au critère MAPE. Le troisième critère R 2 score reste quant à lui élevé pour toutes les stratégies, indiquant ainsi que la capacité à expliquer la variance des données est similaire quelle que soit la durée de la première période T1. La FIG. 3 présente les étapes d’une phase courante d’un procédé de prédiction d’un paramètre de QoS selon un mode de réalisation de l’invention. Les étapes 301 à 303 sont mises en œuvre par le serveur de prédiction 134 décrit précédemment, durant une première période T1 d’indice j : à l’issue de la première période T1 précédente d’indice j-1, le modèle de prédiction mis à jour a été stocké dans le serveur de prédiction 134, pour utilisation lors de la première période T1 d’indice j. Les étapes 301 à 303 peuvent être itérées, à l’expiration d’un compteur initialisé pour une durée correspondant à la deuxième période T2. Comme indiqué précédemment, la deuxième période T2 est plus courte que la première période T1, de manière notamment à ce que plusieurs deuxièmes périodes T2 soient comprises dans la première période T1 d’indice j. Par exemple, la deuxième période T2 est égale à 1 heure, auquel cas si la première période T1 est d’une journée, elle comprend 24 périodes T2. Ainsi, à l’issue d’une deuxième période T2, déterminée à l’étape 301 par le serveur de prédiction 134, le serveur de prédiction 134 peut déterminer à une étape 302 une pluralité de valeurs de latence prédites en appliquant plusieurs fois le modèle de prédiction : - pour un ensemble de positions ou de tuiles ; et - pour chaque position ou chaque tuile, pour un ou plusieurs horizons de prédiction inférieurs à la durée de la deuxième période T2. A titre d’exemple, le modèle de prédiction est appliqué quatre fois, pour deux tuiles Tu1 et Tu2 et la zone géographique donnée, et pour deux horizons de prédiction pour chaque tuile, par exemple pour des horizons de prédiction de 10 minutes et 30 minutes. Ainsi, le serveur de prédiction 134 applique le modèle de prédiction une première fois pour obtenir une première valeur de latence prédite, avec pour données d’entrée : - l’identifiant de la tuile Tu2 ; - l’horizon de prédiction de 10 minutes ; - les M dernières valeurs de latence pour la tuile Tu2 (qui sont les M valeurs collectées avant un instant t 0 à partir duquel est mise en œuvre l’étape 302) et stockées dans la base de données 132, ou en cas d’absence de valeurs de latence pour la tuile Tu2 dans la base de données 132, déterminées par interpolation de valeurs de latence collectées pour des tuiles voisines. Le serveur de prédiction 134 applique le modèle de prédiction une deuxième fois pour obtenir une deuxième valeur de latence prédite, avec pour données d’entrée : - l’identifiant de la tuile Tu2 ; - l’horizon de prédiction de 30 minutes ; - les M dernières valeurs de latence pour la tuile Tu2 (qui sont les M valeurs collectées avant un instant t 0 à partir duquel est mise en œuvre l’étape 302) et stockées dans la base de données 132, ou en cas d’absence de valeurs de latence pour la tuile Tu2 dans la base de données 132, déterminées par interpolation de valeurs de latence collectées pour des tuiles voisines. Le serveur de prédiction 134 applique le modèle de prédiction une troisième fois pour obtenir une troisième valeur de latence prédite, avec pour données d’entrée : - l’identifiant de la tuile Tu1 ; - l’horizon de prédiction de 10 minutes ; - les M dernières valeurs de latence pour la tuile Tu1 (qui sont les M valeurs collectées avant un instant t 0 à partir duquel est mise en œuvre l’étape 302) et stockées dans la base de données 132, ou en cas d’absence de valeurs de latence pour la tuile Tu1 dans la base de données 132, déterminées par interpolation de valeurs de latence collectées pour des tuiles voisines. Le serveur de prédiction 134 applique le modèle de prédiction une quatrième fois pour obtenir une troisième valeur de latence prédite, avec pour données d’entrée : - l’identifiant de la tuile Tu1 ; - l’horizon de prédiction de 30 minutes ; - les M dernières valeurs de latence pour la tuile Tu1 (qui sont les M valeurs collectées avant un instant t 0 à partir duquel est mise en œuvre l’étape 302) et stockées dans la base de données 132, ou en cas d’absence de valeurs de latence pour la tuile T1 dans la base de données 132, déterminées par interpolation de valeurs de latence collectées pour des tuiles voisines. En pratique, le serveur de prédiction peut appliquer le modèle de prédiction pour plus de deux horizons de prédiction et/ou pour plus de deux positions ou tuiles. Ainsi, de manière plus générale, le serveur de prédiction peut appliquer K*L fois le modèle de prédiction pour K tuiles et L horizons de prédiction, K et L étant supérieurs ou égaux à 1, avec notamment K et/ou L de préférence supérieur ou égal à 2. Un ensemble de valeurs de latence prédites est ainsi obtenu à l’étape 302, pour une ou plusieurs positions ou tuiles de la région et pour un ou plusieurs horizons de prédiction. A une étape 303, l’ensemble de valeurs de latence prédites à l’étape 302 peut être publié dans le serveur de publication de prédiction 135 par le serveur de prédiction 134. Ainsi, les prédictions publiées dans le serveur de publication de prédiction 135 peuvent être exploitées par le serveur d’interface 133 apte à fournir un service de prédiction de latence auprès du ou des serveurs applicatifs 131. Ainsi, à une étape 310, le serveur d’interface 133 peut recevoir une requête depuis un serveur applicatif 131, la requête indiquant : - une ou plusieurs positions ou une ou plusieurs tuiles ; - optionnellement, au moins un instant de prédiction t 1 , qui est un instant postérieur à l’instant auquel la requête est transmise. L’instant de prédiction t 1 peut par exemple être 15 minutes après l’instant auquel la requête est transmise. En variante, une série d’instants de prédiction comprenant au moins deux instants de prédiction t 1 et t 2 sont inclus dans la requête. En variante, la requête ne comprend aucun instant de prédiction. Sur réception de la requête, le serveur d’interface 133 obtient à une étape 311, dans le serveur de publication de prédictions 135, une valeur de prédiction pour chaque position ou tuile, dont l’horizon de prédiction est le plus proche de l’instant de prédiction t 1 , si la requête comprend au moins un instant de prédiction. Si la requête ne comprend aucun instant de prédiction, le dispositif d’interface obtient les valeurs de prédictions, pour chaque position ou tuile, pour tous les horizons de prédiction correspondant à un instant de prédiction non encore révolu. Par exemple, si la requête indique la première tuile Tu1 et l’instant de prédiction t 1 , le serveur d’interface 133 renvoie au serveur d’application 131 la valeur de latence prédite correspondant à la tuile Tu1, et à l’horizon t 0 +10 ou t 0 +30, selon que t 1 soit plus proche de l’horizon t 0 +10 ou de l’horizon t 0 +30. Le serveur d’interface 133 transmet une réponse au serveur applicatif 131, à une étape 312, la réponse comprenant l’une ou plusieurs valeurs de latence obtenues à l’étape 311. Sur la base de la valeur de latence prédite reçue à l’étape 312, ou des valeurs de latence prédites à l’étape 312, le serveur applicatif 131 peut anticiper une variation de la latence, par exemple en cas de franchissement d’un seuil, et peut prendre toute mesure anticipatoire pour éviter que la dégradation de la latence ne cause des problèmes de sécurité ou diminue plus généralement l’expérience utilisateur dans les véhicules bénéficiant de l’application véhiculaire V2X mise en œuvre par le serveur applicatif 131. En variante ou en complément, de nouvelles applications véhiculaires V2X peuvent être mises en œuvre par un ou plusieurs serveurs applicatifs 131, en fonction de prédictions de paramètres de QoS. Des exemples d’utilisation du service mis en œuvre par le serveur d’interface 133, pour différentes applications véhiculaires V2X, sont décrits dans ce qui suit en référence à divers cas d’utilisation. En variante de l’envoi d’une requête à l’étape 310, le serveur applicatif 131 peut s’abonner à un service de notification auprès du serveur d’interface 133. Dans ce cas, une requête d’abonnement peut être transmise par le serveur applicatif 131 au serveur d’interface 133, la requête d’abonnement comprenant : - une valeur de seuil ; - une ou plusieurs positions ou tuiles. Dans ce cas, le serveur d’interface 133 peut obtenir les valeurs de latence prédites pour la ou les plusieurs positions ou tuiles, publiées dans le serveur de publication de prédictions 135. Les valeurs de latence prédites sont comparées à la valeur de seuil. En cas de franchissement du seuil pour une position ou tuile, et pour un horizon de prédiction correspondant à un instant futur t 0 +H, le serveur d’interface 133 envoie une notification au serveur applicatif 131, la notification indiquant : - la position ou tuile pour laquelle le seuil est franchi ; et - l’instant futur t 0 +H. Ainsi, pour cette variante également, le serveur applicatif 131, sur réception d’une notification, peut anticiper une dégradation de qualité de service, notamment de latence, et peut prendre toute mesure anticipatoire pour éviter que la dégradation de la latence ne cause des problèmes de sécurité ou diminue plus généralement l’expérience utilisateur dans les véhicules bénéficiant de l’application véhiculaire V2X mise en œuvre par le serveur applicatif 131. Dans un premier cas d’application, le ou les paramètres de QoS prédits permettent une optimisation de la circulation urbaine. Par exemple, les véhicules connectés 110.1 à 110.N peuvent sélectionner des itinéraires en fonction de la bande passante (qui est dans ce cas l’un des paramètres de QoS prédit) et de la latence, grâce à une application véhiculaire V2X associée à un serveur applicatif 131, garantissant des communications fluides pour d’autres applications véhiculaires telles que le contrôle de la circulation ou la coordination du trafic. Par exemple, des véhicules 110.1-110.N peuvent analyser des prédictions de bande passante fournies par le serveur applicatif 131, pour choisir des itinéraires permettant des communications rapides pour la mise à jour de cartes ou pour les signaux de trafic. Selon un autre exemple pour ce premier cas d’application, un serveur applicatif 131 utilise les prédictions de fiabilité de connexion (qui est dans ce cas l’un des paramètres de QoS prédit) pour prioriser des messages de sécurité envoyés à certains feux de signalisation intelligents en fonction de leurs localisations respectives, assurant ainsi des réponses rapides pour la régulation du trafic. Dans un deuxième cas d’application, la prédiction de paramètres de QoS permet d’améliorer la sécurité routière, en permettant d’anticiper des fluctuations de la fiabilité de la connexion, aidant ainsi à prévenir les accidents en assurant une communication constante entre les véhicules. Par exemple, les prédictions de fiabilité de la connexion (qui est dans ce cas l’un des paramètres de QoS prédit), peuvent être transmises par un serveur applicatif 131 aux véhicules 110.1-110.N qui peuvent prendre des mesures préventives en cas de défaillance prévue de la communication, comme activer des systèmes de sécurité autonomes par exemple. Dans un troisième cas d’application, les prédictions des paramètres de QoS aident à maintenir une connectivité stable pour des véhicules d’urgence, garantissant des temps de réponse rapides lors de situations critiques. Par exemple, une application véhiculaire V2X fournie par un serveur applicatif 131 aux véhicules d’urgence leur permet, à partir de prédictions de latence, de choisir des itinéraires offrant une connectivité stable pour transmettre en temps réel des informations vitales vers les hôpitaux. Dans un quatrième cas d’application, les prédictions de paramètres de QoS permettent une gestion proactive d’une application véhiculaire V2X par un serveur applicatif 131, adaptant la qualité des services en fonction des variations prévues des paramètres de QoS. Par exemple, les prédictions de bande passante (qui est dans ce cas un paramètre de QoS prédit) permettent à un service véhiculaire V2X diffusant des contenus dans les véhicules 110.1-110.N de diffuser des contenus dans un format dont la qualité dépend des prédictions de bande passante, ce qui permet d’optimiser la qualité de ces contenus. En prédisant une baisse de bande passante dans une zone spécifique, la résolution vidéo peut être ajustée en temps réel pour maintenir une continuité de la diffusion sans interruption vers les véhicules dans la zone spécifique. Dans un cinquième cas d’application, les prédictions de paramètres de QoS permettent une mise à jour cartographique en temps réel. En prévoyant les variations de latence et de fiabilité de connexion, une application véhiculaire V2X mise en œuvre par un serveur applicatif 131 peut planifier et prioriser des mises à jour cartographiques pour certaines positions et à certaines périodes, pour assurer des données précises et à jour dans les véhicules 110.1-110.N. Par exemple, une prédiction de latence faible sur une période donnée et pour une position ou tuile donnée, permet de déterminer le meilleur moment pour mettre à jour une carte, garantissant une synchronisation efficace des données sans perturber d’autres éventuelles applications véhiculaires V2X utilisées par un véhicule. Dans un sixième cas d’application, un véhicule 110.1-110.N peut accéder aux variations d’un paramètre de QoS via un serveur applicatif 131 accédant au serveur d’interface 133. Le véhicule peut ainsi planifier un diagnostic à distance ou une mise à jour logicielle pour assurer des performances optimales. Par exemple, le véhicule détecte une augmentation prévue de la latence, et déclenche automatiquement une maintenance à distance pour résoudre les problèmes potentiels avant qu’ils n’affectent les performances du véhicule. Ainsi, de manière plus générale, la prédiction d’un paramètre de QoS permet l’optimisation d’applications véhiculaires V2X. La FIG. 4 illustre une structure du serveur de prédiction 134 selon des modes de réalisation de l’invention. Le serveur de prédiction 134 comprend un processeur 401 configuré pour communiquer de manière unidirectionnelle ou bidirectionnelle, via un ou des bus ou via une connexion filaire directe, avec une mémoire 402 telle qu’une mémoire de type « Random Access Memory », RAM, une mémoire de type « Read Only Memory », ROM, ou tout autre type de mémoire (Flash, EEPROM, etc.). En variante, la mémoire 402 comprend plusieurs mémoires des types précités. La mémoire 402 comprend au moins une mémoire non-volatile dans laquelle sont stockées de manière temporaire ou permanente, les données utilisées et/ou issues de la mise en œuvre des étapes 301 à 303 précédemment décrites, et des étapes 202 à 209 lorsqu’elles sont mises en œuvre par le serveur de prédiction 134. En particulier, la mémoire 402 peut stocker le modèle de prédiction lors de l’étape 209 précédemment décrite. Le processeur 401 est apte à exécuter des instructions, stockées dans la mémoire 402, pour la mise en œuvre des étapes 301 à 303, et optionnellement des étapes 202 à 209 décrites précédemment. Le serveur de prédiction 134 comprend en outre une interface réseau 403 apte à communiquer avec les autres entités accédant au réseau étendu 130 décrit en référence à la FIG. 1 . Procédé de prédiction d’un paramètre de qualité de service, QoS, d’un réseau de télécommunications (120) apte à transporter des données d’application véhiculaire, le procédé comportant, pour au moins une position ou une zone d’une zone de couverture radio du réseau de télécommunications et pour au moins un horizon de prédiction : - obtention (200 ; 201) de M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone, M étant un entier supérieur ou égal à 1; - détermination (302) d’une valeur prédite du paramètre de qualité de service, pour l’horizon de prédiction et pour la position ou zone, par application d’un modèle de prédiction à des données d’entrées comprenant un identifiant de la position ou zone, l’au moins un horizon de prédiction et les M valeurs mesurées du paramètre de qualité de service. Procédé selon la revendication 1, comprenant en outre une transmission (312) de la valeur prédite du paramètre de qualité de service à un serveur applicatif (131) configuré pour déployer une application véhiculaire auprès d’un ensemble de véhicules (110.1-110.N) via le réseau de télécommunications (120). Procédé selon la revendication 1 ou 2, comprenant en outre une publication (303) de ladite valeur prédite du paramètre de qualité de service dans un serveur de publication de prédictions (135) accessible via un réseau étendu (130). Procédé selon l’une des revendications précédentes, comprenant la détermination (302) de plusieurs valeurs prédites du paramètre de qualité de service, pour ladite position ou zone et pour plusieurs horizons de prédiction respectifs, par plusieurs applications du modèle de prédiction à des données d’entrée respectives. Procédé selon l’une des revendications précédentes, comprenant la détermination (302) d’au moins une valeur prédite du paramètre de qualité de service pour plusieurs positions ou zones de la zone de couverture radio et pour au moins un horizon de prédiction, par plusieurs applications du modèle de prédiction à des données d’entrée respectives. Procédé selon les revendications 3, 4 et 5, dans lequel, pour K positions ou zones de la zone de couverture radio et pour L horizons de prédiction, K et L étant des entiers supérieurs ou égaux à 2, K*L valeurs prédites de paramètre de QoS sont déterminées (302) pour les K positions ou zones respectives et pour les L horizons de prédiction respectifs par K*L applications du modèle de prédiction à des données d’entrée respectives ; dans lequel les K*L valeurs prédites de paramètres de QoS sont publiées (303) dans le serveur de publication de prédictions (135). Procédé selon l’une des revendications précédentes, dans lequel la détermination (302) de la valeur prédite, pour l’horizon de prédiction et pour la position ou zone, est répétée à une fréquence associée à une période (T2) supérieure à l’horizon de prédiction. Procédé selon l’une des revendications précédentes, comprenant une collecte (200) de valeurs mesurées du paramètre de QoS depuis au moins un serveur applicatif (131) configuré pour mettre en œuvre une application véhiculaire auprès d’un ensemble de véhicules (110.1-110.N) via le réseau de télécommunications (120), lesdites valeurs mesurées étant horodatées et associées à au moins un identifiant de position ou de zone, et un stockage (201) desdites valeurs mesurées du paramètre de QoS dans une base de données ; dans lequel les M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone sont obtenues depuis ladite base de données. Procédé selon l’une des revendications précédentes, dans lequel le modèle de prédiction est obtenu par apprentissage machine par entraînement (204) sur un ensemble de données d’entraînement, l’ensemble de données d’entraînement comprenant des valeurs mesurées du paramètre de QoS associées à des identifiants respectifs de zone ou de position et à des valeurs d’horodatage respectives. Procédé selon la revendication 9, dans lequel le modèle de prédiction est un modèle de type RANdom SAmple Consensus, RANSAC, associé à un estimateur de type forêt aléatoire. Procédé selon la revendication 9 ou 10, dans lequel le modèle de prédiction est mis à jour par entraînement (204) sur l’ensemble de données d’entraînement mis à jour, à une fréquence associée à une période (T1). Procédé selon la revendication 8 et la revendication 11, dans lequel pour une mise à jour du modèle de prédiction pendant une période (T1) d’indice j, l’ensemble de données d’entraînement mis à jour comprend des valeurs mesurées du paramètre de QoS collectées pendant une période (T1) précédente d’indice j-1. Serveur de prédiction (134) d’un paramètre de qualité de service, QoS, d’un réseau de télécommunications (120) apte à transporter des données d’application véhiculaire, le serveur comprenant un processeur (401) configuré, pour au moins une position ou une zone d’une zone de couverture radio du réseau de télécommunications et pour au moins un horizon de prédiction, pour : - obtenir M valeurs mesurées du paramètre de qualité de service pour ladite position ou zone, M étant un entier supérieur ou égal à 1; - déterminer une valeur prédite du paramètre de qualité de service, pour l’horizon de prédiction et pour la position ou zone, par application d’un modèle de prédiction à des données d’entrées comprenant un identifiant de la position ou zone, l’au moins un horizon de prédiction et les M valeurs mesurées du paramètre de qualité de service. Programme d'ordinateur comportant des instructions de code de programme pour la mise en œuvre du procédé de prédiction d’un paramètre de qualité de service selon l’une quelconque des revendications 1 à 12, lorsqu'il est exécuté par un processeur. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 14.