FR3132972A1 - Procédé de gestion d’un véhicule télé-contrôlé par un réseau de communication, dispositif, système et programme d’ordinateur correspondants. - Google Patents

Abstract

L'invention concerne un procédé de gestion d’une position d’un véhicule télé-contrôlé (UAV, 10), dit drone, par rapport à une entité de contrôle (UAVC, 11), ladite entité de contrôle étant configurée pour contrôler le drone par l’intermédiaire d’un flux de données de contrôle transmis de façon indirecte au sein d’une communication établie entre l’entité de contrôle (11) et le drone (10) par l’intermédiaire d’un réseau de communication (RC), ledit procédé comprenant :-pour au moins un instant temporel de la communication, la détermination (E6) d’au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle;- lorsque le paramètre relatif à une distance n’appartient pas à un intervalle de valeurs autorisées pour un mode de pilotage donné, l’application (E10) d’au moins une règle de gestion donnée du drone. FIGURE 3

Description

Procédé de gestion d’un véhicule télé-contrôlé par un réseau de communication, dispositif, système et programme d’ordinateur correspondants. Domaine de l'invention

Le domaine de l'invention est celui des véhicules télé-contrôlés ou drones. Plus précisément, l'invention concerne la surveillance, par un réseau de communication, du déplacement, par exemple du vol, d’un drone par rapport à son pilote.

Art antérieur et ses inconvénients

Les véhicules télé-contrôlés, plus communément appelés drones, sont des véhicules pilotés à distance. Ce type de véhicules est de plus en plus utilisé pour des utilisations aussi diverses que l’analyse d’infrastructures de transports (voies ferrées, réseau d’électricité, infrastructures routières), la réalisation de cartographies ou la livraison de produits à destination de consommateurs finaux. Ces drones, le plus souvent aériens, peuvent également être des véhicules roulants ou bien utilisés en mer. Ils se caractérisent par le fait que leur pilote ne se trouve pas a leur bord mais à distance du véhicule, celui-ci étant contrôlé à l’aide d’un dispositif de contrôle. Le drone peut en effet être commandé à distance par le pilote à l’aide du dispositif de contrôle, ou bien le drone peut se déplacer de façon autonome, par exemple conformément à l’exécution d’un plan de déplacement programmé, mais toujours sous le contrôle du pilote, lequel veille à la navigation du drone conformément au plan de déplacement programmé.

Face à ces nouvelles possibilités et aux risques accrus de mauvais usages (intentionnels ou non), les autorités aériennes ont conçu une architecture, nommée UTM (de l’anglais, « UAV (« Unmanned Aerial Vehicle ») traffic management »), et tout un ensemble de services destinés à permettre une gestion efficace et sécuritaire de l’espace aérien. Une composante clé de cette architecture est l’USS (de l’anglais, « UTM Service Supplier ») qui joue le rôle d’interface entre l’opérateur de drone, par exemple le pilote UAVC (de l’anglais, « UAV Controller ») ou une entreprise qui gère une flotte de drones et propose des services associés (de l’anglais, « UAS Operator »), le couple pilote/drone (UAS pour « Unmanned Aerial System ») et les Autorités Aériennes.

De manière simplifiée, un drone génère deux flux distincts, l’un pour la transmission des données relatives à la mission du drone (par exemple, des photos), qu’on appelle les données utiles ou charge utile (en anglais, « payload »), l’autre pour la transmission des données relatives au pilotage du drone, au contrôle de sa trajectoire et à la gestion du trafic aérien, qu’on appelle les données de contrôle ou « Command & Control », ou encore lien C2.

Comme le pilote n’est pas à bord, ce lien C2 est essentiel car il permet de maintenir la communication entre le drone UAV, en l’air, et le pilote UAVC, au sol. On peut distinguer deux types de vol de drone :
- les vols en ligne de vue directe ou VLoS (de l’anglais, « Visual Line of Sight ») : le pilote est à proximité de son drone et une communication directe est maintenue entre les deux (liaison point à point) ;
- les vols au-delà de la ligne de vue directe ou BVLoS (de l’anglais, « Beyond Visual Line of Sight ») : le pilote peut être très éloigné de son drone, la communication entre les deux est transportée via un réseau de télécommunications (par exemple, satellitaire ou cellulaire).

Il existe de multiples façons d’établir ce lien C2, entre le drone UAV et le pilote UAVC.

Premièrement, la liaison peut être directe, c’est-à-dire que l’UAV et l’UAVC communiquent directement entre eux, via un seul lien radio sol-air, sans aucun intermédiaire et notamment pas de réseau de communication intermédiaire. On parle dans ce cas de « Non-Networked UAV » et de « Non-Networked UAVC ». Ce type de liaison est intrinsèquement lié à la notion de vols en ligne de vue directe VLoS, car la portée de cet unique lien radio est limitée par les caractéristiques physiques de l’environnement et la propagation radio. Néanmoins, l’absence de lien autre que celui établi entre le drone et son pilote ne permet pas d’établir un lien de contrôle entre les Autorités Aériennes et le pilote, si bien qu’elles ne sont ni informées en temps réel lorsque le pilote ne respecte pas le plan de vol déclaré, ni a fortiori en mesure de prendre le contrôle du drone pour le ramener dans une zone autorisée. En plus des bandes de fréquences dédiées à l’aviation (qui ne permettent pas nécessairement un très haut débit), l’utilisation d’autres technologies radio peut être envisagée pour établir une telle liaison directe. La technologie sans fil Wi-Fi est, de loin, la technologie la plus répandue. Peu chère, sa portée relativement courte (qui n’excède pas 1 ou 2 km) contraint le pilote et donc le dispositif de contrôle à rester à proximité de son drone. Elle est considérée comme fiable par les Autorités Aériennes. Récemment, de nouvelles technologies cellulaires, appelées "V2X cellulaire" (C-V2X) ont été proposées pour établir une liaison directe.

Deuxièmement, la liaison peut être indirecte, c’est-à-dire que l’UAV et l’UAVC communiquent entre eux par l’intermédiaire d’un réseau de communications, l’UAV et l’UAVC sont chacun connectés au réseau de communication via un point d’accès à ce réseau, et le réseau (ou système de réseaux, par exemple réseau cellulaire + réseau IP) fait la jonction entre les deux. L’UAV se connecte au réseau via un lien air-sol basé sur une technologie radio, qui peut être Wi-Fi ou :

- la technologie satellitaire, qui a plutôt un usage militaire mais permet de faire voler des drones (généralement complètement autonomes) au-delà de la ligne de vue directe (mode BVLoS), incluant la très longue élongation (par exemple, au milieu de l’océan). Les drones équipés d’une interface satellitaire étant relativement chers, cette technologie représente aujourd’hui une niche du marché et s’avère utile dans certains cas, notamment en l’absence de réseau cellulaire ;
- la technologie cellulaire, qui présente de nombreux avantages. Elle est d’une part plus fiable et beaucoup mieux sécurisée que le Wi-Fi et d’autre part moins chère et beaucoup plus accessible que le satellite. En outre, cette technologie bénéficie de la couverture nationale des opérateurs télécoms ou MNO (de l’anglais, « Mobile Network Operators »), ainsi que de moyens intrinsèques pour contrôler le drone à distance tout en assurant un débit élevé pour la transmission des données de payload liées à la mission du drone.

Dans le cas d’une connexion cellulaire entre le drone et le réseau, on parle de drone en réseau (de l’anglais, « Networked UAV »).

Quant à l’UAVC, il peut se connecter au réseau via une technologie sans-fil (WiFi, Cellulaire, Satellite, etc.) ou filaire (ADSL, fibre optique, etc.). Deux cas principaux peuvent être distingués :
1) le pilote ou contrôleur en réseau (de l’anglais, « Networked UAVC »), pour un pilote utilisant un équipement terminal de type 3GPP tel qu’un téléphone intelligent (en anglais, « smartphone ») et connecté au réseau de communication via une technologie radio cellulaire classique (non « C-V2X ») ;
2) le pilote ou contrôleur en nuage (de l’anglais, « Cloud UAVC »), pour un pilote connecté via une autre technologie d’accès (filaire ou non-filaire) que la technologie radio cellulaire classique et passant par un réseau d’interconnexion, par exemple de type Internet avant de rejoindre le réseau cellulaire et d’atteindre son drone, de type « Networked UAV ».

La liaison indirecte entre l’UAV et l’UAVC offre de nombreux avantages car elle permet de déployer (sur le réseau ou via des entités externes connectées à ce réseau, comme l’USS) tout un ensemble de services permettant un meilleur contrôle des opérations de drones, par exemple, la vérification des autorisations de vol, le contrôle du respect des zones de vols déclarées, la reprise de contrôle du drone, etc. Pour un drone en réseau (« Networked UAV »), l’organisation 3GPP a proposé des solutions pour assurer un certain contrôle de la zone effectivement survolée par le drone grâce aux technologies cellulaires. Elles sont par exemple décrite dans le document TR 23.754 « Study on Suporting Unmanned Aerial Systems (UAS) Connectivity, Identification and Tracking », version 17, publié par le 3GPP en Mars 2021 (solutions 13, 14 et 15).

Ces solutions permettent notamment:
- au système 3GPP mis en œuvre dans le réseau cellulaire d’associer un UAV avec un UAVC (enregistrement, identification, autorisation, etc.) ;
- à l’UTM / USS d’accéder à la géolocalisation de l’UAV et / ou de l’UAVC, par simple requête ou de manière périodique, via la couverture radio du réseau cellulaire ;
- à l’UTM / USS de vérifier ces positions, et potentiellement de demander la révocation de l’autorisation d’un UAV si celui-ci dévie de sa trajectoire ou de sa zone déclarée ;
- au système 3GPP de comparer une position de l’UAV à une trajectoire renseignée par l’UTM / USS, qui peut alors demander un changement de trajectoire ou envoyer une alerte.

En particulier, trois modes de suivi pour l’UAV sont spécifiés, sur la base d’une fonction d’exposition du réseau aux événements NEF ((de l’anglais, « Network Exposure Function »)) et des caractéristiques d’exposition du réseau aux événements (de l’anglais, « 5GC event exposure »), qui permettent une interaction entre le réseau de l’opérateur mobile et un tiers / client, grâce à la collecte d’un certain nombre de données grâce à des APIs, au traitement de ces données puis à leur exposition aux tiers. Les entités impliquées dans le déplacement des drones peuvent donc fournir des informations au réseau cellulaire, concernant :
1) UAV Location Reporting (transmission de la position sur requête ou périodiquement) ;
2) UAV Presence Monitoring Mode (alerte lors qu’un UAV ciblé se déplace en dehors d’une zone géographique) ;

