WO2017202743A1 - Procede d'echange de donnees entre un objet connecte et un serveur central - Google Patents

Procede d'echange de donnees entre un objet connecte et un serveur central Download PDF

Info

Publication number
WO2017202743A1
WO2017202743A1 PCT/EP2017/062212 EP2017062212W WO2017202743A1 WO 2017202743 A1 WO2017202743 A1 WO 2017202743A1 EP 2017062212 W EP2017062212 W EP 2017062212W WO 2017202743 A1 WO2017202743 A1 WO 2017202743A1
Authority
WO
WIPO (PCT)
Prior art keywords
specific information
dns
information
dedicated
connected object
Prior art date
Application number
PCT/EP2017/062212
Other languages
English (en)
Inventor
Joseph TORRENTE
Paul Mazars
Original Assignee
Srazam
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 Srazam filed Critical Srazam
Priority to EP17729785.0A priority Critical patent/EP3466038A1/fr
Publication of WO2017202743A1 publication Critical patent/WO2017202743A1/fr

Links

Classifications

    • 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]

Definitions

  • the present invention relates to a method of exchanging data between a connected object and a central server. More particularly, the method relates to an exchange method using a Wi-Fi access point.
  • the exchange comprises at least the sending of information by the object to the central server, without necessarily requiring feedback from the central server to said object.
  • connected object is meant any information processing device comprising means of connection to a data communication network.
  • a connected object is typically mobile, that is to say likely to connect to the communication network from various geographical positions. Although not strictly required by the invention, it makes sense in the context of mobile connected objects.
  • Such a connected object can connect to the communication network according to any connection technology ranging from wired technologies such as Ethernet to all wireless technologies, that is to say using a radio connection technology such as Bluetooth, Zigbee, Wi-Fi, WiMAX or others.
  • a radio connection technology such as Bluetooth, Zigbee, Wi-Fi, WiMAX or others.
  • FIG. 1 illustrates a Wi-Fi connection between a connected object and a central server.
  • a connected object 1.1 establishes a connection according to the Wi-Fi protocol with a Wi-Fi access point 1.2.
  • the Wi-Fi access point is connected to the communication network 1.3 of an Internet service provider, also called operator, which operates the access point 1.2.
  • the network 1.3 of the operator is itself connected to Internet 1.4, network to which 1.5 servers are also connected.
  • the connections between the access point 1.2 and the network of the operator, as well as between the latter and the Internet can use any type of technology. These are typically high speed wired Ethernet or fiber optic connections.
  • the Wi-Fi enabled connected object scans its radio environment and detects the access point. This results in an exchange phase at the MAC (Media Access Control) level to establish communication with the access point.
  • the connected object receives once this first connection established, an IP (Internet Protocol in English) configuration, typically according to the DHCP protocol (Dynamic Host Configuration Protocol in English).
  • IP Internet Protocol in English
  • DHCP Dynamic Host Configuration Protocol in English
  • This configuration contains an IP address, a subnet mask, the address of a gateway to allow the routing of IP packets, as well as the address of a name server, DNS (Domain Name Server) for the resolution of the names plus any additional parameters.
  • DNS Domain Name Server
  • the connected object then configures its IP interface with the received parameters. Therefore, it can communicate with any device connected to the network using any type of IP-based protocol, such as establishing a Web connection using the HTTP protocol (Hyper Text Transfer Protocol in English).
  • connection at the MAC level between the connected object and the access point may be subject to different authentication modes.
  • any Wi-Fi enabled information processing device is allowed to connect to the access point.
  • a connected object can thus use an open access point without having to have any particular authentication information.
  • the connection is subject to an authentication protocol, typically on the basis of a login name (login) and a password.
  • the object must then have this login name and password to establish the connection with the access point.
  • the communication between the connected object and the access point is then encrypted using this information.
  • Several authentication and encryption protocols can be implemented possessing various levels of security. We can mention, for example, protocols such as WEP (Wired Equivalent Privacy in English), WPA (Wi-Fi Protected Access in English) or WPA2, a variant of the previous protocol. This mode of authentication therefore requires registration with the operator and obtaining a login name and password to be able to connect to the access point.
  • the authentication is then managed by the operator typically using an authentication server such as a RADIUS server (Remote Authentication Dial-in User Service).
  • RADIUS server Remote Authentication Dial-in User Service
  • HTTP HyperText Transfer Protocol
  • UAM Universal Access Method
  • the connection at the MAC level is open, ie the connected object can always connect to the access point. But once connected, he can not access services on the Internet because the communication ports are blocked.
  • a connected object wishing to exchange information with a central server is therefore obliged to implement a relatively heavy TCP / IP connection procedure with this server. Except for negotiating registration with operators providing Wi-Fi access, only open access points may be used. These open access points are rare because legal obligations of traceability tend to make them disappear in favor of secure access by authentication.
  • the present invention aims to solve the aforementioned drawbacks.
  • the information is exchanged between the connected object and the central server by means of a name resolution request (DNS) from a domain name server specific to the domain to which the central server belongs.
  • DNS name resolution request
  • This name server is adapted to interpret the useful information transmitted in the request and possibly respond by introducing the information in return in the response to the DNS query.
  • the term "request” must be understood in a wider sense than conventionally known, insofar as it does not necessarily require a feedback of information. the share of the central server in response to the object being the origin of the request.
  • the exchange of information via a DNS query according to the invention is possible with an access point opened or protected by an HTTP authentication. Only access points protected by encrypted authentication can be used unless you have the necessary authentication credentials.
  • the invention relates to a method for exchanging specific information between a connected object and a central server comprising the following steps performed by said connected object having a Wi-Fi interface:
  • the method further comprises:
  • the method according to the invention advantageously makes it possible to connect mobile objects via Wi-Fi via the central server when they pass close to any hotspot. or access point of an Internet Service Provider (ISP), provided that the object remains in the radio coverage area of the hotspot for at least 100 ms after establishing the radio connection at the MAC level with that latest.
  • ISP Internet Service Provider
  • the method according to the invention advantageously makes it possible to connect objects in any region having hotspots of an ISP, that is to say in practice worldwide, without the need to have previously concluded agreements of the type roaming with these.
  • the specific information sent by the object relates to a service related to the connected object and to a function of said object.
  • the method further comprises a step of receiving a DNS response transmitted by said central server and containing information in response to the specific information transmitted in the DNS request.
  • the object can send to the server specific information that is to say not related to the process of obtaining an IP address by the object from the central server according to the DNS protocol.
  • the information in response is transmitted in the "RDATA" field of a resource record of the DNS response.
  • the specific information is coded in the form of a sequence of labels concatenated to the dedicated subdomain.
  • the specific information is distributed and transmitted via a plurality of DNS requests.
  • the invention also relates to a method for exchanging specific information between a connected object and a central server comprising the following steps executed by said central server:
  • said specific information relates to a service related to the connected object and to a function of said object.
  • the method furthermore comprises:
  • the central server transmits information specific to the object to allow an exchange with the object at the origin of the request.
  • the information in response is transmitted in the "RDATA" field of a resource record of the DNS response.
  • This feature is particularly advantageous in that the sending of the information in response is achieved without using conventional connection ports, which are closed in a link that has not yet resolved its membership in an Access Provider. Internet.
  • the response information is sent through the port 53 serving the Domain Name Resolution Service (DNS), which remains open.
  • DNS Domain Name Resolution Service
  • the extracted specific information is coded in the form of a label sequence concatenated to the dedicated subdomain.
  • This feature advantageously makes it possible to identify a frame as a hierarchical sequence of subdomains which will direct the frame (via the delegation of address) to the specific server for the specific processing. By managing this hierarchy, we can direct the frame to one or more specific servers executing different and appropriate treatments.
  • the invention also relates to a connected object adapted for implementing the method according to the invention.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method according to the invention when said program is executed on a computer.
  • the invention also relates to an information storage means, removable or not, partially or completely readable by a computer or a microprocessor comprising code instructions of a computer program for executing each of the steps of the method according to the invention. the invention.
  • steps of the above method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented by a microprocessor, this program comprising instructions adapted to the implementation of the steps of the method such as than mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a microprocessor-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a microcircuit ROM, or a magnetic recording means, for example a hard disk, or a flash memory.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention may in particular be downloaded to a storage platform of an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the aforementioned information carrier and computer program have characteristics and advantages similar to the method they implement.
  • Figure 1 illustrates a Wi-Fi connection between a connected object and a central server
  • Figure 2 illustrates the hierarchy of domain names
  • FIG. 3 illustrates an exemplary embodiment of the data exchange according to the invention between a connected object and a central server
  • FIG. 4 is a schematic block diagram of an information processing device for implementing one or more embodiments of the invention.
  • An Internet address is assigned to each network interface connecting an information processing device to the Internet regardless of the connection technology used.
  • Two address formats coexist, IPv4-based addresses consisting of four bytes, for example "192.168.10.5" and IPv6-based addresses consisting of 16 bytes. These addresses are used by all IP-based protocols for machine-to-machine communication. However, they are not easily memorized and manipulated by a human. That's why humans refer to machines using domain names.
  • DNS Domain Naine System
  • a service called Domain Naine System (DNS) resolution allows you to translate a domain name into an IP address and conversely to translate an IP address into a domain name. This service is described in Request for Comment (RFC) Number 1035.
  • DNS Domain Naine System
  • Domain names are organized hierarchically and take the form of any number of subdomains separated by periods. For example, the domain “www.apple.com” breaks down hierarchically into “com” which is the main domain, “apple” which refers to the highest level subdomain and “www” which refers to the level subdomain inferior.
  • This domain name designates a commercial service, domain "com”, belonging to the company Apple (registered trademark), sub-domain “apple”, and refers to the web service of this company, subdomain "www”.
  • domain “ftp.dept-physics.universes.edu” refers to the file transfer service, sub-domain “ftp”, of the physics department, subdomain “dept-physics", of the University of Rennes, sub-domain “univ-rennes”, the latter being an educational entity, domain "edu”.
  • DNS server provides the IP address corresponding to a domain. For example, when you type the domain "www.apple.com” in a web browser, it starts by making a DNS request to a DNS server that has the IP address in its configuration to obtain the IP address of the Apple web service. It is only then that it is able to send an HTTP request to the latter by using this IP address.
  • Figure 2 illustrates the hierarchy of domain names.
  • node 2.2 represents the “com” domain.
  • the subdomains of the domain “com” appear as child nodes of the node “com” 2.2.
  • the node 2.3 represents, for example, the subdomain "apple” and the child node 2.4, the subdomain "www”.
  • All Internet domain names can be represented as a huge tree.
  • the organization of the name resolution service, or DNS service reflects this hierarchical tree structure of domain names.
  • root DNS servers to which requests for resolution of a domain name are addressed.
  • DNS servers in charge of different subtrees of the tree of domain names.
  • a request to resolve the domain name "www.apple.com” will be directed to a root DNS server corresponding to the root node 2.1.
  • This root server will extract the top-level domain “com” and relay the request to a name server in charge of the domain "com” corresponding to the node 2.2 of the tree.
  • this server will extract the top-level subdomain "apple” and will relay the request to the name server of the Apple company, corresponding to the node 2.3 of the tree.
  • the latter in charge of the addresses of the computers of the company, can answer the request by giving the IP address corresponding to the subdomain "www".
  • the response will then be transmitted via the different DNS servers until the origin of the request.
  • a cache system is maintained on each DNS server to store the latest requests and their responses.
  • the information thus stored in the cache DNS servers have a limited lifetime called TTL ⁇ Time To Live in English).
  • This lifetime is set by the lower level DNS server.
  • Apple's DNS server might set a lifetime of one day for name information for its subdomain.
  • Wi-Fi access points implementing an HTTP authentication mode have their communication ports closed, their opening being subjected to the success of an authentication procedure via an authentication WEB page.
  • the inventors have however noticed that the dedicated port address resolution service, specifically the port 53 dedicated to the DNS is open.
  • the central server receiving the exchange with the connected object implements a DNS server dedicated to the communication with the connected objects.
  • This server manages a specific subdomain, call the "service-oc" for connected objects service, and registers for this management with a third party DNS server to which it is attached.
  • the central server is managed by an Internet service provider "fai”
  • the sub-domain managed by the DNS server of the connected objects service could be the sub-domain "service-oc”.
  • any DNS request for a sub-domain of the sub-domain "service-oc.fai.com” will be relayed by the DNS servers to be solved, in fine, by the dedicated DNS server implemented on the central server recipient of the exchange .
  • Such a subdomain takes the form "XXX.service-oc.fai.com” where "XXX” can be a null string where any number of subdomain labels are separated by periods.
  • the subdomain string "XXX” will therefore typically have the form:
  • Label l.label2 labelN each label having not more than 63 characters and being limited to 7-bit ASCII characters, a complete domain name string not exceeding 255 characters.
  • the amount of specific information to be transmitted exceeds the capacity of a domain name, it can be transmitted in the form of a plurality of DNS requests.
  • the specific information is then distributed in all of these DNS requests as previously described.
  • a connected object wishing to communicate specific information to the central server can therefore encode this information in a subdomain chain of the "label l.label2 labelN" type, concatenate this string containing the information to be transmitted to the sub-domain of the connected objects service.
  • "Service-oc.fai.com” and send a DNS request requesting the resolution of the subdomain resulting from this concatenation.
  • Specific information is understood as information not related to the standard operation of the name resolution service. This information is specific in the sense that it relates to the service related to the connected object and its function.
  • the object may include one or more sensors capable of measuring physical or physicochemical quantities, such as acceleration, speed, temperature, atmospheric pressure, the concentration of chemical compounds such as fine particles in the atmosphere , optical power or brightness, fluid flow, power and voltage and / or electrical current, etc.
  • sensors capable of measuring physical or physicochemical quantities, such as acceleration, speed, temperature, atmospheric pressure, the concentration of chemical compounds such as fine particles in the atmosphere , optical power or brightness, fluid flow, power and voltage and / or electrical current, etc.
  • the object can also calculate one or more parameters from the quantities measured by the sensors, such as an indicator of the quality of the air and / or water, or a pollution indicator, etc.
  • the object may have the function of reporting to a server the quantities measured by these sensors, or one or more of these parameters.
  • the specific information may comprise measurements and / or parameters related to these measurements, i.e. calculated from values measured by the sensors associated with the object.
  • the object may have the function of counting events, such as the number of times the object passes or leaves a particular location, the number of times an element connected to the object is in motion, the number of times the object is powered / unpowered.
  • the sending of specific information can be done when exceeding a predetermined threshold, in a clocked manner or when unauthorized movement is detected.
  • Other indicators may also be associated with this specific information, such as time and / or geographical location indicators.
  • the object will determine the time and location of a shock whose amplitude threshold is defined.
  • a service linked to the object may consist of sending in the form of concatenated labels any specific information that may include, for example:
  • - data provided by the sensors such as temperature, vibration, acceleration, speed, strain gages, power, voltage and / or intensity electric, atmospheric pressure, flow of fluids, luminous or luminous intensity, opening or closing of doors or valves, composition and measurements of chemical pollution, and more generally all values of physical and / or physical quantities -chemical provided by technical sensors;
  • radio environment data and in particular GSM data, such as data relating to operators of the ISM band ⁇ Industry, Science and Medical), Wi-Fi and MAC addresses, for example, with a view to geolocation by approximation with a database ;
  • a geographical position provided by satellite eg GPS, Galileo, etc.
  • other consumption-based geolocation means adapted to connected objects, such as LoRa or Sigfox technologies, or distance measurement systems using transponders "or hyperbolic localization;
  • These messages can usefully include an identifier of the object and be time stamped and / or numbered.
  • these messages may be transmitted by any radio access point or hotspot without the need for identification or authentication data (eg login and password), in order to achieve natively (ie excluding any agreement with a regional ISP) a worldwide connection.
  • identification or authentication data eg login and password
  • the dedicated DNS server implemented on the Exchange Recipient Central Server is a standard DNS server except that it is adapted to retrieve the subdomain string when it receives a resolution request for a subdomain. This string is then passed to the recipient service on the central server.
  • the information can be transmitted for effective processing by a another server connected to the central server. It is then considered that the information exchange takes place between the connected object and the server hosting the dedicated DNS server independently of the processing of the information subsequently transmitted.
  • a connected object can transmit information in the form of a DNS query to the central server.
  • the messages exchanged according to the name resolution protocol as defined in the RFC 1035 standard contain resource records called RRs (for Resource Record in English). These RRs are contained in both DNS queries and responses to these queries. These RRs contain a data field (RDATA) and a field length (RDLENGTH) which make it possible to encode any useful complementary information in a DSN message.
  • RDATA data field
  • RDLENGTH field length
  • a DNS message can have up to 3 RRs including an additional RR to transmit additional information.
  • this information when a response information transmission is required from the central server to the connected object having made the request, this information may be encoded in this additional RR, for example.
  • This information is then transmitted by returning the central server to the connected object in the form of a DNS response sent by the dedicated DNS server and adapted to the connected objects service.
  • This response is relayed by the entire chain of DNS servers until it reaches the connected object.
  • the lifetime of the response is set by the RR TTL field. This lifetime is advantageously set to 0 to prevent the different DNS servers to memorize the response in their cache. Indeed, a memorization in the cache of a Intermediate DNS server between the connected object and the central server results in a new request with the same subdomain name not reaching the central server and responding to the response stored in the cache.
  • FIG. 3 illustrates an exemplary embodiment of the data exchange according to the invention between a connected object and a central server.
  • the connected object scans its radio environment to detect an access point. When it finds an access point, it starts the connection process at the MAC level with the access point by sending a connection request in a step 3.2.
  • This request typically contains a request for IP connection parameters according to the DHCP protocol.
  • This connection attempt may succeed or fail.
  • step 3.3 a test on the success of the connection is made. If the connection failed, the process ends with the final step 3.4. If successful, the connection is established. The success of the connection typically depends, as we have seen, on the authentication mode implemented by the access point.
  • the connection at the MAC level succeeds.
  • the connection request must contain a shared secret necessary to establish the encrypted connection between the connected object and the access point. In this case, except that the connected object knows this secret, the connection fails.
  • the connected object When the connection is established, the connected object has received an IP configuration from the access point and configured its Wi-Fi interface using the received parameters. A IP-level dialogue can therefore be initiated between the connected object and the access point.
  • an open access point access by any protocol to destinations beyond the access point is possible.
  • the communication ports of the access point are closed to communications from the connected object waiting for successful authentication via a web page. Only the port 53 dedicated to the name resolution service is open.
  • the connected object issues a DNS request, step 3.5, containing the information to be transmitted as seen above concatenated to the sub-domain corresponding to the connected objects service.
  • This request is then relayed to the dedicated DNS server and adapted to the central server receiving the exchange.
  • This server extracts the information transmitted for its use by the server.
  • the dedicated DNS server receives information from an object and records the received frame in a database.
  • This frame includes, for example, the identifier of the object, a time stamp (i.e. time stamp in English), location elements and sensor measurement elements embedded on the object.
  • This database is shared with multiple application servers. Such servers are for example adapted to send notifications by email, in the case where certain measured quantities exceed predefined critical thresholds. This is particularly advantageous in the context of geofencing applications to prevent a third party that the object leaves a geographical surveillance area.
  • this response is elaborated by the central server and then transmitted to the dedicated DNS server and adapted for transmission integrated in the response of the DNS server to the received request. It is emphasized that this response step is optional, depending on the application considered, it may not be necessary.
  • the object In general, if no change in the behavior of the object is desired (eg change in the value of the critical thresholds or the rate of the items), the answer is not necessary.
  • the object in order to make it possible to modify the behavior of the object, the object is adapted to systematically wait for a response during a previously set time window. This response to the DNS request is then relayed by the intermediate DNS servers to be finally received by the connected object in step 3.6.
  • the exchange phase then ends with the final step 3.7.
  • an exchange, possibly bidirectional, of information is implemented between a connected object and a central server. This exchange is fast because it does not require the establishment of a connection between the object and the server.
  • the delay for sending the useful information is typically 50 to 100 ms against 2 to 3 s in the classic case using an HTTP request and the transmission of HTLM pages.
  • the method according to the invention eliminates the sending by the object of an HTTP request whose duration is typically between 100 and 800 ms, the redirection of the request HTTP to the portal of the ISP (typically lasting 300 to 800 ms), the receipt by the object of the HTML pages necessary to enter the login and password of the user, sending the HTML page containing the login and password of the user with acceptance of the terms and conditions, if any, of the receipt of this page for identification of the user.
  • the classical solution it is only after being identified / authenticated that the user can transmit his useful data.
  • a connection waiting of the order 5 to 10 s is noted by the user before proceeding to the transmission of its useful data.
  • a mobile phone ie moving object
  • traveling at a speed of 25 m / s or 90 km / h rarely remains for several seconds in the radio coverage area of a Wi-Fi access point.
  • the moving object since the moving object remains at least 100 ms in this coverage area, it can transmit specific information to the central server.
  • FIG. 4 is a schematic block diagram of an information processing device 4.0 for implementing one or more embodiments of the invention.
  • the information processing device 4.0 may be a peripheral such as a microcomputer, a workstation or a mobile telecommunication terminal.
  • the device 4.0 comprises a communication bus connected to:
  • a central processing unit 4.1 such as a microprocessor, denoted CPU
  • a random access memory 4.2 denoted RAM
  • the memory capacity thereof may be supplemented by an optional RAM connected to an extension port, for example;
  • ROM read-only memory
  • computer programs for implementing the embodiments of the invention
  • a network interface 4.4 is normally connected to a communication network on which digital data to be processed are transmitted or received.
  • the network interface 4.4 may be a single network interface, or composed of a set of different network interfaces (eg wired and wireless, interfaces or different types of wired or wireless interfaces). Data packets are sent on the network interface for transmission or are read from the network interface for reception under the control of the software application executed in the processor 4.1;
  • a user interface 4.5 for receiving entries from a user or for displaying information to a user
  • the executable code can be stored in a read-only memory 4.3, on the storage medium 4.6 or on a removable digital medium such as for example a disk.
  • the executable code of the programs can be received by means of a communication network, via the network interface 4.4, in order to be stored in one of the storage means of the communication device 4.0, such as the storage medium 4.6, before being executed.
  • the central processing unit 4.1 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to one of the embodiments of the invention, instructions which are stored in one aforementioned storage means. After power-up, the CPU 4.1 is able to execute instructions stored in the main RAM 4.2, relating to a software application, after these instructions have been loaded from the ROM for example. Such software, when executed by the processor 4.1, causes the steps of the flowcharts shown in Figure 3 to be executed.
  • the apparatus is a programmable apparatus that uses software to implement the invention.
  • the present invention may be implemented in the hardware (for example, in the form of a specific integrated circuit or ASIC).

