FR3101506A1

FR3101506A1 - Procédé de caractérisation d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet

Info

Publication number: FR3101506A1
Application number: FR1910868A
Authority: FR
Inventors: Florent MAERTEN; Pascal BENOIS
Original assignee: Bouygues Telecom SA
Current assignee: Bouygues Telecom SA
Priority date: 2019-10-01
Filing date: 2019-10-01
Publication date: 2021-04-02
Anticipated expiration: 2039-10-01
Also published as: FR3101506B1

Abstract

La présente invention concerne un procédé de caractérisation depuis un serveur distant (3) d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet (2), caractérisé en ce qu’il comprend des étapes de : (b) Emission depuis le serveur (3) à destination du boitier d’accès internet (2) d’un flux de données dans un protocole de communication utilisant un mode de transmission sans connexion ; (c) Redirection par le boitier d’accès internet (2) dudit flux de données vers un équipement local cible (1a) connecté au boitier d’accès internet (2) via ladite connexion sans-fil ; (d) Caractérisation du débit réel de la connexion sans-fil audit boitier d’accès à internet (2) en fonction d’au moins un compteur de paquets transmis dudit flux de données. Figure de l’abrégé : Fig 1

Description

Procédé de caractérisation d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet

DOMAINE TECHNIQUE GENERAL

La présente invention concerne le domaine de la fourniture d’accès à Internet.

Plus précisément, elle concerne un procédé de caractérisation d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet.

ETAT DE L’ART

Il est souhaitable, que ce soit pour identifier des dysfonctionnements ou au contraire vérifier des améliorations de performances, pouvoir surveiller les débits de données chez un utilisateur. Par exemple, il est courant qu’un utilisateur se plaigne de ne plus avoir un accès à Internet convenable et appelle le service client, et ce dernier doit être en capacité de constater le problème pour pouvoir y apporter une solution.

Si le débit de données au niveau de la passerelle d’accès (la « box »), dit débit WAN (pour Wide Access Network) est facilement mesurable (par exemple en lui faisant télécharger un fichier), le débit Wifi réel derrière cette passerelle l’est beaucoup moins.

En effet, si on fait simplement télécharger un fichier à l’équipement de l’utilisateur, on pourra constater l’existence d’un goulot limitant le débit quelque part, mais on ne pourra pas savoir où. Or il est tout à fait possible que la connexion FTTH ou xDSL (i.e. le lien WAN) d’une passerelle soit nominale, mais que le Wifi soit le facteur limitant, par exemple à cause d’un problème dans l’émission radio au niveau de la passerelle ou du fait d’une perturbation électromagnétique. Inversement, le Wifi peut être en sous-capacité si le débit WAN est trop faible. Et dans tous les cas, il reste encore possible que le problème ne soit lié ni au Wifi ni au lien WAN mais provienne d’une erreur de configuration au niveau de l’équipement de l’utilisateur.

Il serait possible de mesurer le débit Wifi réel en installant sur un équipement client du réseau local connecté une application apte à échanger des données avec la passerelle, ou même en faisant faire de la part de l’utilisateur certaines actions.

Toutefois, ceci n’est pas souhaitable : d’une part on ne peut pas envisager avoir des applications pour tous les équipements potentiellement connectés en Wifi à une passerelle (qui peuvent être de types très variés, allant de l’imprimante réseau à la console de jeux), et d’autre part les utilisateurs peuvent être novice et la procédure de test doit pouvoir être faite intégralement à distance par le service client.

Il serait par conséquent souhaitable de disposer d’une nouvelle solution universelle, fiable, et pouvant intégralement être mise en œuvre à distance de mesure d’un débit réel d’une connexion sans-fil.

PRESENTATION DE L’INVENTION

Selon un premier aspect, la présente invention se rapporte donc à un procédé de caractérisation depuis un serveur distant d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet, caractérisé en ce qu’il comprend des étapes de :

(b) Emission depuis le serveur à destination du boitier d’accès internet d’un flux de données dans un protocole de communication utilisant un mode de transmission sans connexion ;

(c) Redirection par le boitier d’accès internet dudit flux de données vers un équipement local cible connecté au boitier d’accès internet via ladite connexion sans-fil ;

(d) Caractérisation du débit réel de la connexion sans-fil audit boitier d’accès à internet en fonction d’au moins un compteur de paquets transmis dudit flux de données.