3) Liste des UE aériens (UAV) présents dans une zone géographique donnée.

En revanche, les solutions existantes basées sur une liaison indirecte pour les communications C2 (incluant les solutions proposées au 3GPP) sont essentiellement adaptées à un usage en mode BVLoS, car elles effacent toute notion de distance entre l’UAV et l’UAVC et ne garantissent pas que le drone reste à proximité de son UAVC, quelle que soit la zone de vol déclarée auprès des autorités aériennes.En outre, le contrôle d’une position d’un UAV ou d’un UAVC ne peut pas s’effectuer autrement que sur la base d’une trajectoire ou d’une zone de survol prédéfinie et renseignée par l’UTM / USS. Il en résulte que, malgré les nombreux avantages de la technologie cellulaire et la forte demande des opérateurs de drones pour cette technologie, cette technologie n’est toujours pas autorisée par les autorités aériennes pour la transmission de données de contrôle utilisant le lien C2. En effet, le lien entre l’UAV et l’UAVC n’étant pas direct, la technologie cellulaire est naturellement associée à un vol en mode BVLoS et on peut supposer que les autorités aériennes craignent une généralisation tous azimuts de tels vols. Or, le déploiement de drones se déplaçant sans pilote à proximité pourrait devenir compliqué à gérer aussi bien en cas d’incidents (ex : comment gérer à distance un crash ?) que pour les autorisations et contrôles exercés par les forces de l’ordre (ex : comment contrôler les autorisations de vol ?).

Il existe donc un besoin d'une technique permettant de surveiller le vol d’un drone utilisant une liaison indirecte avec son pilote, et notamment de s’assurer qu’il reste en ligne de vue directe pour son pilote.

L’invention vient améliorer la situation.

L'invention répond à ce besoin en proposant un procédé de gestion d’une position d’un véhicule télé-contrôlé, dit drone, par rapport à une entité de contrôle, ladite entité de contrôle étant configurée pour contrôler le drone par l’intermédiaire d’un flux de données de contrôle transmis de façon indirecte au sein d’une communication établie entre l’entité de contrôle et le drone par l’intermédiaire d’un réseau de communication, ledit procédé comprenant :
-pour au moins un instant temporel de la communication, la détermination d’au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle;
- lorsque le paramètre relatif à une distance n’appartient pas à un intervalle de valeurs autorisées pour un mode de pilotage donné, l’application d’au moins une règle de gestion du drone.

Dans le présent document, il est entendu par entité de contrôle d’un drone un dispositif de contrôle d’un drone, un pilote de drone, qu’il s’agisse d’un être humain ou d’un pilote automatique, ou d’un couple constitué par un pilote et un dispositif de contrôle d’un drone, l’entité de contrôle et son drone étant connectés entre par une liaison indirecte, c’est-à-dire via un réseau de communication, par exemple un réseau mobile ou un réseau satellitaire ou encore un réseau de réseaux, tel que par exemple un réseau mobile interconnecté avec un réseau de données, type Internet, le drone étant connecté au réseau mobile par exemple par voie radio cellulaire et l’entité de contrôle au réseau de données par voie radio Wi-Fi, ou par un lien filaire quelconque.

Dans ce contexte, le drone et son entité de contrôle n’étant pas connectés par une liaison point à point, le déplacement du drone n’est pas limité par une quelconque portée radio au-delà de laquelle il perdrait la connexion avec son pilote.

Même si dans la suite on s’attache plus spécifiquement à décrire le cas d’un drone, l’invention s’applique bien sûr à tous types de dispositifs télé-contrôlés qu’ils soient volants, roulants ou flottants.

L’invention propose une approche tout-à-fait nouvelle et inventive de la gestion de la position d’un drone par rapport à son pilote qui s’appuie sur la détermination d’un paramètre relatif à une distance entre le drone et son pilote et sur la vérification que la valeur de ce paramètre reste comprise dans un intervalle de valeurs autorisées pour un mode de pilotage donné. Lorsque ce n’est pas le cas, une ou plusieurs règles de gestion du drone sont mises en application en vue de ramener le drone à proximité suffisante de son pilote ou de modifier le mode d’utilisation du drone.

Avantageusement, cette détermination d’un paramètre de distance est répétée à plusieurs reprises au cours du déplacement ce qui permet de réaliser un suivi du déplacement du drone par rapport à son pilote et de corriger la situation lorsque le drone ne respecte pas les contraintes d’éloignement réciproque fixées au préalable.

On désigne ici par paramètre relatif à une distance aussi bien une mesure physique entre les positions géographiques du drone et de son entité de contrôle à un instant donné, qu’une mesure de latence d’un signal de données émis entre l’un et l’autre, tel que le flux de données de contrôle par exemple ou encore que toute autre mesure de qualité de la communication établie entre les deux et qui se dégrade lorsque la distance physique entre le drone et son pilote augmente, comme par exemple une mesure de rapport signal à interférence et bruit entre le drone et la station d’accès à laquelle le drone est connecté et pouvant contribuer à évaluer la distance entre le drone et l’entité de contrôle.

De la sorte, l’invention permet aussi bien de garantir un mode de pilotage manuel selon une ligne de vue directe, lorsque le paramètre de distance est une mesure de distance physique et l’intervalle de distance associé est limité par la distance de ligne de vue directe communément admise par les Autorités Aériennes (de l’ordre de 200 à 300 m), qu’un mode de pilotage automatique, lorsque le paramètre de distance considéré renseigne sur une qualité de service de la connexion entre le drone et l’entité de contrôle ou est calculé à partir d’une mesure de latence du flux de données de contrôle échangé entre le drone et son pilote.

L’invention peut aussi bien être mise en œuvre dans une ou plusieurs entités ou fonctions du réseau de communication, par exemple une entité d’un système de gestion de la connectivité des drones intégré dans ce réseau, dans le cas où il s’agit d’un réseau cellulaire et tel que décrit par le 3GPP, que dans un système connecté audit réseau, tel que par exemple un système UTM/USS de gestion du trafic des drones géré par exemple par les Autorités Aériennes et configuré pour interagir avec le système précédent.

Ainsi, l’invention s’appuie sur l’infrastructure d’un réseau de communication par l’intermédiaire duquel un pilote est connecté à son pilote pour surveiller en temps réel que le déplacement du drone satisfait les conditions édictées par les Autorités Aériennes et intervenir si ce n’est pas le cas.

Selon un aspect de l’invention, le procédé comprend en outre l’obtention d’une position géographique du drone et d’une position géographique de l’entité de contrôle, ledit paramètre comprend au moins une mesure de distance physique entre le drone et l’entité de contrôle déterminée à partir desdites positions géographiques et ladite au moins une règle de gestion est mise en application lorsque ladite mesure de distance dépasse une distance maximale autorisé).

Avantageusement, les mesures restrictives sont appliquées dès que le drone sort d’une zone géographique autorisée centrée sur la position géographique de l’entité de contrôle et comprise dans un rayon égal par exemple à la distance de ligne de vue directe communément admise par les autorités aériennes.

L’invention propose d’analyser les positions géographiques successives d’un drone par rapport à celles de son pilote, ce qui lui permet de réaliser un géo-repérage (de l’anglais, « geofencing ») dynamique du drone et de déclencher des alertes ou des actions restrictives dès que la frontière virtuelle d’une zone de déplacement autorisée par le mode de pilotage est franchie.

Ainsi, selon ce mode de réalisation de l’invention, l’entité de contrôle devient un point d’ancrage pour détecter un écart de déplacement du drone par rapport à des règles données fixées pour le mode de pilotage qui marque l’association drone – entité de contrôle.

Lorsqu’il est déterminé que le drone a dépassé la limite de distance autorisée, une ou plusieurs mesures règles de gestion, correspondant par exemple à des règles restrictives de déplacement sont mises en application dans le but, par exemple, de ramener le drone dans un voisinage plus immédiat de son entité de contrôle.

Par exemple, pour un mode de pilotage dit VLOS, en ligne de vue directe, l’invention permet notamment de garantir le principe de vol en « ligne de vue directe » et ainsi de reproduire, dans le cas d’une liaison indirecte entre le drone et son pilote, cette caractéristique d’un vol de drone en mode VLOS basé sur une technologie radio point à point, par exemple Wi-Fi.

Selon un autre aspect de l’invention, ledit paramètre relatif à une distance comprend au moins une mesure de latence de la communication établie entre le drone et l’entité de contrôle et ladite au moins une règle de gestion du drone est mise en application lorsque ladite mesure de latence est supérieure à une valeur de latence maximale.

Avantageusement, il s’agit d’une mesure de latence de bout en bout. Elle permet de détecter lorsque la qualité de la communication se dégrade entre le drone et l’entité de contrôle. Par exemple, lorsque l’entité de contrôle est un pilote automatique intégré dans un système informatique déporté à proximité d’une première station de base, de type MEC, une mesure de latence trop élevée peut signifier que le drone s’est trop éloigné de la première station de base et qu’il est temps de transférer le contrôle du drone vers un autre pilote automatique plus proche de la deuxième station de base.

Selon encore un autre aspect de l’invention, le procédé comprend l’obtention préalable d’un modèle de classification d’un voisinage de l’entité de contrôle associé au mode de pilotage donné, ledit modèle comprenant au moins une première zone, dite zone de déplacement autorisée, définie par ledit intervalle de valeurs du paramètre et une deuxième zone de déplacement non autorisée, complémentaire de la première, et la dite au moins une règle de gestion du drone est mise en application lorsque le drone sort de la zone de déplacement autorisée.

Ce modèle de classification d’un voisinage peut être associé par défaut à un mode de pilotage donné. Par exemple, pour un mode pilotage en ligne de vue directe VLOS, la zone autorisée est définie par la distance de ligne de vue directe communément admise par les Autorités Aériennes.

Selon un autre aspect de l’invention, le procédé comprend l’obtention d’informations relatives à une zone de déplacement déclarée pour le drone 10, ladite zone de déplacement autorisée est adaptée en fonction de la zone de déplacement déclarée et ladite au moins une règle de gestion du drone est mise en application lorsque le drone sort de la zone de déplacement autorisée ou de la zone déclarée.

Avantageusement, lorsque le pilote a déclaré une zone de déplacement ou survol ou plan de vol, cette information est obtenue par le réseau et exploitée pour définir plus précisément la zone géographique autorisée. Autrement dit, le drone doit à la fois se trouver à l’intérieur de la zone déclarée et dans l’intervalle de valeurs du paramètre de distance.

