FR 3067900 A1 20181221 FR 1755371 A 20170614 GEOLOCALISATION WiFi DE BIENS OU DE PERSONNES La présente invention est relative à la géolocalisation de biens ou de 5 personnes. DOMAINE TECHNIQUE GÉNÉRAL ET ART ANTÉRIEUR Les traceurs permettant de géo-localiser des biens ou des personnes sont généralement composés de deux parties fonctionnelles : - un module « GPS » qui permet au dispositif de calculer sa position 10 (exprimée en coordonnées de latitude et de longitude - coordonnées GPS) ; - un module de communication (modem « WAN ») qui permet au traceur de transmettre sa position à travers un réseau sans-fil opéré (GSM, 3G, 4G, réseaux d'opérateurs IoT, etc....). Ils comportent en outre habituellement un troisième élément actif : un 15 microcontrôleur qui gère ces deux modules et le cas échéant d'autres fonctionnalités. Cette implémentation présente plusieurs inconvénients. En particulier, elle est onéreuse : les modules GPS sont généralement d'un coût conséquent ; en outre, le coût global du traceur est d'autant plus 20 important que celui-ci doit comporter trois éléments actifs (le module GPS, le module de communication et le microcontrôleur) et deux antennes. Egalement l'utilisation d'un réseau « opéré » pour transmettre les informations implique le versement d'un abonnement à l'opérateur pendant toute la durée de vie du traceur. 25 Par ailleurs une telle implémentation de traceur est encombrante : ceci du fait de sa structure à trois éléments actifs et deux antennes et de la taille du module GPS et de son antenne associée. En outre, les trois éléments actifs rendent sa consommation en énergie importante de sorte que les traceurs GPS sont souvent d'une faible 30 autonomie. 2 Egalement encore, une telle implémentation de traceur a l'inconvénient de ne fonctionner qu'en extérieur. L'antenne du GPS doit en effet être dirigée vers le ciel, sans que sa fenêtre de réception ne soit obstruée. On connait par ailleurs déjà, notamment pour les systèmes de géolocalisation utilisés sur les téléphones portables, des techniques géolocalisation s'appuyant sur la détection des points d'accès WiFi visibles par un téléphone portable et le cas échéant sur le niveau de puissance que ledit téléphone détecte pour lesdits point d'accès. Les informations sur les points d'accès visibles par ledit téléphone portable et le cas échéant sur les niveaux de puissance relevés pour ceux-ci sont collectées par une application logicielle dudit téléphone, qui interroge - via une connexion internet établie à partir dudit du téléphone - une base de données à distance pour que celle-ci lui donne en retour des coordonnées de géolocalisation. Une telle solution - qui est parfaitement adaptée à la localisation de téléphones portables ou analogues (tablettes, par exemple) - reste onéreuse et est difficilement transposable à faible coût aux traceurs de localisation dédiés du fait qu'elle nécessite des composants de communication cellulaire et un abonnement opérateur pour l'établissement d'une communication internet permettant un dialogue avec la base de données à distance. Enfin, on connait également déjà de nombreuses autres solutions qui utilisent des infrastructures spécifiques (réseau de bornes WiFi ou Bluetooth 25 dédiées par exemple). Ces solutions sont complexes et sont limitées aux zones où ces infrastructures sont mises en place. 3 PRÉSENTATION GÉNÉRALE DE L'INVENTION Un but général de l'invention est de proposer une solution permettant un suivi de la localisation de biens ou de personnes qui ne présentent pas les inconvénients des techniques antérieures. 5 Notamment, un but de l'invention est de proposer une solution permettant un suivi de la localisation de biens ou de personnes au moyen de traceurs qui soient particulièrement peu encombrants, d'un très faible coût et d'une grande autonomie. Un autre but encore de l'invention est de permettre un suivi de 10 localisation aussi bien en extérieur et en intérieur en s'appuyant sur l'environnement d'accès WiFi déployé classiquement dans les villes, les locaux de société, les lieux publics (gares, aéroports, musées, centres commerciaux, ...), sans nécessiter d'infrastructure dédiée particulière. L'invention propose quant à elle un procédé de géolocalisation d'un 15 bien ou d'une personne dans lequel un traceur associé audit bien ou à ladite personne met en oeuvre les étapes suivantes : - détection de réseaux WiFi et de leurs points d'accès se trouvant à sa portée, - collecte de données brutes relatives à au moins réseau WiFi 20 détecté et à au moins un point d'accès par lequel ledit réseau est rendu visible audit traceur, - lorsqu'un réseau WiFi ouvert est détecté, o connexion au réseau WIFI o obtention d'une adresse IP et des paramètres du serveur DNS associé à ce réseau, o génération et transmission au serveur DNS associé audit réseau WiFi d'une requête DNS encapsulant lesdites données avec un nom de domaine correspondant à un serveur de résolution. Le serveur de résolution traite la requête pour récupérer lesdites données et à interroge avec celles-ci un serveur de localisation lui-même 4 apte à fournir une information de localisation à partir de données brutes sur un environnement WiFi. Ainsi, le traceur transmet ses informations au serveur de résolution indirectement par Internet 5 - en utilisant les réseaux Wi-Fi ouverts se trouvant à sa portée -de manière indirecte, à l'aide de requêtes de nom de domaine (DNS), telles que définies par les RFC 1034 et 1035 de l'IETF, spécifiquement formatées et détournées de leur finalité d'origine. La transmission est donc indirecte car propagée du module vers le serveur DNS de résolution par le 10 serveur DNS du réseau WiFi. On relèvera en outre que le traceur ne transmet pas à proprement parler de données de localisation, mais des données d'environnement brutes concernant les réseaux Wi-Fi (« primitives de géolocalisation ») qui lui sont en visibilité. 15 L'invention propose également un traceur pour la mise en oeuvre de ce procédé : il est particulièrement simplifié et comporte un microcontrôleur, un module émetteur/récepteur WiFi, ainsi qu'une alimentation. Le microcontrôleur est apte à mettre en oeuvre le procédé proposé. 20 Un tel traceur est d'une structure particulièrement simple. Son module émetteur/récepteur WiFi est à la fois utilisé pour écouter les données d'environnement et transmettre les informations collectées. La simplicité de l'électronique de ce traceur apporte des avantages certains en termes d'encombrement, de coût, et de consommation 25 énergétique. 5 PRÉSENTATION DES FIGURES D'autres caractéristiques et avantages de l'invention ressortiront encore de la description qui suit, laquelle est purement illustrative et non limitative, et doit être lue en regard des figures annexées sur lesquelles : 5 - la figure 1 est une représentation schématique illustrant l'architecture intervenant dans un exemple de mise en oeuvre de l'invention ; - les figures 2a et 2b illustrent deux modes de réalisation possibles pour des traceurs conformes à l'invention ; 10 - la figure 3 illustre différentes étapes susceptibles d'être mises en oeuvre par un traceur conforme à un mode de réalisation l'invention. DESCRIPTION D'UN OU PLUSIEURS MODES DE MISE EN OEUVRE ET DE RÉALISATION 15 Sur la figure 1, on a illustré un traceur de géolocalisation 1, différents points d'accès Wi-Fi 2a, 2b dans la zone de réception ZR dudit traceur 1 (périmètre schématiquement délimité par des traits pointillés) et une pluralité de serveurs 3a, 3b et 3c qui interviennent dans la chaine de transmission et de traitement des données (requêtes R) transmises par le 20 traceur 1. Structure du traceur Le traceur 1 comporte pour l'essentiel une unité de traitement et un émetteur/récepteur WiFi lui permettant d'écouter l'environnement Wi-Fi 25 autour de lui et de communiquer en Wi-Fi. Deux exemples d'architectures particulièrement simples possibles pour le traceur 1 sont illustrés sur les figures 2a et 2b. Dans ces exemples, le traceur 1 comporte un microcontrôleur la, un module émetteur/récepteur WiFi lb associé à une antenne, ainsi qu'une alimentation lc. 30 L'alimentation lc peut être assurée par une ou plusieurs piles non rechargeables montées en série (piles P1 sur la figure 2a). 6 L'alimentation peut également être rechargeable (pile P2 rechargeable alimentée par un chargeur C dans l'exemple de la figure 2b). Egalement, un étage de régulation ld peut être prévu pour protéger le microcontrôleur la et le module émetteur/récepteur lb. Cet étage est 5 alors interposé entre d'une part les éléments actifs que constituent ledit microcontrôleur la et ledit module lb et d'autre part le reste du circuit d'alimentation lc (piles P1 en série dans le cas de la figure 2a ou pile P2 et son chargeur C dans le cas de la figure 2b). Cet étage de régulation ld permet d'écrêter la tension appliquée en 10 entrée du microcontrôleur la et du module lb lorsque la tension d'alimentation est susceptible de dépasser la tension maximale supportée par le microcontrôleur la et le module émetteur/récepteur lb. L'électronique du traceur 1 est par exemple montée sur un support souple ou rigide (étiquette, support rigide, etc.) ou dans un boîtier de petites 15 dimensions, ce qui permet de l'intégrer facilement à tout objet dont on souhaiterait pouvoir suivre la localisation (sacs de voyage, vêtements, colliers pour animal, etc.). Egalement, il peut se présenter sous la forme d'un patch adapté pour être collé à la peau d'un individu. 20 Points d'accès Parmi les points d'accès 2a, 2b visibles par le traceur de suivi 1, le point d'accès 2b est un point d'accès ouvert qui permet une connexion de tout appareil Wi-Fi, sans nécessiter de clé de sécurité pour l'établissement de la connexion. 25 On notera que de tels points d'accès ouverts 2b sont largement répandus sur le réseau Wi-Fi : hôtels, cafés, bornes Wi-Fi dans des lieux publics (gares, aéroports, musées, etc...), bornes WiFi de particuliers, qui auraient été laissées ouvertes par ceux-ci. De tels points d'accès 2b peuvent eux-mêmes être contrôlés et 30 nécessiter un identifiant et un mot de passe pour l'accès aux services ou plus généralement à internet. Dans ce cas, l'utilisateur souhaitant accéder aux services doit préalablement s'enregistrer sur un portail captif. 7 Par opposition, les points d'accès 2a qui ne sont pas ouverts, sont ceux qui requièrent la reconnaissance d'une clé de sécurité avant tout échange de données avec un terminal sans fil. 5 Serveurs Sur la figure 1, le serveur 3a est un serveur DNS associé au point d'accès ouvert 2b. Il reçoit du traceur 1 un message R qui se présente pour ledit serveur 3a sous la forme d'une requête DNS. Cette requête DNS générée par le 10 traceur 1 encapsule avec un nom de domaine différentes données collectées par le traceur 1. Ces données sont notamment des données brutes relatives à l'environnement WiFi du traceur 1 (données dites « primitives de géolocalisation »). Elles peuvent également comprendre d'autres données 15 complémentaires. Le message R ainsi reçu est traité par le serveur 3a comme une requête de nom de domaine. Elle est résolue comme telle par ledit serveur 3a, lequel échange à cet effet avec d'autres serveurs du réseau internet, jusqu'à atteindre le serveur 3b dont le FQDN (« Fully Qualified Domain 20 Name » selon la terminologie anglosaxonne) est contenu dans la requête R préfixée par les données encapsulées. Le serveur 3b reçoit ainsi les données encapsulées. Il les traite en les désencapsulant et le cas échéant en décodant les données brutes. 25 Une fois les données brutes récupérées, le serveur 3b interroge le serveur 3c en lui transmettant les données butes ainsi décodées. Ledit serveur 3c est un serveur de localisation apte fournir une information de localisation à partir des données brutes sur un environnement WiFi. 30 Il traite les données brutes reçues du serveur 3b, c'est-à-dire les données collectées par le traceur 1 sur les réseaux Wi-Fi visibles dans son environnement, et retourne audit serveur 3b une information de localisation 8 (coordonnées de latitude ou longitude (système géodésique WGS 84, couramment utilisé, notamment par le système GPS)). Ledit serveur 3c peut être interrogé à distance via internet (service en ligne) ou être un serveur propriétaire. 5 Données brutes d'environnement - primitives de localisation Les données brutes d'environnement collectées par le traceur 1 - ou primitives de la localisation - sont issues des points d'accès Wi-Fi 2a, 2b les 10 plus visibles dudit traceur 1 (point d'accès pour lesquels ledit traceur 1 reçoit un signal WiFi avec le meilleur niveau de signal). Ces points d'accès peuvent être sélectionnés par le microcontrôleur la du traceur 1 par comparaison à un seuil, ou encore en sélectionnant les N points d'accès WiFi les plus visibles par ledit traceur (ou N est un entier 15 supérieur ou égal à 1. De ces points d'accès, tout ou partie des informations suivantes sont collectées : - Nom du réseau diffusé par le point accès (SSID), - Identifiant du point d'accès (BSSID), 20 - Niveau de puissance du signal reçu, en dBm (RSSI). Par exemple, avec les données de 3 points d'accès, les données brutes collectées par le capteur seront des données alphanumériques reprenant ces trois types d'information pour chacun des trois points. Point Acces 1 SSID Point Acces 1 BSSID Point Acces 1 RSSI Point Acces 2 SSID Point Acces 2 BSSID Point Acces 2 RSSI Point Acces 3 SSID Point Acces 3 BSSID Point Acces 3 RSSI 25 Des implémentations avec un nombre différents de points d'accès sont également possibles, la collecte d'informations sur un seul point d'accès permettant en elle-même de fournir une information de localisation. La multiplication des points d'accès et des informations collectées permet 30 une triangulation et ainsi une meilleure précision sur la localisation. 9 Fonctionnement interne du traceur de suivi (Figure 3) Le microcontrôleur la (microcontrôleur lb) alterne entre un état de veille profonde (AO), lui permettant d'économiser l'alimentation du traceur, 5 et un état de réveil dans lequel il effectue une tentative de transmission de données. Par exemple, sur un cycle d'une heure, il peut être en veille pendant 59' et 55 secondes à un niveau de consommation énergétique très faible, et se réveiller 5 secondes pour effectuer ses tâches. 10 Une fois réveillé, le microcontrôleur lb effectue une séquence de tâches du type de celles illustrées sur la figure 3. Notamment : - il écoute son environnement WiFi et détecte les points d'accès (étape Al), - il mémorise (étape A2) : 15 . la liste de l'ensemble des points d'accès Wi-Fi environnants visibles par le récepteur Wi-Fi, . la liste des réseaux ouverts par ordre décroissant de force du signal des points d'accès correspondants, lorsque un ou plusieurs réseaux de ce type sont visibles. 20 Les différents points d'accès peuvent être identifiés sont identifiés par leur BSSID (identifiant de station), et le cas échéant par leur SSID (identifiant de réseau), le microcontrôleur la pouvant également mémoriser le niveau (RSSI) du signal qu'il reçoit de ces réseaux. Le microcontrôleur la compare alors la première liste (celle de 25 l'ensemble des points d'accès observés) à celle du dernier cycle ayant permis une localisation (étape A3). Lorsqu'il y a des points d'accès en commun, le microcontrôleur la considère que le traceur 1 ne s'est pas déplacé significativement et se remet en veille (étape A4) jusqu'au prochain cycle. 30 Dans le cas contraire (A5), le microcontrôleur la cherche à se connecter aux réseaux ouverts (étapes A6a, A6b, A6c...). 10 Si aucun réseau ouvert n'a été détecté lors du cycle en cours, le microcontrôleur la interrompt sa séquence et se remet dans un état de veille. Si un ou plusieurs réseaux ouverts ont été détecté, le microcontrôleur 5 la tente de se connecter au réseau identifié pour lequel il a détecté le niveau de puissance le plus élevé, d'obtenir une adresse IP, et enfin d'obtenir les paramètres du serveur DNS (le serveur 3a sur la figure 1) lié à ce réseau (étape A7). Si la connexion Wi-Fi réussit, que le microcontrôleur la a réussi à 10 récupérer l'adresse IP, et qu'il récupère l'adresse d'un serveur DNS, alors il génère une requête DNS telle que décrite ci-dessous et l'envoie à ce serveur DNS (étape A8). Si cette séquence est interrompue pour quelque raison, ou que le microcontrôleur la échoue à envoyer son message, il tente alors de se 15 connecter sur réseau ouvert suivant qu'il a mémorisé (par niveau de signal décroissant) ; s'il a épuisé la liste il se remet en veille jusqu'au prochain cycle. En cas de succès, avant de se remettre en veille, le microcontrôleur la mémorise la liste des points d'accès observés lors de ce cycle (étape A9). 20 Construction de la requête Dans une requête DNS, la syntaxe possible pour la définition nom de domaine est contrainte par la norme. La longueur totale du domaine DNS reste toujours inférieure à 255 25 octets. Les données sont réparties dans des labels de taille inférieure à 63 octets conformément au §2.3.4 de la RFC 1035. Seuls les caractères ASCII sont autorisés. La requête DNS générée par le microcontrôleur la est constituée de l'assemblage : 30 - des données brutes à transmettre exprimées dans un format de sous-domaines en conformité avec la norme DNS, - du nom de domaine (FQDN) du serveur 3b. 11 Cet assemblage dans lequel les données brutes sont encapsulées, doit respecter les règles de syntaxe des noms de domaine. Dans une première implémentation, les données brutes sont encapsulées sans ré-encodage dans un sous-domaine DNS, les données 5 binaires étant inscrites sous forme de chaines de caractères représentant leur valeur hexadécimale, les données textuelles alphanumériques sous forme de chaîne de caractères ASCII. Pour les textes alphanumériques à transmettre (champ SSID), seuls sont conservés les caractères alphanumériques [A-Z] [a-z] [0-9] et les 10 caractères « moins » ( - ) et le tiret bas ( _ ) afin de respecter le format d'un sous-domaine dans la norme DNS. En plus des données SSID, BSSID, RSSI du ou des réseaux correspondant aux différents points d'accès (AP) détectés, le microcontrôleur la peut également transmettre le numéro de version du 15 traceur 1, le numéro de cycle ou séquence, ... La trame peut commencer par un ou plusieurs bits drapeau (« Flag ») permettant d'indiquer au serveur qu'il s'agit d'une requête émise par un traceur. Elle se termine par la séquence FQDN du serveur 3b « sous-20 domaine.domaine.tld », ou tld désigne le nom de domaine racine. Par exemple, la requête DNS peut être constituée de la façon suivante, en prenant garde à respecter la longueur de 255 octets : Données Représentation Taille en octets Taille du Label#1 hexadécimal « Flag » 2 caractères ASCII Numéro de version 2 caractères ASCII BSSID du point ouvert 12 caractères ASCII 12 Numéro de séquence 4 caractères ASCII Mémoire RAM du traceur 5 caractères ASCII 5 12 Décalage temporel 5 caractères ASCII Tension d'alimentation 3 caractères ASCII SSID du point d'accès 30 caractères ASCII 1 à 30 ouvert max Taille du Label#2 hexadécimal BSSID de l'AP visible #1 12 caractères ASCII 12 SSID de l'AP visible #1 32 caractères ASCII 1 à 32 max RSSI de l'AP visible #1 hexadécimal Taille du Label#3 hexadécimal BSSID de l'AP visible #2 12 caractères ASCII 12 SSID de l'AP visible #2 32 caractères ASCII 1 à 32 max RSSI de l'AP visible #2 hexadécimal Taille du Label#4 hexadécimal 1 BSSID de l'AP visible #3 12 caractères ASCII 12 SSID de l'AP visible #3 32 caractères ASCII 1 à 32 max RSSI de l'AP visible #3 hexadécimal Taille du Label#5 hexadécimal Sous-domaine associé 1 à 63 caractères -1 à 63 au serveur destinataire ASCII (ex : server) Taille du Label#6 hexadécimal 1 domaine associé 2 à 63 caractères -2 a 63 ex : connectedcycle) ASCII Taille du Label#7 hexadécimal 1 Domaine de premier 2 à 24 caractères - 2 à 24 niveau (ex : com) ASCII 13 Il a été vérifié que la plupart des accès Wi-Fi ouverts permettent l'envoi de cette trame, et la plupart des serveurs DNS associés à ces accès l'interprètent correctement. D'autres implémentations sont également possibles, notamment des 5 implémentations utilisant un codage « binaire vers texte », comme par exemple un codage base 64 (URL-safe, selon la norme IETF RFC4648 §5) ou un codage base 32 (URL safe selon la norme IETF RFC4648 §6) permettant de compacter les données en les rendant compatibles avec la norme DNS. 10 Pour cela, les données sont par exemple préparées de la façon suivante. Tout d'abord, une chaine hexadécimale est constituée : Données Représentation Taille en octets Version hexadécimal 1 BSSID de l'AP ouvert hexadécimal 6 Numéro de séquence hexadécimal Mémoire RAM du traceur hexadécimal Décalage temporel hexadécimal Tension d'alimentation hexadécimal BSSID hexadécimal Longueur du SSID hexadécimal 1 SSID de l'AP ouvert 1 à 32 caractères ASCII 1 à 32 BSSID de l'AP visible #1 hexadécimal 6 RSSI de l'AP visible #1 hexadécimal 1 Long. du SSID de l'AP visible #1 hexadécimal 1 SSID de l'AP visible #1 1 à 32 caractères ASCII 1 à 32 BSSID de l'AP visible #2 hexadécimal 6 RSSI de l'AP visible #2 hexadécimal 1 Long. du SSID de l'AP visible #2 hexadécimal 1 SSID de l'AP visible #2 1 à 32 caractères ASCII 1 à 32 BSSID de l'AP visible #3 hexadécimal 6 14 RSSI de l'AP visible #3 hexadécimal 1 Long. du SSID de l'AP visible #3 hexadécimal 1 SSID de l'AP visible #3 1 à 32 caractères ASCII 1 à 32 Taille du Label#4 hexadécimal 1 Sous-domaine associé au serveur 1 à 63 caractères ASCII -1 à 63 destinataire (ex : server) Taille du Label#5 hexadécimal domaine associé 2 à 63 caractères ASCII -2 à 63 (ex : connectedcycle Taille du Label#5 hexadécimal 1 Domaine de premier niveau e 2 à 24 caractères ASCII - 2 à 24 com) Ces données sont encodées dans une chaine de caractère suivant les encodages précisés ci-dessus. Une fois encodées, les données sont précédées d'un préfixe drapeau 5 (« flag ») de 2 caractères ASCII. Cette chaîne est alors découpée en labels de 63 octets préfixée par un octet indiquant la taille, sauf pour le dernier label qui peut être plus court que 63 octets. Elle est suffixée par le FQDN (Labels #4, 5 et 6 et octets de tailles correspondants) : 10 Taille = 63 o Label #1 Taille = 63 o Label #2 Taille = 50 o Label #3 Taille = 2 o Label #4 sous-domaine Taille = 4 o Label #5 domaine Taille = 3 o Label #6 TLD données données données Propagation de la requête par les serveurs DNS 15 Le serveur DNS 3a associé au fournisseur d'accès du point d'accès sur lequel le module s'est connecté reçoit la requête DNS du module et cherche à résoudre le sous-domaine associé au nom de domaine utilisé. Par exemple pour une requête telle que celle-ci : 15 « EECEMP4NG3ITYFMAHYXUAAAAAAOIGXIPRLEJW7QDKXJFDESICUKJCU2 UCMJFHAH.RBUNPR4EBZSDNEFALKQOJUW45BNGA3S2UDIN52G643NMFZ HIIBVGUZDA5B6FMRG.36BTBVLUSRSJEBKFERKN KBGESTTUHYVR2RQYHA GVOSKGJEQFIUSFJVIEYSKO.resolution.domaine.com » 5 Afin que la requête parvienne au serveur de résolution 3b, une entrée spécifique NS a été préalablement créée dans la zone DNS du domaine (zone de domaine.com dans l'exemple), indiquant que la gestion de ce sous-domaine est déléguée. Cette entrée NS est paramétrée avec les 10 informations nécessaires à la résolution. Le serveur DNS de l'accès Wi-Fi interroge ainsi un serveur racine pour obtenir un serveur DNS pour « .com », puis interroge ce dernier pour obtenir celui pour « domaine.com », et enfin interroge ce dernier pour 15 obtenir celui de « resolution.domaine.com » (adresse du sous-domaine). La requête DNS finit donc par être envoyée au serveur de résolution, qui désencapsule le message, le cas échéant le décode, et interroge le serveur 3b. 20 Traitement réalisé par le serveur de résolution Le serveur de résolution décode l'information. Pour cela : 1. Il commence par s'assurer qu'il s'agit bien d'une requête en provenance d'un module, notamment en lisant le ou les octets drapeau « Flag » et en 25 vérifiant que le sous-domaine demandé correspond. D'autres mécanismes permettant de vérifier l'origine de la requête sont envisageables (somme de contrôle, signature, cryptage, ...) 2. Il retire le préfixe, le suffixe ex : « .sous-domaine.domaine.com », et supprime tous les octet « Taille de label » afin de reconstituer la séquence 30 de données utiles (au format ASCII). Label #1 Label #2 Label #3 données données données 16 3. Les données ainsi obtenues sont décodées en suivant l'algorithme inverse de celui qui a été utilisé pour le codage dans le module. 4. Les données décodées sont ensuite décomposées pour retrouver les 5 valeurs de chaque champ. Une fois que l'ensemble des informations ont été récoltées, il peut alors demander la résolution des informations collectées en informations de géolocalisation soit via un algorithme qu'il implémente lui-même, soit via un service commercial externe (API) qu'il interroge à cette fin. 10 Pour cela, il envoie une partie des données reçues à son algorithme ou à l'API externe (serveur 3b par exemple). Les données nécessaires correspondent à des informations concernant les points d'accès visibles dont le signal a été le plus fort. Pour chaque point d'accès, il s'agit par exemple : 15 - de l'identifiant du point d'accès (BSSID), - et/ou du nom du réseau (SSID), - et/ou du niveau de champ (RSSI) Par exemple, les données relatives aux points d'accès Wi-Fi peuvent être encodées au format JSON de la façon suivante (cas de trois points 20 d'accès) : f Fr[ "SSIDNetwork 1, 25 "BSSID":"A8:34:62:C3:C2:07", "RSSI":-50 "SSID"."Network 2, 30 "BSSID":"7B 3A:2C 23 7D:F8", "RSSI":-51 "SSID":"Network 3", 17 "BSSID":"EC:42:A3:D7:01:79", "RSS7:-55 5 } La requête à cette API est effectuée en HTTP, le serveur retourne alors les informations dans une réponse HTTP. Lorsque le serveur a pu résoudre avec succès l'environnement Wi-Fi en coordonnées GPS, la réponse contient généralement : 10 - la latitude estimée, - la longitude estimée, - la précision (en mètres), - l'adresse postale si les coordonnées GPS ont également pu être résolues en adresse postale. 15 Divers Mémorisation des informations d'environnement lorsqu'aucun accès ouvert n'est disponible Dans une variante possible, le traceur 1, lorsqu'il ne dispose pas d'un 20 réseau ouvert à proximité au cours d'un cycle, mémorise dans une mémoire volatile ou non les informations d'environnement Wi-Fi qui auraient dû être transmises pour les envoyer de manière différée au cours d'un cycle suivant pour lequel un réseau ouvert sera accessible, afin que le serveur puisse reconstituer le trajet parcouru avec plus de détail. 25 Constitution d'une liste noire de réseaux à éviter pour la connexion Egalement, le traceur 1 peut stocker dans une mémoire volatile ou non la liste des réseaux (désignées par leur SSID et BSSID) auxquels il n'a pas pu se connecter, au bout d'une ou plusieurs tentatives. Cela lui-permet 30 de se constituer une liste noire de réseaux auquel il ne tentera plus de se connecter ultérieurement, soit si le SSID est identique, soit si le BSSID est identique. Cette liste noire pourra être récupérée par tout moyen en ligne 18 ou hors-ligne afin de pouvoir munir une nouvelle version du logiciel du dispositif d'une liste de réseaux préconfigurés en liste noire. Le traceur 1 peut notamment être préconfiguré avec une liste de réseaux ouverts identifiés par SSID ou BSSID auxquels il lui est interdit de 5 se connecter liste noire. Liste de réseaux préférés Le traceur 1 peut être muni par programmation d'une liste de réseaux ouverts préférés auxquels il se connectera prioritairement s'ils sont visibles. 10 De plus, il peut être munis d'identifiants permettant de se connecter à certains réseaux fermés qu'il détecterait dans son environnement Détection de mouvement ou détection de sédentarité : En cas de succès d'émission de l'information de localisation, le traceur 15 1 peut enregistrer tout ou partie des réseaux visibles jusqu'au prochain cycle. Lorsque le nouveau cycle intervient, le traceur 1 récupère à nouveau la liste des réseau environnants, et la compare à la liste précédente pour savoir si le traceur a bougé ou non : si un ou plusieurs réseaux sont identiques entre les deux listes, le traceur n'a pas bougé ou a bougé d'une 20 distance faible ( REVENDICATIONS1. Procédé de géolocalisation d'un bien ou d'une personne dans lequel un traceur associé audit bien ou à ladite personne met en oeuvre les étapes suivantes : - détection de réseaux WiFi et points d'accès associés se trouvant à sa portée, - collecte de données brutes relatives à au moins réseau WiFi détecté et à au moins un point d'accès par lequel ledit réseau est rendu visible audit traceur, - lorsqu'un réseau WiFi ouvert est détecté, o connexion au réseau WIFI o obtention d'une adresse IP et des paramètres du serveur DNS associé au point d'accès, o génération et transmission audit serveur DNS d'une requête DNS encapsulant lesdites données brutes avec un nom de domaine correspondant à un serveur de résolution apte à traiter la requête pour récupérer lesdites données et à interroger avec celles-ci un serveur de localisation lui- même apte à fournir une information de localisation à partir de données brutes sur un environnement WiFi. 2. Procédé selon la revendication 1, dans lequel des données brutes comprennent un identifiant de point d'accès (BSSID) et/ou un nom de réseau (SSID) et/ou un niveau de puissance du signal reçu (RSSI). 3. Procédé selon l'une des revendications précédentes, dans lequel pour les données alphanumériques, seuls sont conservés les caractères alphanumériques ([A-Z] [a-z] [0-9]) et les caractères « moins » ( - ) et « tiret bas » ( _ ), les données binaires étant exprimées dans leur valeur hexadécimale convertie en texte ASCII, 22 les données alphanumériques et les données binaires converties en texte ASCII étant ensuite encapsulées dans la requête DNS. 4. Procédé selon la revendication 1 ou selon la revendication 2, dans lequel les données sont concaténées dans une chaine hexadécimale, 5 ladite chaine étant ensuite encodée en texte, puis encapsulée dans la requête DNS. 5. Procédé selon l'une des revendications précédentes, dans lequel lorsque plusieurs réseaux WiFi ouverts sont détectés, le traceur tente de s'y connecter par niveaux de signal décroissant. 10 6. Procédé selon l'une des revendications précédentes, dans lequel les données brutes encapsulées comportent des données d'au moins un capteur de mesure de grandeurs physiques externes. 7. Procédé selon l'une des revendications précédentes, dans lequel on met également en oeuvre une détection de réseaux Bluetooth et 15 dans lequel les données brutes encapsulées comportent des données relatives à au moins un équipement Bluetooth, lorsqu'un tel équipement est visible par le traceur. 8. Procédé de géolocalisation d'un bien ou d'une personne dans lequel un serveur de résolution reçoit une requête DNS générée et 20 transmise par un traceur associé audit bien ou à ladite personne selon un procédé conforme à l'une des revendications précédentes, dans lequel ledit serveur de résolution : - traite la requête pour y récupérer les données brutes relatives à au moins réseau WiFi détecté par le traceur et 25 - interroge avec celles-ci un serveur de localisation apte à fournir une information de localisation à partir de données brutes sur un environnement WiFi. 23 9. Procédé selon la revendication 8, dans lequel ledit serveur désencapsule lesdites données et le cas échéant les décode. 10. Traceur de géolocalisation de biens ou de personnes comportant un microcontrôleur, un module émetteur/récepteur WiFi, ainsi qu'une 5 alimentation, dans lequel le microcontrôleur est apte à mettre en oeuvre le procédé selon l'une des revendications 1 à 7. 11. Traceur selon la revendication 10, caractérisé en ce qu'il comporte en outre au moins un capteur de mesure de grandeurs physiques externes. 10 12. Système de géolocalisation de biens ou services comportant au moins un traceur selon la revendication 10 ou la revendication 11 et serveur de résolution adapté pour mettre en oeuvre un procédé selon la revendication 8 ou selon la revendication 9. 15