Landscapes

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

Abstract

Selon l'invention, l'information est échangée entre l'objet connecté et le serveur central au moyen d'une requête DNS auprès d'un serveur de noms de domaine spécifique au domaine auquel appartient le serveur central. Ce serveur de nom est adapté pour interprété l'information utile transmise dans la requête et éventuellement répondre en introduisant dans la réponse à la requête DNS l'information en retour. L'échange d'information via une requête DNS selon l'invention est possible avec un point d'accès ouvert ou protégé par une authentification HTTP.

Description

PROCEDE D'ECHANGE DE DONNEES
ENTRE UN OBJET CONNECTE ET UN SERVEUR CENTRAL
La présente invention concerne un procédé d'échange de données entre un objet connecté et un serveur central. Plus particulièrement, le procédé concerne un procédé d'échange utilisant un point d'accès Wi-Fi.
Dans le cadre de la présente invention, l'échange comprend au moins l'envoi d'informations par l'objet au serveur central, sans nécessiter forcément un retour d'information de la part du serveur central audit objet.
On entend dans ce document par objet connecté tout dispositif de traitement de l'information comprenant un moyen de connexion à un réseau de communication de données. Un tel objet connecté est typiquement mobile, c'est-à-dire susceptible de se connecter au réseau de communication à partir de diverses positions géographiques. Bien que non strictement requis par l'invention, celle-ci prend tout son sens dans le contexte d'objets connectés mobiles.
Un tel objet connecté peut se connecter au réseau de communication selon toute technologie de connexion allant de technologies filaires comme Ethernet à l'ensemble des technologies sans fil, c'est-à-dire utilisant une technologie de connexion radio telle que Bluetooth, Zigbee, Wi-Fi, WiMAX ou autres. Nous nous intéressons dans ce document plus particulièrement aux objets connectés utilisant la technologie Wi-Fi, c'est-à-dire utilisant l'un des standards de la famille IEEE 802-11.
La Figure 1 illustre une connexion Wi-Fi entre un objet connecté et un serveur central. Un objet connecté 1.1 établit une connexion selon le protocole Wi-Fi avec un point d'accès Wi-Fi 1.2. Le point d'accès Wi-Fi est connecté au réseau 1.3 de communication d'un fournisseur d'accès Internet, aussi appelé opérateur, qui opère le point d'accès 1.2. Le réseau 1.3 de l'opérateur est lui-même connecté à Internet 1.4, réseau auquel les serveurs 1.5 sont eux-aussi connectés. Les connexions entre le point d'accès 1.2 et le réseau de l'opérateur, ainsi qu'entre ce dernier et Internet peut utiliser tout type de technologie. Il s'agit généralement de connexions filaires à haut débit du type Ethernet ou fibre optique. Pour que l'objet connecté 1.1 puisse communiquer avec un serveur 1.5 il doit tout d'abord se connecter au point d'accès 1.2. Cette connexion s'effectue selon l'une des normes IEEE 802-11 et se passe selon le schéma suivant. L'objet connecté compatible Wi-Fi scanne son environnement radio et détecte le point d'accès. Il s'ensuit une phase d'échange au niveau MAC (Media Access Control en anglais) pour établir une communication avec le point d'accès. L'objet connecté reçoit alors une fois cette première connexion établie, une configuration IP (Internet Protocol en anglais), typiquement selon le protocole DHCP (Dynamic Host Configuration Protocol en anglais). Cette configuration contient une adresse IP, un masque de sous-réseau, l'adresse d'une passerelle pour permettre le routage de paquets IP, ainsi que l'adresse d'un serveur de nom, DNS (Domain Name Serveur en anglais) pour la résolution des noms plus d'éventuels paramètres supplémentaires. L'objet connecté configure alors son interface IP avec les paramètres reçus. Dès lors, il peut communiquer avec tout appareil connecté au réseau en utilisant tout type de protocole basé sur IP, comme par exemple établir une connexion Web en utilisant le protocole HTTP (Hyper Text Transfer Protocol en anglais).
La connexion au niveau MAC entre l'objet connecté et le point d'accès peut être soumise à différents modes d'authentification.
Selon un premier mode d'authentification dit ouvert, aucune authentification n'est requise. Dans ce cas tout dispositif de traitement de l'information compatible Wi- Fi est autorisé à se connecter au point d'accès. Un objet connecté peut ainsi utiliser une point d'accès ouvert sans devoir posséder d'information d'authentification particulière.
Selon un second mode d'authentification dit chiffré, la connexion est soumise à un protocole d'authentification, typiquement sur la base d'un nom de connexion (login en anglais) et d'un mot de passe. L'objet doit alors posséder ce nom de connexion et ce mot de passe pour établir la connexion avec le point d'accès. La communication entre l'objet connecté et le point d'accès est alors chiffrée à l'aide de ces informations. Plusieurs protocoles d'authentification et de chiffrement peuvent être mis en œuvre possédant divers niveaux de sécurité. On peut citer, par exemple, des protocoles tels que WEP (Wired Equivalent Privacy en anglais), WPA (Wi-Fi Protected Access en anglais) ou encore WPA2, une variante du protocole précédent. Ce mode d' authentification nécessite donc une inscription auprès de l'opérateur et l'obtention d'un nom de connexion et d'un mot de passe pour pouvoir se connecter au point d'accès. L' authentification est alors gérée par l'opérateur typiquement en utilisant un serveur d' authentification tel qu'un serveur RADIUS (Remote Authentication Dial-in User Service en anglais). Un troisième mode d' authentification dit HTTP est décrit dans le document intitulé « Best Current Practices for Wireless Internet Service Provider (WISP) Roaming » disponible auprès du consortium « Wi-Fi Alliance » en charge de tester et de valider la compatibilité des appareils Wi-Fi et de promouvoir cette technologie. Ce document décrit une méthode d'accès universel UAM (Universal Access Method en anglais), basée sur un navigateur Internet (browser en anglais), à un point d'accès Wi- Fi. Selon cette méthode la connexion au niveau MAC est ouverte, c'est-à-dire que l'objet connecté peut toujours se connecter au point d'accès. Mais une fois connecté, il ne peut pas accéder à des services sur Internet car les ports de communication sont bloqués. Il doit alors utiliser un navigateur Web pour envoyer une requête HTTP sur un serveur quelconque. Cette requête est alors interceptée par le point d'accès et une redirection est opérée vers une page Web d' authentification invitant le navigateur à communiquer un nom de connexion et un mot de passe. Une fois authentification validée, les ports sont débloqués et l'accès au réseau de communication est alors possible. Ce mode d' authentification est très courant pour les accès publics, notamment dans les gares, les aéroports, les cafés et restaurants, les hôtels etc.
Un objet connecté souhaitant échanger des informations avec un serveur central est donc obligé de mettre en œuvre une procédure relativement lourde de connexion TCP/IP avec ce serveur. Sauf à négocier une inscription auprès d'opérateurs fournissant un accès Wi-Fi, seuls les points d'accès ouverts peuvent être utilisés. Ces points d'accès ouverts sont rares car des obligations légales de traçabilité tendent à les faire disparaître au profit d'accès sécurisés par une authentification. La présente invention a pour but de résoudre les inconvénients précités. Selon l'invention, l'information est échangée entre l'objet connecté et le serveur central au moyen d'une requête en résolution de nom (DNS) auprès d'un serveur de noms de domaine spécifique au domaine auquel appartient le serveur central. Ce serveur de nom est adapté pour interpréter l'information utile transmise dans la requête et éventuellement répondre en introduisant dans la réponse à la requête DNS l'information en retour. Ainsi, il convient de souligner que dans le cadre de la présente invention, le terme "requête" doit être compris dans une acception plus large que celle connue de manière conventionnelle, dans la mesure où elle ne nécessite pas forcément un retour d'information de la part du serveur central en réponse à l'objet étant à l'origine de la requête.
L'échange d'information via une requête DNS selon l'invention est possible avec un point d'accès ouvert ou protégé par une authentification HTTP. Seuls les points d'accès protégés par une authentification chiffrée ne peuvent être utilisés sauf à posséder les crédits d' authentification nécessaires.
L'invention concerne un procédé d'échange d'information spécifique entre un objet connecté et un serveur central comprenant les étapes suivantes exécutées par ledit objet connecté disposant d'une interface Wi-Fi :
- une étape de détection d'un point d'accès Wi-Fi dans l'environnement radio de l'objet connecté ;
- une étape d'envoi d'une requête de connexion au niveau MAC au point d'accès détecté ;
caractérisé en ce que, en cas de succès de la connexion au niveau MAC, le procédé comporte en outre :
une étape d'envoi d'une requête DNS pour la résolution d'un nom de domaine intégrant un sous-domaine dédié, ledit sous-domaine dédié étant géré par un serveur DNS dédié sur ledit serveur central, ladite requête DNS contenant l'information spécifique à transmettre, ladite information spécifique étant non relative au fonctionnement standard d'un service de résolution du nom de domaine.
Le procédé selon l'invention permet avantageusement de connecter par Wi-Fi des objets mobiles via le serveur central, lors de leur passage à proximité de tout hotspot ou point d'accès d'un Fournisseur d'Accès à Internet (FAI), pourvu que l'objet reste dans la zone de couverture radio dudit hotspot pendant au moins 100 ms après l'établissement de la connexion radio au niveau MAC avec ce dernier.
A plus grande échelle, le procédé selon l'invention permet avantageusement de connecter des objets dans toute région disposant de hotspots d'un FAI, c'est-à-dire en pratique mondialement, sans nécessité d'avoir préalablement conclu des accords de type roaming avec ces derniers.
Selon une particularité de l'invention, l'information spécifique envoyée par l'objet est relative à un service lié à l'objet connecté et à une fonction dudit objet.
Selon un mode particulier de réalisation, le procédé comporte en outre une étape de réception d'une réponse DNS émise par ledit serveur central et contenant une information en réponse à l'information spécifique transmise dans la requête DNS.
Ainsi, l'objet peut envoyer au serveur de l'information spécifique c'est-à-dire non relative au processus d'obtention d'une adresse IP par l'objet auprès du serveur central selon le protocole DNS.
Selon un mode particulier de réalisation, l'information en réponse est transmise dans le champ « RDATA » d'un enregistrement de ressource de la réponse DNS.
Selon un mode particulier de réalisation, l'information spécifique est codée sous la forme d'une séquence de labels concaténée au sous-domaine dédié.
Selon un mode particulier de réalisation, l'information spécifique est répartie et transmise via une pluralité de requêtes DNS. L'invention concerne également un procédé d'échange d'information spécifique entre un objet connecté et un serveur central comprenant les étapes suivantes exécutées par ledit serveur central :
- une étape de réception d'une requête DNS pour la résolution d'un nom de domaine dédié par un serveur DNS dédié et adapté ;
- une étape d'extraction d'une information spécifique contenue dans ladite requête DNS par le serveur DNS dédié et adapté ; - une étape de transmission de ladite information spécifique à un service dédié aux objets connectés, ladite information spécifique étant non relative au fonctionnement standard d'un service de résolution du nom de domaine.
Selon une spécificité de l'invention, ladite information spécifique est relative à un service lié à l'objet connecté et à une fonction dudit objet.
Selon un mode particulier de réalisation, le procédé comprend en outre :
- une étape de transmission d'une réponse DNS à la requête DNS intégrant une information en réponse à l'information spécifique reçue. Ainsi, le serveur central transmet une information spécifique à l'objet pour permettre un échange avec l'objet à l'origine de la requête.
Selon un mode particulier de réalisation, l'information en réponse est transmise dans le champ « RDATA » d'un enregistrement de ressource de la réponse DNS.
Cette caractéristique est particulièrement avantageuse en ce que l'envoi de l'information en réponse est réalisé sans utiliser les ports conventionnels de connexion, ceux-ci étant fermés dans une liaison qui n'a pas encore résolu son appartenance à un Fournisseur d'Accès Internet. Ainsi, l'information de réponse est envoyée à travers le port 53 servant au service de résolution des noms de domaines (DNS), celui-ci restant toujours ouvert.
Selon un mode particulier de réalisation, l'information spécifique extraite est codée sous la forme d'une séquence de labels concaténée au sous-domaine dédié.
Cette caractéristique permet avantageusement d'identifier une trame comme étant une suite hiérarchique de sous-domaines qui orientera la trame (par l'intermédiaire de la délégation d'adresse) vers le serveur spécifique pour le traitement spécifique. En gérant cette hiérarchie, on peut orienter la trame vers un ou plusieurs serveurs spécifiques exécutant des traitements différents et appropriés.
L'invention concerne également un objet connecté adapté pour la mise en œuvre du procédé selon l'invention. L'invention concerne également un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l'invention lorsque ledit programme est exécuté sur un ordinateur.
L'invention concerne également un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'invention.
Dans un mode particulier de réalisation, des étapes du procédé précité sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un microprocesseur, ce programme comprenant des instructions adaptées à la mise en œuvre des étapes du procédé tel que mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en œuvre.
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après en relation avec les dessins annexés, donnés à titre d'exemples non limitatifs :
la Figure 1 illustre une connexion Wi-Fi entre un objet connecté et un serveur central ;
la Figure 2 illustre la hiérarchie des noms de domaine ;
la Figure 3 illustre un exemple de réalisation de l'échange de données selon l'invention entre un objet connecté et un serveur central ;
la Figure 4 est un bloc-diagramme schématique d'un dispositif de traitement de l'information pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention. Une adresse Internet est attribuée à chaque interface réseau connectant un dispositif de traitement de l'information au réseau Internet quelque soit la technologie de connexion utilisée. Deux formats d'adresses coexistent, les adresses selon le protocole IPv4 constituées de quatre octets, par exemple « 192.168.10.5 » et les adresses selon le protocole IPv6 constituées de 16 octets. Ces adresses sont utilisées par tous les protocoles basés sur IP pour la communication de machine à machine. Toutefois, elles ne sont pas facilement mémorisables et manipulables par un humain. C'est pourquoi les humains font référence aux machines à l'aide de noms de domaine. Un service appelé résolution de nom de domaine ou DNS (Domain Naine System) permet de traduire un nom de domaine en adresse IP et à l'inverse de traduire une adresse IP en nom de domaine. Ce service est décrit dans la requête pour commentaire (RFC pour Request For Comment en anglais) numéro 1035.
Les noms de domaine sont organisés de manière hiérarchique et prennent la forme d'un nombre quelconque de sous-domaines séparés par des points. Par exemple, le domaine « www.apple.com » se décompose hiérarchiquement en « com » qui est le domaine principal, « apple » qui désigne le sous-domaine de plus haut niveau et « www » qui désigne le sous-domaine de niveau inférieur. Ce nom de domaine désigne un service commercial, domaine « com », appartenant à la société Apple (marque déposée), sous-domaine « apple », et désigne le service Web de cette société, sous- domaine « www ». De manière similaire, le domaine « ftp.dept-physique.univ- rennes.edu » désigne le service de transfert de fichier, sous-domaine « ftp », du département de physique, sous domaine « dept-physique », de l'université de Rennes, sous-domaine « univ-rennes », cette dernière étant une entité éducative, domaine « edu ». Une requête à un serveur de nom de domaine appelé serveur DNS permet d'obtenir l'adresse IP correspondant à un domaine. Par exemple, lorsque l'on tape le domaine « www.apple.com » dans un navigateur Web, ce dernier commence par effectuer une requête DNS auprès d'un serveur DNS dont il dispose de l'adresse IP dans sa configuration pour obtenir l'adresse IP du service web d'Apple. Ce n'est qu'ensuite qu'il est en mesure d'adresser une requête HTTP à ce dernier en utilisant cette adresse IP. La Figure 2 illustre la hiérarchie des noms de domaine. Par exemple, à partir d'une racine 2.1, tous les domaines de plus haut niveau, tels que « com », « fr », « edu », « gov » etc. sont des fils de la racine. Par exemple, le nœud 2.2 représente le domaine « com ». Les sous-domaines du domaine « com » apparaissent comme nœuds fils du nœud « com » 2.2. Le nœud 2.3 représente, par exemple, le sous-domaine « apple » et le nœud fils 2.4, le sous-domaine « www ». L'intégralité des noms de domaines Internet peut ainsi être représentée sous la forme d'un immense arbre. L'organisation du service de résolution de nom, ou service DNS, reflète cette structure hiérarchique en arbre des noms de domaine. Il existe des serveurs DNS dit racine auxquels sont adressées les requêtes en résolution d'un nom de domaine. Il existe également des serveurs DNS en charge de différents sous arbres de l'arbre des noms de domaine. Ainsi, une requête visant la résolution du nom de domaine « www.apple.com» sera dirigée vers un serveur DNS racine correspondant au nœud racine 2.1. Ce serveur racine va extraire le domaine de plus haut niveau « com » et relayer la requête vers un serveur de nom en charge du domaine « com » correspondant au nœud 2.2 de l'arbre. A nouveau ce serveur va extraire le sous-domaine de plus haut niveau « apple » et va relayer la requête vers le serveur de nom de la société Apple, correspondant au nœud 2.3 de l'arbre. Ce dernier, en charge des adresses des ordinateurs de la société, pourra répondre à la requête en donnant l'adresse IP correspondant au sous-domaine « www ». La réponse sera alors transmise via les différents serveurs DNS jusqu'à l'origine de la requête. Un système de mémoire cache est géré sur chaque serveur DNS de manière à mémoriser les dernières requêtes et leurs réponses. Ainsi une nouvelle requête pour un domaine dont la réponse est mémorisée dans le cache pourra être résolue sans relayer la requête à l'ensemble des sous-serveurs concernés, la réponse sera ainsi beaucoup plus rapide. Pour assurer qu'un changement d'adresse soit tout de même pris en compte, les informations ainsi mémorisées dans la mémoire cache des serveurs DNS sont assorties à une durée de vie limitée appelée TTL {Time To Live en anglais). Cette durée de vie est définie par le serveur DNS de plus bas niveau. Par exemple, le serveur DNS de la société Apple pourra fixer une durée de vie d'une journée pour les informations de nom relatives à son sous-domaine. Nous avons vu que les points d'accès Wi-Fi implémentant un mode d' authentification HTTP ont leurs ports de communication fermés, leur ouverture étant soumise au succès d'une procédure d' authentification via une page WEB d' authentification. Les inventeurs ont toutefois remarqué que le port dédié au service de résolution d'adresse, précisément le port 53 dédié au DNS est ouvert. En effet, la redirection vers la page WEB d' authentification requiert généralement la résolution du nom de domaine hébergeant ladite page. Il est donc possible pour un objet connecté d'émettre une requête DNS, une fois la connexion au point d'accès au niveau MAC établie, sans nécessairement s'authentifier via la page WEB d' authentification. Cette observation est à la base de l'invention.
Selon un premier aspect de l'invention, le serveur central destinataire de l'échange avec l'objet connecté implémente un serveur DNS dédié à la communication avec les objets connectés. Ce serveur gère un sous-domaine spécifique, appelons le « service-oc » pour service objets connectés, et s'inscrit pour cette gestion auprès d'un serveur DNS tiers auquel il se rattache. Par exemple, si l'accès à internet dudit serveur central est géré par un fournisseur d'accès à Internet « fai », le sous-domaine géré par le serveur DNS du service objets connectés pourrait être le sous-domaine « service- oc. fai.com ». Ainsi toute requête DNS pour un sous-domaine du sous-domaine « service-oc.fai.com » sera relayé par les serveurs DNS pour être résolu, in fine, par le serveur DNS dédié implémenté sur le serveur central destinataire de l'échange. Un tel sous-domaine prend la forme « XXX.service-oc.fai.com » où « XXX » peut être une chaîne nulle où un nombre quelconque de labels de sous-domaines séparés par des points. La chaîne de sous-domaines « XXX » aura donc typiquement la forme :
« label l.label2 labelN », chaque label ayant au plus 63 caractères et étant limitée à des caractères en ASCII sur 7 bits, une chaîne complète de nom de domaine ne pouvant excéder 255 caractères.
Avantageusement, si la quantité d'information spécifique à transmettre excède la capacité d'un nom de domaine, elle peut être transmise sous la forme d'une pluralité de requêtes DNS. L'information spécifique est alors répartie dans l'ensemble de ces requêtes DNS comme décrit précédemment.
Un objet connecté souhaitant communiquer une information spécifique au serveur central peut donc coder cette information dans une chaîne de sous-domaines du type « label l.label2 labelN », concaténer cette chaîne contenant l'information à transmettre au sous-domaine du service objets connectés « service-oc.fai.com » et transmettre une requête DNS demandant la résolution du sous-domaine résultant de cette concaténation. Une information spécifique est comprise comme une information non relative au fonctionnement standard du service de résolution de noms. Cette information est spécifique dans le sens où elle est relative au service lié à l'objet connecté et à sa fonction.
L'objet peut inclure un ou plusieurs capteurs aptes à mesurer des grandeurs physiques ou physico-chimiques, telles que l'accélération, la vitesse, la température, la pression atmosphérique, la concentration de composés chimiques tels que les particules fines dans l'atmosphère, la puissance optique ou la luminosité, le débit de fluides, la puissance et la tension et/ou intensité électrique, etc. Cette liste n'étant pas limitative, l'homme du métier pourra bien évidemment considérer tout autre type de grandeurs en fonction de l'application considérée.
L'objet peut également calculer un ou plusieurs paramètre à partir des grandeurs mesurées par les capteurs, tel qu'un indicateur de la qualité de l'air et/ou de l'eau, ou un indicateur de pollution, etc..
L'objet peut avoir pour fonction la remontée auprès d'un serveur des grandeurs mesurées par ces capteurs, ou d'un ou plusieurs de ces paramètres.
Ainsi, l'information spécifique peut comprendre des mesures et/ou des paramètres liés à ces mesures, i.e. calculés à partir de valeurs mesurées par les capteurs associés à l'objet.
A titre d'exemples illustratifs, l'objet peut avoir pour fonction le comptage d'événements, tel que le nombre de fois que l'objet passe ou quitte un endroit particulier, le nombre de fois qu'un élément raccordé à l'objet est en mouvement, le nombre de fois que l'objet est alimenté/désalimenté.
De manière générale, l'envoi des informations spécifiques peut être effectué lors du dépassement d'un seuil prédéterminé, de manière cadencée ou lorsqu'un mouvement non autorisé est détecté.
D'autres indicateurs pourront également être associés à ces informations spécifiques, tels que des indicateurs temporels et/ou de localisation géographique. Par exemple, dans le cas de la détection de chocs, l'objet déterminera le moment et l'endroit d'un choc dont le seuil d'amplitude est défini.
Ainsi, un service lié à l'objet peut consister à envoyer sous forme de labels concaténés, toute information spécifique pouvant inclure par exemple :
- des données fournies par les capteurs, telles que la température, des vibrations, l'accélération, la vitesse, des jauges de contrainte, la puissance, tension et/ou intensité électriques, la pression atmosphérique, le débit de fluides, l'intensité lumineuse ou luminosité, l'ouverture ou la fermeture de portes ou vannes, la composition et les mesures de pollution chimique, et plus généralement toutes valeurs de grandeurs physiques et/ou physico-chimiques fournies par des capteurs techniques ;
- des données d'environnement radio et en particulier GSM, telles que des données relatives aux opérateurs de la bande ISM {Industrie, Science et Médical), Wi-Fi et adresses MAC, par exemple, en vue de réaliser une géolocalisation par rapprochement avec une base de données ;
- une position géographique fournie par satellite (e.g. GPS, Galiléo, etc.) ou déterminée par d'autres moyens de géolocalisation à base consommation adaptés aux objets connectés, tels que les technologies LoRa, Sigfox ou encore des systèmes de mesure de distance par "transpondeurs" ou localisation hyperboliques ;
- des "signes de vie" périodiques adressés au système pour attester du fonctionnement de l'objet ;
- des messages envoyés au serveur cible, en vue d'obtenir en retour un ordre modifiant le comportement de l'objet.
Ces messages peuvent utilement comporter un identifiant de l'objet et être horodatés et/ou numérotés.
Il convient de noter que ces messages peuvent être transmis par tout point d'accès radio ou hotspot sans nécessiter de données d'identification ou d'authentification (e.g. login et mot de passe), de manière à réaliser nativement (c'est-à-dire en dehors de tout accord avec un FAI régional) une connexion mondiale.
On pourra considérer la transmission de tout type d'information à l'exception de contenus volumineux tels que des vidéos. L'information spécifique transmise dans une même requête DNS ne dépassera pas 255 octets. Toutefois, dans le cas où cette information spécifique a une taille supérieure à 255 octets, elle pourra être transmise par l'envoi de plusieurs requêtes DNS.
Le serveur DNS dédié implémenté sur le serveur central destinataire de l'échange est un serveur DNS standard sauf en ce qu'il est adapté pour extraire la chaîne de sous-domaine lorsqu'il reçoit une requête en résolution pour un sous-domaine. Cette chaîne est alors transmise au service destinataire sur le serveur central. Dans certains modes de réalisation, l'information peut être transmise pour un traitement effectif par un autre serveur connecté au serveur central. On considère alors que l'échange d'information intervient entre l'objet connecté et le serveur hébergeant le serveur DNS dédié indépendamment du traitement de l'information transmise ultérieurement. Ainsi, un objet connecté peut transmettre une information sous la forme d'une requête DNS au serveur central. De plus, il est possible d'utiliser les points d'accès ouverts et les points d'accès protégés par un mode d' authentification HTTP pour transmettre l'information. Seuls les points d'accès protégés par un mode d' authentification chiffré qui nécessite la connaissance d'une clé de chiffrement pour l'établissement de la connexion au niveau MAC entre l'objet connecté et le point d'accès ne peuvent pas être utilisés, sauf à connaître des informations de connexion et donc avoir été enregistré au préalable auprès de l'opérateur du point d'accès.
Les messages échangés selon le protocole de résolution de noms tel que défini dans la norme RFC 1035 contiennent des enregistrements de ressources appelées RRs (pour Ressource Record en anglais). Ces RRs sont contenus tant dans les requêtes DNS que dans les réponses à ces requêtes. Ces RRs contiennent un champ de données (RDATA) et une longueur de champ (RDLENGTH) qui permettent d'encoder dans un message DSN toute information complémentaire utile. Un message DNS peut comporter jusqu'à 3 RRs dont un RR additionnel pour transmettre des informations additionnelles.
Dans certains modes de réalisation de l'invention, lorsqu'une transmission d'information en réponse est requise du serveur central vers l'objet connecté ayant fait la requête, cette information peut être encodée dans ce RR additionnel, par exemple. Cette information est alors transmise par retour du serveur central à l'objet connecté sous forme de réponse DNS envoyée par le serveur DNS dédié et adapté au service objets connectés. Cette réponse est relayée par l'ensemble de la chaîne des serveurs DNS jusqu'à atteindre l'objet connecté. La durée de vie de la réponse est fixée par le champ TTL du RR. Cette durée de vie est avantageusement fixée à 0 pour interdire aux différents serveurs DNS de mémoriser la réponse dans leur cache. En effet, une mémorisation dans le cache d'un serveur DNS intermédiaire entre l'objet connecté et le serveur central a pour effet qu'une nouvelle requête avec le même nom de sous-domaine n'atteindra pas le serveur central et qu'il y sera répondu la réponse mémorisée dans le cache. Dans le cas où l'information transmise par l'objet connecté change à chaque requête, ceci n'est pas gênant car le sous-domaine généré par la requête sera nouveau lors de chaque requête. Donc, cette nouvelle requête atteindra toujours le serveur central. Dans les applications où l'information échangée peut être identique entre deux transmissions, une telle mise en cache peut empêcher la requête d'atteindre le serveur central. Dans ce cas, l'échange entre l'objet connecté et le serveur central ne peut être garanti que si la durée de vie est mise à 0.
La Figure 3 illustre un exemple de réalisation de l'échange de données selon l'invention entre un objet connecté et un serveur central. Lors de l'étape 3.1, l'objet connecté scanne son environnement radio pour détecter un point d'accès. Quand il trouve un point d'accès, il commence le processus de connexion au niveau MAC avec le point d'accès par l'envoi d'une requête de connexion lors d'une étape 3.2. Cette requête contient typiquement une requête pour des paramètres de connexion IP selon le protocole DHCP. Cette tentative de connexion peut réussir ou échouer. Lors de l'étape 3.3, un test sur le succès de la connexion est effectué. Si la connexion a échoué, le processus se termine par l'étape finale 3.4. En cas de succès, la connexion est établie. Le succès de la connexion dépend typiquement, comme nous l'avons vu, du mode d' authentification implémenté par le point d'accès. Typiquement, si le point d'accès est ouvert ou protégé par un mode d' authentification HTTP, la connexion au niveau MAC réussit. Dans le cas où le point d'accès est protégé par un mode d' authentification chiffré, la requête en connexion doit contenir un secret partagé nécessaire à l'établissement de la connexion chiffrée entre l'objet connecté et le point d'accès. Dans ce cas, sauf à ce que l'objet connecté connaisse ce secret, la connexion échoue.
Une fois la connexion établie, l'objet connecté a reçu une configuration IP du point d'accès et a configuré son interface Wi-Fi à l'aide des paramètres reçus. Un dialogue au niveau IP peut donc être initié entre l'objet connecté et le point d'accès. Dans le cas d'un point d'accès ouvert, l'accès selon tout protocole à des destinations au- delà du point d'accès est possible. Dans le cas d'un point d'accès protégé par un mode d'authentification HTTP, les ports de communication du point d'accès sont fermés aux communications issues de l'objet connecté en attente d'une authentification réussie via une page Web. Seul le port 53 dédié au service de résolution de nom est ouvert.
Dans tous les cas, l'objet connecté émet une requête DNS, étape 3.5, contenant l'information à transmettre comme vu plus haut concaténée au sous-domaine correspondant au service objets connectés. Cette requête est alors relayée jusqu'au serveur DNS dédié et adapté sur le serveur central destinataire de l'échange. Ce serveur extrait l'information transmise pour son utilisation par le serveur.
Le serveur DNS dédié reçoit une information de la part d'un objet et enregistre la trame reçue dans une base de données. Cette trame comprend, par exemple l'identifiant de l'objet, une estampille temporelle (i.e. time stamp en anglais), des éléments de localisation et des éléments de mesures de capteurs embarqués sur l'objet.
Cette base de données est partagée avec plusieurs serveurs d'application. De tels serveurs sont par exemple adaptés à envoyer des notifications par emails, dans le cas où certaines grandeurs mesurées dépassent des seuils critiques prédéfinis. Ceci est particulièrement avantageux dans le cadre d'applications de géo-repérage (geofencing en anglais) pour prévenir un tiers que l'objet sort d'une zone géographique de surveillance.
Dans le cas où une réponse est nécessaire, cette réponse est élaborée par le serveur central puis transmise au serveur DNS dédié et adapté pour transmission intégrée dans la réponse du serveur DNS à la requête reçue. On souligne que cette étape de réponse est optionnelle, selon l'application considérée, elle peut ne pas être nécessaire.
De manière générale, si l'on ne souhaite aucun changement de comportement de l'objet (e.g. changement de la valeur des seuils critiques ou de la cadence des envois), la réponse n'est pas nécessaire. En revanche, pour permettre de modifier le comportement de l'objet, l'objet est adapté à attendre systématiquement une réponse pendant une fenêtre de temps préalablement réglée. Cette réponse à la requête DNS est alors relayée par les serveurs DNS intermédiaires pour être finalement réceptionnée par l'objet connecté lors de l'étape 3.6. La phase d'échange se termine alors par l'étape finale 3.7. Ainsi, un échange, éventuellement bidirectionnel, d'information est implémenté entre un objet connecté et un serveur central. Cet échange est rapide car il ne nécessite pas l'établissement d'une connexion entre l'objet et le serveur.
A partir du moment où la connexion radio est établie, le délai pour l'envoi de l'information utile (i.e. transmission de données utiles ou charge utile dite payload) en utilisant la présente invention est typiquement de 50 à 100 ms contre 2 à 3 s dans le cas classique utilisant une requête HTTP et la transmission de pages HTLM.
En effet, par rapport à une solution classique, le procédé selon l'invention s'affranchit de l'envoi par l'objet d'une requête HTTP dont la durée est typiquement comprise entre 100 et 800 ms, de la redirection de la requête HTTP vers le portail du FAI (durant typiquement 300 à 800 ms), de la réception par l'objet des pages HTML nécessaires à la saisie du login et mot de passe de l'utilisateur, de l'envoi de la page HTML contenant le login et mot de passe de l'utilisateur avec acceptation des conditions générales le cas échéant, de la réception de cette page pour identification de l'utilisateur. Dans la solution classique, ce n'est qu'après avoir été identifié/authentifié que l'utilisateur peut transmettre ses données utiles. Selon la solution classique, une attente de connexion de l'ordre 5 à 10 s est constatée par l'utilisateur avant de procéder à la transmission de ses données utiles.
On notera que ces délais sont donnés à titre indicatif mais qu'ils pourront varier en fonction du cas pratique considéré, étant donné qu'ils dépendent fortement de la qualité de l'environnement radio et du matériel radio utilisés, ainsi que des traitements logiques de préparation des messages. Toutefois, quelles que soient les conditions d'environnement et de matériel, la présente invention permettra toujours d'obtenir un délai signifie ativement réduit par rapport aux solutions classiques.
Il en résulte en particulier une économie d'énergie appréciable pour des objets connectés alimentés par pile ou batterie ainsi qu'une facilité accrue de réaliser une connexion pour des objets en mouvement. Par exemple, un téléphone mobile (i.e. objet en mouvement) se déplaçant à une vitesse de 25 m/s soit 90 km/h ne reste que rarement plusieurs secondes dans la zone de couverture radio d'un point d'accès Wi-Fi. Selon le procédé de l'invention, dès lors que l'objet en mouvement reste au moins 100 ms dans cette zone de couverture, il peut transmettre de l'information spécifique au serveur central.
Il est possible de tirer parti des points d'accès ouverts et de ceux protégés par un mode de protection HTTP.
La Figure 4 est un bloc-diagramme schématique d'un dispositif de traitement de l'information 4.0 pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention. Le dispositif 4.0 de traitement de l'information peut être un périphérique tel qu'un micro-ordinateur, un poste de travail ou un terminal mobile de télécommunication. Le dispositif 4.0 comporte un bus de communication connecté à:
- une unité centrale de traitement 4.1, tel qu'un microprocesseur, notée CPU ; - une mémoire à accès aléatoire 4.2, notée RAM, pour mémoriser le code exécutable du procédé de réalisation de l'invention ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation de l'invention, la capacité de mémoire de celui- ci peut être complété par une mémoire RAM optionnelle connectée à un port d'extension, par exemple ;
- une mémoire morte 4.3, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des modes de réalisation de l'invention ;
- une interface réseau 4.4 est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmis ou reçus. L'interface réseau 4.4 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur 4.1 ;
- une interface utilisateur 4.5 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur ;
- un support de stockage optionnel 4.6 noté HD ; - un module d'entrée/sortie 4.7 pour la réception / l'envoi de données depuis / vers des périphériques externes tels que disque dur, support de stockage amovible ou autres. Le code exécutable peut être stocké dans une mémoire morte 4.3, sur le support de stockage 4.6 ou sur un support amovible numérique tel que par exemple un disque. Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 4.4, afin d'être stocké dans l'un des moyens de stockage du dispositif de communication 4.0, tel que le support de stockage 4.6, avant d'être exécuté.
L'unité centrale de traitement 4.1 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation de l'invention, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 4.1 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 4.2, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple. Un tel logiciel, lorsqu'il est exécuté par le processeur 4.1, provoque les étapes des organigrammes présentés dans la figure 3 pour être exécutées.
Dans ce mode de réalisation, l'appareil est un appareil programmable qui utilise un logiciel pour mettre en œuvre l'invention. Toutefois, à titre subsidiaire, la présente invention peut être mise en œuvre dans le matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n'est pas limitée aux modes de réalisation spécifiques, et les modifications qui se trouvent dans le champ d'application de la présente invention seront évidentes pour une personne versée dans l'art.