Selon des caractéristiques avantageuses et non-limitatives :

Le procédé comprend une étape (a) de sélection dudit équipement local cible parmi l’ensemble des équipements locaux connectés au boitier d’accès internet via ladite connexion sans-fil.

Ledit équipement local cible sélectionné est inactif ou peu actif.

L’étape (c) est mise en œuvre grâce à une règle de redirection vers ledit équipement local cible, l’étape (a) comprenant en outre la création sur le boitier d’accès à internet de ladite règle de redirection suite à la sélection dudit équipement local cible.

Ladite règle de redirection est une règle de traduction d’adresse réseau, NAT, ou de traduction d’adresse de port, PAT.

L’étape (a) comprend préalablement la connexion sécurisée du serveur auprès du boitier d’accès à internet.

Ledit protocole de communication de la couche de transport utilisant un mode de transmission sans connexion est un protocole de la couche de transport, en particulier le protocole UDP.

L’étape (d) comprend l’estimation d’un débit réel atteignable de la connexion sans-fil audit boitier d’accès à internet en fonction d’au moins un paramètre de ladite connexion sans-fil.

L’étape (a) comprend l’obtention dudit au moins un paramètre de ladite connexion sans-fil.

Ledit au moins un paramètre de ladite connexion sans-fil est choisi parmi un niveau de bruit, un indicateur de puissance de signal, un nombre de flux.

Selon un deuxième aspect, l’invention concerne un serveur de caractérisation d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet, caractérisé en ce qu’il est configuré pour :

créer sur le boitier d’accès à internet une règle de redirection vers un équipement local cible connecté au boitier d’accès internet via ladite connexion sans-fil ;
émettre à destination du boitier d’accès internet un flux de données dans un protocole de communication utilisant un mode de transmission sans connexion, en vue de sa redirection par le boitier d’accès internet vers ledit équipement local cible ;
caractériser le débit réel de la connexion sans-fil audit boitier d’accès à internet en fonction d’au moins un compteur de paquets transmis dudit flux de données.

Selon un troisième et un quatrième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de caractérisation depuis un serveur distant d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet ; et des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon le premier aspect de caractérisation depuis un serveur distant d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet.

PRESENTATION DES FIGURES

D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :

la figure 1 représente un mode réalisation préféré d’une architecture pour la mise en œuvre du procédé selon l’invention ;

la figure 2 est un exemple illustrant la différence entre débit réel et débit réel atteignable.

DESCRIPTION DETAILLEE

Architecture globale

En référence à lafigure 1, est proposé un procédé de caractérisation depuis un serveur distant 3 d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet 2.

Par « caractérisation », on entend notamment l’estimation dudit débit ou du moins d’un ordre de grandeur, voire simplement une évaluation de son caractère normal ou pas. On note qu’on considéré ici le débit « réel » c’est-à-dire effectivement constaté et non le débit physique abrévié « phy rate », qui est facile à connaitre mais correspond à un débit théorique qui n’est en pratique pas atteint, a fortiori s’il y a un problème.

Ce procédé permeta minimade signaler un tel problème dans la connexion Wifi, et avantageusement de permettre la résolution rapide et efficace du problème, en évitant à l’utilisateur des manipulations laborieuses, ou la nécessité qu’un technicien passe.

Ce procédé peut être lancé notamment à distance par un Conseiller de Clientèle (si par exemple l’utilisateur se plaint de son débit Wi-Fi), par un technicien ayant mis en service le boitier d’accès à internet 2 chez un client, directement par l’utilisateur pour s’auto-diagnostiquer, etc.

Dans la figure 1, le boitier 2 est connecté au réseau internet 20 via un réseau opérateur 21. Le serveur distant 3, typiquement un serveur de l’opérateur du boitier d’accès à Internet 2, est disposé dans le réseau internet 20 ou le réseau opérateur 21 et est ainsi connecté au boitier 2.

Ce boitier 2 génère un réseau local (dit LAN pour Local Access Network) au moins partiellement sans-fil, c’est-à-dire qu’une connexion sans fil est établie, et on suppose qu’au moins un équipement 1a, 1b local est connecté audit boitier via ladite connexion sans-fil. Ladite connexion sans-fil est typiquement une connexion Wifi (on prendra cet exemple dans la suite de la description), mais également une connexion Bluetooth ou tout autre protocole radio ou autre. A noter qu’il n’est pas exclu que le boitier 2 soit connecté à un ou plusieurs autres équipements 1a, 1b via une connexion filaire, typiquement en Ethernet.

