EP3639531B1 - Géolocalisation wifi de biens ou de personnes - Google Patents

Géolocalisation wifi de biens ou de personnes Download PDF

Info

Publication number
EP3639531B1
EP3639531B1 EP18729703.1A EP18729703A EP3639531B1 EP 3639531 B1 EP3639531 B1 EP 3639531B1 EP 18729703 A EP18729703 A EP 18729703A EP 3639531 B1 EP3639531 B1 EP 3639531B1
Authority
EP
European Patent Office
Prior art keywords
tracker
raw data
data
network
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP18729703.1A
Other languages
German (de)
English (en)
Other versions
EP3639531A1 (fr
Inventor
Christian KRAVANJA
Jean-Marie DEBBASCH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Connected Cycle
Original Assignee
Connected Cycle
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Connected Cycle filed Critical Connected Cycle
Publication of EP3639531A1 publication Critical patent/EP3639531A1/fr
Application granted granted Critical
Publication of EP3639531B1 publication Critical patent/EP3639531B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/69—Types of network addresses using geographic information, e.g. room number

Definitions

  • the present invention relates to the geolocation of goods or people.
  • a microcontroller which manages these two modules and, where appropriate, other functionalities.
  • This implementation has several drawbacks.
  • the GPS modules are generally of a considerable cost; in addition, the overall cost of the plotter is all the more important as it must include three active elements (the GPS module, the communication module and the microcontroller) and two antennas.
  • Such a plotter implementation is bulky: this because of its structure with three active elements and two antennas and the size of the GPS module and its associated antenna.
  • the three active elements make its energy consumption important so that GPS trackers are often of low autonomy.
  • GPS antenna must in fact be pointed towards the sky, without its reception window being obstructed.
  • the document US 2015/0181511 A1 describes a system including a GNSS tracking module.
  • the information on the access points visible by said mobile telephone and, where applicable, on the power levels recorded for them are collected by a software application of said telephone, which queries - via an internet connection established from said telephone - a remote database so that it gives him geolocation coordinates in return.
  • the document US 2014/0274043 A1 describes a method of selecting Wi-Fi access points based on a location assistance quality value.
  • the document US 2015/0223016 A1 describes a transmission of location information based on information about an access point.
  • a general aim of the invention is to provide a solution allowing tracking of the location of goods or people who do not have the drawbacks of the prior techniques.
  • one aim of the invention is to provide a solution allowing tracking of the location of goods or people by means of plotters which are particularly compact, very inexpensive and have great autonomy.
  • Yet another object of the invention is to allow location tracking both outdoors and indoors by relying on the WiFi access environment conventionally deployed in cities, company premises, public places (stations , airports, museums, shopping centers, etc.), without requiring any specific dedicated infrastructure.
  • the invention is defined by a method according to claim 1 and a plotter according to claim 16. Further embodiments are defined in the dependent claims.
  • the tracer does not, strictly speaking, transmit location data, but raw environmental data relating to the Wi-Fi networks (“geolocation primitives”) which are visible to it.
  • Such a tracer is of a particularly simple structure. Its WiFi transmitter / receiver module is used both to listen to environmental data and to transmit the information collected.
  • FIG. 1 there is illustrated a geolocation plotter 1, various Wi-Fi access points 2a, 2b in the reception area ZR of said plotter 1 (perimeter schematically delimited by dotted lines) and a plurality of servers 3a, 3b and 3c which intervene in the chain of transmission and processing of data (requests R) transmitted by the plotter 1.
  • the tracer 1 essentially comprises a processing unit and a WiFi transmitter / receiver enabling it to listen to the WiFi environment around it and to communicate via WiFi.
  • the plotter 1 comprises a microcontroller 1a, a WiFi transmitter / receiver module 1b associated with an antenna, as well as a power supply 1c.
  • Power supply 1c can be provided by one or more non-rechargeable batteries connected in series (batteries P1 on the figure 2a ).
  • the power supply can also be rechargeable (rechargeable P2 battery powered by a charger C in the example of figure 2b ).
  • a regulation stage 1d can be provided to protect the microcontroller 1a and the transmitter / receiver module 1b. This stage is then interposed between on the one hand the active elements that constitute said microcontroller 1a and said module 1b and on the other hand the rest of the supply circuit 1c (batteries P1 in series in the case of the figure 2a or battery P2 and its charger C in the case of figure 2b ).
  • This regulation stage 1d makes it possible to clip the voltage applied at the input of the microcontroller 1a and of the module 1b when the supply voltage is liable to exceed the maximum voltage supported by the microcontroller 1a and the transmitter / receiver module 1b.
  • the electronics of the plotter 1 is for example mounted on a flexible or rigid support (label, rigid support, etc.) or in a small-sized box, which makes it possible to easily integrate it into any object which one would like to be able to follow. location (travel bags, clothing, pet collars, etc.). Also, it can be in the form of a patch adapted to be stuck to the skin of an individual.
  • the access point 2b is an open access point that allows a connection of any Wi-Fi device, without requiring a security key for the connection establishment.
  • Wi-Fi network hotels, cafes, Wi-Fi terminals in public places (stations, airports, museums, etc.), private Wi-Fi terminals , which would have been left open by them.
  • Such access points 2b can themselves be controlled and require an identifier and a password for access to the services or more generally to the Internet.
  • the user wishing to access the services must first register on a captive portal.
  • the access points 2a which are not open are those which require the recognition of a security key before any data exchange with a wireless terminal.
  • the server 3a is a DNS server associated with the open access point 2b.
  • This DNS query generated by the plotter 1 encapsulates with a domain name various data collected by the plotter 1.
  • These data are in particular raw data relating to the WiFi environment of the plotter 1 (data known as “geolocation primitives”). They may also include other additional data.
  • the message R thus received is processed by the server 3a as a request for a domain name. It is resolved as such by said server 3a, which exchanges for this purpose with other servers of the Internet network, until reaching the server 3b whose FQDN (“Fully Qualified Domain Name”) is contained in the request R prefixed by the encapsulated data.
  • the server 3b thus receives the encapsulated data.
  • the server 3b interrogates the server 3c by transmitting to it the end data thus decoded.
  • Said server 3c is a location server capable of providing location information from raw data on a WiFi environment.
  • Said server 3c can be queried remotely via the internet (online service) or be a proprietary server.
  • the raw environmental data collected by the plotter 1 - or location primitives - come from the most visible Wi-Fi access points 2a, 2b of said plotter 1 (access point for which said plotter 1 receives a signal WiFi with the best signal level).
  • These access points can be selected by the microcontroller 1a of the plotter 1 by comparison with a threshold, or even by selecting the N WiFi access points most visible by said plotter (where N is an integer greater than or equal to 1.
  • the raw data collected by the sensor will be alphanumeric data containing these three types of information for each of the three points.
  • Implementations with a different number of access points are also possible, the collection of information on a single access point in itself making it possible to provide location information.
  • the multiplication of access points and the information collected allows triangulation and thus better precision on the location.
  • the microcontroller 1a (microcontroller 1b) alternates between a deep sleep state (A0), allowing it to save the power supply to the tracer, and a waking state in which it makes an attempt to transmit data.
  • the microcontroller 1b performs a sequence of tasks of the type illustrated on figure 3 .
  • the different access points can be identified are identified by their BSSID (station identifier), and if necessary by their SSID (network identifier), the microcontroller can also memorize the level (RSSI) of the signal it receives. of these networks.
  • BSSID station identifier
  • SSID network identifier
  • the microcontroller compares the first list (that of all the access points observed) with that of the last cycle which allowed a location (step A3).
  • the microcontroller When there are common access points, the microcontroller considers it that the plotter 1 has not moved significantly and goes back to standby (step A4) until the next cycle.
  • the microcontroller seeks it to connect to the open networks (steps A6a, A6b, A6c, etc.).
  • the microcontroller interrupts its sequence and returns to a standby state.
  • the microcontroller attempts to connect to the identified network for which it has detected the highest power level, to obtain an IP address, and finally to obtain the settings from the DNS server. (server 3a on the figure 1 ) linked to this network (step A7).
  • the microcontroller If the Wi-Fi connection is successful, the microcontroller has succeeded in retrieving the IP address, and it retrieves the address of a DNS server, then it generates a DNS query as described below and the sends to this DNS server (step A8).
  • the microcontroller stores the list of access points observed during this cycle (step A9).
  • the total length of the DNS domain is always less than 255 bytes.
  • the data is distributed in labels smaller than 63 bytes in accordance with ⁇ 2.3.4 of RFC 1035. Only ASCII characters are allowed.
  • This assembly in which the raw data is encapsulated, must respect the rules of syntax for domain names.
  • the raw data is encapsulated without re-encoding in a DNS subdomain, the binary data being written in the form of character strings representing their hexadecimal value, the alphanumeric textual data in the form of an ASCII character string.
  • the microcontroller 1a can also transmit the version number of the plotter 1, the cycle or sequence number, etc.
  • the frame can begin with one or more flag bits (“Flag”) allowing the server to be informed that it is a request sent by a tracer.
  • Flag flag bits
  • the DNS request can be made as follows, taking care to respect the length of 255 bytes:
  • a "binary to text" encoding such as for example a base 64 encoding (URL-safe, according to the IETF RFC4648 ⁇ 5 standard) or a base 32 encoding (URL safe according to the IETF standard RFC4648 ⁇ 6) allowing data to be compacted by making them compatible with the DNS standard.
  • a base 64 encoding URL-safe, according to the IETF RFC4648 ⁇ 5 standard
  • a base 32 encoding URL safe according to the IETF standard RFC4648 ⁇ 6
  • the data is for example prepared as follows.
  • the data is preceded by a flag prefix of 2 ASCII characters.
  • the DNS server 3a associated with the access provider of the access point to which the module is connected receives the DNS request from the module and seeks to resolve the subdomain associated with the domain name used.
  • a specific NS entry was previously created in the DNS zone of the domain (zone of domain.com in the example), indicating that the management of this subdomain is delegated.
  • This NS entry is configured with the information required for resolution.
  • the Wi-Fi access DNS server thus queries a root server to obtain a DNS server for ".com”, then queries the latter to obtain the one for "domaine.com”, and finally queries the latter to obtain that of ". resolution.domain.com ”(subdomain address).
  • the DNS request therefore ends up being sent to the resolution server, which decapsulates the message, if necessary decodes it.
  • the resolution server resolves the connected data into location information, then the server 3b transmits the decoded geolocation information to an information system or a database.
  • the resolution server decodes the information. For that : 1. It starts by making sure that it is indeed a request coming from a module, in particular by reading the flag byte (s) "Flag” and by checking that the requested subdomain corresponds. Other mechanisms making it possible to verify the origin of the request are possible (checksum, signature, encryption, etc.) 2. It removes the prefix, the suffix eg: “.subdomain.domain.com”, and removes all the “Label size” bytes in order to reconstitute the sequence of useful data (in ASCII format). Label # 1 Label # 2 Label # 3 data data data 3. The data thus obtained is decoded by following the reverse algorithm of that which was used for the coding in the module. 4. The decoded data is then decomposed to find the values of each field.
  • the required data is information about the visible access points with the strongest signal.
  • data relating to Wi-Fi access points can be encoded in JSON format as follows (case of three access points):
  • the tracer 1 when it does not have an open network nearby during a cycle, or if the characteristics of this cycle correspond to certain internal rules that it implements, stores the information in a volatile memory or not. Wi-Fi environment that should have been transmitted to send them in a deferred manner during a following cycle for which an open network will be accessible, so that the server can reconstruct the route traveled with more details.
  • the tracer 1 can store in a volatile memory or not the list of networks (designated by their SSID and BSSID) to which it has not been able to connect, after one or more attempts. This allows it to build up a blacklist of networks to which it will no longer attempt to connect later, either if the SSID is identical, or if the BSSID is identical.
  • This blacklist can be retrieved by any online or offline means in order to be able to provide a new version of the device's software with a list of preconfigured blacklisted networks.
  • the plotter 1 can in particular be preconfigured with a list of open networks identified by SSID or BSSID to which it is prohibited from connecting to a blacklist.
  • the plotter 1 can be provided by programming with a list of preferred open networks to which it will connect as a priority if they are visible. In addition, it can be provided with identifiers allowing it to connect to certain closed networks that it would detect in its environment.
  • the plotter 1 can record all or part of the visible networks until the next cycle. When the new cycle occurs, the plotter 1 recovers the list of surrounding networks again, and compares it to the previous list to find out whether the plotter has moved or not: if one or more networks are identical between the two lists, the plotter n has not moved or has moved from a short distance (usually ⁇ 100 m).
  • said tracer 1 When said tracer 1 has not moved, it can immediately go back to standby without performing a transmission cycle in order to save energy), given that its location is already known from the previous cycle.
  • the tracer 1 is based on a subset of the BSSID of the surrounding wifi access points to eliminate one of two similar networks which would in fact be transmitted by the same physical access point and would harm the diversity sought for the 3 access point identifiers serving as primitive for geolocation.
  • the module can encrypt the raw data using a numeric key, before it is adapted to the DNS format.
  • the server then performs the decryption processing.
  • the module can digitally sign the raw data contained in the DNS request, the signature also being adapted to be transmitted in DNS format in the same request.
  • the server performs the signature verification.
  • the module and the server can realize a combination of the two preceding variants.
  • the location primitive used can integrate the visibility of Bluetooth devices identified by their device identifier. devices, only (when no WiFi hotspots) are detected or in addition to wifi hotspot identifiers.
  • the plotter 1 can also be provided with a sensor for measuring external physical quantities, the data of which is transmitted in the DNS request.
  • Such a sensor can be a barometric sensor, the data of which are intended to be converted by the server 3b into altitude data, an acceleration sensor (s), a temperature sensor or even a pollution data sensor (temperature sensor. concentration of polluting particles).
  • an acceleration sensor s
  • a temperature sensor or even a pollution data sensor (temperature sensor. concentration of polluting particles).
  • Other types of sensors are of course possible.
  • the tracer 1 after having sent a DNS request, listens to a DNS response from the server. It can use this response on the one hand to ensure that the server has received its transmission (acknowledgment): if the DNS request is not acknowledged, the module can attempt to re-send it through another point. 'open access.
  • the DNS response can make it possible to receive information allowing it to reconfigure certain parameters (eg change of its transmission frequency, etc.).
  • the DNS response can also be used to update the firmware of the plotter (1), for example if the module is connected to a closed network.
  • Wi-Fi environment data is also used to determine the floor or the approximate altitude of the module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

  • La présente invention est relative à la géolocalisation de biens ou de 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 (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 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 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.
  • 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 autonomie.
  • 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.
  • Le document US 2015/0181511 A1 décrit un système incluant un module de localisation GNSS.
  • 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.
  • Le document US 2014/0274043 A1 décrit un procédé de sélection de points d'accès Wi-Fi en fonction d'une valeur de qualité d'assistance à la localisation. Le document US 2015/0223016 A1 décrit une transmission d'une information de localisation en fonction d'informations sur d'un point d'accès.
  • On connaît également une solution, décrite dans le document EP 2443562 , de géolocalisation à partir d'une requête DNS encapsulant des données relatives à des réseaux Wi-Fi ouverts détectés. Néanmoins, si ces données ne peuvent être transmises, elles ne sont alors pas exploitées. Il est alors impossible de reconstituer le trajet complet du traceur.
  • Enfin, on connait également déjà de nombreuses autres solutions qui utilisent des infrastructures spécifiques (réseau de bornes WiFi ou Bluetooth dédiées par exemple).
  • Ces solutions sont complexes et sont limitées aux zones où ces infrastructures sont mises en place.
    • 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.
  • 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 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 est définie par un procédé selon la revendication 1 et un traceur selon la revendication 16. Des modes de réalisation supplémentaires sont définis dans les revendications dépendantes.
  • Ainsi, le traceur transmet ses informations au serveur de résolution indirectement par Internet
    • 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 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é.
  • 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 énergétique.
    • 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 :
    • la figure 1 est une représentation schématique illustrant l'architecture intervenant dans un exemple de mise en œuvre de l'invention ;
    • les figures 2a et 2b illustrent deux modes de réalisation possibles pour des traceurs conformes à l'invention ;
    • la figure 3 illustre différentes étapes susceptibles d'être mises en œuvre par un traceur conforme à un mode de réalisation l'invention.
    DESCRIPTION D'UN OU PLUSIEURS MODES DE MISE EN ŒUVRE ET DE RÉALISATION
  • 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 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 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 1a, un module émetteur/récepteur WiFi 1b associé à une antenne, ainsi qu'une alimentation 1c.
  • L'alimentation 1c peut être assurée par une ou plusieurs piles non rechargeables montées en série (piles P1 sur la figure 2a).
  • 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 1d peut être prévu pour protéger le microcontrôleur la et le module émetteur/récepteur 1b. Cet étage est alors interposé entre d'une part les éléments actifs que constituent ledit microcontrôleur la et ledit module 1b et d'autre part le reste du circuit d'alimentation 1c (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 1d permet d'écrêter la tension appliquée en entrée du microcontrôleur la et du module 1b 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 1b.
  • 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 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.
    • 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.
  • 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 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.
  • 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.
    • 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 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 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 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.
  • 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.
  • 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 (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.
    • 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 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 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),
    • 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
  • 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 une triangulation et ainsi une meilleure précision sur la localisation.
    • Fonctionnement interne du traceur de suivi (Figure 3)
  • Le microcontrôleur la (microcontrôleur 1b) alterne entre un état de veille profonde (A0), lui permettant d'économiser l'alimentation du traceur, 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.
  • Une fois réveillé, le microcontrôleur 1b 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 A1),
    • il mémorise (étape A2) :
      • 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.
  • 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 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.
  • Dans le cas contraire (A5), le microcontrôleur la cherche à se connecter aux réseaux ouverts (étapes A6a, A6b, A6c...).
  • 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 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 à 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 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).
    • 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 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 :
    • 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.
  • 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 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 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 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-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 :
    Figure imgb0001
    Figure imgb0002
  • 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 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.
  • 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 :
    Figure imgb0003
    Figure imgb0004
  • 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 (« 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) :
    Taille Label #1 Taille Label #2 Taille Label #3 Taille Label #4 Taille Label #5 Taille Label #6
    = 63 o données = 63 o données = 50 o données = 2 o sous-domaine =4 o domaine = 3 o TLD
    • Propagation de la requête par les serveurs DNS
  • 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 :
    Figure imgb0005
  • 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 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 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. Le serveur de résolution résout les données connectées en information de localisation, puis le serveur 3b transmet l'information de géolocalisation décodée à un système d'information ou une base de données.
    • 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 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 de données utiles (au format ASCII).
    Label #1 Label #2 Label #3
    données données données

    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 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.
  • Pour cela, il envoie une partie des données reçues à son algorithme ou à l'API externe (serveur 3c 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 :
    • 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 d'accès) :
    Figure imgb0006
  • 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 :
    • 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.
    Mémorisation des informations d'environnement lorsqu'aucun accès ouvert n'est disponible :
  • Le traceur 1, lorsqu'il ne dispose pas d'un réseau ouvert à proximité au cours d'un cycle, ou si les caractéristiques de ce cycle correspondent à certaines règles internes qu'il implémente, 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étails.
    • Divers
  • 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 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 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 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. 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 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 distance faible ( < 100 m généralement).
  • Lorsque ledit traceur 1 n'a pas bougé, il peut se remettre immédiatement en veille sans effectuer un cycle d'émission afin d'économiser de l'énergie), compte tenu du fait que sa localisation est déjà connue depuis le cycle précédent.
  • Il peut également automatiquement allonger la temporisation entre les cycles s'il détecte que le module n'est pas en mouvement.
  • Il peut aussi forcer son émission, lors d'un réveil, après un certain nombre de cycles sans mouvement.
  • Dans certains d'usages, on peut aussi souhaiter utiliser le mécanisme à l'inverse : les positions ne sont alors transmises que lorsque le module ne bouge pas.
    • Diversité des Point d'accès utilisés pour la localisation
  • Le traceur 1 se base sur un sous-ensemble du BSSID des points d'accès wifi environnants pour éliminer l'un de deux réseaux similaires qui seraient en fait émis par un même point d'accès physique et nuirait à la diversité recherchée pour les 3 identifiants de point d'accès servant de primitive à la géolocalisation.
    • Signature et cryptage des données
  • Le module peut crypter les données brutes à l'aide d'une clé numérique, avant que celles-ci ne soient adaptées au format DNS. Le serveur effectue alors le traitement de décryptage.
  • Le module peut réaliser une signature numérique des données brutes contenues dans la requête DNS, la signature étant également adaptée pour être transmise au format DNS dans la même requête. Le serveur effectue la vérification de la signature.
  • Le module et le serveur peuvent réaliser une combinaison des deux variantes précédentes.
    • Visibilité d'équipements Bluetooth
  • Egalement, la primitive de localisation utilisée peut intégrer la visibilité d'équipements Bluetooth identifiés par leur identifiant de dispositifs, uniquement (lorsqu'aucun hotspots WiFi) n'est détecté ou en complément d'identifiants de hotspots wifi.
    • Données d'un capteur externe
  • Le traceur 1 peut en outre être muni d'un capteur de mesure de grandeurs physiques externes, dont les données sont transmises dans la requête DNS.
  • Un tel capteur peut être un capteur barométrique dont les données sont destinées à être converties par le serveur 3b en données d'altitude, un capteur d'accélération(s), un capteur de température ou encore un capteur de données de pollution (capteur de concentration de particules polluantes). D'autres types de capteurs sont bien entendu possibles.
    • Re-paramétrage du module initié par le serveur DNS :
  • En variante encore, le traceur 1, après avoir émis une requête DNS se met à l'écoute d'une réponse DNS du serveur. Il peut se servir de cette réponse d'une part pour s'assurer que le serveur a bien reçu sa transmission (acquittement) : si la requête DNS n'est pas acquittée, le module peut tenter de la réémettre à travers un autre point d'accès ouvert.
  • D'autre part, la réponse DNS peut permettre de recevoir une information lui permettant de reconfigurer certains paramètres (ex : changement de sa fréquence d'émission, etc...). La réponse DNS peut également permettre de mettre à jour le micrologiciel du traceur (1), par exemple si le module est connecté à un réseau fermé.
  • Utilisation des données Wi-Fi pour déterminer l'altitude ou un étage :
    En variante encore, les données d'environnement Wi-Fi servent également à déterminer l'étage ou l'altitude approximative du module.