Claims

REVENDICATIONS
Procédé d'échange d'information spécifique entre un objet connecté (1.1) et un serveur central (1.5) comprenant les étapes suivantes exécutées par ledit objet connecté disposant d'une interface Wi-Fi (4.4) :
- une étape de détection (3.1) d'un point d'accès Wi-Fi (1.2) dans l'environnement radio de l'objet connecté (1.1) ;
- une étape d'envoi (3.2) d'une requête de connexion au niveau MAC au point d'accès détecté (1.2) ;
caractérisé en ce que, en cas de succès de la connexion au niveau MAC, le procédé comporte en outre :
- une étape d'envoi (3.5) d'une requête DNS pour la résolution d'un nom de domaine intégrant un sous-domaine dédié, ledit sous-domaine dédié étant géré par un serveur DNS dédié sur ledit serveur central (1.5), ladite requête DNS contenant l'information spécifique à transmettre, ladite information spécifique étant non relative au fonctionnement standard d'un service de résolution du nom de domaine.
Procédé selon la revendication 1, caractérisé en ce que ladite information spécifique est relative à un service lié à l'objet connecté et/ou à une fonction dudit objet.
Procédé d'échange d'information spécifique selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comporte en outre :
- une étape de réception (3.6) d'une réponse DNS émise par ledit serveur central (1.5) et contenant une information en réponse à l'information spécifique transmise dans la requête DNS.
4. Procédé d'échange d'information spécifique selon la revendication 3 caractérisé en ce que l'information en réponse est transmise dans le champ « RDATA » d'un enregistrement de ressource de la réponse DNS. Procédé d'échange d'information spécifique selon l'une des revendications 1 à 4, caractérisé en ce que l'information spécifique est codée sous la forme d'une séquence de labels (labell,...,labelN; XXX) concaténée au sous- domaine dédié.
Procédé d'échange d'information spécifique selon l'une des revendications 1 à 5, caractérisé en ce que l'information spécifique est répartie et transmise via une pluralité de requêtes DNS.
Procédé d'échange d'information spécifique entre un objet connecté (1.1) et un serveur central (1.5) comprenant les étapes suivantes exécutées par ledit serveur central :
- une étape de réception d'une requête DNS pour la résolution d'un nom de domaine dédié par un serveur DNS dédié et adapté ;
- une étape d'extraction d'une information spécifique contenue dans ladite requête DNS par le serveur DNS dédié et adapté ;
- une étape de transmission de ladite information spécifique à un service dédié aux objets connectés (1.1), ladite information spécifique étant non relative au fonctionnement standard d'un service de résolution du nom de domaine.
8. Procédé selon la revendication 7, caractérisé en ce que ladite information spécifique est relative à un service lié à l'objet connecté et à une fonction dudit objet.
9. Procédé d'échange d'information spécifique selon l'une quelconque des revendications 7 et 8, caractérisé en ce qu'il comprend en outre :
- une étape de transmission d'une réponse DNS à la requête DNS intégrant une information en réponse à l'information spécifique reçue.
10. Procédé d'échange d'information spécifique selon la revendication 9 caractérisé en ce que l'information en réponse est transmise dans le champ « RDATA » d'un enregistrement de ressource de la réponse DNS.
11. Procédé d'échange d'information spécifique selon l'une des revendications 7 à 10, caractérisé en ce que l'information spécifique extraite est codée sous la forme d'une séquence de labels (label l,...,labelN) concaténée au sous- domaine dédié.
12. Objet connecté (1.1 ; 4.0) adapté pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 6.
13. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté sur un ordinateur (4.0).
14. Moyen de stockage d'informations (4.3 ; 4.6), amovible ou non, partiellement ou totalement lisible par un ordinateur (4.0) ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 5.
PCT/EP2017/062212 2016-05-25 2017-05-22 Procede d'echange de donnees entre un objet connecte et un serveur central WO2017202743A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17729785.0A EP3466038A1 (fr) 2016-05-25 2017-05-22 Procede d'echange de donnees entre un objet connecte et un serveur central

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1654688 2016-05-25
FR1654688A FR3052004B1 (fr) 2016-05-25 2016-05-25 Procede d'echange de donnees entre un objet connecte et un serveur central.