Ici, la connexion sans-fil existe mais n’est pas forcément dans un « état de fonctionnement nominal », c’est-à-dire un état exempt d’anomalie et ou de panne. Par contraste, on dit que la connexion sans-fil n’est pas dans un état de fonctionnement nominal quand elle ne permet pas l’accès au réseau 20 via le boitier 2, ou de façon dégradée (mauvaise qualité de service, par exemple débit anormalement lent ou coupures) en d’autres termes qu’elle n’est pas capable de remplir son rôle, que ce soit du fait d’un problème dans le boitier 2, mais également dans l’environnement (perturbation électromagnétique) ou dans un équipement client 1a, 1b.

De manière classique, le boitier d’accès à internet 2 et le serveur 3 comprennent des moyens de traitement de données respectifs de type processeur, et le cas échéant des moyens de stockages de données (une mémoire), par exemple un disque dur.

Le ou les équipements 1a, 1b peuvent être de n’importe quel type. Dans la figure 1, le premier équipement 1a est un terminal mobile de type smartphone et le deuxième équipement 1b est par exemple une imprimante réseau.

Principe

De manière classique, la connexion sans-fil s’établit au niveau des couches basses du modèle OSI, et en particulier la couche physique (niveau 1) et/ou la couche de liaison de données (niveau 2, en particulier une ou plusieurs sous-couches de cette couche).

Par exemple, le Wifi est régi par les normes du groupe IEEE 802.11 (ISO/CEI 8802-11) qui s’attache à définir au niveau de la couche physique la modulation des ondes radioélectriques et les caractéristiques de la signalisation pour la transmission de données, et au niveau de la couche liaison de données l’interface entre le bus de la machine et la couche physique, notamment une méthode d’accès proche de celle utilisée dans le standard Ethernet et les règles de communication entre les différentes stations contrôle d’accès au support de type MAC. Par-dessus, il est possible d’utiliser n’importe quel protocole de transport basé sur IP sur un réseau 802.11 au même titre que sur un réseau Ethernet.

Ici on suppose qu’au moins un équipement local 1a, 1b est connecté au boitier d’accès internet 2 via ladite connexion sans-fil, i.e. qu’ils sont capables « d’échanger des paquets de données », sans plus de spécificité. Cela qui se traduit en pratique par une connectivité au niveau de la couche réseau du modèle OSI (niveau 3), typiquement conforment au protocole IP (en d’autres termes, chaque équipement 1a, 1b dispose d’une adresse IP locale).

Les protocoles IP assurent l'acheminement au mieux des paquets. Ils ne se préoccupent pas du contenu des paquets, mais fournissent une méthode pour les mener à destination, et sont considérés comme « non fiables ». Cela ne signifie pas qu'ils n'envoient pas correctement les données sur le réseau, mais qu'ils n'offrent aucune garantie pour les paquets envoyés concernant les points suivants :

corruption de données ;
ordre d'arrivée des paquets ;
perte de paquets ;
duplication des paquets.

En termes de fiabilité, le seul service offert par un protocole IP est de s'assurer que les en-têtes de paquets transmis ne comportent pas d'erreurs grâce à l'utilisation de somme de contrôle (checksum). Si l'en-tête d'un paquet comprend une erreur, sa somme de contrôle ne sera pas valide et le paquet sera détruit sans être transmis. En cas de perte d'un paquet, aucune notification n'est envoyée à l'expéditeur.

Ainsi, les garanties non offertes par un protocole IP sont déléguées aux protocoles de niveau supérieur, c’est pourquoi la connexion sans-fil peut être parfaitement établie au niveau 3 du modèle OSI sans être dans ledit état de fonctionnement nominal : si c’est le cas le problème est à un de ces niveaux supérieurs.

Le présent procédé propose d’utiliser astucieusement les protocoles de niveau supérieurs, en particulier ceux de la couche de transport du modèle OSI (niveau 4) ou une couche supérieure pour pouvoir caractériser le débit réel de ladite connexion sans-fil.