Claims (18)

  1. Procédé de géolocalisation d'un bien ou d'une personne dans lequel un microcontrôleur (1a) d'un traceur (1) associé audit bien ou à ladite personne met en œuvre un cycle comportant un état de veille profonde et un état de réveil, au cours duquel il effectue les étapes suivantes :
    • détection de réseaux Wi-Fi et points d'accès (2a, 2b) associés se trouvant à sa portée,
    • collecte de données brutes relatives à au moins réseau Wi-Fi détecté et à au moins un point d'accès (2a, 2b) par lequel ledit réseau est rendu visible audit traceur (1),
    • lorsqu'un réseau Wi-Fi ouvert est détecté,
    ∘ connexion au réseau Wi-Fi,
    ∘ obtention d'une adresse IP et des paramètres d'un serveur de nom de domaine, DNS, associé au point d'accès (2b),
    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 adapté pour traiter la requête pour récupérer lesdites données brutes et à interroger avec celles-ci un serveur de localisation lui-même adapté pour fournir une information de localisation à partir de données brutes sur un environnement Wi-Fi,
    • lorsqu'aucun réseau Wi-Fi ouvert n'est détecté au cours d'un cycle,
    o mémorisation, dans une mémoire, desdites données brutes qui auraient dû être transmises,
    o envoi desdites données brutes de manière différée au cours d'un cycle suivant,
    ledit procédé comprenant en outre les étapes suivantes, mises en œuvre avant que le microcontrôleur (1a) cherche à se connecter à un réseau Wi-Fi ouvert :
    • comparaison d'une liste des points d'accès (2a, 2b) Wi-Fi détectés à une liste des points d'accès (2a, 2b) Wi-Fi mémorisée lors du dernier cycle ayant permis une localisation,
    • mise en veille du microcontrôleur (1a) jusqu'à un prochain cycle lorsque les deux listes comportent des points d'accès (2a, 2b) en commun.
  2. Procédé selon la revendication 1, dans lequel le traceur (1) est muni d'identifiants qu'il mémorise et qui lui permettent de se connecter à des réseaux fermés qu'il détecterait dans son environnement.
  3. Procédé selon la revendication 1 ou la revendication 2, dans lequel le traceur (1) est préconfiguré avec une liste de réseaux ouverts auxquels il lui est interdit de se connecter.
  4. Procédé selon l'une des revendications précédentes, dans lequel des données brutes comprennent un identifiant de point d'accès (2a, 2b), BSSID, et/ou un nom de réseau, SSID, et/ou un niveau de puissance du signal reçu, RSSI.
  5. Procédé selon l'une des revendications précédentes, dans lequel les données sont concaténées dans une chaine hexadécimale, ladite chaine étant ensuite encodée en texte, puis encapsulée dans la requête DNS.
  6. Procédé selon la revendication 5, 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, les données alphanumériques et les données binaires converties en texte ASCII étant ensuite encapsulées dans la requête DNS.
  7. Procédé selon l'une des revendications précédentes, dans lequel lorsque plusieurs réseaux Wi-Fi ouverts sont détectés, le traceur (1) tente de s'y connecter par niveaux de signal décroissant.
  8. 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.
  9. 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 parmi un numéro de cycle, un numéro de version du logiciel du traceur (1), des paramètres de configuration, une tension d'alimentation, une information horaire.
  10. Procédé selon l'une des revendications précédentes, comprenant en outre une étape de reconfiguration de certains paramètres du traceur (1) suite à la réception d'une réponse DNS, et/ou de mise à jour du logiciel du traceur (1).
  11. Procédé selon la revendication 10, dans lequel le traceur mémorise des grandeurs physiques externes lorsqu'aucun accès ouvert n'est disponible.
  12. Procédé selon l'une des revendications précédentes, comprenant en outre une étape d'élimination par le traceur (1) de l'un de deux réseaux similaires qui seraient émis par un même point d'accès (2a, 2b) physique, le traceur (1) se basant sur un sous-ensemble du BSSID des points d'accès (2a, 2b) Wi-Fi environnants.
  13. Procédé selon l'une des revendications précédentes, dans lequel le traceur (1) met également en œuvre une détection de réseaux Bluetooth et 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 (1).
  14. Procédé selon l'une des revendications précédentes, comportant en outre les étapes suivantes, effectuées par le serveur de résolution :
    - réception de la requête DNS générée et transmise par le traceur (1),
    - traitement de la requête pour y récupérer les données brutes relatives à l'au moins réseau Wi-Fi détecté par le traceur (1) et
    - interrogation, avec lesdites données brutes, du serveur de localisation adapté pour fournir l'information de localisation à partir de données brutes sur l'environnement Wi-Fi.
  15. Procédé selon la revendication 14, dans lequel ledit serveur de résolution désencapsule lesdites données brutes et le cas échéant décode lesdites données brutes.
  16. Traceur (1) de géolocalisation de biens ou de personnes comportant un microcontrôleur (1a), un module émetteur/récepteur Wi-Fi, ainsi qu'une alimentation, dans lequel le microcontrôleur (1a) est adapté pour mettre en œuvre le procédé selon l'une des revendications 1 à 13.
  17. Traceur (1) selon la revendication 16, comportant en outre au moins un capteur de mesure de grandeurs physiques externes.
  18. Système de géolocalisation de biens ou services comportant au moins un traceur (1) selon la revendication 16 ou la revendication 17 et un serveur de résolution adapté pour mettre en œuvre un procédé selon la revendication 14 ou selon la revendication 15.