Publications (1)

Publication Number Publication Date
WO2017202743A1 true WO2017202743A1 (fr) 2017-11-30

Family

ID=57045059

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/062212 WO2017202743A1 (fr) 2016-05-25 2017-05-22 Procede d'echange de donnees entre un objet connecte et un serveur central

Country Status (3)

Country Link
EP (1) EP3466038A1 (fr)
FR (1) FR3052004B1 (fr)
WO (1) WO2017202743A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008042911A2 (fr) * 2006-10-05 2008-04-10 Limelight Networks, Inc. Service de nom de domaine à distance
US20100274970A1 (en) * 2009-04-23 2010-10-28 Opendns, Inc. Robust Domain Name Resolution
US20140089523A1 (en) * 2012-09-21 2014-03-27 Interdigital Patent Holdings, Inc. Systems and methods for providing dns server selection using andsf in multi-interface hosts

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008042911A2 (fr) * 2006-10-05 2008-04-10 Limelight Networks, Inc. Service de nom de domaine à distance
US20100274970A1 (en) * 2009-04-23 2010-10-28 Opendns, Inc. Robust Domain Name Resolution
US20140089523A1 (en) * 2012-09-21 2014-03-27 Interdigital Patent Holdings, Inc. Systems and methods for providing dns server selection using andsf in multi-interface hosts