Plus précisément, on va tirer parti des propriétés d’un protocole de communication utilisant un mode de transmission sans connexion, en particulier un protocole de communication de la couche de transport (ce que « l’on appelle plus simplement un « protocole de transport »).

Par « mode de transmission sans-connexion » ou « en mode non-connecté » on entend une transmission de données dans laquelle chaque paquet est préfixé par un en-tête contenant une adresse de destination, suffisante pour permettre la livraison autonome du paquet, sans recours à d'autres instructions. Cela s’entend par opposition à un mode de transmission « orientée connexion » dans lequel il est nécessaire de déclarer l’échange de données, notamment via un mécanisme de « handshake ».

Le protocole typique de transport utilisant un mode de transmission sans connexion est UDP (User Datagram Protocol). Un paquet transmis en mode sans connexion est en effet fréquemment appelé un datagramme.

Le rôle de ce protocole est de permettre la transmission de données de manière très simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port (i.e. connexion établie en couche 3). Aucune communication préalable n'est requise pour établir la connexion, au contraire de TCP (Transmission Control Protocol), qui utilise le mécanisme de handshake. UDP est détaillé dans la RFC 768.

Un protocole utilisant un mode de transmission sans connexion expose le programme qui l'utilise aux problèmes éventuels de fiabilité du réseau : il n'existe pas de garantie de protection quant à la livraison, l'ordre d'arrivée, ou la duplication éventuelle des datagrammes. UDP est donc adapté à un usage pour lequel la détection et la correction d'erreurs ne sont pas nécessaires, ou sont effectuées directement par l'application, c’est pourquoi il est généralement utilisé pour transmettre rapidement de petites quantités de données, depuis un serveur vers de nombreux clients ou bien dans des cas où la perte éventuelle d'un datagramme est préférée à l'attente de sa retransmission. Le DNS, la voix sur IP ou les jeux en ligne sont ainsi des utilisateurs typiques de ce protocole : par exemple, dans le cas de la transmission de la VoIP ou d’un jeu de type FPS, la perte occasionnelle d'un paquet est tolérable dans la mesure où il existe des mécanismes de substitution des données manquantes, par contre la rapidité de transmission est un critère primordial pour la réactivité.

Il est également utilisé pour émettre des données à plusieurs récepteurs simultanément (multicast, broadcast), la connexion TCP n'étant que point-à-point.

Dans le présent procédé, c’est paradoxalement le caractère « non-fiable » d’UDP (et de façon générale de tout protocole de communication utilisant un mode de transmission sans connexion) qui est expressément recherché car il va justement permettre de mettre en évidence les éventuels problèmes du réseau sans-fil.

Ainsi, un flux UDP envoyé depuis le serveur 3 au boitier d’accès à Internet 2 et redirigé vers un équipement local 1a, 1b connecté via ladite connexion sans-fil va permettre de caractériser le débit réel de cette connexion sans-fil.

En effet, il est possible « d’arroser » un équipement de paquets non-sollicités (et donc sans qu’aucune action de l’utilisateur ou application n’ait à être impliquée), que ce dernier va simplement rejeter puisqu’il n’attend rien. Cependant la transmission a bien eu lieu donc il est possible en l’observant d’estimer le débit réel de la connexion sans-fil.

A noter qu’on pourra utiliser tout autre protocole de communication utilisant un mode de transmission sans connexion tel que FASP (Fast and Secure Protocol), ICMP (Internet Control Message Protocol), IPX (Internetwork Packet Exchange), etc.

Procédé

Le procédé commence par une étape (a) optionnelle d’initialisation du procédé par le serveur 3. A noter que le procédé peut être géré directement pas le boitier 2, et ainsi commencer directement par l’étape (b) suivante, voir ci-après.

Préférentiellement, l’étape (a) commence par l’établissement d’une connexion sécurisée entre le serveur 3 et le boitier 2, par exemple via SSH (Secure Shell) ou encore TLS, SSL, etc.

Ensuite, l’étape (a) comprend en particulier la sélection (par le serveur 3 ou le boitier 2) d’un équipement local cible 1b parmi l’ensemble des équipements locaux 1a, 1b connectés au boitier d’accès internet 2 via ladite connexion sans-fil.

