FR 3148698 A1 20241115 FR 2304706 A 20230512 La présente divulgation propose une détection d’un terminal susceptible d’être embarqué dans un appareil en cours de vol, le terminal étant connecté à un réseau mobile comportant une pluralité de cellules couvertes par des antennes respectives. Il est proposé en particulier de: - obtenir (S1) des données courantes de connexion du terminal à des cellules successives du réseau mobile, lesdites données courantes comportant au moins des données des cellules intervenant dans la connexion du terminal au réseau mobile, - comparer (S2) les données courantes à des données de référence de connexion de terminaux terrestres et faisant intervenir au moins une cellule desdites données courantes, et - en fonction de ladite comparaison, déterminer (S3) si le terminal est embarqué dans un appareil en vol. Figure de l’abrégé : Figure 3 Détection de terminaux embarqués dans des appareils en vol, tels que des drones La présente divulgation relève du domaine de la détection d’appareils en vol tels que des drones. Typiquement, des drones embarquent des terminaux, dits « terminaux aériens » ci-après. Un terminal aérien peut servir à transmettre un flux de données vidéos (acquises par exemple par une caméra embarquée dans le drone) via un réseau mobile auquel le terminal aérien est connecté. Il peut servir aussi à piloter directement le drone en transmettant des instructions reçues d’un autre terminal à disposition d’un utilisateur, pilote du drone. Ainsi, dans ces différentes situations, un terminal aérien est connecté à un réseau, par exemple un réseau mobile cellulaire. Détecter un drone pour vérifier notamment s’il est autorisé à voler nécessite souvent une installation complexe de capteurs radiofréquences, et/ou de radars, et/ou de moyens pour mettre en œuvre une détection de balises radiofréquences que diffuse le drone, cette diffusion étant dite « ADS-B » (pour « Automatic Dependent Surveillance-Broadcast »). Les dronistes peuvent utiliser des terminaux mobiles grand public connectés à un réseau mobile pour contrôler leurs drones. Or, un drone doit avoir un plan de vol pour être autorisé à voler sur une zone. De plus, une licence de vol valide doit être délivrée au droniste. Dans le cas contraire, le droniste peut être soumis à une amende et à une révocation de sa licence. Néanmoins, pour ce faire, il faut détecter le drone et déterminer l’identité du droniste. Par ailleurs, un utilisateur malveillant d’un drone peut avoir désactivé les balises précitées pour la diffusion ADS-B. Une approche peut consister à s’appuyer sur un réseau cellulaire mobile pour détecter la présence d’un terminal aérien. Toutefois, les réseaux cellulaires, conçus pour des transmissions pour des terminaux terrestres, ne sont pas optimisés pour la connectivité aérienne. Un terminal aérien (appelé « drone » par extension ci-après) peut s’attacher sur des lobes secondaires des antennes proches du drone ou à des lobes principaux distants du drone. Il en résulte que les modems mobiles utilisés pour connecter les drones ne sont pas forcément identifiés comme étant de type « drone », ce qui complique la détection de drones véritables. De plus, l’identité d’un propriétaire du drone, utilisée par un pilote qui peut être très distant (« Beyond Visible Line Of Sight » par exemple) peut ne pas être connue. De même, l’identité d’un pilote qui utilise un drone en vol à vue et qui diffuse en direct, via un réseau mobile sur Internet par exemple, des données d’images capturées par le drone, peut ne pas être connue. Résumé La présente divulgation vient améliorer la situation. A cet effet, elle propose un procédé de détection d’un terminal susceptible d’être embarqué dans un appareil en cours de vol (typiquement un drone, mais possiblement un ULM ou autres). Le terminal est connecté à un réseau mobile comportant une pluralité de cellules couvertes par des antennes respectives (typiquement des stations de bases dans un réseau cellulaire classique, mais aussi possiblement des hotspots wifi (par exemple des passerelles wifi de relai), ou autres. En particulier, ce procédé comporte : - obtenir des données courantes de connexion du terminal à des cellules successives du réseau mobile, lesdites données courantes comportant au moins des données des cellules intervenant dans la connexion du terminal au réseau mobile, - comparer les données courantes à des données de référence de connexion de terminaux terrestres et faisant intervenir au moins une cellule desdites données courantes, et - en fonction de ladite comparaison, déterminer si le terminal est embarqué dans un appareil en vol. Ces données de référence peuvent correspondre à des données de connexion de terminaux terrestres ou à des valeurs théoriques de connexions propres à un terminal terrestre en déplacement classique au sol (conformément à un abaque par exemple). En effet, comme détaillé plus loin en référence aux figures 1 et 2, la connectivité au réseau cellulaire d’un terminal en vol est différente de la connectivité classique d’un terminal au sol. Par exemple, l’attachement aux stations de base dans les situations de transferts de connexion (ou « handovers ») a été observé comme étant différent pour un terminal en vol et pour un terminal terrestre en déplacement. Ainsi, il est proposé ici d’analyser les données remontées par les réseaux mobiles pour détecter notamment des drones non déclarés et embarquant des terminaux utilisant une connectivité cellulaire pour diffuser des flux média (notamment des données d’images, vidéo et/ou audio) et/ou exploiter des données de pilotage. Dans un mode de réalisation exploitant les situations de handovers précitées, le procédé peut comporter : - obtenir des données courantes de transferts de connexion du terminal d’une cellule à une autre cellule, lesdites données courantes comportant au moins des données des cellules intervenant dans lesdits transferts, et - comparer les données courantes à des données de référence de transferts de connexion de terminaux terrestres et faisant intervenir au moins une cellule desdites données courantes. Notamment si deux cellules du réseau sont réputées être adjacentes car elles assurent un transfert de connexion d’un terminal terrestre d’une des deux cellules à l’autre, alors ladite comparaison des données peut comporter la détection dans les données courantes d’un transfert de connexion entre deux cellules qui ne sont pas réputées être adjacentes. On comprendra ainsi que la détection d’un handover entre deux cellules qui ne s’effectue jamais pour un terminal terrestre peut caractériser la présence d’un terminal en vol. Dans une telle réalisation, si les données courantes comportent en outre des instants respectifs de ces transferts, alors les données courantes peuvent être analysées pour détecter si le terminal se connecte plusieurs fois successivement à deux cellules qui ne sont pas réputées être adjacentes et en un laps de temps inférieur à un seuil (cette situation étant nommée ci-après « ping-pong » entre deux cellules). Alternativement ou en complément, dans cette réalisation, si les données courantes comportent en outre des instants respectifs des transferts, les données courantes peuvent être analysées pour détecter si une trajectoire que réalise le terminal passe par des cellules successives qui ne sont pas réputées être adjacentes. Ainsi, la trajectoire du terminal en vol peut être déterminée par les situations de handovers. Néanmoins, alternativement ou en variante des détections des handovers, les données courantes peuvent comporter notamment une donnée de force de lien radiofréquence de connexion du terminal avec chacune des cellules successives, précitées, du réseau mobile, pour estimer des positions successives du terminal (possiblement mais optionnellement en coordonnées 3D). On entend ici par « force du lien », de façon générique, tout paramètre physique caractérisant ce lien (intensité ou puissance, ou encore rapport signal à bruit, de la liaison radiofréquence). Ainsi par la détermination des positions successives occupées par le terminal, il est possible de déterminer sa trajectoire. Dans le mode de réalisation utilisant les données de handovers ou le mode de réalisation utilisant la force de lien radiofréquence, les données courantes peuvent alors comporter en outre des instants respectifs de connexion audites cellules successives, et les données courantes précitées peuvent être analysées pour déterminer une trajectoire du terminal et détecter par exemple si une vitesse de déplacement du terminal sur cette trajectoire est supérieure à un seuil. Pour l’étude des forces de liens radiofréquences précitées, une entité du réseau mobile peut exécuter une fonction de type GMLC pour « Gateway Mobile Location Center » (dont les références sont détaillées plus loin). Alternativement ou en complément, l’étude des connexions du terminal aux cellules successives, notamment en situation de handover, peut être mise en œuvre par une entité du réseau exécutant une fonction de type NWDAF pour « Network Data Analytic Function » (détaillée plus loin). L’entité du réseau susceptible de mettre en œuvre de telles fonctions est typiquement le cœur de réseau (ou « Core Network » ci-après), ou encore une entité dédiée à cette application de détection de terminaux aériens et connectée au Core Network, comme présenté plus loin en référence à la . Dans une réalisation, les données courantes précitées peuvent comporter typiquement au moins un identifiant du terminal et au moins un identifiant d’utilisateur du terminal. En effet, dès lors que les données gérées par le réseau (cœur de réseau) sont accessibles, les identifiants du terminal et l’identité de son utilisateur sont aussi accessibles. Dans une telle réalisation, il est alors possible de : - consulter une plateforme (par exemple de type « USS », comme détaillé plus loin) d’enregistrements de pilotes et/ou de plans de vol d’appareils embarquant des terminaux, et - déterminer au moins si l’identifiant d’utilisateur du terminal est déclaré parmi lesdits enregistrements de la plateforme. Il est possible en outre de : - consulter cette plateforme pour déterminer si au moins la trajectoire du terminal est conforme à un plan de vol déclaré pour ledit terminal, et/ou encore de - vérifier si la trajectoire détectée inclut au moins un site sensible, associé à des conditions restrictives de survol (qui n’avait pas été autorisé par exemple par une administration gérant ce site sensible). D’autres exemples de contrôle peuvent être menés, notamment pour contrôler l’instant de survol d’un site dans une période autorisée ou non (par exemple en raison d’un évènement ponctuel). La description détaillée ci-après détaille ces divers exemples. La présente divulgation vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé selon les présentes, lorsqu’elles sont exécutées par un circuit de traitement. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un circuit de traitement, sur lequel est enregistré un tel programme. La présente divulgation vise aussi un dispositif comportant un circuit de traitement pour la mise en œuvre du procédé ci-avant. Ce dispositif peut comporter typiquement une connexion à un cœur du réseau mobile, d’une part, et à une plateforme du type précité, d’enregistrements de pilotes et/ou de plans de vol d’appareils embarquant des terminaux, d’autre part. Un tel dispositif peut alors être agencé pour exécuter au moins une fonction parmi au moins une fonction de type NWDAF – « Network Data Analytic Function » et une fonction de type GMLC - « Gateway Mobile Location Center ». Ce type de fonction s’interface avantageusement avec une fonction de type NEF (pour « Network Exposition Fonction ») que met en œuvre une passerelle de type USS. Ainsi, le dispositif peut être agencé pour exécuter ladite fonction de type NWDAF ou GMLC, en connexion avec la plateforme USS, via une telle fonction de type NEF. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 illustre un exemple de connexion d’un terminal embarqué dans un appareil en vol. Fig. 2 illustre un exemple de connexions du terminal embarqué B, à des antennes successives du réseau mobile cellulaire, à comparer avec les connexions habituelles d’un terminal A, au sol. Fig. 3 illustre un exemple d’un procédé au sens de la présente divulgation, selon un mode de réalisation. Fig. 4 illustre un exemple d’un système incluant un dispositif SER au sens de la présente divulgation, selon un mode de réalisation. On entend ci-après par « terminal normal », un terminal classique, terrestre. Il est noté UE_A (pour « User Equipement » (UE) terrestre), et il est supposé être connecté sur l’antenne d’une station de base en visibilité directe du terminal au sol. Un terminal classique est par exemple un terminal de type smartphone ou un terminal de type IoT (en anglais « Internet of Things »). Par opposition, on entend ci-après par « terminal anormal », un terminal embarqué sur un engin « aérien ». Il est noté UE_B. Etant embarqué sur un engin en altitude, le terminal UE_B ne s’accroche pas forcément à l’antenne habituellement la plus proche pour un terminal au sol mais peut se connecter sur des cellules beaucoup plus distantes car le lobe secondaire de l’antenne la plus proche émet moins pour le terminal anormal qu’une antenne distante que le terminal normal ne pourrait pas avoir en visibilité. Cette situation est illustrée sur l’exemple de la où un terminal en vol UE_B est couvert par le lobe principal LP2 (en traits pointillés) d’une antenne ici d’une station de base plus distante BS2, alors qu’au sol il aurait été couvert par le lobe principal LP1 (en trait plein) de la station la plus proche BS1, comme telle est la situation d’un terminal normal UE_A. Le(s) lobe(s) secondaire(s) LS1 de la station de base la plus proche BS1 ne suffit(sent) pas à couvrir le terminal UE_B en vol, de sorte qu’il s’attache naturellement à la station BS2, même si elle est plus lointaine que la station BS1 pour le terminal UE_B. Un mode de réalisation de la présente divulgation propose de tirer parti de cette observation pour détecter des terminaux embarqués, notamment par des drones. L‘analyse des connexions aux stations de base du réseau cellulaire (ou plus généralement « antennes » ci-après) permet d’étudier notamment les trajectoires des terminaux (ainsi que les effets dits « ping-pong » et les vitesses de déplacements des terminaux, comme on le verra plus loin). Dans le présent mode de réalisation, il est proposé de détecter des trajectoires qui ne correspondent pas à une trajectoire normale pour un terminal normal UE_A, terrestre. Par exemple en référence à la , la liste d’antennes utilisées pour connecter un terminal est collectée lors des procédures de mobilités, aussi appelées transferts, entre antennes (dites « handover » pour passer d’une cellule couverte par une station à une cellule couverte par une autre station). Cette liste d’antennes définit une trajectoire comme illustrée sur la , avec en particulier : - pour le terminal UE_A, la trajectoire A définie par : 3,t1 ; 2,t2 ; 3,t3 ; 2,t4 ; 4,t5 ; 5,t6, et - pour le terminal UE_B, la trajectoire B définie par : 10,t1 ; 3t2 ; 10t3 ; 3,t4 ; 1,t5 ; 8,t6 ; 10,t7. Il apparait alors que la trajectoire B montre l’utilisation de cellules qui ne sont pas nécessairement « adjacentes » (dans le sens de leur utilisation habituelle pour des terminaux « normaux » au sol) pendant les handovers, ce qui permet alors de détecter une anomalie caractérisant l’embarquement du terminal UE_B dans un engin volant. Ainsi, l’analyse des données de contrôle du réseau mobile entre chaque antenne empruntée et le réseau cœur mobile via des sondes peut permettre, dans certaines circonstances, d’analyser le déplacement de terminaux anormaux. Le contrôle du réseau mobile (ou « CDR ») permet d’obtenir des données de comptages nécessaires à la facturation notamment. Ces CDRs peuvent être générés en analysant la signalisation par exemple sur des interfaces S1 vers le réseau cœur entre les stations de base ou « eNodeB » du réseau et la passerelle S-GW (« Serving Gateway ») ou le gestionnaire MME (pour « Mobility Management Entity ») au niveau du cœur du réseau mobile, avec l’aide de sondes. La signalisation entre le gestionnaire MME et les eNodeB contient les informations d’identifiant de cellule, d’identité de terminal IMEI, d’identité de session @IP, d’identité de l’utilisation (USIM/ISIM). Ainsi, à partir de l’ensemble des cellules utilisées pour connecter un terminal, il est possible de reconstituer la trajectoire du véhicule qui embarque le terminal. Les données de signalisation peuvent ainsi fournir des informations telles que l’identité du terminal, le nom de l’opérateur, la date de connexion, les identifiants des cellules (courante et précédente) qui ont été utilisées pour connecter le terminal, le type de service, etc. L’analyse des données de signalisation (plan de contrôle, plan de transfert) peut être réalisée dans une fonction de type NWDAF (pour « Network Data Analytic Function » selon la norme TS 23.288) ou dans un plan de gestion avec la fonction MDAF (pour « management data analytic function » selon la norme TS 28.533, du réseau 5G). Les fonctions 5G MDAF, NWDAF peuvent également collecter des données souhaitées des fonctions du plan de contrôle et du plan de transfert du réseau 5G sans passer par des sondes. L’inventaire des localisations des antennes à des instants données permet d’avoir des informations sur les distances parcourues entre cellules, et la zone géographique qui a été survolée. Chaque antenne peut être identifiée avec les informations de longitude et latitude. Il est proposé alors d’enrichir une fonction de ce type NWDAF pour analyser les trajectoires des terminaux, à partir d’une liste d’antennes auxquelles le terminal a été connecté avec les dates de connexion associées, cette liste étant tirée de l’analyse des données de signalisation du réseau mobile. Dans ce contexte, un service proposant de détecter des comportements anormaux de terminaux (« abnormal behaviour ») peut être créé afin de détecter des trajectoires mobiles anormales. Cette détection peut être notifiée à une application ayant : - souscrit au service « abnormal behaviour », et - demandé les statistiques ou prédictions de trajectoire sur une zone et une durée données, la liste des types de terminaux ou les identités des terminaux avec comportement anormaux (@IP, IMEI, IMSI, nom-prénom, etc.). Un tel service peut proposer les outils tels que : - « Unexpected UE location » (détection d’une position non-attendue du terminal), - « Ping-ponging across neighbouring cells » (échanges entre cellules supposées voisines notamment pour un handover), - « Unexpected wakeup » (apparition non-attendue d’un terminal à une cellule donnée), - « Unexpected radio link failures » (interruption inattendue d’une liaison radio avec une cellule). Le tableau ci-dessous donne (colonne de gauche) une liste plus exhaustive de ces outils possibles et (en colonne de droite) la description des paramètres préexistants, normalisés, permettant de mettre en œuvre ces outils. Identifiants d’incidents Paramètres de comportements de t erminaux à fournir Unexpected UE location Expected UE Moving Trajectory Stationary Indication Unexpected long-live/large rate flows Periodic Time Scheduled Communication Time Communication Duration Time Unexpected wakeup Periodic Time Communication Duration Time Scheduled Communication Time Suspicion of DDoS attack Periodic Time Communication Duration Time Scheduled Communication Time Scheduled Communication Type Traffic Profile Expected transaction Dispersion Too frequent Service Access Periodic Time Unexpected radio link failures Expected UE Moving Trajectory Ping-ponging across neighbouring cells Expected UE Moving Trajectory Stationary Indication L’implémentation d’une fonction de type NWDAF permet d’accéder à ces paramètres (colonne de droite), et de là, par un enrichissement au sens de la présente divulgation de cette fonction, d’accéder à des détections d’incidents (colonne de gauche) caractérisant la présence d’un terminal embarqué dans un appareil volant tel qu’un drone. En variante ou en complément (pour renforcer la détermination de trajectoire), une fonction de localisation de type GMLC (pour « Gateway Mobile Location Center » - comme présentée notamment dans le document TS 29.515 V18.1.0 (2023-03) du 3GPP) peut être aussi utilisée. Une telle fonction détermine plus finement la position courante d’un terminal en s’appuyant sur la mesure de puissance du lien radiofréquence avec les antennes avoisinantes. La détermination de la position du terminal s’effectue ensuite par trilatération. De façon plus générale pour une fonction de type MDAF, NWDAF ou GMLC, la collecte des données peut être réalisée sur les réseaux mobiles existants pour tous les terminaux, habituellement afin de générer des tickets de facturation. Cette collecte est mise en œuvre pour des besoins réglementaires (service d’urgence, ou autres). Avec la norme 5G, la collecte peut être réalisée à la demande et pour une zone donnée pour tout terminal. Ces données peuvent alors être analysées pour déterminer une identité du terminal, ainsi qu’une identité de son utilisateur. Il peut être vérifié typiquement si l’utilisateur s’est déclaré pour piloter un drone auprès d’une autorité de surveillance aérienne et, le cas échéant, s’il a déclaré auprès de cette autorité un plan de vol conforme à la trajectoire observée pour ce drone par la mise en œuvre de la fonction d’analyse précitée (par exemple NWDAF). Par ailleurs, en complément ou en variante, il peut être vérifié aussi si le type-même de plan de vol est conforme à une déclaration préalable de son pilote. Par exemple, un vol à haute altitude (quelque soit la trajectoire précise du drone) notamment pour des applications de surveillance, de police et/ou militaires, peut être détecté par une fonction d’analyse (par exemple NWDAF) si un taux de comportements anormaux (par exemple un taux d’attachements à des cellules non habituelles, notamment en situation de handovers) est supérieur à un premier seuil THR1. En revanche, un vol à plus basse altitude notamment pour des applications de livraisons de marchandises ou autres, peut être caractérisé par un taux de comportements anormaux compris entre le premier seuil THR1 et un deuxième seuil THR2, inférieur au seuil THR1, et en-dessous duquel le terminal pourrait être qualifié de terrestre par exemple. Dans un mode de réalisation, cette fonction d’analyse (par exemple NWDAF et/ou encore GMLC) peut s’interfacer avec une plateforme de type USS (pour « UAS Service Supplier », « UAS » pour « UAV system » et « UAV » pour « Unmanned aerial vehicle »). Il s’agit d’un fournisseur de services pour des systèmes de drones (de tels systèmes comprenant les drones et les infrastructures pour les contrôler). Une telle plateforme USS gère l’utilisation de l’espace aérien en fournissant des services à l’exploitant et/ou au pilote d’un drone pour répondre aux exigences opérationnelles d’un gestionnaire de drones dit « UTM » (pour « Uncrewed Aerial System Traffic Management »). L’interfaçage de la fonction d’analyse de type NWDAF et de l’USS permet alors de vérifier si des conditions de souscription de services d’un tiers sont vérifiées, et d’alerter sinon une autorité qui souhaite détecter des drones dans un espace-temps donné ou détecter et identifier des drones qui ne se sont pas déclarés ou qui survolent une zone non autorisée, ou autres. Il est maintenant fait référence à la illustrant une forme possible d’un procédé au sens de la présente divulgation. Il est proposé d’analyser les données du plan de contrôle des réseaux mobiles pour au moins l’une des actions ci-après: - détecter des drones connectés au réseau mobile, - identifier qu’un terminal est potentiellement un drone UAV (pour « Unmanned Aerial Vehicle », donc un véhicule aérien sans humain à bord, typiquement un drone), - détecter les comportements non conformes du drone par rapport à des paramètres de vol, déclarés pour ce drone, - retrouver l’identité du droniste (par exemple le pilote) qui contrôle un engin identifié comme étant de type « UAV » via un profil de souscription de service associé à cet engin, - émettre des notifications à des services de sécurité aériens qu’un drone n’utilisant pas un service aérien géré par un USS a été détecté, et éventuellement que ce drone arrive ou a été détecté dans une zone de vol non autorisée ou nécessitant une souscription particulière. Par exemple, un souscripteur à un tel service de détection de drones peut être une entité en lien avec l’USS et imposant une surveillance d’un espace aérien donné (par exemple un site sensible, tel qu’un site militaire ou nucléaire, une prison, ou autres) ou encore une entité en charge de certains couloirs aériens (notamment pour l’aviation civile). Ainsi, le pilote d’un drone peut se déclarer à une étape S0 de souscription, via une fonction applicative, à un service de contrôle aérien géré par une ou plusieurs entités USS en lien avec une ou plusieurs autorités telles qu’une direction générale de l’avion civile d’un pays donné, un ou plusieurs acteurs en charge de la sécurité de sites sensibles (centrales nucléaires, prisons, etc.). La plateforme USS (ou finalement le pilote via l’USS) peut déclarer en outre l’association entre le drone, l’identité du pilote et les zones de vol autorisées auprès d’un opérateur de réseau mobile pour détecter typiquement ces drones via une fonction d’exposition de service du réseau mobile (appelée NEF pour « network exposition fonction »). Lors d’un vol d’un tel drone déclaré, la fonction NWDAF précitée peut s’interfacer alors avec l’USS, plus précisément via cette fonction de type NEF, en vue d’identifier par exemple si le drone franchit une zone non autorisée. Plus généralement, les acteurs sollicitant l’USS peuvent souhaiter : - repérer des drones non déclarés, par souscription d’un service auprès d’un opérateur de réseau mobile, et - repérer des drones éventuellement déclarés mais survolant des sites sensibles (par exemple par défaut autour d’un aéroport si le seul de ces acteurs est une direction de l’aviation civile). L’USS, via la fonction NEF, sollicite alors une fonction de type NWDAF (pour « Network Data Analytic Function ») pour le service de détection de drones, qui peut s’opérer alors : - dans une zone géographique 3D donnée, et éventuellement - pendant une durée donnée (pour un événement tel qu’un festival par exemple). En référence alors à la , après cette étape S0 initiale de déclaration et souscription de service, lors d’une étape S1 de mise en œuvre courante du service, la fonction NEF sollicite des données auprès d’une fonction de type NWDAF pour obtenir des comportements de terminaux anormaux, i.e. anormaux pour des terminaux terrestres et susceptibles de correspondre alors à des comportements de drones (ou de terminal dans un drone) dans une zone géographique courante. Cette opération permet d’obtenir une liste d’antennes sollicitées ou directement les coordonnées géographiques de chaque terminal à comportement erratique pendant un intervalle de temps donné, comme détaillé ci-après. Une entité du réseau telle que le cœur de réseau ou « Core Network » peut alors implémenter la fonction NWDAF à l’étape suivante générale S2 en collectant les données du réseau mobile et en analysant les comportements anormaux de terminaux. Au moins l’une des opérations tests ci-après peut être mise en œuvre, à cet effet. Une première opération possible S21 propose d’analyser la probabilité des effets dits « ping-pong » lorsque les terminaux s’attachent plusieurs fois sur des antennes voisines pendant un laps de temps court (typiquement moins de 5 secondes). Cette situation peut être détectée car le terminal se connecte à des antennes ayant les mêmes identifiants plusieurs fois dans un laps de temps court. Par exemple, la suite d’effet ping-pong pour un terminal terrestre UE_A normal (3 :2 :3 :2) qui est quasi-statique peut permettre d’identifier un comportement anormal avec la suite suivante du terminal en vol UE_B (10 : 3 : 10 : 3). En effet, la probabilité de retrouver des effets ping-pong avec des antennes 3 :10 est faible, voire nulle, pour un terminal terrestre. De plus, la distance entre l’antenne 3 et 10 est plus élevée que les distances de ping-pong pour des terminaux terrestres dans cette zone. Un terminal terrestre ne peut pas, en principe, s’attacher sur les antennes 10 :3 en un laps de temps court (en moins de 5 secondes typiquement). La distance entre les antennes est analysée avec les coordonnées des différentes antennes du réseau mobile. Une deuxième opération possible S22 propose de comparer une trajectoire en cours avec les probabilités de trajectoires analysées pour des terminaux terrestres (une trajectoire normale étant 3 :2 :3 :2 :4 :5 d’après l’exemple de la ). Un terminal qui obtient une trajectoire hors des probabilités propres aux terminaux terrestres peut entrer dans la catégorie des « terminaux probablement aériens ». Cette probabilité de trajectoire anormale est identifiée à l’opération S22 comme anormale car la probabilité qu’un terminal passe de l’antenne 10 à l’antenne 3 est très faible et, de même, entre les antennes 8 et 10 (10 : 3 : 10 : 3 : 1 : 8 : 10). La probabilité qu’une trajectoire est probablement aérienne peut être validée/confirmée en analysant la distance entre les antennes. Par exemple, si la distance entre les antennes 8 et 10 est supérieure à 20 km, cette suite d’antennes est improbable pour un terminal terrestre et son emprunt caractérise la trajectoire d’un drone. Une troisième opération possible S23 propose d’analyser la vitesse des terminaux en estimant les distances parcourues entre des cellules non adjacentes (10 :3 :1 :8 :10). Une telle opération permet aussi d’améliorer les prédictions de détection de drones qui n’ont pas, en principe, les mêmes vitesses de déplacement que les terminaux terrestres (piétons, cyclistes, automobiles souvent sur des voies à forte densité de trafic, etc.), la vitesse de déplacement d’un drone étant généralement plus grande. Ainsi, l’implémentation de la fonction NWDAF permet d’obtenir, après la mise en œuvre de l’étape générale S2, une liste de terminaux avec les probabilités associées qu’ils soient embarqués dans des drones respectifs, par observations de ping-pong anormal, et/ou de trajectoire (de handover) anormale, et/ou de vitesse anormale (pour un terminal terrestre). Cette liste peut être fournie au contrôleur aérien avec les identifiants des terminaux ayant un tel comportement anormal, en association avec les informations sur l’identité des propriétaires respectifs des abonnements au réseau (notamment dans le cas où cette autorité de contrôle aérien disposerait déjà de telles informations sur les utilisateurs, comme par exemple une police d’autorité de régulation aérienne, la sécurité civile, ou autres). Ainsi, ces trois types d’analyse peuvent être ajoutés aux services d’analyse habituels dont la fonction NWDAF est déjà en charge : - la détection d’un ping-pong anormal S21 (mobilité répétitive vers des antennes identiques en un laps de temps très court, par exemple inférieur à un seuil de cinq secondes ou moins), - la détection d’une trajectoire anormale S22 (suite d’antennes assurant des handovers successifs ayant une très faible probabilité par rapport à un ensemble de trajectoires de terminaux réputés terrestres), - la détection d’une vitesse anormale du terminal S23 (caractérisée par une distance parcourue, d’après les handovers relevés par les antennes, supérieure à un seuil (par exemple de 20 km) pour une latence inférieure à un seuil par exemple de quelques minutes). Il convient de noter que ces différentes détections peuvent être réalisées pour un drone qui est piloté via un réseau mobile mettant en œuvre cette fonction NWDAF, mais aussi pour un drone qui utilise une connexion mobile pour transmettre un flux média (comme un flux de vidéo que capture une caméra du drone) et qui n’est pas forcément contrôlé par un pilote connecté via un accès mobile. A la suite de cette étape S2, à l’étape générale suivante S3, ces analyses permettent de retrouver les identités de chaque terminal (le type de terminal (hardware, fournisseur de logiciel, etc.), l’identifiant du terminal unique (par exemple de type IMEI), l’identifiant de souscription (par exemple de type IMSI), l’identité de la carte SIM permettant la connexion au réseau cellulaire), ce qui permet de retrouver les identités du pilote du drone éventuellement en infraction (identité de profil de souscription au service mobile (ISIM), identité de connexion utilisée telle que l’adresse IP sur le réseau, identité de facturation associée au pilote (nom, prénom, adresse code postale, etc.)). Il est alors possible à l’étape S4 de déterminer typiquement si le pilote a souscrit ou non à un service du type précité en accord avec l’aviation civile, en recherchant l’identité du pilote dans une base de données générée par exemple à l’étape S0 de déclaration. S’il n’est pas identifié comme ayant souscrit à ce service à l’étape S0, une alerte peut être générée à l’étape S6. Il est possible ensuite à l’étape S5 de déterminer si le drone, même déclaré à l’étape S0, est autorisé à survoler une zone courante. Ainsi, à cette étape S5, le terminal est identifié comme potentiellement embarqué dans un drone et s’il est prédit que ce drone est en train de se rapprocher d’une zone de vol restreinte en analysant les données collectées auprès des antennes du réseau mobile, une alerte peut être générée à l’étape S6. A l’étape S5, pour une vérification plus générale et automatisée des zones de vol par rapport à des déclarations préalables de plans de vol autorisés, on peut prévoir que la fonction NWDAF vérifie dans les échanges de messages remontés par une entité du réseau en charge de la gestion UDM (pour « Unified data management ») qu’un drone identifié a bien une autorisation de vol. Une telle réalisation permet typiquement de récupérer un identifiant de vol du drone et un niveau d’autorisation de zones pouvant être survolées ou non. En outre, un échange de messages entre une entité USS et la fonction NWDAF peut fournir des informations sur la trajectoire prévue du drone, afin de comparer celle-ci avec une trajectoire attendue (dite « Expected UE Moving Trajectory ») pour une confirmation. Ainsi, la fonction NWDAF peut renseigner l’entité USS de l’endroit où le drone se situe exactement, ou encore notifier un tiers ayant souscrit à un service de surveillance de l’un de ses sites sensibles qu’un drone y a été détecté afin de contrôler son propre espace aérien. A l’issue de cette étape d’alerte S6, si la consultation de l’USS confirme que le terminal (détecté comme aérien) n’est pas autorisé à être embarqué sur un drone, le contrôleur aérien peut décider de bloquer le terminal en demandant au réseau mobile de suspendre la connectivité du drone. Le contrôleur aérien peut déclarer le terminal comme un drone pour bloquer tout attachement au réseau mobile s’il n’a pas un plan de vol attendu en ajoutant le terminal sur une liste des terminaux blacklistés chez les opérateurs mobiles. Le contrôleur aérien peut sommer le droniste de fournir l’identité de l’utilisateur qui a utilisé une connectivité mobile dans une zone interdite, ou encore tout autre action visant la sécurité d’un espace aérien. On a illustré sur la une réalisation possible d'un système pour la mise en œuvre du procédé décrit ci-avant. Le réseau mobile RESM est piloté par une entité telle que le cœur de réseau CN, à laquelle peut être connecté un dispositif SER pour la mise en œuvre du procédé présenté ci-avant en référence à la . Ce dispositif peut par exemple être réalisé sous la forme d’un serveur SER comportant un circuit de traitement équipé : - d'une interface de communication COM (notamment avec le cœur de réseau CN), - d’un processeur PROC, et - d’une mémoire MEM stockant des données d'instructions d'un programme informatique pour la mise en œuvre du procédé ci-avant, lorsque ces instructions sont lues et exécutées par le processeur PROC. L'interface de communication COM du serveur permet d'établir une connexion (par exemple via un réseau étendu RE), avec une plateforme USS du type précité. Typiquement, le serveur SER, se connectant au cœur de réseau CN, peut mettre en œuvre des fonctions de type NWDAF ou GMLC, lesquelles peuvent adresser une fonction de type NEF de la plateforme USS, comme décrit précédemment. Bien entendu, la plateforme USS peut en outre recevoir des données d'autorités telles que l'aviation civile AC, ou encore des autorités militaires MIL ou des industriels IND souhaitant restreindre le survol de zones sensibles (de sites militaires ou industriels typiquement). La présente divulgation ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples : elle s’étend à d’autres variantes. Ainsi par exemple, le serveur SER précité peut faire partie intégrante du cœur de réseau CN, lequel peut exécuter directement les fonctions NWDAF et/ou GMLC en lien avec la fonction NEF de l’USS. Ainsi, le dispositif au sens de la présente divulgation peut être directement le cœur de réseau CN. Par ailleurs, l’interconnexion du serveur SER (ou directement du cœur de réseau CN) à une plateforme de type USS est un exemple de réalisation. En complément ou en variante, des industriels ou des autorités militaires (ou autres) peuvent partager un serveur d’interconnexion SER avec le cœur de réseau CN pour recevoir directement des alertes issues de la surveillance du réseau par la mise en œuvre de fonction NWDAF notamment, typiquement pour déterminer si un drone embarquant un terminal à comportement anormal a survolé une zone sensible (militaire ou industrielle). En outre, les étapes S21 à S23 ci-avant sont illustrées à titre d’exemples relativement à ce que permet l’exécution d’une fonction de type NWDAF : d’une part, un autre type de fonction telle que GMLC peut être mis en œuvre, en variante ou en complément de la fonction de type NWDAF, et, d’autre part, la mise en œuvre de seulement l’une ou deux de ces étapes S21 à S23 est possible. Par ailleurs, on a appelé ci-avant l’objet UE embarqué par la désignation « terminal ». En terminologie 3GPP, le terminal peut être désigné aussi par les termes "agent utilisateur" (et toujours noté UE). Par ailleurs, à l’étape S0 présentée ci-avant, lors de la souscription, il peut être demandé à l’utilisateur si le drone n’est associé qu’à un seul agent utilisateur (ou terminal) ou alors à un couple SIM/IMEI associé à un drone, sur cet espace de vol, comme décrit ci-avant. Sinon (si l’utilisateur embarque plusieurs terminaux ou agents utilisateurs), l’utilisateur fournit les identifiants des autres agents utilisateurs (SIM, IMEI, PEI) afin de compléter l’analyse sur des trajectoires de différents agents utilisateurs embarqués ensemble dans un même appareil. Procédé de détection d’un terminal susceptible d’être embarqué dans un appareil en cours de vol, le terminal étant connecté à un réseau mobile comportant une pluralité de cellules couvertes par des antennes respectives, le procédé comportant : - obtenir (S1) des données courantes de connexion du terminal à des cellules successives du réseau mobile, lesdites données courantes comportant au moins des données des cellules intervenant dans la connexion du terminal au réseau mobile, - comparer (S2) les données courantes à des données de référence de connexion de terminaux terrestres et faisant intervenir au moins une cellule desdites données courantes, et - en fonction de ladite comparaison, déterminer (S3) si le terminal est embarqué dans un appareil en vol. Procédé selon la revendication 1, comportant : - obtenir (S1) des données courantes de transferts de connexion du terminal d’une cellule à une autre cellule, lesdites données courantes comportant au moins des données des cellules intervenant dans lesdits transferts, et - comparer (S2) les données courantes à des données de transferts de connexion de terminaux terrestres et faisant intervenir au moins une cellule desdites données courantes. Procédé selon la revendication 2, dans lequel, deux cellules du réseau étant réputées être adjacentes si elles assurent un transfert de connexion d’un terminal terrestre d’une des deux cellules à l’autre, ladite comparaison des données comporte la détection (S21 ; S22) dans les données courantes d’un transfert de connexion entre deux cellules qui ne sont pas réputées être adjacentes. Procédé selon la revendication 3, dans lequel les données courantes comportent en outre des instants respectifs desdits transferts, et lesdites données courantes sont analysées pour détecter (S21) si le terminal se connecte plusieurs fois successivement à deux cellules qui ne sont pas réputées être adjacentes et en un laps de temps inférieur à un seuil. Procédé selon l'une des revendications 3 et 4, dans lequel les données courantes comportent en outre des instants respectifs desdits transferts, et lesdites données courantes sont analysées pour détecter (S22) si une trajectoire que réalise le terminal passe par des cellules successives qui ne sont pas réputées être adjacentes. Procédé selon l'une des revendications précédentes, dans lequel les données courantes comportent une donnée de force de lien radiofréquence de connexion du terminal avec chacune desdites cellules successives du réseau mobile, pour estimer des positions successives du terminal. Procédé selon l'une des revendications 2 à 6, dans lequel les données courantes comportent en outre des instants respectifs de connexion auxdites cellules successives, et lesdites données courantes sont analysées pour déterminer une trajectoire du terminal et détecter si une vitesse de déplacement du terminal sur ladite trajectoire est supérieure à un seuil. Procédé selon l'une des revendications 2 à 5 et 7, mis en œuvre par une entité du réseau mobile et par l’exécution d’une fonction de type NWDAF – « Network Data Analytic Function ». Procédé selon l'une des revendications 6 et 7, mis en œuvre par une entité du réseau mobile et par l’exécution d’une fonction de type GMLC - « Gateway Mobile Location Center ». Procédé selon l'une des revendications précédentes, dans lequel lesdites données courantes comportent (S3) au moins un identifiant du terminal et au moins un identifiant d’utilisateur du terminal. Procédé selon la revendication 10, comportant en outre : - consulter une plateforme (USS) d’enregistrements de pilotes et/ou de plans de vol d’appareils embarquant des terminaux, et - déterminer (S4) au moins si l’identifiant d’utilisateur du terminal est déclaré parmi lesdits enregistrements de la plateforme. Procédé selon la revendication 11, prise en combinaison avec l’une des revendications 5 et 7, comprenant en outre : - consulter ladite plateforme pour déterminer (S5) si au moins la trajectoire du terminal est conforme à un plan de vol déclaré pour ledit terminal. Procédé selon l'une des revendications 11 et 12, prises en combinaison avec l’une des revendications 5 et 7, comprenant en outre : - vérifier (S5) si ladite trajectoire inclut au moins un site sensible, associé à des conditions restrictives de survol. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsqu’elles sont exécutées par un circuit de traitement. Dispositif comportant un circuit de traitement pour la mise en œuvre du procédé selon l’une des revendications 1 à 13. Dispositif selon la revendication 15, comportant une connexion (COM) à un cœur (CN) du réseau mobile, d’une part, et à une plateforme (USS) d’enregistrements de pilotes et/ou de plans de vol d’appareils embarquant des terminaux, d’autre part. Dispositif selon l'une des revendications 15 et 16, agencé pour exécuter au moins une fonction parmi au moins une fonction de type NWDAF – « Network Data Analytic Function » et une fonction de type GMLC - « Gateway Mobile Location Center ». Dispositif selon la revendication 16 combinée à la revendication 17, le dispositif étant agencé pour exécuter ladite fonction, en connexion avec ladite plateforme USS, via une fonction de type NEF - « Network Exposition Fonction ».