Also Published As

Publication number Publication date
FR3052004B1 (fr) 2019-08-02
FR3052004A1 (fr) 2017-12-01
EP3466038A1 (fr) 2019-04-10

Similar Documents

Publication Publication Date Title
Frolov et al. Detecting Probe-resistant Proxies.
EP1842389A1 (fr) Procede, dispositif et programme de detection d'usurpation d'adresse dans un reseau sans fil
EP2822285B1 (fr) Appariement de dispositifs au travers de réseaux distincts
CN110913036A (zh) 一种基于权威dns识别终端位置的方法
EP2912818A1 (fr) Procede d'authentification mutuelle entre un terminal et un serveur distant par l'intermediaire d'un portail d'un tiers
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
EP1905194B1 (fr) Detection de double attachement entre un reseau filaire et au moins un reseau sans-fil
WO2006087473A1 (fr) Procede, dispositif et programme de detection d'usurpation d'adresse dans un reseau sans fil
EP3466038A1 (fr) Procede d'echange de donnees entre un objet connecte et un serveur central
FR3079709A1 (fr) Procede de connexion sans fil d'un objet communicant a un reseau de communication local, programme d'ordinateur et equipement d'acces correspondant.
EP3087719B1 (fr) Procédé de ralentissement d'une communication dans un réseau
EP3688926B1 (fr) Gestion de groupes d'objets connectés utilisant des protocoles de communication sans fil
CA3100170A1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
Hoogstraaten Evaluating server-side internet proxy detection methods
EP3337137A2 (fr) Mise en oeuvre conditionnelle d'un service
EP3672209B1 (fr) Procédé d'identification de noeud de communication
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é
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.
EP4256753A1 (fr) Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
FR3093882A1 (fr) Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.
FR3067900A1 (fr) Geolocalisation wifi de biens ou de personnes
FR3112002A1 (fr) Procédé et dispositif de détection d'une faille de sécurité.
FR3112057A1 (fr) Procédé et dispositif de sélection d’un réseau en mode non connecté.
EP3360293A1 (fr) Moyens de gestion d'accès à des données

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17729785

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017729785

Country of ref document: EP

Effective date: 20190102