Par équipement cible, on entend l’équipement local vers lequel envoyer le flux UDP. Techniquement, l’équipement cible pourrait être n’importe quel équipement local connecté au réseau sans-fil, mais préférentiellement est sélectionné un équipement inactif ou peu actif (en particulier l’équipement le moins actif parmi les équipements connectés, i.e. échangeant le moins de paquets).

En effet, l’équipement actif échange déjà des paquets TCP sur la connexion sans-fil, et il risque d’y avoir conflit entre ces paquets TCP et les paquets UDP : soit il va être capable de recevoir moins de paquets UDP que ce qu’il pourrait s’il était inactif en d’autres termes, la bande-passante UDP est « limitée » par les échanges TCP), soit des paquets TCP vont être bloqués du fait de la saturation UDP et l’utilisation de l’équipement cible sera perturbée. En résumé, un équipement cible inactif permet donc une mesure de débit réel plus fiable et sans interférence.

Par exemple, on pourra choisir un équipement tel qu’une imprimante réseau (comme représenté sur la figure 1), une caméra IP ou de façon générale un objet connecté (en particulier domotique), car ce sont des équipements fonctionnant par intermittence et majoritairement inactifs, contrairement à des équipements tel qu’un terminal mobile de type smartphone qui échangent des données en permanence.

Alternativement ou en complément, on pourra sélectionner l’équipement cible en fonction d’autres critères tels que, et sans cela soit exhaustif, son niveau de signal reçu, son nombre d’antennes, sa compatibilité annoncée avec les différentes versions de standard de connexion sans-fil, ou une combinaison de ces critères (en particulier parmi les équipements cibles inactifs).

Ensuite, l’étape (a) comprend avantageusement la création sur le boitier d’accès à internet 2 d’une règle de redirection vers ledit équipement local cible 1b, laquelle est en particulier une règle NAT (Network Address Translation, i.e. traduction d’adresse réseau) et/ou PAT (Port Address Translation, i.e. traduction d’adresse de port).

Plus précisément, alors que le boitier d’accès à internet 2 à une adresse IP publique, les équipements locaux 1a, 1b n’ont que des adresses IP privées. Ladite règle NAT et/ou PAT associe à un port du boitier 2 l’adresse de l’équipement cible 1b. Ainsi, pour envoyer des données à l’équipement cible 1b depuis l’extérieur (i.e. depuis le réseau internet 20), il suffit de les envoyer à l’adresse publique du boitier 2 sur le port correspondant, et le boitier va traduire cette adresse vers l’adresse de l’équipement cible 1b.

On note que soit cette règle de redirection est créé par le boitier 2, soit elle est poussée sur ce dernier par le serveur 3, ce qui est facilité en cas de connexion sécurisée du serveur 3 auprès du boitier 2.

Enfin, l’étape (a) comprend avantageusement l’obtention d’informations préalable au test, et notamment l’obtention d’au moins un paramètre de ladite connexion sans-fil, en particulier associé audit équipement cible 1b. Comme l’on verra, ce paramètre permet de définir les conditions dans laquelle la connexion sans-fil est établie, et est préférentiellement choisi parmi un niveau de bruit, un indicateur de puissance de signal reçu (RSSI), un niveau de bruit radio, un taux d’occupation de la radio par des perturbateurs sur le même canal radio ou des canaux adjacents, un taux d’occupation du canal radio par d’autres équipements partageant la même ressource radio, une modulation choisie (MCS), un nombre de flux obtenu (en cas de multiplexage spatial), une compatibilité annoncée avec les différentes versions de standard de connexion sans-fil, un type d’équipement identifié par son constructeur (OUI) associé à l’identifiant mondial unique de l’équipement (Adresse MAC), un nombre de paquets perdus et/ou un nombre de paquets retransmis ….

Par ailleurs, les informations préalables au test peuvent comprendre un compteur de paquets (i.e. le compteur est relevé avant le test).

Test

Dans les étapes (b) puis (c) principales, le test est en pratique effectué : le serveur 3 génère et émet à destination du boitier d’accès internet 2 un flux de données dans ledit protocole de communication utilisant un mode de transmission sans connexion (en particulier UDP), et le boitier d’accès internet 2 redirige ce flux de données vers l’équipement local cible 1a connecté au boitier d’accès internet 2 via ladite connexion sans-fil (en particulier grâce à la règle de redirection).