Selon encore un autre aspect de l’invention, le procédé comprend l’obtention préalable du mode de pilotage donné, ledit mode de pilotage étant stocké en mémoire pour une association entre le drone et l’entité de contrôle dans ledit réseau.

Selon l’invention, l’association entre le drone et l’entité de contrôle qui doit être autorisée par les Autorités Aériennes avant le vol est marquée par un mode de pilotage donné. Ce marquage conditionne ensuite la surveillance du système drone – entité de contrôle pendant le vol. Par exemple, le mode de pilotage est stocké en lien avec un identifiant du drone et un identifiant de l’entité de contrôle ou en lien avec un identifiant de l’association entre le drone et l’entité de contrôle.

Un avantage est que le mode de pilotage est enregistré lors de la procédure d’association du drone et de son pilote. Un avantage est de se greffer à la procédure d’association déjà spécifiée par le 3GPP et de réutiliser des échanges de messages existants.

Le mode de pilotage peut être en ligne de vue directe ou VLOS, adapté à un pilote manuel. Pour un pilote automatique, un mode de pilotage « LAT » lié à des contraintes de latence est plus adapté.

Selon un autre aspect de l’invention, ladite au moins une règle de gestion du drone appartient à un groupe comprenant au moins l’envoi à l’entité de contrôle d’une notification relative à :
- une alerte de sortie de la zone de déplacement autorisée au moins ;
- un ordre de retour dans la zone de déplacement autorisée ;
- un plan de déplacement à destination de la zone de déplacement autorisée ;
- une notification de transfert de contrôle du drone vers une deuxième entité de contrôle.

De telles mesures sont des injonctions. Elles sont destinées à informer le pilote de la situation et des risques qu’il encourt.

Selon encore un autre aspect de l’invention, ladite au moins une règle de gestion du drone comprend le déclenchement d’un transfert de contrôle du drone vers une deuxième entité de contrôle autorisée.

La deuxième entité de contrôle doit posséder une autorisation de contrôle du drone délivrée par un système de gestion du trafic de drones UTM et s’être préalablement connectée au réseau de télécommunications mobile.

Un avantage d’une telle mesure est qu’elle est coercitive. On peut envisager de la mettre en application par exemple, mais non nécessairement lorsque des mesures incitatives d’alerte ont échoué.

Avantageusement, ledit transfert de contrôle du drone vers la deuxième entité de contrôle, déclenche une mise à jour du mode de pilotage, de l’intervalle de valeurs autorisé et de la au moins une règle de gestion du drone.

En effet la deuxième entité de contrôle peut être, comme la première entité de contrôle marquée par un mode de pilotage « VLOS , mais elle peut aussi être mandatée par les autorités aériennes ou bien être un pilote automatique du réseau de télécommunications mobiles et être marquée par un mode de pilotage « LAT », lié à des contraintes de latence de la communication entre le drone et son pilote automatique.

Avantageusement, le changement d’entité de contrôle peut aussi déclencher l’obtention d’un nouveau modèle de classification associé à la deuxième entité de contrôle pour le deuxième mode de pilotage.

Selon encore un autre aspect de l’invention, ladite au moins une règle de gestion comprend la transmission d’un ordre d’interdiction d’attachement du drone à au moins un équipement d’accès situé à portée radio de la zone non autorisée.

Un avantage est de pouvoir borner la zone non autorisée en rendant techniquement impossible le franchissement d’une certaine limite par le drone.

Selon un autre aspect de l’invention, ladite au moins une règle de gestion du drone comprend la transmission à au moins un équipement d’accès situé à portée radio de la ladite zone géographique non autorisée, d’un ordre de dégradation d’une qualité de signal entre le drone et ledit au moins un équipement d’accès dudit réseau.