EP18729703.1A 2017-06-14 2018-06-14 Géolocalisation wifi de biens ou de personnes Active EP3639531B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1755371A FR3067900B1 (fr) 2017-06-14 2017-06-14 Geolocalisation wifi de biens ou de personnes
PCT/EP2018/065884 WO2018229227A1 (fr) 2017-06-14 2018-06-14 Geolocalisation wifi de biens ou de personnes

Publications (2)

Publication Number Publication Date
EP3639531A1 EP3639531A1 (fr) 2020-04-22
EP3639531B1 true EP3639531B1 (fr) 2021-11-10

Family

ID=60182640

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18729703.1A Active EP3639531B1 (fr) 2017-06-14 2018-06-14 Géolocalisation wifi de biens ou de personnes

Country Status (3)

Country Link
EP (1) EP3639531B1 (fr)
FR (1) FR3067900B1 (fr)
WO (1) WO2018229227A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010148260A1 (fr) * 2009-06-19 2010-12-23 Devicescape Software, Inc. Systèmes et procédés pour déterminer l'emplacement sur un réseau
CN104704861B (zh) * 2012-08-09 2018-09-28 索尼电脑娱乐公司 移动终端、用于基于与接入点的识别的接收时间相关联的所述识别定位所述终端的方法、程序和存储介质
US8977288B2 (en) * 2012-11-16 2015-03-10 Broadcom Corporation Apparatus and method for performing low-power geo-fence operations
US20140274043A1 (en) * 2013-03-15 2014-09-18 Qualcomm Incorporated Access point selection for assistance data generation

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
FR3067900A1 (fr) 2018-12-21
EP3639531A1 (fr) 2020-04-22
WO2018229227A1 (fr) 2018-12-20
FR3067900B1 (fr) 2020-10-09