Le flux de données doit être émis à un débit suffisant, en particulier supérieur ou égal à la capacité du lien WAN et/ou au débit théorique de la connexion sans-fil, si l’on ne veut pas estimer de manière biaisée le débit réel de la connexion sans-fil, et son contenu peut être arbitraire. A noter qu’on peut jouer sur la taille des paquets UDP pour affiner le diagnostic.

Alors, dans une étape (d), le débit réel de la connexion sans-fil audit boitier d’accès à internet 2 peut être caractérisé en fonction d’au moins un compteur de paquets transmis dudit flux de données.

Plus précisément, même si les paquets sont rejetés par l’équipement cible 1b, on peut savoir combien de paquets ont été effectivement transmis (en comparant le compteur avant et après) sur quel intervalle de temps et en déduire une estimation du débit réel.

De manière préféré, l’étape (d) comprend la suppression de la règle de redirection ajoutée (de sorte à laisser le boitier 2 dans l’état d’origine et ne pas créer de perturbation potentielle), et la fermeture de l’éventuelle connexion sécurisée.

A noter qu’il reste possible que le boitier 2 comprenne en permanence une règle de redirection, par exemple établie à la première mise en route du boitier 2 et mise à jour à chaque connexion/déconnexion d’un équipement 1a, 1b du réseau sans-fil, par exemple utilisant un port dédié défini et réservé par l’opérateur.

Normalisation

Il peut être souhaitable d’estimer, outre le débit réel « instantané », un débit réel atteignable, en particulier dans des conditions « optimales », voir le débit réel atteignable sur un équipement local activement utilisé par le client. Par exemple, sur la figure 1, ce qui est important est en pratique le débit atteignable sur son terminal 1a.

Cela permet ainsi en grande partie de résoudre un éventuel problème d’expérience utilisateur.

Ainsi, l’étape (d) peut comprendre l’estimation dudit débit réel atteignable de la connexion sans-fil audit boitier d’accès à internet 2 en fonction d’au moins un paramètre de ladite connexion sans-fil.

L’idée est de « normaliser » le débit estimé en fonction desdits paramètres de ladite connexion sans-fil. Par exemple, en référence à lafigure 2, si l’on constate un fort niveau de bruit et un mauvais indicateur de force de signal, on peut estimer la valeur du débit réel qu’on aurait obtenu si ces niveaux de bruit/ indicateur de force de signal avaient été normaux. Ainsi, il devient possible de comparer deux valeurs de débit réel atteignables pour déterminer s’il y a un problème ou non.

Plus précisément, estimer le débit réel atteignable correspond à calculer au débit réel qu’on aurait dû mesurer si les paramètres de ladite connexion sans-fil avait présenté des valeurs standard (représentatives d’une situation normale).

Cette normalisation peut être réalisée en utilisant une base de données de valeurs de référence de débit réel chacune pour un n-uplet desdits paramètres de connexion sans-fil, ces n-uplets étant les plus variés possibles. Ces dernières peuvent être tirées de mesures terrain ou de bases de données externes. L’idée est de construire un modèle de référence à partir de cette base de données de valeurs de référence, i.e. un abaque, permettant de modéliser comment les variations de ces paramètres de la connexion sans-fil influent sur la valeur du débit réel. On pourra pour cela utiliser toute technique connue de l’homme du métier, en particulier des techniques statistiques, des méthodes d’apprentissage automatisé, etc.

En extrapolant, on peut même estimer le débit réel que pourrait atteindre la connexion sans-fil dans n’importe quelle pièce du logement, avec n’importe quel type d’équipement 1a, 1b, etc. Pour cela il suffit de simuler les paramètres du réseau sans-fil qu’on aurait alors, et de calculer le débit réel qu’on aurait dû mesurer si les paramètres de ladite connexion sans-fil avait présenté ces valeurs simulées.

Serveur et produit programme d’ordinateur

Selon un deuxième aspect, l’invention concerne un serveur 3 configuré pour la mise en œuvre du présent procédé.

En particulier, ce serveur 3 est configuré pour créer sur le boitier d’accès à internet 2 une règle de redirection vers l’équipement local cible 1b connecté au boitier d’accès internet 2 via ladite connexion sans-fil, émettre à destination du boitier d’accès internet 2 un flux de données dans un protocole de communication utilisant un mode de transmission sans connexion (UDP préférentiellement) en vue de sa redirection par le boitier d’accès internet vers ledit équipement local cible 1b, et caractériser le débit réel de la connexion sans-fil audit boitier d’accès à internet 2 en fonction d’au moins un compteur de paquets transmis dudit flux de données.