Un avantage est de simuler la baisse de qualité du signal radio dans le cas d’une liaison radio point à point que le pilote est habitué à considérer comme une alerte et à associer à un éloignement trop important du drone de son pilote (sortie de la zone de portée radio-.

Avantageusement, cet ordre de dégradation peut être limité au flux de données utiles et ne pas affecter le flux de données de contrôle.

Selon encore un autre aspect de l’invention, le procédé comprend l’obtention d’un rapport d’événements et la transmission dudit rapport à une entité accréditée et/ou à l’entité de contrôle.

Il s’agit par exemple du système de gestion du trafic des drones UTM/USS ou des Autorités Aériennes. Un avantage est que l’invention leur permet d’accès à des informations relatives au déplacement du drone automatiquement et à bref délai après le vol, ce qui n’est pas le cas actuellement lorsque l’entité de contrôle est connectée au drone selon une liaison radio point à point.

L’invention concerne également un dispositif de gestion d’une position d’un véhicule télé-contrôlé, dit drone, par rapport à par une entité de contrôle, ladite entité de contrôle étant configurée pour contrôler le drone par l’intermédiaire d’un flux de données de contrôle transmis de façon indirecte au sein d’une communication établie entre l’entité de contrôle et le drone par l’intermédiaire d’un réseau de communication.

Ledit dispositif est configuré pour mettre en œuvre :
-pour au moins un instant temporel de la communication, la détermination d’au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle ;
- lorsque le paramètre relatif à une distance n’appartient pas à un intervalle de valeurs autorisées pour un mode de pilotage donné, l’application d’au moins une règle de gestion donnée du drone.

Avantageusement, ledit dispositif de gestion est mis en œuvre par une ou plusieurs entités ou fonctions d’un système de gestion de la connectivité des drones intégré au réseau de communication. Avantageusement, ledit dispositif de gestions et ledit système de gestion de la connectivité des drones sont compris dans un système de gestion d’une position d’un véhicule télé-contrôlé, dit drone, par rapport à une entité de contrôle configurée pour le contrôler par l’intermédiaire d’une session de communication établie dans un réseau de télécommunications. Ledit système de gestion comprend en outre un système de gestion du trafic de drones qui est connecté audit réseau.

Le système de gestion et le dispositif de traitement présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion précité.

L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre respective du procédé de gestion précité, lorsqu’il est exécuté par un processeur.

Un 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 au moins un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé selon l’invention tel que décrit ci-dessus.

Un tel 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 (carte mémoire) ou un disque dur ou un SSD.

D'autre part, un tel 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. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.

Alternativement, le ou les supports d'enregistrement peuvent être un ou des circuits intégrés dans lesquels chaque programme est incorporé, le ou les circuits étant adaptés pour exécuter ou pour être utilisé dans l'exécution du ou des procédés précités.

Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d’éléments matériels et/ou logiciels support d’une fonction ou d’un service, qu’ils soient unitaires ou combinés.

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.

Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.

Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.

Liste des figures

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

: cette figure représente les différents éléments intervenant dans la mise en œuvre de la présente solution, pour un drone et une entité de contrôle connectés entre eux via un réseau de communication ;

: cette figure détaille les différents éléments intervenant dans la mise en œuvre de la présente solution, lorsque l’entité de contrôle du drone est connectée au réseau de communications par l’intermédiaire d’un réseau de données ;

: cette figure représente un exemple illustratif d’architecture d’un système de gestion de dispositif télé-contrôlé dans un réseau de télécommunications mobiles selon un premier mode de réalisation de l’invention,

: cette figure représente, sous la forme d’un diagramme de flux les différentes étapes d’un procédé de gestion de la position d’un drone par un réseau de télécommunications mobiles, pendant la phase de préparation de déplacement du drone,

: cette figure représente un exemple de modèle de classification d’un voisinage d’une entité de contrôle en zones géographiques selon un mode de réalisation de l’invention,

: cette figure représente, sous la forme d’un diagramme de flux les différentes étapes d’un tel procédé de gestion de la position d’un drone par un réseau de télécommunications mobiles, pendant la phase de déplacement ou de vol,

: cette figure représente, sous la forme d’un diagramme de flux les différentes étapes d’un tel procédé de gestion de la position d’un drone par un réseau de télécommunications mobiles, suite à un transfert de contrôle du drone à une deuxième entité de contrôle,

: cette figure représente un exemple illustratif d’architecture d’un système de gestion de dispositif télé-contrôlés dans un réseau de télécommunications mobiles selon un deuxième mode de réalisation de l’invention ; et

: cette figure représente, de façon schématique un exemple de structure matérielle d’un dispositif de gestion de la position d’un dispositif télé-contrôlé selon un mode de réalisation de l’invention.

Description détaillée de modes de réalisation de l'invention

Le principe général de l'invention repose sur la détermination, notamment au cours du déplacement d’un drone, d’un paramètre relatif à une distance entre ce drone et son entité de contrôle, connectés l’un à l’autre par une liaison indirecte, et sur la mise en application de règles de gestion du drone, comprenant par exemple des mesures de restriction de déplacement du drone, lorsque ce paramètre prend une valeur qui n’appartient pas à un intervalle de valeurs autorisées pour un mode de pilotage donné.

Le drone et son entité de contrôle, et éventuellement leur association, font l’objet d’une autorisation préalable au déplacement, par les Autorités Aériennes. Avantageusement, le drone et / ou son entité de contrôle et / ou leur association est marquée, avant le déplacement, par le mode de pilotage donné et ce marquage conditionne la surveillance du déplacement du drone par rapport à son entité de contrôle selon l’invention.

Dans un mode de réalisation particulier, le paramètre déterminé est une mesure de distance physique obtenue à partir de relevés des positions géographiques du drone et de l’entité de contrôle et la mise en application des mesures de restriction de déplacement sont déclenchées lorsque cette mesure de distance dépasse un seuil donné.

Par exemple, le mode de pilotage est le mode de pilotage en ligne de vue directe VLOS et le seuil donné est fixé à la distance maximale de ligne de vue directe communément admise par les Autorités Aériennes.

L’invention permet ainsi de surveiller qu’un drone et son pilote respecte les conditions d’un vol en mode VLOS et d’agir lorsque ce n’est pas le cas pour ramener le drone à proximité de son pilote.

Les mesures restrictives peuvent être aussi bien incitatives, et par exemple prendre la forme d’alertes envoyées à l’entité de contrôle, que coercitives, et par exemple entraîner une modification de la connexion du drone et de l’entité de contrôle au réseau de télécommunications ou un changement du plan de vol ou encore un transfert de contrôle du drone. Avantageusement, elles peuvent être prises de façon échelonnée au cours du vol en fonction des réactions du pilote à des mesures prises précédemment.

Dans la suite, on décrit de façon plus détaillée des modes de réalisation de l’invention dans un réseau de télécommunications mobiles, dont l’architecture est conforme à la norme 3GPP (dans une de ses versions actuelles ou futures) et met en œuvre des fonctions d’accès radio, par exemple de type station de base, et des fonctions/ de cœur de réseau, par exemple NEF ou UPF (de l’anglais, « User Plane Fonction »). On note que selon la norme 5G du 3GPP, un réseau mobile se compose de fonctions de réseau physiques et/ou virtuelles PNF/VNF (pour « Physical Network Functions/Virtual Network Functions », en anglais) qui sont interconnectées et peuvent appartenir à la partie accès et/ou à la partie cœur du réseau de communications.

On présente désormais, en relation avec les et les différents éléments intervenant dans la mise en œuvre de la présente solution.

Ainsi, un véhicule télé-contrôlé 10, tel qu’un drone par exemple, est sur le point de partir en mission, au cours de laquelle il sera contrôlé par une première entité de contrôle 11. Un tel drone 10 appartient à une flotte de drones gérée par un opérateur de drone, ou entité de gestion 15 d’une flotte de drones. Une telle entité de gestion 15 d’une flotte de drones est par exemple une entreprise de livraison de biens à domicile ou une société de surveillance de sites industriels.

Dans l’exemple de réalisation de la , une telle entité de contrôle 11 est configurée pour exercer le contrôle du drone 10, en échangeant un flux de données de contrôle au travers d’une communication 13 établie entre le drone 10 et l’entité de contrôle 11 via le réseau de communication RC. Le flux de données est bidirectionnel : Le pilote envoie des ordres, par exemple de direction, et le drone lui transmet ses paramètres de vol, sa position GPS etc. Cette communication est par exemple supportée par un ou plusieurs canaux de transmission établis entre l’entité de contrôle 11 et le drone 10. L’établissement et la maintenance de cette communication sont effectués par des entités du réseau RC, qui implémentent un certain nombre de fonctionnalités additionnelles spécifiques à la gestion de la connectivité de systèmes télé contrôlés dans un système SGC 14. Par exemple, le drone 10 et l’entité de contrôle 11 sont identifiés auprès du système SGC 14.

On suppose ici que le drone 10 est connecté au réseau RC par un accès radio cellulaire. L’entité de contrôle UAVC 11 peut quant à elle être connectée elle aussi via un accès radio cellulaire, comme dans l’exemple de la et dans ce cas le réseau RC peut être un réseau mobile, ou bien elle est connectée au réseau RC par un autre réseau d’accès, par exemple un réseau de données DN (ou « Data Network », en anglais) comme illustré par la . Dans ce deuxième cas, le réseau RC est un réseau de réseaux comprenant le réseau mobile RM et le réseau de données DN qui peut être un réseau filaire (Fibre, xDSL) ou non filaire.

Un tel système SGC 14 de gestion de la connectivité des systèmes télé-contrôlés est par exemple un système tel que celui décrit dans la publication du 3GPP TR 23.754 V2.0.0 : Study on supporting Unmanned Aerial Systems (UAS) connectivity, Identification and tracking (Release 17) - Novembre 2020, déjà citée. Ce document décrit plusieurs solutions pour le contrôle d’un drone par une entité de contrôle par l’intermédiaire d’une communication établie dans un réseau de communications, lesquelles font intervenir différents équipements, entités ou fonctions du réseau de communication, qui ne seront pas systématiquement détaillés dans ce qui suit.

Le système SGC 14 communique avec un système UTM/USS 16 de gestion du trafic de drones, lui-même connecté au réseau de communication RC. Un tel système UTM/USS 16 assure la gestion du trafic des drones afin de limiter et même d’éviter les accidents entre drones ou avec d’autres véhicules télé-contrôlés ou non. À cette fin, le système UTM/USS 16 de gestion du trafic de drones est habilité à délivrer des autorisations de déplacements au drone 10 ainsi que des autorisations de contrôle aux entités de contrôle 11, 12. Ainsi, seul un drone 10 autorisé peut effectuer une mission. De même, seule une entité de contrôle 11, 12 autorisée peut exercer le contrôle d’un drone. Ce système 16 est connecté au réseau de communication RC.

La illustre de façon schématique un exemple d’architecture d’un système S pour la gestion des véhicules télé-contrôlés dans un réseau de communication RC, selon un mode de réalisation de l’invention.

Selon ce mode de réalisation de l’invention, le système S comprend au moins des fonctions du système SGC 14, qui sont configurées pour gérer la connectivité entre un drone 10 et son entité de contrôle 11. Pour un réseau 5G, les fonctions ou entités du système SGC 14 peuvent être :

- uniquement dédiées à la gestion des drones et de leurs entités de contrôle, comme par exemple, une entité UFES (ou « UAV Flight Enablement Subsystem », en anglais) ;

- communes à la gestion de tout type d’utilisateur, qu’il s’agisse de drones, d’entités de contrôle ou de terminaux utilisateurs ou UE (de l’anglais, « User Equipment ») « classiques » terrestres du réseau mobile, comme par exemple les équipements de gestion de sessions de type SMF (de l’anglais, « Session Management Function »), de gestion de l’accès et de la mobilité de type AMF (de l’anglais, « Access and Mobility Managmenent Function »), de gestion des données utilisateur de type UPF (de l’anglais, « User Plane Fonction ») ou encore de gestion du profil utilisateur (abonnement, droits, …), de type UDM (de l’anglais, « Unified Data Management »), qui sauvegarde ces profils dans une base de données UDR ((de l’anglais, « Unified Data Repository »)

Selon l’invention, le système S comprend un dispositif 100 de gestion d’une position d’un véhicule télé-contrôlé par rapport à une entité de contrôle dans un réseau de communication, ladite entité étant apte à surveiller le déplacement d’un véhicule télé-contrôlé (UAV 10), dit drone, ledit drone étant contrôlé par une entité de contrôle UAVC 11 par l’intermédiaire d’un flux de données de contrôle transmis au sein d’une communication établie entre l’entité de contrôle UAVC 11 et le drone 10 dans le réseau de communication RC. Un tel dispositif 100 de gestion est configuré pour déterminer, à au moins un instant temporel donné, notamment pendant le déplacement du drone, au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle et, lorsque le paramètre relatif à une distance n’appartient à un intervalle de valeurs autorisées pour un mode de pilotage donné, appliquer au moins une règle de restriction de déplacement du drone.

Le dispositif 100 met ainsi en œuvre le procédé de gestion d’une position d’un drone selon l’invention qui sera détaillé ci-après en relation avec la .

Dans l’exemple de réalisation de la , le dispositif 100 est intégré dans le système SGC 14.

Alternativement, le dispositif 100 peut être indépendant du système 14, mais connecté à celui-ci par une liaison quelconque, filaire ou non. Le dispositif 100 comprend aussi une mémoire M1, dans laquelle il stocke par exemple l’intervalle de valeurs autorisées, un modèle de classification du voisinage de l’entité de contrôle à utiliser pour le couple drone – entité de contrôle considéré, ainsi que les mesures ou règles restrictives associées aux différentes zones géographiques définies par ce modèle. Avantageusement, il comprend au moins une interface E/R de communication avec le réseau RC.

Le système S de gestion des drones selon l’invention comprend aussi le système UTM/USS 16 de gestion du trafic de drones, connecté au réseau de télécommunications RC.

Selon une variante d’implémentation de l’invention, le dispositif 100 de gestion d’une position d’un drone par rapport à son entité de contrôle, est intégré au système UTM/USS 16.

Le système S comprend également le véhicule télé contrôlé ou drone 10 et l’entité de contrôle 11, lesquels sont par exemple chacun connectés au réseau RC

Ainsi, dans une première implémentation, on suppose que le drone 10, de type « Networked UAV », s’est attaché à un équipement d’accès cellulaire, tel que la station de base BS1, au réseau de télécommunication mobile RC. On suppose que l’entité de contrôle 11, de type « Networked UAVC », s’est attachée également à un équipement d’accès cellulaire, tel que la station de base BS2, au réseau de télécommunication mobile RC. Sans perte de généralité, la station de base BS2 peut être la même que la station de base BS1. Dans une deuxième implémentation, l’entité de contrôle 11, de type « Cloud UAVC », est connectée au réseau d’interconnexion DN par un équipement d’accès WiFi ou x-DSL, et accède au réseau de télécommunications RC via une entité UPF.

Quelle que soit l’implémentation retenue, un premier service de connectivité est établi entre le drone 10 et l’entité de contrôle 11, via les entités du réseau de télécommunication RC, et éventuellement via les entités du réseau DN, et sous le contrôle du système 14 de gestion de la connectivité de systèmes télé-contrôlés SGC, par exemple pour la vérification des autorisations.

Dans certains cas, le ou les canaux de transmission établis depuis le drone 10 peuvent supporter des sessions de communication supplémentaires, dites sessions de données, au travers desquelles le drone échange en outre des données avec l’entité de contrôle 11 ou tout autre équipement avec lequel le drone 10 a besoin d’échanger des données pour remplir sa mission, par exemple des photos, des vidéos ou des données collectées par des capteurs embarqués sur le drone 10.

En référence à la ,on présente désormais les différentes étapes d’un procédé de gestion d’une position d’un drone par rapport à son entité de contrôle selon un premier mode de réalisation de l’invention.

Dans ce qui suit, on décrit une phase préparatoire au déplacement ou vol du drone, une phase de vol proprement dite et une phase postérieure à l’atterrissage (ou à la fin du déplacement).

Selon ce premier mode de réalisation de l’invention, le procédé de gestion est mis en œuvre par le dispositif 100 intégré au système SGC 14 de gestion de la connectivité des drones du réseau mobile RC.

Avant le vol

Ainsi, dans une étape préalable E0, avant le vol, le drone 10 et, selon ce premier mode de réalisation, l’entité de contrôle 11, sont authentifiés et enregistrés (requête RQ_REG) auprès du réseau de télécommunication RC selon les procédures communes aux utilisateurs terrestres, qui mettent en jeu les différents équipements du réseau d’accès et de cœur (station de base, AMF, UDM, etc). Puis, le drone 10 et l’entité de contrôle 11 sont enregistrés auprès du système SGC 14 de gestion de la connectivité de systèmes télé-contrôlés. Les procédures relatives à ces enregistrements spécifiques sont décrites en particulier dans le document 3GPP TR 23.754.

Dans cet exemple de mise en œuvre, en E1, le drone 10 et l’entité de contrôle sont chacun identifiés et authentifiés (requête RQ_ID), puis les deux s’associent en E2 (en anglais, « paired »), (requête RQ_ASS).

L’entité de contrôle 11 possède une autorisation de contrôle AC11 du drone 10 délivrée par le système UTM/USS 16 de gestion de trafic de drones. Cette autorisation de contrôle AC11 a par exemple été préalablement reçue par le système SGC et elle est stockée dans l’équipement 14 en association avec un identifiant de l’entité de contrôle 11. Elle peut aussi être contenue dans une des requêtes d’association reçues du drone UAV 10 et de l’entité de contrôle UAVC 11. Elle est vérifiée lors de l’étape E2.

Selon l’invention, le dispositif 100 obtient en E3 une information de marquage IM de l’association entre le drone 10 et l’entité de contrôle 11, comprenant un mode de pilotage donné, par exemple « VLOS ». Avantageusement, le marquage comprend l’enregistrement de l’information de marquage dans une entrée d’une table de données, en lien avec l’identifiant du drone 10 et l’identifiant de l’entité de contrôle 11, et / ou l’identifiant de leur association. On note que le marquage IM de l’association drone UAV 10 – entité de contrôle UAVC 11 peut être « stocké » dans différentes entités : dans le réseau de communication RC, par exemple dans l’UDM ou l’AMF et/ou dans le système SGC 14, par exemple dans l’UFES ou une AF, et/ou encore dans le système UTM/USS 16, en dehors du réseau mobile RC. Ces informations de marquage peuvent également faire partie des différents blocs d’information utilisés pour configurer les canaux de communications, par exemple les sessions PDU, le bloc d’informations relatif au contexte de l’UE (ou « UE context », en anglais) ou celui lié à la souscription de l’UE (ou « UE subscription, en anglais), etc.

On note que le marquage permet d’identifier les situations suivantes :
- Le fabricant du drone indique que le drone 10 doit être piloté absolument en VLoS (par exemple du fait de son poids, sa taille, sa fabrication, les caractéristiques de sa batterie, etc) ;
L’entité de contrôle 11 n’est pas accréditée pour piloter en mode BVLoS. Elle doit donc être marquée en VLoS ;
les Autorités Aériennes ont prononcé une interdiction de vol en mode BVLoS, par exemple pour des raisons d’environnement (zone peuplée, zone de survol interdite), de créneau horaire (vol pendant une heure de pointe), etc.

Comme illustré par la , selon une première option, cette information de marquage IM est obtenue dans une requête de marquage RQM « VLOS » en provenance du drone 10. Par exemple, le drone 10 en question n’a pas été conçu pour des missions de types BVLoS et il doit uniquement opérer en mode VLoS, même si son pilote est accrédité pour les vols BVLoS. Réciproquement, et selon une deuxième option, cette information de marquage IM est obtenue dans une requête de marquage RQM « VLOS » (représentée en pointillés) en provenance de l’entité de contrôle 11, par exemple, parce que le pilote n’a pas les accréditations nécessaires pour une missions BVLoS. Selon une troisième option, l’information de marquage IM est obtenue dans une requête RQM en provenance de l’UTM / USS 16 (représentée en pointillés) lors de l’association entre le drone 10 et l’entité de contrôle 11, par exemple parce que la mission a été déclarée comme étant de type VLOS. Selon une quatrième option (non représentée), l’information de marquage IM est obtenue dans une requête RQM en provenance du système SGC 14 parce que les missions de type BVLOS ne sont pas autorisées dans la zone géographique où le drone 10 s’est attaché. Selon une cinquième option, cette requête provient plus généralement de toute entité accréditée, par exemple les Forces de l’Ordre, qui pourraient avoir à prendre le contrôle du drone 10 via leur propre système de gestion des drones, sans avoir à passer par l’UTM/USS 16 utilisée par l’entité de gestion 15.

Cette requête RQM déclare l’association entre le drone 10 et l’entité de contrôle 11 comme soumise au mode de pilotage spécifié par l’information de marquage IM. Par exemple, l’information de marquage prend une valeur « VLOS », indiquant que tout vol de ce drone 10 contrôlé par cette entité de contrôle 11 est soumis à l’obligation d’être opéré selon le mode de pilotage en ligne de vue directe « VLOS ».

Selon une implémentation particulière de l’invention, cette requête de marquage RQM est comprise dans la requête d’association RQ_ASS émise par l’entité de contrôle 11 par exemple. Elle est donc intégrée à la procédure d’association. Un avantage de greffer ce marquage à la procédure d’association est de réutiliser les échanges de messages déjà prévus entre les équipements/entités impliqués dans celle de l’association. Dans ce cas, le marquage est déclenché par un élément / une fonction du système SGC 14 de gestion de la connectivité des systèmes télé-contrôlés lui-même, lors de l’association entre le drone UAV 10 et l’entité de contrôle UAVC 11 en E2, par exemple lors de la notification par le système de gestion du trafic des drones UTM de l’autorisation d’association.

Dans le cas où rien ne permettrait de déterminer lequel parmi l’identifiant du drone 10 et celui de l’entité de contrôle 11 correspond à l’entité de contrôle, la réception de cette requête RQM déclencherait en E31 l’émission d’une requête d’identification RQ_I de l’entité de contrôle à destination du système UTM/USS 16 de gestion du trafic des drones. C’est le cas par exemple lorsque la carte SIM insérée dans le drone UAV 10 ne permet pas a priori de la différencier de celle d’un UE classique (non-drone). Une réponse RP_I comprenant un identifiant de l’entité de contrôle serait alors reçue en E32 et l’identifiant obtenu pour l’entité de contrôle 11 est stocké en mémoire. Dans un autre mode de réalisation, la requête RQ_I est envoyée à la fois au drone 10 et à l’entité de contrôle 11, et cette dernière envoie la réponse RP_I.

Dans une étape E33, le dispositif 100 notifie l’entité de contrôle 11, le drone 10 et le système UTM de gestion du trafic des drones du marquage effectif de leur association en mode de pilotage « VLOS ».

Dans une étape optionnelle E4, des informations relatives à une zone ZD de déplacement ou survol déclarée par l’entité de contrôle UAVC 11 ou l’entité de gestion 15 d’une flotte de drones au système UTM/USS 16 de gestion des drones sont reçues de l’UTM/USS 16 par le système SGC 14 de gestion de la connectivité de systèmes télé-contrôlés. Ces informations comprennent par exemple un ensemble de coordonnées GPS délimitant la zone de déplacement déclarée ZD. On note que cette zone ZD a préalablement été vérifiée et autorisée par le système UTM/USS 16, qui a notamment exclu les zones interdites de survol (en anglais, « no-fly zones »). Les procédures relatives à cette étape E4 sont décrites, par exemple, dans les points 11 et 12 du document 3GPP TR 23.754.

Au cours d’une étape E5, un modèle MC1 de classification d’un voisinage géographique de l’entité de contrôle UAVC 11 est obtenu, par exemple d’une mémoire où il est stocké en association avec un identifiant de l’entité de contrôle 11.

Selon l’invention, ce modèle découpe le voisinage de l’entité de contrôle en plusieurs zones distinctes et associe à chacune de ces zones distinctes un ensemble de mesures/règle de restriction de déplacement à appliquer au système UAVS (drone UAV 10 – entité de contrôle UAVC 11) pendant le vol, en fonction de la position du drone UAV 10 par rapport à son entité de contrôle UAVC 11.

En relation avec la ,on a représenté un exemple de modèle de classification MC1 à N niveaux, avec N égal à 3, qui comprend les classes suivantes :

- une première zone Z_VLOSest définie par la position de l’UAVC et une distance maximale D_visu. Cette distance D_visucorrespond à une distance donnée, par exemple fixée par le système UTM de gestion du trafic des drones, qui correspond à la distance maximale jusqu’à laquelle un drone est en ligne de vue directe avec son pilote. Cette distance est typiquement fixée à 300 m. En l’absence de déclaration d’une zone de survol ZD pour le drone 10, cette première zone ZVLOS constitue une zone autorisée qui n’est a priori soumise à aucune mesure de restriction de vol ;
- une deuxième zone, dite de tolérance ZT (hachurée avec un motif à vagues sur la ), située autour de la première zone Z_VLOSet par exemple définie par un ensemble de coordonnées GPS. Ces coordonnées peuvent, par exemple, correspondre à un disque de rayon DT, auquel est appliquée une marge d’erreur plus ou moins grande pour prendre en compte les imprécisions sur la localisation ou le positionnement des stations de base auxquelles le drone 10 s’attache. Le rayon de tolérance DT peut être défini par défaut, par exemple égal à la portée radio d’un signal Wi-Fi, typiquement, environ 1 à 2km en espace ouvert. Au sein d’une telle zone, le drone 10 se trouve nécessairement à une distance de son entité de contrôle UAVC 11 qui est supérieure à la distance D_visu. Le principe de pilotage en ligne de vue directe n’étant plus respecté, des mesures de restriction s’appliquent. Par exemple, une notification d’alerte de sortie de zone autorisée ou un nouveau plan de vol sont transmis à l’entité de contrôle 11. Les restrictions peuvent également concerner les autres canaux de communication relatifs au drone 10, et entraîner, par exemple, le maintien du flux de données de contrôle sans restriction, mais la coupure du flux de données utiles de type Payload ;
- enfin, une troisième zone Z_RTqui comprend le reste du territoire. Cette zone est interdite de survol. Avantageusement, une règle de gestion est de rendre impossible tout attachement du drone 10 avec les stations de base situées dans cette zone. Une règle de gestion associée est le déclenchement d’une procédure d’atterrissage d’urgence ou de retour à la maison (de l’anglais, « return home ») pour un drone qui se serait aventuré dans cette zone Z_T.

Dans le cas où une zone de déplacement ZD a été déclarée en E4, elle est aussi prise en compte pour définir une zone supplémentaire, dite zone autorisée ZA, comme l’intersection de la première zone ZVLOS et la zone de survol déclarée ZD. La zone autorisée ZA devient la seule zone à l’intérieur de laquelle le drone 10 n’est soumis à aucune restriction de déplacement. Similairement, dans un exemple de mise en œuvre du modèle de classification MC1, une ou plusieurs zones ZI1 à ZI7 peuvent être définies chacune par la zone de couverture d’une station de base. Par exemple, dans ces zones, l’Agence Nationale des Fréquences ANFR a prononcé une interdiction d’utiliser une bande de fréquences donnée et la règle de gestion associée à ces zones comprend cette interdiction. On comprend que les mesures restrictives peuvent être incrémentales ou additives. Par exemple, la zone autorisée sans restriction ZA est donc définie comme l’intersection de la première zone ZVLOS et de la zone de survol déclarée ZD, mais excluant les zones ZI1 à ZI7. Au sein d’une zone ZIi incluse dans la zone ZA, les mesures de restrictions liées, par exemple, à l’interdiction d’utiliser une bande de fréquences donnée s’appliquent. Les mesures de restrictions à appliquer dans la zone de tolérance ZT dépendent alors de l’appartenance du drone 10 à l’une des zones ZI1 à ZI7, les mesures restrictives des deux zones ZT et Zij (j compris entre 1 et 7) pouvant s’appliquer simultanément. Enfin, les mesures de restrictions peuvent, par exemple, rester identiques pour la zone ZRT.

Dans un exemple d’implémentation de l’invention, le modèle de classification mis en œuvre peut être un modèle par défaut stocké dans le système 14 de gestion de la connectivité des dispositifs télé-contrôlés ou dans le dispositif 100, ET par exemple limité aux 3 zones, comprenant la zone Z_VLOS, la zone ZT et la zone ZRT.

Dans encore un autre exemple d’implémentation de l’invention, le modèle de classification et les règles / restrictions associées sont déclarés par le pilote 11 et/ou le système UTM/USS 16 de gestion du trafic des drones et/ou toute autre entité accréditée. Par exemple, cette déclaration est mise en œuvre via une interface de programmation de type API (de l’anglais, « Application Programming interface »). Si plusieurs entités de contrôle UAVC sont déclarées (par exemple : un pilote humain, un pilote automatique, un pilote des autorités aériennes, un pilote BVLoS, etc.), une classification spécifique peut être définie pour chaque pilote. Dans ce cas, le procédé de gestion met en œuvre dans une phase préalable aux étapes précédemment décrites, typiquement lors du traitement d’une demande d’autorisation de vol reçue par le système UTM quelques jours avant la date effective du vol, les étapes suivantes :
- le dispositif 100 propose une configuration par défaut au système UTM/USS 16 de gestion du trafic des drones. Il s’agit par exemple d’un simple paramétrage pour la zone VLoS (D_visu= 300m). Ici, le système UTM/USS 16 répond par une demande de modification de cette proposition pour ajouter / supprimer des niveaux ou pour ajouter / supprimer / modifier les restrictions de ces niveaux ou modifier les règles de gestion du drone associées à ces niveaux ;
- le système vérifie les autorisations de modifications / ajouts / suppressions. En effet, le demandeur peut ne pas être autorisé à modifier certains paramétrages (ex : demander D_visu= 3km). Les configurations possibles pour les règles et restrictions peuvent être proposées parmi une liste prédéfinie et validée par le dispositif 100. Cette validation préalable permet d’éviter que le système UTM/USS 16 n’obtienne l’instauration de mesures restrictives qui seraient difficiles à mettre en œuvre techniquement pour le système SGC 14 et le réseau de communication RC ;
Il peut s’agir à la fois d’une validation technique (certaines configurations peuvent n’être disponibles que sous certaines conditions) et légale (respect des règlementations aériennes), éventuellement financière (surcoût en cas de services spéciaux, par exemple, une demande de ressources supplémentaires à l’intérieur de la zone VLoS). Les différents niveaux (et règles / restrictions associées) peuvent aussi être priorisés les uns par rapport aux autres. Par exemple, le respect des règlementations aériennes prime sur les services additionnels par exemple liés à une demande de ressources spécifiques à la mission du drone. Une fois validée, cette classification peut être définie et stockée dans une mémoire du système 14 SGC, par exemple du dispositif 100. En E54 le modèle de classification validé MC1 est confirmé à l’UTM/USS 16 et à l’entité de contrôle UAVC 11.

Une fois le modèle de classification MC1 de la zone de déplacement configuré, avec ses mesures de restrictions associées, la phase de préparation se termine et la mission du drone, autrement dit son déplacement ou vol peut démarrer.

Pendant le déplacement ou vol

Selon l’invention, le procédé de gestion détermine à différents instants temporels pendant le vol un paramètre relatif à une distance entre le drone 10 et son entité de contrôle 11 et il vérifie que la valeur de ce paramètre appartient à un intervalle de valeurs autorisé pour le mode de pilotage qui marque l’association drone 10 entité de contrôle 11. Il peut s’agir d’un seul instant temporel si le drone est position stationnaire par exemple.

Dans l’exemple de la· , ce paramètre relatif à une distance comprend une mesure de distance physique calculée à partir des positions géographiques du drone 10 et de son entité de contrôle 11 à un instant temporel donné. Plus précisément, le dispositif 100 effectue un double suivi (en temps réel, périodiquement ou sur requête) des positions géographiques de l’entité de contrôle UAVC 11 et du drone UAV 10. A partir de la position géographique de l’entité de contrôle UAVC 11, il recalcule les zones définies par le modèle de classification du voisinage déterminé pendant la préparation du vol, puis il détermine dans quelle zone se situe le drone UAV 10, comme détaillé ci-après, en relation avec la .

Au cours d’une étape E6, la position géographique POS_10 du drone UAV 10 et celle POS_11 de l’entité de contrôle UAVC 11 sont récupérées à un instant temporel donné. Il peut s’agir d’un échange requête / réponse entre le dispositif 100 et l’UAV 10 / UAVC 11, d’un envoi périodique par le drone 10 et son entité de contrôle 11 de leurs positions et / ou d’un calcul sur la base d’autres solutions de géolocalisation.

Par exemple, l’obtention des positions géographiques du drone 10, mais aussi de son entité de contrôle 11 dans le cas d’un pilote en réseau (« Networked UAVC »), peut être réalisée, via les solutions 14 ou 15 du document 3GPP TR 23.754 déjà cité.

Selon un autre exemple, les positions géographiques du drone 10 et de l’entité de contrôle 11, notamment pour un pilote de type « Cloud UAVC », sont obtenues, sur requête au système UTM/USS 16.

En E7, le dispositif 100 applique la classification déterminée en E5 en la centrant sur la position géographique de l’entité de contrôle UAVC 11 qui vient d’être obtenue pour l’instant temporel donné et en déduit une délimitation des différentes zones définies par cette classification. En particulier, il détermine une délimitation de la zone ZVLOS et si une zone de survol ZD a été déclarée, celle de la zone ZA autorisée, qui est l’intersection de la zone ZVLOS et de la zone de survol déclarée ZD. On note que généralement l’entité de contrôle UAVC 11 ne se déplace pas ou peu. Il ne sera donc pas nécessaire de mettre à jour la classification du voisinage de l’entité de contrôle 11 à chaque nouveau relevé de positions géographiques.

Au cours d’une étape E8, le dispositif de gestion 100 utilise ensuite la position géographique du drone 10 pour l’affecter à une des zones de la classification. En l’absence de zone de survol déclarée ZD, il lui suffit de calculer une distance entre l’entité de contrôle UAVC 11 et le drone UAV 10 pour déterminer si le drone est bien situé à l’intérieur de la zone ZVLOS autorisée.

On note que dans cet exemple de réalisation de l’invention, le procédé de gestion peut être avantageusement mis en œuvre par une ou plusieurs fonctions du système SGC 14 configurée pour obtenir les positions géographiques du drone 10 et de son entité de contrôle 11. Il s’agit par exemple de la fonction UAVF décrite par la solution #4 du document 3GPP TR 23.754, de l’équipement ou entité UFES (de l’anglais, « UAV Flight Enablement Subsystem »).

Lorsque le dispositif 100 établit que le drone 10 est situé dans la zone VLOS ou la zone autorisée ZA, il se met en attente d’un nouvel événement déclencheur d’un suivi du couple drone 10 – entité de contrôle 11, par exemple l’occurrence d’un nouvel instant de suivi à l’issue d’une période temporelle donnée ou la réception d’une requête de suivi émanant de l’UTM/USS 16 ou du réseau RC, par exemple lors de l’attachement du drone 10 à une nouvelle station de base, ou encore l’obtention de nouvelles positions géographiques.

Au contraire, lorsqu’il établit que le drone 10 n’est pas dans la zone autorisée ZA, le dispositif 100 récupère en E9 la ou les règles de gestion du drone associées par le modèle de classification à la zone non autorisée, par exemple ZT ou ZIj à laquelle le drone 10 a été affecté, puis il déclenche en E10 l’application de la règle de gestion récupérée.

Les règles de gestion en question peuvent comprendre, par exemple :
- l’envoi d’une notification ou d’une alerte à l’entité de contrôle UAVC 11 et/ou au système de gestion du trafic des drones UTM ou à toute autre entité accréditée. Un tel envoi peut être réitéré de façon périodique tant que le drone UAV 10 se trouve dans la zone géographique concernée ;
- l’envoi d’une nouvelle position GPS de destination (ou « waypoint », en anglais), d’une nouvelle trajectoire (c’est-à-dire d’un ensemble de positions GPS ou de plusieurs « waypoints ») ou d’un message de retour à la maison (« return-to-home ») comprenant au moins la position GPS de la maison ou du point de décollage du drone 10 ou de la position du pilote 11 ;
- la mise en application d’une interdiction d’attachement du drone UAV 10 à un ensemble donné de stations de base situées dans la zone géographique concernée ;
- l’envoi d’une commande de reprise de contrôle du drone UAV 10 par les Autorités Aériennes ou toute autre entité accrédité, par exemple les Forces de l’Ordre (changement de pilote par la mise en œuvre d’une procédure de transfert de contrôle) ;
- le déclenchement d’une procédure de dégradation contrôlée et progressive de la qualité de service ou QoS (de l’anglais, « Quality of Service ») de la communication établie entre l’entité de contrôle 11 et le drone 10. On désigne ici par qualité de service toute mesure de performance du réseau ou mesure de capacité à véhiculer un flux dans de bonnes conditions, généralement définies à l’avance. Il peut s’agir, par exemple, d’un débit minimum, d’une plage de latence, d’un niveau de disponibilité des réseaux. Le respect d’un certain niveau de QoS est mis en œuvre par un ensemble de technologies dédiées au contrôle de l’allocation des ressources du réseau entre les différents utilisateurs. La gestion de la qualité de service s’appuie sur des mesures quantitatives de paramètres de performances. Il s’agit ici par exemple de dégrader la qualité du signal sur le canal de transmission radio établi entre le drone 10 et la station de base à laquelle il est attaché, pour mimer les caractéristiques d’une liaison point-à-point (de type Wi- Fi). En effet, un pilote est habitué à associer une dégradation de la qualité du signal, par exemple du contrôle vidéo, à l’approche des limites de la zone de portée radio. Avantageusement, cette dégradation mise en œuvre par l’invention est fonction de la distance calculée entre le drone 10 et l’entité de contrôle 11. Par exemple, plus cette distance augmente, plus la qualité de signal perçue au niveau de l’entité de contrôle UAVC 11 ou du drone 10 est dégradée par le dispositif 100 (ex : contrôle vidéo dégradé). Cette dégradation peut être obtenue par divers moyens, par exemple, en ajoutant de la latence au niveau de la station de base servant le drone UAV 10 et / ou l’entité de contrôle UAVC 11, ou au niveau d’un autre équipement du réseau RC; ou bien en diminuant la quantité de ressources radio allouées au drone UAV 10 et / ou à l’entité de contrôle UAVC 11. A cet égard, on note que cette dégradation volontaire peut être contrainte par des obligations légales imposées par les Autorités Aériennes en matière de sécurité aérienne. Autrement dit, selon cet exemple, il n’est pas autorisé de dégrader la qualité de service sur le canal de transmission au-delà d’un certain seuil. En outre, la dégradation peut s’appliquer à l’ensemble des flux issus du drone, flux de données comme flux de contrôle, ou bien à une partie seulement de ces flux (par exemple seulement les flux de données ou payload),
- l’envoi au drone 10 d’une commande de passage en mode économie d’énergie (ex : diminution de la qualité du streaming vidéo) pour sanctionner le fait de voler dans une zone non autorisée.

On comprend que la mise en application de ces mesures restrictives peut nécessiter la contribution de plusieurs entités ou fonctions du système SCG 14 et plus généralement du réseau RC. Certaines en particulier peuvent impliquer une modification de paramètres réseaux de la session de communication établie entre le drone 10 et l’entité de contrôle 11 dans le réseau RC. C’est le cas notamment pour la mesure de dégradation de la QoS, qui impacte non seulement la ou les stations de base auxquelles sont attachés le drone 10 et son entité de contrôle 11 mais aussi possiblement des équipements du réseau RC en charge de la gestion de la QoS.

En relation avec la , on détaille désormais où il est décidé de transférer le contrôle du drone 10 à une autre entité de contrôle que l’entité de contrôle UAV 11. Par exemple, on se trouve dans une situation selon laquelle plusieurs relevés successifs de positions ont conduit à déterminer que le drone 10 se trouvait dans une zone non autorisée et les règles de gestion peu contraignantes mises en application jusque-là, de type notification d’alerte, n’ont pas eu l’effet escompté de faire revenir le drone 10 en zone autorisée. Bien sûr, le transfert de contrôle peut aussi être décidé directement, sans notification ou autre règle de gestion préalable. Il en résulte que le drone 10 s’éloigne de plus en plus de la zone autorisée ZA et vient de franchir une limite de la zone ZT. Ce franchissement constitue un exemple d’événement déclencheur d’une décision par le dispositif 100 de gestion selon l’invention de prendre le contrôle du drone 10. On suppose que cette entité de contrôle 12 a établi une session de communication PDU avec le système de connectivité SGC 14.

Partant du principe que les autorisations de contrôle d’un drone sont délivrées par le système UTM/USS 16 de gestion de trafic de drones, il est nécessaire que l’entité de contrôle 12 soit préalablement autorisée par le système de gestion du trafic de drones UTM/USS 16 à contrôler le drone 10. Si besoin, une vérification est mise en œuvre par l’envoi d’une requête au système UTM. Dans une variante d’implémentation, l’autre entité de contrôle 12 a déjà été déclarée par exemple par l’UTM via l’API précédemment décrite.

Selon l’invention, il est aussi nécessaire que l’entité de contrôle déclare au préalable un modèle de classification et qu’il soit validé par les Autorités Aériennes.

Une fois la vérification de l’autorisation effectuée auprès de l’UTM, le transfert de contrôle est opéré par le système SGC. En particulier, l’association actuellement stockée dans le système SGC 14 est mise à jour par l’enregistrement d’une nouvelle association entre le drone 12 et l’autre entité de contrôle 12.

Avantageusement, le procédé de gestion selon l’invention qui vient d’être décrit s’applique à ce nouveau système UAVS formé du drone 10 et de l’entité de contrôle 12. Selon l’invention, la nouvelle association est marquée par un mode de pilotage IM qui peut être par exemple le mode « VLOS » ou un autre mode de pilotage. En particulier, lorsque la deuxième entité de contrôle est un pilote automatique, par exemple intégré dans le système UTM/USS 16 ou hébergé dans le réseau mobile RC, comme dans une architecture de type MEC (en anglais, « Multi-access Edge Computing ») où un environnement de service informatique et des ressources de calcul sont déportées à la périphérie du réseau, par exemple à proximité d’une station de base. Par nature, un tel pilote automatique n’est pas soumis à des contraintes de pilotage en ligne de vue directe qui n’ont pas de sens dans ce cas, mais plutôt à des contraintes de latence maximale, qui définissent un mode de pilotage « LAT » et un modèle de classification correspondant. Cette latence maximale, par exemple égale à 3 ms, est prise en considération, en lieu et place de la distance D_visu, pour définir une première zone ZLAT autorisée.

Selon une implémentation de l’invention, le transfert de contrôle déclenche donc en E5 la modification du modèle de classification à utiliser.

Selon un premier exemple, un deuxième modèle de classification a été préalablement déclaré par l’UTM/USS 16 ou par toute autre entité accréditée pour l’entité de contrôle 12 au dispositif 100 et ce deuxième modèle est directement pris en compte à la place du premier pour mettre en œuvre l’affectation d’une zone au drone 10 selon l’invention. Il en résulte que les différentes zones sont recalculées.

Dans le cas qui vient d’être présenté, la modification du modèle de classification est déclenchée par le transfert de contrôle. Plus généralement, on note que selon l’invention, l’UAV 10, l’UAVC 12, le système SCG 14, l’UTM / USS 16 ou toute autre entité accréditée peuvent à tout moment émettre une requête de changement de configuration de la classification ou la modification des règles / restrictions appliquées.

De même que décrit précédemment, une fois que toutes les vérifications préalables ont été effectuées avec succès, le système SGC connecte le troisième canal de communication de l’entité de contrôle 12 à celle du drone 10 et l’entité de contrôle 12 peut effectivement contrôler le déplacement du drone 10.

Autrement dit, les étapes E6-E10 de suivi de leurs positions sont mises en œuvre ainsi que l’affectation d’une zone au drone 10 en fonction de sa position dans un voisinage de l’entité de contrôle 12 découpé en zones définies par un modèle de classification prédéterminé.

Les étapes E6 à E10 sont répétées de manière périodique, selon une période qui peut varier de quelques millisecondes à quelques secondes selon le type de déplacement du drone et le type de service supporté par le drone, , par exemple toutes les 20 secondes pour un drone à vitesse de déplacement modérée ou toutes les secondes pour un drone se déplaçant rapidement, ou sur requête jusqu’à l’atterrissage ou jusqu’à un positionnement du drone par exemple à proximité immédiate de l’entité de contrôle 12.

Après le vol

Comme illustré par les figures 5 et 6, au cours d’une étape E11, un rapport d’événement LOG (de l’anglais, « log ») est constitué par le dispositif 100 et envoyé aux entités intéressées, telles que par exemple le pilote, ou l’opérateur de drone, l’UTM /USS, les autorités aériennes, etc. Il comprend par exemple les positions géographiques successivement relevées pendant le vol et les zones géographiques du modèle de classification affectés au drone 10 à chaque instant temporel et, le cas échéant, les mesures restrictives décidées. De la sorte, les différentes parties peuvent prendre connaissance des évènements, voire incidents, survenus pendant le vol.

Le mode de réalisation qui vient d’être détaillé en relation avec les figures 3, 5 et 6 décrit un dispositif de gestion 100 intégré dans le système SGC 14 ou dans le réseau RC. L’invention n’est toutefois pas limitée à cet exemple. En effet, le dispositif 100 peut de façon alternative être intégré au système UTM/USS 16 de gestion du trafic des drones, qui est connecté au réseau mobile RC et interagit avec le système SGC 14. Dans ce cas, les positions géographiques du drone 10 et de l’entité de contrôle 11 peuvent être obtenues du système SGC 14, du réseau de RC, mais la détermination de la mesure de distance, la vérification basée sur cette distance que le drone évolue dans une zone autorisée et si ce n’est pas le cas l’envoi au réseau RC de requêtes demandant la mise en œuvre de règles de gestion du drone, sont mises en œuvre dans le système UTM/USS 16.

On présente désormais, en relation avec la , un autre mode de réalisation de l’invention, selon lequel l’entité de contrôle 11 est un pilote automatique 11 intégré au réseau RC, par exemple grâce à une architecture de type MEC (en anglais, « Multi-access Edge Computing »). On considère par exemple un service de livraison par drones de produits à destination de consommateurs finaux. L’entité de contrôle / le pilote automatique 11 est hébergé dans une entité MEC1 située à proximité de la station de base BS1, par exemple sur le même site physique. Une telle entité MEC1 est configurée pour mettre à disposition des clients du réseau, ici une société de livraison, un environnement de type cloud, ainsi que des ressources de calcul et d’analyse importantes permettant l’exécution de services divers, ici le pilotage automatique du drone 10 selon les règles de gestion de la flotte de drones de la société de livraison. Le fait que le pilote automatique soit intégré à l’entité MEC1 lui permet de bénéficier d’une latence beaucoup plus faible que si l’environnement informatique et les ressources de calculs étaient situés dans un cloud centralisé, par exemple physiquement hébergé au niveau du siège social de la société de livraison.

Selon cet exemple de réalisation, le dispositif 100 de gestion du système UAVS drone 10 – pilote automatique 11 est par exemple intégré dans le réseau RC, au sein du système SGC 14. Les étapes E0-E11 précédemment décrites s’appliquent.

On suppose qu’une zone de survol ZD a préalablement été déclarée à l’UTM/USS 16 en fonction de la ou les adresses de livraison du ou des produits transportés par le drone 10. On suppose aussi que l’association entre le drone 10 et le pilote automatique 11 est marquée à l’aide du mode de pilotage « LAT » précédemment décrit.

Avantageusement, selon ce deuxième mode de réalisation, deux paramètres de distance distincts peuvent être pris en considération et déterminés en E6. Le premier correspond à la mesure de distance physique précédemment décrite, basée sur un double suivi des positions géographiques du système UAVS pendant le vol et calculée à chaque nouveau relevé de positions, pour vérifier que le drone 10 ne sort pas de la zone de survol ZD déclarée. Le deuxième est une mesure de latence du flux de données de contrôle dans la communication entre le drone 10 et le pilote automatique 11 ou entre le drone 10 et un équipement du réseau RC. Cette mesure de latence est utilisée pour vérifier que le drone 10 ne sort pas de la première zone ZLAT pour laquelle la latence est inférieure à un seuil ThLat par exemple égal à 3 ms. Elle peut être mesurée par exemple par le pilote automatique directement, ou bien au niveau d’un équipement du réseau RC. Elle est avantageusement obtenue à plusieurs reprises pendant le vol, régulièrement ou non, sur requête du dispositif 100 ou du système SGC 14, ou non. En effet, la latence est susceptible d’augmenter avec l’éloignement du drone 10 de la station de base BS1 ou lorsque le drone 10 se détache de la station de base BS1 pour s’attacher à la station de base BS2 (du fait notamment de la topologie du réseau, le flux de contrôle peut traverser plus d’équipements réseaux, ce qui peut augmenter la latence).

On comprend que dans ce cas, le positionnement du pilote automatique 11 dans l’entité MEC1 devient moins pertinent, notamment par rapport à l’intérêt de déployer un pilote automatique au plus près de la station d’accès à laquelle se connecte le drone 10 pour réduire la latence notamment, et le contrôle qu’il opère sur le drone 10 est donc moins performant. Lorsque la latence mesurée à un instant donné excède la valeur de seuil donnée ThLat, alors il est décidé d’opérer un transfert de contrôle du drone 10 vers un deuxième pilote automatique 12 situé dans une entité MEC2 à proximité immédiate de la station de base BS2, plus proche du drone 10. Cette action aura pour effet de diminuer significativement la latence et donc d’améliorer la qualité de la communication entre le drone et le pilote automatique 12 et ainsi de garantir que la mission du drone 10 s’effectue dans des conditions de sécurité et de contrôle optimales. Ce transfert de contrôle du drone 10 vers un deuxième pilote automatique 12 peut aussi être déclenché par le changement d’association de station de base (en anglais, « handover ») du drone 10.

On présente maintenant, en relation avec la , un exemple de structure matérielle d’un dispositif 100 de gestion d’une position d’un véhicule télé-contrôlé dit drone, par rapport à par une entité de contrôle, ladite entité de contrôle étant configurée pour contrôler le drone par l’intermédiaire d’un flux de données de contrôle transmis de façon indirecte au sein d’une communication établie entre l’entité de contrôle et le drone par l’intermédiaire d’un réseau de communication, ledit dispositif comprenant un module de détermination d’au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle et un module d’application d’au moins une règle de gestion du drone.
Avantageusement, le dispositif 100 comprend en outre un module d’obtention d’une position géographique du drone et d’une position géographique de l’entité de contrôle, un module d’obtention d’un modèle de classification d’un voisinage de l’entité de contrôle associé au mode de pilotage donné, ledit modèle comprenant au moins une première zone, dite zone de déplacement autorisée, définie par ledit intervalle de valeurs du paramètre et une deuxième zone de déplacement non autorisée, complémentaire de la première. Il peut comprendre en outre un module d’obtention du mode de pilotage donné et de stockage en mémoire dudit mode de pilotage pour une association entre un identifiant du drone et un identifiant de l’entité de contrôle dans ledit réseau. Il peut comprendre aussi un module d’obtention d’un rapport d’événements et un module de transmission dudit rapport à une entité accréditée et/ou à l’entité de contrôle.

Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.

Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg1, représentatif des modules précités, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir, par exemple, l’information de validation du deuxième niveau de qualité de service, l’information d’identification de l’équipement serveur, etc.

La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu’il effectue les étapes du procédé de gestion d’une position d’un drone tel que détaillé ci-dessus, en relation avec les figures 3, 5, 6 et 7, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 mis en œuvre dans une ou plusieurs fonctions réseau du réseau de télécommunications RC, tel que par exemple une entité UFES ou une fonction applicative AF dédiée d’un système SGC 14 de gestion de la connectivité des dispositifs télé-contrôlés mis en œuvre dans un réseau mobile. Bien sûr, l’invention ne se limite pas à ces exemples.

L’invention qui vient d’être présentée présente de nombreux avantages. Elle propose de mettre en œuvre, dans un réseau de télécommunications mobiles une solution de gestion de la position relative d’un drone par rapport à son entité de contrôle, qui est sécurisée et efficace. En particulier, elle s’appuie sur un double suivi des positions géographiques du drone et de son entité de contrôle pour vérifier régulièrement que le drone ne s’éloigne pas trop de son pilote par rapport à des règles préalablement établies, réagir en cas de franchissement d’une limite non autorisée et informer les autorités aériennes en temps réel. Elle peut aussi prendre en considération d’autres mesures qu’une distance physique entre le drone et son pilote, comme par exemple une mesure de latence du flux de données de contrôle échangé entre eux via le réseau de communication et déclencher la mise en application de règles de gestion appropriées lorsque cette mesure de latence dépasse un seuil donné.

Claims (15)

1. Procédé de gestion d’une position d’un véhicule télé-contrôlé (UAV, 10), dit drone, par rapport à une entité de contrôle (UAVC, 11), ladite entité de contrôle étant configurée pour contrôler le drone par l’intermédiaire d’un flux de données de contrôle transmis de façon indirecte au sein d’une communication établie entre l’entité de contrôle (11) et le drone (10) par l’intermédiaire d’un réseau de communication (RC), caractérisé en ce que ledit procédé comprend :
   -pour au moins un instant temporel de la communication, la détermination (E6) d’au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle;
   - lorsque le paramètre relatif à une distance n’appartient pas à un intervalle de valeurs autorisées pour un mode de pilotage donné, l’application (E10) d’au moins une règle de gestion du drone.
2. Procédé de gestion selon la revendication 1, caractérisé en ce qu’il comprend en outre l’obtention (E6) d’une position géographique du drone et d’une position géographique de l’entité de contrôle, en ce que ledit paramètre comprend au moins une mesure de distance physique entre le drone et l’entité de contrôle déterminée à partir desdites positions géographiques et en ce que ladite au moins une règle de gestion est mise en application lorsque ladite mesure de distance dépasse une distance maximale autorisée (Dvisu).
3. Procédé de gestion selon l’une quelconque des revendications précédentes, caractérisé en ce que ledit paramètre relatif à une distance comprend au moins une mesure de latence de la communication établie entre le drone et l’entité de contrôle et en ce que ladite au moins une règle de gestion du drone est mise en application lorsque ladite mesure de latence est supérieure à une valeur de latence maximale.
4. Procédé de gestion selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend l’obtention préalable (E5) d’un modèle de classification d’un voisinage de l’entité de contrôle associé au mode de pilotage donné, ledit modèle comprenant au moins une première zone, dite zone de déplacement autorisée, définie par ledit intervalle de valeurs du paramètre et une deuxième zone de déplacement non autorisée, complémentaire de la première, et en ce que la dite au moins une règle de gestion du drone est mise en application lorsque le drone sort de la zone de déplacement autorisée.
5. Procédé de gestion selon la revendication 4, caractérisé en ce qu’il comprend l’obtention (E4) d’informations relatives à une zone de déplacement déclarée (ZD) pour le drone 10 et en ce que ladite zone de déplacement autorisée est adaptée en fonction de la zone de déplacement déclarée, ladite au moins une règle de gestion du drone étant mise en application lorsque le drone sort de la zone de déplacement autorisée ou de la zone déclarée.
6. Procédé de gestion selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend l’obtention préalable du mode de pilotage donné, ledit mode de pilotage étant stocké en mémoire pour une association entre le drone et l’entité de contrôle dans ledit réseau.
7. Procédé de gestion selon l’une quelconque des revendications 4 à 6, caractérisé en ce que ladite au moins une règle de gestion du drone appartient à un groupe comprenant au moins l’envoi à l’entité de contrôle d’une notification relative à :
   - une alerte de sortie de la zone de déplacement autorisée au moins ;
   - un ordre de retour dans la zone de déplacement autorisée ;
   - un plan de déplacement à destination de la zone de déplacement autorisée ;
   - une alerte sur un risque de transfert de contrôle du drone vers une deuxième entité de contrôle.
8. Procédé de gestion selon l’une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une règle de gestion du drone comprend le déclenchement d’un transfert de contrôle du drone vers une deuxième entité de contrôle autorisée.
9. Procédé de gestion selon la revendication 8, caractérisé en ce que, ledit transfert de contrôle du drone vers la deuxième entité de contrôle, déclenche une mise à jour du mode de pilotage, de l’intervalle de valeurs autorisé et de la au moins une règle de gestion du drone.
10. Procédé de gestion selon la revendication 4, caractérisé en ce que ladite au moins une règle de gestion comprend la transmission d’un ordre d’interdiction d’attachement du drone à au moins un équipement d’accès situé à portée radio de la zone non autorisée.
11. Procédé de gestion selon la revendication 4, caractérisé en ce que ladite au moins une règle de gestion du drone comprend la transmission à au moins un équipement d’accès situé à portée radio de la ladite zone géographique non autorisée, d’un ordre de dégradation d’une qualité de signal entre le drone et ledit au moins un équipement d’accès dudit réseau.
12. Procédé de gestion selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend l’obtention (E11) d’un rapport d’événements et la transmission dudit rapport à une entité accréditée et/ou à l’entité de contrôle.
13. Dispositif (100) de gestion d’une position d’un véhicule télé-contrôlé (UAV, 10), dit drone, par rapport à par une entité de contrôle (UAVC, 11), ladite entité de contrôle étant configurée pour contrôler le drone par l’intermédiaire d’un flux de données de contrôle transmis de façon indirecte au sein d’une communication établie entre l’entité de contrôle (11) et le drone (10) par l’intermédiaire d’un réseau de communication (RC), caractérisé en ce que ledit dispositif est configuré pour mettre en œuvre :
    -pour au moins un instant temporel de la communication, la détermination d’au moins un paramètre relatif à une distance entre le drone et l’entité de contrôle;
    - lorsque le paramètre relatif à une distance n’appartient pas à un intervalle de valeurs autorisées pour un mode de pilotage donné, l’application d’au moins une règle de gestion donnée du drone.
14. Système (S) de gestion d’une position d’un véhicule télé-contrôlé, dit drone, par rapport à une entité de contrôle (UAVC, 11) configurée pour le contrôler par l’intermédiaire d’une communication établie dans un réseau de télécommunications (RC), caractérisé en ce qu’il comprend un système de gestion de la connectivité des drones (SGC, 14)) intégré audit réseau, un système (UTM/USS, 16)) de gestion du trafic de drones connecté audit réseau et un dispositif (100) de gestion selon la revendication 13.
15. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de gestion selon l’une quelconque des revendications 1 à 12, lorsqu’il est exécuté par un processeur.