Similar Documents

Publication Publication Date Title
EP2120411A1 (fr) Adaptation du statut de présence de messagerie instantaneé
FR3074002B1 (fr) Procede d&#39;assistance a la configuration a distance d&#39;une carte euicc et systeme mettant en œuvre un tel procede
WO2020043877A1 (fr) Procede de localisation de donnees, systeme de controle, dispositif emetteur
EP2942244A1 (fr) Dispositif, système et procédé de suivi et de repérage de véhicule
EP3642641B1 (fr) Geolocalisation sans gps par un traceur mixte wifi et lpwan
EP2942245A1 (fr) Dispositif de suivi et de repérage de véhicule
EP3639531B1 (fr) Géolocalisation wifi de biens ou de personnes
EP3172939B1 (fr) Balise informative a multiples interfaces de communication
FR2864279A1 (fr) Procede pour ajouter des donnees de caracterisation pendant une saisie d&#39;image
FR2814898A1 (fr) Procede et dispositif de calcul de la position d&#39;une station mobile, programme informatique et support memoire correspondants
FR2865604A1 (fr) Localisation assistee, par etablissement d&#39;un canal de transport ussd, de terminaux mobiles de communication d&#39;un reseau cellulaire, pour un centre d&#39;appels
FR2865605A1 (fr) Procede de localisation assistee de terminaux mobiles de communication d&#39;un reseau cellulaire, par utilisation d&#39;un canal de transport ussd
EP4068818A1 (fr) Procédé de gestion de sécurité dans un système de communication de données, et système pour la mise en oeuvre du procédé
FR2984051A1 (fr) Procede de configuration par association d&#39;un terminal machine avec un terminal utilisateur
WO2020212255A1 (fr) Aide au positionnement d&#39;un terminal mobile
FR2987480A1 (fr) Procede et dispositif d&#39;identification d&#39;appareils electroniques portables communicants
EP2109990A2 (fr) Procede et systeme de telecommunication securise a usage simplifie
EP4342207A1 (fr) Optimisation de la géolocalisation d&#39;un terminal à partir d&#39;un ou plusieurs identifiants de dispositifs émetteurs voisins
EP3436332B1 (fr) Dispositif autonome d&#39;alerte en cas de mouvement de véhicule
FR2886753A1 (fr) Dispositif et procede pour attester de la presence d&#39;un individu dans un endroit donne a un instant donne
WO2023046852A1 (fr) Coopération entre deux méthodes de géolocalisation d&#39;un terminal d&#39;un système de communication sans fil
EP2494764A1 (fr) Procede d&#39;authentification d&#39;un terminal mobile de communication pour la fourniture d&#39;un service de donnees, systeme de fourniture de service et terminal associes
FR3110316A1 (fr) Procédé de gestion d’une communauté virtuelle d&#39;utilisateurs de terminaux
CH709924A2 (fr) Balise à multiples interfaces de communication.
WO2019057770A1 (fr) Procede de verification de la validite d&#39;une ligne telephonique d&#39;un utilisateur

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20201013

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20210615

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1447184

Country of ref document: AT

Kind code of ref document: T

Effective date: 20211115

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602018026455

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20211110

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1447184

Country of ref document: AT

Kind code of ref document: T

Effective date: 20211110

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220210

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220310

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220310

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220210

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220211

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602018026455

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20220811

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20220630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220614

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220630

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220614

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220630

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230428

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20180614

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20250617

Year of fee payment: 8

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20250625

Year of fee payment: 8

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20250513

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211110