Le serveur 3 est également éventuellement configuré pour établir une connexion sécurisée avec le boitier 2, sélectionner ledit équipement local cible 1b, et/ou supprimer ladite règle de redirection du boitier d’accès à internet 2.

Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (en particulier sur les moyens de traitement de données du serveur 3) du procédé de caractérisation depuis un serveur distant 3 d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet 2, ainsi que des moyens de stockage lisibles par un équipement informatique (notamment des moyens de stockage de données du serveur 3) sur lequel on trouve ce produit programme d’ordinateur.

Claims

Procédé de caractérisation depuis un serveur distant (3) d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet (2), caractérisé en ce qu’il comprend des étapes de :
(b) Emission depuis le serveur (3) à destination du boitier d’accès internet (2) d’un flux de données dans un protocole de communication utilisant un mode de transmission sans connexion ;
(c) Redirection par le boitier d’accès internet (2) dudit flux de données vers un équipement local cible (1a) connecté au boitier d’accès internet (2) via ladite connexion sans-fil ;
(d) Caractérisation du débit réel de la connexion sans-fil audit boitier d’accès à internet (2) en fonction d’au moins un compteur de paquets transmis dudit flux de données.
Procédé selon la revendication 1, comprenant une étape (a) de sélection dudit équipement local cible (1a) parmi l’ensemble des équipements locaux (1a, 1b) connectés au boitier d’accès internet (2) via ladite connexion sans-fil.
Procédé selon la revendication 2, dans lequel ledit équipement local cible (1a) sélectionné est inactif ou peu actif.
Procédé selon l’une des revendications 2 et 3, dans lequel l’étape (c) est mise en œuvre grâce à une règle de redirection vers ledit équipement local cible (1b), l’étape (a) comprenant en outre la création sur le boitier d’accès à internet (2) de ladite règle de redirection suite à la sélection dudit équipement local cible (1b).
Procédé selon la revendication 4, dans laquelle ladite règle de redirection est une règle de traduction d’adresse réseau, NAT, ou de traduction d’adresse de port, PAT.
Procédé selon l’une des revendications 2 à 5, dans lequel l’étape (a) comprend préalablement la connexion sécurisée du serveur (3) auprès du boitier d’accès à internet (2).
Procédé selon l’une des revendication 1 à 6, dans lequel ledit protocole de communication de la couche de transport utilisant un mode de transmission sans connexion est un protocole de la couche de transport, en particulier le protocole UDP.
Procédé selon l’une des revendication 1 à 7, dans lequel l’étape (d) comprend l’estimation d’un débit réel atteignable de la connexion sans-fil audit boitier d’accès à internet (2) en fonction d’au moins un paramètre de ladite connexion sans-fil.
Procédé selon la revendication 8 en combinaison avec l’une des revendications 2 à 6, dans lequel l’étape (a) comprend l’obtention dudit au moins un paramètre de ladite connexion sans-fil.
Procédé selon l’une des revendications 7 et 8, dans lequel ledit au moins un paramètre de ladite connexion sans-fil est choisi parmi un niveau de bruit, un indicateur de puissance de signal, un nombre de flux.
Serveur (3) de caractérisation d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet (2), caractérisé en ce qu’il est configuré pour
créer sur le boitier d’accès à internet (2) une règle de redirection vers un équipement local cible (1b) connecté au boitier d’accès internet (2) via ladite connexion sans-fil ;

émettre à destination du boitier d’accès internet (2) un flux de données dans un protocole de communication utilisant un mode de transmission sans connexion, en vue de sa redirection par le boitier d’accès internet vers ledit équipement local cible (1b) ;

caractériser le débit réel de la connexion sans-fil audit boitier d’accès à internet (2) en fonction d’au moins un compteur de paquets transmis dudit flux de données.
Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 de caractérisation depuis un serveur distant (3) d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet (2), lorsque ledit programme est exécuté par un ordinateur
Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 de caractérisation depuis un serveur distant (3) d’un débit réel d’une connexion sans-fil à un boitier d’accès à internet (2).