FR3020537A1 - Moyens d’evaluation de performances, dans un reseau de donnees - Google Patents

Abstract

L'invention se rapporte à un procédé d'évaluation de la performance et de la qualité relatives à l'utilisation du protocole de contrôle de transmissions TCP pour transmettre, dans un réseau de données, au cours d'une session, des paquets de données: • depuis un premier terminal vers un deuxième terminal dans un premier sens; • depuis le deuxième terminal vers le premier terminal, dans un deuxième sens. Le procédé comporte une étape de collecte d'informations protocolaires, comportant des marquages temporels, relatives à la session. Le procédé comporte en outre les étapes suivantes: • pour au moins un des paquets de la session, détermination, exprimés relativement à un temps de référence commun au premier terminal et au deuxième terminal, à partir des informations protocolaires, ○ d'un temps de latence dans le premier sens, d'un temps de latence dans le deuxième sens; et/ou ○ d'un temps de boucle entre le premier terminal et le deuxième terminal en fonction du marquage temporel d'au moins un premier paquet émis soit dans le premier sens soit dans le deuxième sens et du marquage temporel d'un second paquet émis dans un sens opposé au premier paquet comportant une référence au marquage temporel du premier paquet.

Description

La présente invention se rapporte à des moyens pour évaluer la qualité et les performances, au sein d'un réseau de données selon le protocole de contrôle de transmissions, plus généralement désigné par l'acronyme anglo-saxon «TCP» pour «Transmission Control Protocol».

Elle concerne plus particulièrement des moyens adaptés à être mis en oeuvre sur un terminal, pour estimer le dimensionnement optimal de la fenêtre de congestion, la latence dans chaque sens de transmission, ainsi que le temps de boucle tout au long d'une session TCP. Dans le cadre de l'exploitation d'un réseau de données construit autour des protocoles de la suite TCP/IP, mesurer la qualité et les performances relatives au protocole TCP, en particulier au niveau des terminaux, est un enjeu majeur, notamment pour déterminer si l'utilisation du protocole TCP est un facteur limitant la performance et/ou la qualité des services de données entre un terminal et un émetteur, et identifier les optimisations envisageables pour optimiser la performance et/ou la qualité constatés. Dans le cas d'un transfert de données entre un émetteur et un récepteur selon le protocole TCP, la détermination des informations suivantes, en temps réel, s'avère particulièrement utile pour établir des mesures fiables de performance et de qualité à un instant donné: la latence entre le récepteur et l'émetteur, en voie montante et descendante, au cours d'une session TCP, et typiquement mesurée en millisecondes; le temps de boucle en voie montant et descendante entre l'émetteur et le récepteur au sein d'une session TCP, plus généralement désigné par l'acronyme anglo-saxon «RTT» pour «Round Trip Time», et typiquement mesuré en millisecondes ; la quantité de données en cours de transit entre l'émetteur et le récepteur en voie montant et descendante, plus généralement désigné par l'acronyme anglo-saxon «BIF» pour «Bytes In Flight», et typiquement mesuré en kilo-octets, ou la taille de la fenêtre de congestion TCP correspondante en nombre de paquets, désignée par l'acronyme anglo-saxon «CWND» pour «Congestion Window»; la quantité de données à transmettre pour atteindre le débit maximal TCP entre l'émetteur et le récepteur, et saturer le canal («bit pipe» en anglais) correspondant, plus généralement désigné par l'acronyme anglo-saxon «BDP» pour «Bandwidth Delay Product», typiquement mesuré en kilo-octets.

Or, lors des échanges protocolaires TCP/IP, la latence, le temps de boucle RTT, la taille de la fenêtre de congestion, la quantité de données en cours de transit BIF entre l'émetteur et le récepteur, la quantité de données minimale et/ou optimale BDP à transmettre pour atteindre le débit maximal TCP entre l'émetteur et le récepteur, ne sont pas exposés. En outre, dans le cas d'un réseau configuré pour gérer des équipements utilisateurs de type terminaux mobiles, l'analyse critique des performances TCP en voie descendante et/ou montante pour un terminal donné est rendue difficile par le grand nombre et la variabilité des indicateurs contributifs à la performance globale des protocoles employés. En particulier, pour ces raisons, il est difficile de savoir si un terminal donné a pu obtenir la performance maximale ou la qualité optimale atteignable sur le réseau. En effet, une telle performance ou une telle qualité dépend des conditions radio, de la charge courante de la cellule du réseau prenant en charge le transfert de données TCP ainsi que de la charge des équipements et liens traversés par la communication TCP. Or ces paramètres peuvent fluctuer très rapidement, typiquement en quelques millisecondes. C'est pourquoi il existe aussi un besoin pour des moyens permettant de vérifier si le protocole TCP, utilisé pour le transport de services de données en voie descendante et/ou montante par le terminal, est un facteur limitant, à un instant donné, de la performance et/ou de la qualité qu'est susceptible de délivrer le réseau. Un des objets de l'invention est de fournir des moyens permettant de déterminer, à un instant donné, la quantité de données en cours de transit BIF, entre l'émetteur et le récepteur, et/ou la taille de la fenêtre de congestion TCP correspondante. Un des objets de l'invention est de fournir des moyens pour permettre l'analyse et l'investigation des performances et de la qualité TCP, notamment fournir des informations relatives par exemple: à la latence en voie montante entre un terminal et une autre partie, à un instant donné, d'une session TCP; et/ou, à la latence en voie descendante entre l'autre partie et le terminal, à un instant donné, d'une session TCP; et/ou, à un temps de boucle RTT en voie montante, entre le terminal et l'autre partie, à un instant donné, d'une session TCP ; et/ou, à un temps de boucle RTT en voie descendante, entre l'autre partie et le terminal, à un instant donné, d'une session TCP ; et/ou, à la taille optimale BDP de la fenêtre de congestion en voie montant et descendante, pour permettre par exemple d'obtenir le débit maximum afin de s'assurer que le protocole TCP n'est pas un facteur limitant, à un instant donné ; et/ou, à la taille de la fenêtre de congestion d'un émetteur TCP, à un instant donné ; et/ou, à la quantité d'octets en transit BIF d'une session TCP entre l'émetteur et le récepteur, à chaque instant ; et/ou, à la comparaison, à un instant donné, entre la latence dans chaque sens et la latence minimale dans chaque sens pour atteindre une qualité optimale TCP à la comparaison, à un instant donné, entre la taille de la fenêtre de congestion TCP (ou la quantité d'octets en transit BIF) et la quantité de données minimale et/ou optimale BDP à transmettre pour atteindre la performance maximale TCP; etc.

Un autre objet de l'invention est de fournir des mesures en collectant des données de capture TCP/IP, que cette collecte soit réalisée sur l'émetteur, le terminal ou sur tout autre élément du réseau en coupure entre l'émetteur et le récepteur. Un des objets de l'invention est de permettre une analyse causale des facteurs limitant la performance lors d'un service de données TCP dans le sens montant ou descendant. Un autre objet de l'invention est de fournir des moyens adaptés à être déployés et mis en oeuvre efficacement sur un réseau utilisant le protocole TCP, exploité par des opérateurs, des entreprises, des fournisseurs d'infrastructures. Un autre objet de l'invention est de proposer des outils fiables de test, de mesure, d'analyse et d'investigation de la performance TCP/IP. Plus particulièrement, dans le cas notamment d'un réseau configuré pour gérer des équipements utilisateurs de type terminaux mobiles, l'invention a pour objet de fournir des moyens d'estimation, à chaque instant, à partir de données collectées sur un terminal permettant la capture des traces radio et TCP/IP: d'une part, du débit maximal atteignable pour un utilisateur sur une interface, par exemple une interface dit à accès par paquet en liaison montante et/ou descendante haut débit, plus communément désigné par l'acronyme anglo-saxon «HSDPA» et «HSUPA» pour «High Speed Downlink Packet Access» et «High Speed Uplink Packet Access», une interface de type téléphonie mobile comme "LTE" pour "Long Term Evolution" en anglais, ou encore une interface sans fil comme "WiFi"; et d'autre part, de la quantité de données minimale et/ou optimale que le protocole TCP, du point de vue de l'émetteur, doit fournir à une interface pour obtenir ce débit maximal. Un autre objet de l'invention est de fournir des moyens pour identifier les situations, à chaque instant, dans lesquelles le dimensionnement de la fenêtre de congestion TCP est suffisant ou limitant, pour obtenir le débit maximal atteignable lors d'un transfert de données en voie descendante et/ou montante. Un autre objet de l'invention est de fournir des moyens pour l'analyse causale et temporelle des facteurs limitant la performance lors d'un transfert de données en voie descendante et/ou montante. Un autre objet de l'invention est de fournir des moyens adaptés à être déployés et mis en oeuvre efficacement sur un réseau exploité par des opérateurs, des entreprises, des fournisseurs d'infrastructures. Un autre objet de l'invention est de proposer des outils fiables de test, de mesure, d'analyse et d'investigation de la performance et de la qualité TCP. Un ou plusieurs de ces objets sont remplis par la méthode selon les revendications indépendantes. Les revendications dépendantes fournissent en outre des solutions à ces objets et/ou d'autres avantages. Plus particulièrement, selon un premier aspect, l'invention se rapporte à un procédé d'évaluation de la performance et de la qualité relatives à l'utilisation du protocole de contrôle de transmissions TCP pour transmettre, dans un réseau de données, au cours d'une session, des paquets de données: - depuis un premier terminal vers un deuxième terminal dans un premier sens; - depuis le deuxième terminal vers le premier terminal, dans un deuxième sens. Le procédé comporte une étape de collecte d'informations protocolaires, comportant des marquages temporels, relatives à la session. Le procédé comporte en outre au moins une étapes de détermination, pour au moins un des paquets de la session, exprimé relativement à un temps de référence commun au premier terminal et au deuxième terminal, à partir des informations protocolaires, d'un temps de latence dans le premier sens, d'un temps de latence dans le deuxième sens; et/ou d'un temps de boucle entre le premier terminal et le deuxième terminal en fonction du marquage temporel d'au moins un premier paquet émis soit dans le premier sens soit dans le deuxième sens et du marquage temporel d'un second paquet émis dans un sens opposé au premier paquet comportant une référence au marquage temporel du premier paquet. En particulier, le procédé selon le premier aspect peut comporter en outre une étape de détermination, à l'aide des marquages temporels collectés et d'une référence horaire locale, du temps de référence commun au premier terminal et au deuxième terminal. L'utilisation d'un temps de référence commun entre le premier terminal et le deuxième terminal permet de recaler temporellement les informations temporelles comprises dans les marquages temporels et permet in fine de créer des métriques de mesure des temps entre des évènements émetteur et récepteur. Sans l'utilisation d'un temps de référence commun, toute comparaison des informations temporelles comprises dans les paquets est faussée, car le premier terminal et le deuxième terminal possèdent des horodatages exprimés dans des référentiels temporels différents.

En outre, le procédé peut être mis en oeuvre en collectant des données de capture TCP/IP, que cette collecte soit réalisée sur le premier terminal, sur le deuxième terminal, ou sur tout autre élément du réseau en coupure entre le premier terminal et le deuxième terminal. Le marquage temporel des paquets est par exemple un champ, compris dans l'en-tête d'un paquet TCP, dont la valeur correspond à un marquage temporel ou «timestamp» en anglais, tel que décrit dans le document RFC 1323, «TCP Extensions for High Performance», Request for comments n°1323, The Internet Engineering Task Force (IETF), mai 1992. Par informations protocolaires TCP, on entend par exemple les informations comprises dans les en-têtes des paquets TCP, en particulier la valeur des drapeaux SYN et SYN/ACK, la valeur du champ de marquage temporel, ou encore le numéro de séquence ou d'acquittement pour chacun des paquets dans la session. La référence horaire peut être déterminée en utilisant un moyen de mesure du temps mis en oeuvre sur un dispositif accueillant un module de mesure, par exemple une horloge interne. Lorsque les informations protocolaires collectées, pour chacun des paquets de la session, comprennent un numéro de séquence et un numéro d'acquittement, le procédé selon le premier aspect peut comporter en outre les étapes suivantes: - estimation de la quantité de données en cours de transit, dans le premier sens et le deuxième sens, entre le premier terminal et le deuxième terminal, à un instant t en: - déterminant une heure d'émission pour au moins un des paquets de la session, exprimées relativement au temps de référence commun, en fonction des marquages temporels dudit au moins un paquet; et, - identifiant un troisième paquet, émis soit dans le premier sens soit dans le deuxième sens, et dont le numéro de séquence est le plus grand parmi tous les numéros de séquence des paquets collectés ayant la même heure d'émission, relativement au temps de référence commun, que ledit au moins un paquet; - identifiant un quatrième paquet, émis dans le sens opposé au troisième paquet, dont le numéro d' acquittement est le plus grand parmi tous les numéros d'acquittement des paquets dont l'heure d'émission, relativement au temps de référence commun, est antérieure à l'instant t; - calculant la différence entre le numéro de séquence du troisième paquet et le numéro d'acquittement du quatrième paquet. Le procédé peut en outre comporter une étape d'estimation du taux de congestion TClatence à l'instant t, obtenu en calculant le ratio entre le temps de latence dans le premier ou deuxième sens et le temps de latence minimal.

En particulier, une information indiquant que l'utilisation du protocole TCP n'est pas considérée comme un facteur limitant relativement à la latence peut être produite, lorsque le taux de congestion TClatence est sensiblement supérieur à 2 et sensiblement inférieur à 4. Le temps de latence minimal peut être calculé comme égal sensiblement au 90ème centile de la valeur minimale de tous les temps de latence déterminés pour les paquets de la session dans ce sens. Le procédé peut en outre comporter une étape d'estimation du taux de congestion TCRTT à l'instant t, obtenu en calculant le ratio entre le temps de boucle et le temps de boucle minimal. En particulier, une information indiquant que l'utilisation du protocole TCP n'est pas considérée comme un facteur limitant relativement au temps de boucle peut être produite, lorsque le taux de congestion TCRTT est sensiblement supérieur à 2 et sensiblement inférieur à 4. Le temps de boucle minimal étant calculé comme égal sensiblement au 90ème centile de la valeur minimale de tous les temps de boucle déterminés pour les paquets de la session.

Le procédé peut en outre comporter une étape d'estimation du taux de congestion TCbif, à l'instant t, obtenu en calculant le ratio entre la quantité de données en transit et la quantité de données à transmettre pour atteindre le débit optimal TCP. En particulier, une information indiquant que l'utilisation du protocole TCP n'est pas considérée comme un facteur limitant relativement à la quantité de données en cours de transit est produite, lorsque le taux de congestion TCbif est typiquement compris entre 1 et 4. La référence horaire commune au premier terminal (terminal 1) et au deuxième terminal (terminal 2) peut être obtenue en: - identifiant, pour la session, une heure locale de réception du paquet reçu en premier et une heure locale de réception du paquet reçu en dernier; - déterminant le temps total local V de la session à partir de l'heure locale du paquet reçu en premier et du paquet reçu en dernier; - identifiant, pour la session, le marquage temporel Tterminal1 et Tterminal2 du paquet reçu en premier et le marquage temporel Tterminal1 et Tterminal2 du paquet reçu en dernier; - déterminant les temps totaux Dterminal1 et Dterminal2 de la session à partir des marquages temporels du paquet reçu en premier et du paquet reçu en dernier; - calculant un niveau de précision Pterminal1 et Pterminal2 des marquages temporels des paquets pour la session, en fonction du temps total local V et des temps totaux Dterminal1 et Dtermina12.

L'heure commune d'émission et de réception peut être déterminée, pour chaque paquet de la session, en: - identifiant un temps de latence minimal correspondant au plus petit des temps de latence déterminés pour les paquets de la session; et, - calculant un écart temporel local en multipliant le niveau de précision P des marquages temporels des paquets pour la session par l'écart temporel entre le marquage temporel dudit paquet et le marquage temporel du premier paquet de la session; - soustrayant à l'écart temporel un ratio du temps de latence minimal. Le temps de latence pour chaque paquet de la session peut être obtenu en calculant un écart temporel entre le marquage temporel dans le temps de référence local du paquet et le marquage temporel dans le temps de référence commun dudit paquet. Plus particulièrement, - pour la latence dans un sens : calculant un écart temporel entre le temps local du paquet et le marquage temporel « émetteur » dudit paquet - pour la latence dans l'autre sens : calculant un écart temporel entre le temps de boucle et le temps de latence déjà calculé Le temps de boucle RTT pour chaque paquet de la session peut être obtenu en calculant un écart temporel entre le temps local du paquet et le marquage temporel « récepteur » dudit paquet Le temps de boucle RTT pour chaque paquet de la session peut aussi être obtenu en: - sélectionnant au moins un des paquets de la session, émis dans le premier ou deuxième sens; - déterminant l'heure H1 à laquelle ledit paquet a été collecté; - cherchant et déterminant l'heure H2 de collecte d'un paquet de la session, émis dans le sens opposé audit paquet, ayant un marquage temporel commun avec ledit au moins un paquet; - calculant la différence entre l'heure H2 et l'heure H1: RTT=H2-H1 Le temps de boucle RTT pour chaque paquet de la session peut aussi être obtenu, en analysant trois paquets, sans utiliser nécessairement l'horloge de capture, en: - sélectionnant au moins un des paquets de la session, émis dans le premier ou deuxième sens, et déterminant le marquage temporel Ti dudit au moins un paquet; - cherchant un cinquième paquet, émis dans le sens opposé audit paquet, ayant un marquage temporel commun avec ledit au moins un paquet; - cherchant un sixième paquet, émis dans le sens opposé au cinquième paquet, ayant un marquage temporel commun avec le cinquième paquet; - déterminant le marquage temporel T2 du sixième paquet; - calculant la différence entre le marquage temporel T2 et le marquage temporel Ti ; - calculant le temps de boucle RTT comme égale au produit du niveau de précision des marquages temporels et de la différence T2-T1, soit RTT= (T2-Ti)xP. Dans un mode de réalisation, le réseau de données est configuré pour gérer des équipements utilisateurs de type terminaux mobiles, le deuxième terminal étant un équipement utilisateur adapté à être couplé au réseau en utilisant une interface radio. Le procédé comporte alors en outre les étapes suivantes: - détermination d'un débit maximal théorique atteignable par le deuxième terminal; - collecte d'informations radio relatives à l'interface radio du deuxième terminal; - détermination, à l'aide d'un modèle, d'un débit maximal de l'interface radio du deuxième terminal, en fonction des informations radio et du débit maximal théorique atteignable par le deuxième terminal ; - estimation d'une quantité de données à transmettre pour atteindre un débit optimal TCP en calculant le ratio entre le débit maximal et le temps de latence minimal. Le procédé peut aussi répondre à plusieurs questions relatives à l'analyse et à l'investigation des performances d'un réseau mobile, notamment: Quel est le débit maximal atteignable, à chaque instant, par un terminal lors d'un transfert de données TCP en voie descendante ou montante ? Le débit atteint mesuré est-il conforme au débit maximal atteignable? Quel est le dimensionnent minimal/optimal de la fenêtre de congestion TCP de la fenêtre d'émission TCP d'un émetteur TCP, à chaque instant, pour obtenir le débit en voie descendante/montante maximal attendu? Le dimensionnement de la fenêtre de congestion TCP est-il suffisant ou limitant, à chaque instant, pour obtenir le débit en voie descendante/montante maximal atteignable par le réseau? Le temps de latence minimal peut être choisi égal à un temps de latence minimal de référence correspondant à un réseau typique sans charge. Au cours de l'étape de détermination du débit maximal de l'interface radio du deuxième terminal, les informations radio utilisées par le modèle peuvent comprendre une ou une combinaisons d'informations radio parmi la liste suivante: un indicateur de qualité d'une interface radio ou filaire utilisée par le deuxième terminal pour la session, un taux de retransmission de blocs reçus affectés par des erreurs en fonction du nombre total de blocs reçus, meilleure stratégie d'efficacité spectrale compatible avec ce que peut recevoir l'équipement utilisateur, un niveau de variabilité de l'indicateur de qualité de l'interface radio ou filaire, une quantité de ressources allouées à un équipement utilisateur, un nombre d'équipements utilisateurs présents dans une cellule ou un noeud de raccordement utilisateur, une quantité ou proportion de temps au cours de laquelle un équipement utilisateur se voit attribué des ressources pour pouvoir émettre ou recevoir des données. Au cours de l'étape de détermination du débit maximal de l'interface radio du deuxième terminal, le modèle peut tenir compte de l'une ou plusieurs des hypothèses comme par exemple : l'indicateur de qualité de l'interface radio/filaire varie sensiblement de quelques dB (par exemple 1dB); le taux de retransmission moyen souhaité est sensiblement de x%, par exemple 10%. Selon un deuxième aspect, l'invention se rapporte à un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon le premier aspect, lorsque ledit programme est exécuté par un processeur. Chacun de ces programmes 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. En particulier, il est possible d'utiliser des langages de script, tels que notamment tcl, javascript, python, perl qui permettent une génération de code «à la demande» et ne nécessitent pas de surcharge significative pour leur génération ou leur modification.

Selon un troisième aspect, l'invention se rapporte à un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon le premier aspect. Le support d'informations peut être n'importe quelle entité ou n'importe quel dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé par 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 un réseau Internet ou Intranet. 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. D'autres particularités et avantages de la présente invention apparaîtront, dans la description ci-après de modes de réalisation, en référence aux dessins annexés, dans lesquels: - la figure 1 est un schéma d'un réseau de données, adapté à mettre en oeuvre des transferts de données selon les protocoles de la suite TCP/IP et comportant un module de mesure de performance et de qualité relatives au protocole TCP, selon un mode de réalisation l'invention ; - la figure 2 est un synoptique d'un procédé de mesure de performance et de qualité relatives au protocole TCP, selon un mode de réalisation l'invention ; - la figure 3est un synoptique d'un procédé de mesure de performance et de qualité relatives au protocole TCP, dans un réseau HSDPA, selon un mode de réalisation l'invention; Dans la suite de la description, toute référence à l'acronyme TCP se rapporte au protocole de contrôle de transmissions, plus généralement désigné par l'acronyme anglo-saxon «TCP» pour «Transmission Control Protocol», et telle que décrit notamment par le document «Transmission control protocol», Request for comments n°793, The Internet Engineering Task Force (IETF), septembre 1981. La figure 1 illustre schématiquement un réseau 10 de données, adapté à mettre en oeuvre des transferts de données selon les protocoles de la suite TCP/IP. Le réseau 10 comprend typiquement des moyens d'interconnexion usuels (non représenté sur la figure) pour permettre l'acheminement des données, tel que des routeurs, des ponts, des pare-feux, des commutateurs, etc. Sur la figure 1, sont représentés un premier terminal 12 et un deuxième terminal 14, pourvus chacun de moyens de couplage au réseau 10, et de moyens pour mettre en oeuvre une pile protocolaire TCP/IP. Le premier terminal 12 et le deuxième terminal 14 peuvent être d'un des types suivants: ordinateur, téléphone mobile, tablette, serveur, et plus généralement tout dispositif apte à échanger des données selon les protocoles TCP/IP. Le deuxième terminal 14 comporte un module 16 de mesure de performance et de qualité relatives au protocole TCP, selon un mode de réalisation l'invention. Par souci de clarté, dans la suite de la description, il est pris pour hypothèse que le module 16 de mesure est localisé sur le deuxième terminal 14. Toutefois, le module 16 de mesure pourrait être mis en oeuvre en tout point du réseau 10 et/ou sur n'importe quel dispositif appartenant au réseau 10, à partir duquel il est possible de capturer ou d'observer les échanges de données entre le premier terminal 12 et le deuxième terminal 14. Cela comprend notamment, mais non exclusivement, le premier terminal 12, les dispositifs de routage utilisé pour acheminer les données entre le premier terminal 12 et le deuxième terminal 14, ou tout autre dispositif intermédiaire situé entre le premier terminal 12 et le deuxième terminal 14. Dans la suite de la description, il est supposé qu'une session S, de type session TCP, est établie entre le premier terminal 12 et le deuxième terminal 14. En outre, les acronymes suivants sont utilisés dans la suite de la description: - paquet TCP/SYN: paquet TCP dont l'en-tête comporte un drapeau SYN correspondant à une demande de synchronisation ou d'établissement de connexion ; - paquet TCP/SYN/ACK: paquet TCP dont l'en-tête comporte un drapeau ACK pour indiquer que ledit paquet est un accusé de réception. De plus, dans la suite de la description, il est pris comme exemple des paquets TCP comportant, dans leur en-tête, un champ dont la valeur correspond à un marquage temporel ou «timestamp» en anglais. Le document RFC 1323, «TCP Extensions for High Performance», Request for comments n°1323, The Internet Engineering Task Force (IETF), mai 1992, décrit un tel en-tête, et la présence d'un tel champ: les paquets TCP, respectant cette spécification quant au marquage temporel, remplissent donc ce critère. Toutefois, d'autres moyens de marquages temporels peuvent s'avérer adéquats, dès lors que ces derniers permettent d'obtenir une information temporelle sur la date à laquelle le paquet a été transmis. A titre de rappel et par souci de clarté, il est rappelé que les paquets TCP comportant un marquage temporel selon le document RFC 1323 comportent notamment dans leur en-tête: - un champ TSVal, ou «TimeStamp Value» en anglais, adapté à être renseigné, par l'émetteur du paquet, avec un marquage temporel obtenu à partir de son horloge locale, et fonction de l'heure d'émission du paquet; et, - un champ TSEcR, ou «TimeStamp Echo Reply» en anglais, adapté à être renseigné, par l'émetteur du paquet, avec la valeur du champ TSval du dernier paquet reçu, au moment de l'émission, dans la session en cours. La figure 2 illustre, par un synoptique, un procédé de mesure de performance et de qualité relatives au protocole TCP, selon un premier mode de réalisation l'invention. Le procédé est notamment adapté à être mis en oeuvre par le module 16 de mesure. Au cours d'une étape 110, les informations protocolaires TCP du flux Fd de données, échangées au cours de la session S entre le premier terminal 12 et le deuxième terminal 14, sont capturées. Cette étape 110 peut être réalisée de manière continue, en temps réel ou quasi-temps réel, de sorte à intercepter instantanément les informations protocolaires TCP et permettre l'analyse des performances et de la qualité TCP en continu. Les informations protocolaires du flux Fd de données peuvent aussi être acquises puis enregistrées de sorte à permettre une analyse ultérieure des performances. Par informations protocolaires TCP, on entend notamment les informations comprises dans les en-têtes des paquets TCP, en particulier la valeur des drapeaux SYN et SYN/ACK, la valeur du champ de marquage temporel, ou encore le numéro des paquets dans la session S. Au cours de l'étape 110, l'heure d'arrivée locale des paquets reçus au niveau du dispositif accueillant le module 16 de mesure, en l'espèce le deuxième terminal 14, est déterminée et enregistrée. En particulier, pour tout paquet observé sur le module de mesure 16, il est possible de relever une heure locale d'arrivée grâce à une horloge installée sur le module de mesure 16. Il est considéré qu'une heure locale est exprimée sous la forme d'un nombre de millisecondes ou de microsecondes depuis une date origine gérée par l'horloge du module de mesure 16. Au cours d'une étape 120 optionnelle, on vérifie si le champ de marquage temporel est présent et/ou renseigné dans les paquets TCP capturés de la session S. Par exemple, au cours de la session S, le deuxième terminal 14 ayant transmit un paquet TCP/SYN et le premier terminal 12 transmis un paquet TCP/SYN/ACK, il est possible de procéder à cette vérification en lisant dans les en-têtes des paquets TCP/SYN et TCP/SYN/ACK les options TCP utilisées. Si ces dernières incluent l'option correspondante aux marques temporelles telle que décrit dans le document ((TCP Extensions for High Performance», Request for comments n°1323, The Internet Engineering Task Force (IETF), mai 1992, alors l'étape de vérification peut être considérée comme réussie. Au cours d'une étape 130, on identifie, pour la session S, l'heure d'arrivée locale Hidu premier paquet reçu Piet l'heure d'arrivée locale H, du dernier paquet reçu P,, au niveau du dispositif accueillant le module 16 de mesure, en l'espèce le deuxième terminal 14. On détermine alors le temps total local V de la session S en soustrayant l'heure d'arrivée locale H, à l'heure d'arrivée locale H1, soit V=H, -Hi.De même, au cours de l'étape 130, le premier paquet reçu PEicomportant un champ TSEcR renseigné, pour la session S, est identifié. Le dernier paquet reçu PEn comportant un champ TSEcR renseigné, pour la session S, est aussi identifié. On détermine alors la valeur D1 en soustrayant la valeur TSEcREi du champ TSEcR du paquet PEiàla valeur TSEcRE, du champ TSEcR du paquet PEN, soit D1 = TSEcRE, - TSEcREi.Une première précision P1 du marquage temporel pour la session S, calculée pour le premier terminal, est alors calculée, par exemple en divisant la valeur D1 par le temps total local V, soitP1 = r. De plus, au cours de l'étape 130, le premier paquet reçu PEicomportant un champ TSval renseigné, pour la session S, est identifié. Le dernier paquet reçu PEn comportant un champ TSval renseigné, pour la session S, est aussi identifié. On détermine alors la valeur D2 en soustrayant la valeur TSvalEi du champ TSval du paquet PEiàla valeur TSval En du champ TSval du paquet PEN, soit D2=TSval En - TSval El. La précision P2 du marquage temporel pour la session S, calculée pour le deuxième terminal, est alors calculée, par exemple en divisant la valeur D2 par le temps total local V, soitP2 = f'.Dans un cas typique nominal, la précision P1 et la précision P2 peuvent varier sensiblement entre 1 ms et 100 ms. L'utilisation des marques temporelles selon les spécifications du document RFC 1323, inclus dans les en- têtes TCP des paquets, permet de créer un temps de référence, commun entre le premier terminal 12 et le deuxième terminal 14, permettant d'horodater précisément, selon un même référentiel temporel partagé, les paquets échangés au cours de la session S. Au cours d'une étape 140, le temps de boucle RTT, pour chaque segment de la session S, en voie montante et descendante, est estimé. Un premier mode de réalisation de l'étape 140 pour estimer le temps de boucle, pour chaque segment de la session S, en voie montante et descendante, va maintenant être décrit. Pour chaque paquet, on relève la valeur R1 du champ TSEcR et l'heure locale H1 d'arrivée locale dudit paquet.

On calcule l'écart temporel Tbeta entre TSEcR et TSEcRref du paquet référent (par exemple 1 er paquet de la session ou paquet ayant généré le plus petit RTT) multiplié par la précision temporelle P1 ou P2 en fonction du sens montant ou descendant calculé à l'étape 130. On calcule l'écart temporel local Hbeta entre H1 et Href du paquet référent. On calcule le temps de boucle comme l'écart entre Hbeta et Tbeta. Un deuxième mode de réalisation de l'étape 140 pour estimer le temps de boucle, pour chaque segment de la session S, en voie montante et descendante, va maintenant être décrit. Pour chaque paquet reçu, on relève la valeur El du champ TSVal et l'heure locale Hy1 d'arrivée locale dudit paquet. On recherche alors le paquet, reçu ultérieurement au cours de la session S, dont la valeur du champ TSEcR est égale à la valeur El afin de déterminer l'heure locale Hy2 d'arrivée locale dudit paquet. On détermine alors une estimation du temps de boucle RTT en calculant la différence entre l'heure locale He et l'heure locale He soit RTT = H2-H1 Il est à noter que, dans l'hypothèse où le module 16 de mesure est localisé sur un dispositif du réseau 10 entre le premier terminal 12 et le deuxième terminal 14, il est possible de mesurer le temps de boucle RTT dans les deux sens (entre le point de mesure et le premier terminal; entre le point de mesure et le deuxième terminal). Un troisième mode de réalisation de l'étape 140 pour estimer le temps de boucle, pour chaque segment de la session S, en voie montante et descendante, va maintenant être décrit. Le temps de boucle RTT pour chaque paquet de la session peut aussi être obtenu, en analysant trois paquets, sans utiliser nécessairement l'horloge de capture, en: - sélectionnant au moins un des paquets de la session, émis dans le premier ou deuxième sens, et déterminant le marquage temporel Ti dudit paquet; - cherchant un cinquième paquet, émis dans le sens opposé audit paquet, ayant un marquage temporel commun avec ledit paquet; - cherchant un sixième paquet, émis dans le sens opposé au cinquième paquet, ayant un marquage temporel commun avec le cinquième paquet; - déterminant le marquage temporel T2 du sixième paquet; - calculant la différence entre le marquage temporel T2 et le marquage temporel Ti ; - calculant le temps de boucle RTT comme égale au produit du niveau de précision des marquages temporels et de la différence T2-T1, soit RTT= (T2-T1)xP. Au cours d'une étape 150, la quantité de données en transit BIF entre le premier terminal 12 et le deuxième terminal 14, pour la session S, est estimée. La quantité de données en transit BIF peut être estimée, quelque soit le dispositif auquel le module 16 de mesure est couplé. Plus particulièrement, un mode de réalisation de l'estimation de la quantité de données en transit BIF au cours de l'étape 150 va maintenant être décrit. Un premier mode de réalisation de l'étape 150 pour le calcul de la quantité de données en transit BIF entre le premier terminal 12 et le deuxième terminal 14, va maintenant être décrit. Pour chaque paquet Pa, on relève la valeur Ea du champ TSVal, l'heure locale Ha d'arrivée locale dudit paquet et la valeur Seqa du numéro de séquence. On calcule l'écart temporel Ta entre 30205 3 7 16 TSVaI et TSvalref du paquet référent (par exemple 1er paquet de la session ou paquet ayant généré le plus petit RTT) multiplié par la précision temporelle P1 Ou P2 en fonction du sens montant ou descendant calculé à l'étape 130. On recherche dans le passé un paquet Pb de direction opposée à Pa ayant le plus 5 grand numéro d'acquittement Ackb (ACK ou SACK) dont l'écart temporel multiplié par sa précision temporelle est inférieur à celui calculé pour Pa. Le BIF est alors la différence entre Seqa et Ackb. Un deuxième mode de réalisation de l'étape 150 pour le calcul de la quantité de données en transit BIF entre le premier terminal 12 et le deuxième 10 terminal 14, va maintenant être décrit. On cherche, parmi toutes les estimations de temps de boucle RTT calculées au cours d'une étape 140, la valeur minimale RTTmin pour tous les paquets transmis au cours de la session S. Pour tous les paquets transmis au cours de la session S, on calcule une heure locale de référence HEx obtenue ainsi: 15 HEx = ( Ex- E0) x P -0 RTTmin(E-R) avec - Ex la valeur du champ TSEcR, pour le paquet dont on souhaite calculer I heure locale de référence Hi, 20 - P la précision du marquage temporel pour tous les paquets transmis au cours de la session S, telle que calculée au cours de l'étape 130; - û étant compris entre 0 et 1. Pour un segment x donné dont le numéro de séquence est égal à SEQx, ou pour un acquittement x donné dont le numéro d'acquittement est égal à ACKX, 25 - on identifie l'heure locale de référence HEx correspondant au segment x; - on recherche, dans tous les segments reçus au cours de la session S, le segment y ayant le numéro de séquence SEQmax le plus grand et dont l'heure locale de référence HEy est inférieure ou égale à l'heure locale 30 de référence HEx ; - on recherche, dans tous les acquittements reçus au cours de la session S, l'acquittement z ayant le numéro d'acquittement ACQmax le plus grand (ACK ou SACK) et dont l'heure locale de référence HEz est inférieure ou égale à l'heure locale de référence HEx; 35 - on estime alors la quantité de données en transit BIF en calculant la différence entre le numéro de séquence SEQmax le plus grand et le numéro d'acquittement ACKmax le plus grand, soit: BIF = SEQmax - ACKmax.

Un troisième mode de réalisation de l'étape 150 pour le calcul de la quantité de données en transit BIF entre le premier terminal 12 et le deuxième terminal 14,va maintenant être décrit. Pour chaque paquet reçu, on relève la valeur El du champ TSVal et le numéro de séquence SEQ dudit paquet. - on recherche le paquet, dans le même sens, possédant le plus grand numéro de séquence SEQ et possédant le même marquage temporel, qui peut être le paquet considéré lui-même; - On recherche alors le paquet, reçu précédemment au cours de la session S, dont la valeur du champ TSEcR est égale à la valeur El, et possédant le plus grand numéro d'acquittement ACK (ou SACK). On détermine alors une le BIF comme étant SEQ-ACK ou (SEQ - SACK). Au cours d'une étape 160, on estime le taux T de congestion TCP, en calculant, pour chaque valeur du temps de boucle RTT obtenue au cours de l'étape 140: RTT T= x x RTTmIN avec: - RTTMIN le 90ème centile de la valeur minimale de tous les temps de boucle RTT, entre les deux parties de la session S; - x un nombre réel compris entre 2 et 3. Selon une variante du procédé présenté en figure 1, au cours d'une étape 140', le temps de latence L pour chaque paquet de la session peut être obtenu en calculant un écart temporel entre le marquage temporel dans le temps de référence local du paquet et le marquage temporel dans le temps de référence commun dudit paquet. Plus particulièrement, - pour la latence L dans un sens : calculant un écart temporel entre le temps local du paquet et le marquage temporel « émetteur » dudit paquet - pour la latence L dans l'autre sens : calculant un écart temporel entre le temps de boucle et le temps de latence déjà calculé Selon ladite variante du procédé, il est possible d'utiliser un second mode de réalisation de l'étape 160 de calcul du taux de congestion T, le taux de congestion étant défini de la façon suivante : T= X X LmIN avec: - Lm le 90ème centile de la valeur minimale de toutes les latences L dans un sens donné, entre les deux parties de la session S; - x un nombre réel compris entre 2 et 3.

La figure 3 illustre, par un synoptique, un procédé de mesure de performances relatives au protocole TCP, selon un mode de réalisation l'invention. Le procédé est écrit ci-après dans le contexte d'un réseau HSDPA. Toutefois, le procédé pourrait être utilisé, tant sur la voie montante que descendante, pour mesurer les performances d'autres types d'interfaces radio, en particulier des interfaces HSUPA, des interfaces de type téléphonie mobile comme LTE, ou encore une interface sans fil comme WiFi. Le procédé est notamment adapté à être mis en oeuvre par le module 16 de mesure. Le procédé est adapté pour être utilisé avec le procédé décrit à la figure 2, pour notamment apporter des mesures de performances supplémentaires, relatives au réseau HSDPA. Plus particulièrement, dans la suite de la description, il est pris en compte que le réseau 10 est configuré pour gérer des équipements utilisateurs de type terminaux mobiles utilisant un protocole dit à accès par paquet en liaison descendante haut débit, plus communément désigné par l'acronyme anglo-saxon «HSDPA» pour «High Speed Downlink Packet Access». Le protocole HSDPA est décrit notamment dans la spécification 3GPP, TS 25.308,«High Speed Downlink Packet Access (HSDPA); Overall description; Stage 2», Rel. 11, 2012-09-12.De plus, dans l'exemple qui suit, le deuxième terminal 14 est un équipement utilisateur, ou «user equipment» en anglais, par exemple un téléphone mobile, adapté à être couplé au réseau en utilisant le protocole HSDPA. Par équipement utilisateur, on entend tout terminal utilisé par un utilisateur du réseau HSDPA, et caractérisé notamment par une catégorie HSDPA désignant ses capacités et performances maximales, sur la voie descendante, notamment le nombre maximal de codes qu'il peut décoder en parallèle, les modulations supportées, etc. Le procédé permet notamment d'estimer à chaque instant, à partir de données collectées sur un terminal permettant la capture des traces radio et TCP/IP: d'une part, du débit maximal atteignable pour un utilisateur sur une interface HSDPA; et d'autre part, de la quantité de données minimale et/ou optimale que le protocole TCP, du point de vue de l'émetteur, doit fournir à une interface HSDPA pour obtenir ce débit maximal.

Au cours d'une étape 210, les informations protocolaires TCP du flux Fd de données, échangées au cours de la session S entre le premier terminal 12 et le deuxième terminal 14, sont capturées. Au cours d'une étape 210, les informations radio relatives à l'interface radio HSDPA sont également capturées. De même, au cours de l'étape 210, la catégorie HSDPA du deuxième terminal 14 est déterminée, par exemple en exploitant les informations échangées entre le deuxième terminal 14 et le réseau HSDPA relatives à l'interface radio. Cette étape 210 peut être réalisée de manière continue, en temps réel ou quasi-temps réel, de sorte à intercepter instantanément les informations protocolaires TCP et les informations relatives à l'interface radio HSDPA et permettre l'analyse des performances TCP et HSDPA en continu. Les informations protocolaires du flux Fd de données et les informations radio relatives à l'interface radio HSDPA peuvent aussi être acquises puis enregistrées de sorte à permettre une analyse ultérieure des performances. Par informations relatives à l'interface radio HSDPA, on entend notamment la catégorie HSDPA du deuxième terminal 14. Au cours de l'étape 210, l'heure d'arrivée locale des paquets reçus au niveau du dispositif accueillant le module 16 de mesure, en l'espèce le deuxième terminal 14, est déterminée et enregistrée. L'heure d'arrivée locale d'un paquet de la session S est déterminée en utilisant un moyen de mesure du temps mis en oeuvre sur le dispositif accueillant le module 16 de mesure. À titre d'exemple, une horloge interne du deuxième terminal 14 peut être exploitée à cette fin. Au cours d'une étape 220, on estime ou calcule le temps de boucle RTT minimal du réseau. Pour cela, il est possible de mettre en oeuvre les étapes 120, 130 et 140 du procédé de mesure de performances relatives au protocole TCP, tel que décrit précédemment et illustré à la figure 2. Alternativement, le temps de boucle RTTmIN minimal peut être considéré comme égal à un temps de boucle RTTmIN minimal de référence correspondant à un réseau HSDPA typique, sans charge, et égal par exemple sensiblement à 60 ms. Au cours d'une étape 230, on estime ou calcule la quantité de données en transit BIF entre le premier terminal 12 et le deuxième terminal 14. Pour cela, il est possible de mettre en oeuvre l'étape 150 du procédé de mesure de performances relatives au protocole TCP, tel que décrit précédemment et illustré à la figure 2. Au cours d'une étape 240, on choisit un modèle de performances HSDPA en fonction de la catégorie HSDPA du deuxième terminal 14, obtenue au cours de l'étape 210. Par modèle de performances HSDPA, on entend notamment un modèle permettant d'évaluer le débit maximal atteignable par un équipement utilisateur appartenant à ladite catégorie HSDPA en fonction, par exemple, d'un indicateur de qualité du canal utilisé par le deuxième terminal pour la session S, et un taux de blocs HDSPA reçus affectés par des erreurs en fonction du nombre total de blocs HDSPA reçus. L'indicateur de qualité du canal utilisé par le deuxième terminal pour la session S est par exemple l'indicateur HDSPA désigné par l'acronyme anglo-saxon «CQI» pour «Channel Quality Indicator», exprimé sur une échelle logarithmique de 1 à 30, et envoyé par l'équipement utilisateur à un noeud du réseau dit «NodeB» pour exprimer la qualité du signal HSDPA. L'indicateur CQI est utilisé par le noeud «NodeB» pour sélectionner la meilleure stratégie d'efficacité spectrale compatible avec ce que peut recevoir l'équipement utilisateur. Le taux de blocs HDSPA reçus affectés par des erreurs en fonction du nombre total de blocs HDSPA reçus est par exemple l'indicateur le taux de blocs erreurs HDSPA désigné par l'acronyme anglo-saxon «BLER» pour «Block Error Rate». Le modèle de performances HSDPA peut prendre en outre d'autres paramètres en considération pour déterminer le débit maximal atteignable, par exemple la variabilité de l'indicateur CQI, le nombre de codes HSDPA qu'un équipement utilisateur peut se voir attribuer, le nombre d'équipement utilisateur présent dans la même cellule, le taux d'ordonnancement en fonction du temps du terminal, etc. Le taux d'ordonnancement dans un système à temps et ressources partagées correspond, sur une période d'observation donnée, au nombre de fois où un élément (ici notre terminal) s'est vu attribuer des ressources. Le modèle de performances HSDPA peut être un modèle théorique, un modèle construit à partir de mesures de performances réalisées en laboratoire et/ou sur le terrain, ou une combinaison des deux types de modèles précédemment cités. Au cours d'une étape 250, on calcule, à partir des informations radio relatives à l'interface radio HSDPA recueillies au cours de l'étape 210, en utilisant le modèle de performances HSDPA choisi au cours de l'étape 240, le débit maximal DmAx, exprimé en mégabits par seconde (symbole Mbit/s). À titre d'exemple, les hypothèses simplificatrices suivantes peuvent être utilisées pour faciliter les calculs: - l'indicateur CQI peut varier rapidement de 1 à 2 dB; - le deuxième terminal 14 est supposé seul dans sa cellule HSDPA, peut obtenir tous les codes HSDPA, et être ordonnancé 100% du temps; - le taux de blocs erreurs BLER moyen souhaité est sensiblement de 10%.

Au cours d'une étape 260, on estime la quantité de données à transmettre BDP, en voie montant ou descendante, pour atteindre le débit maximal TCP, en kilo-octets, en appliquant la formule suivante, pour chaque valeur du temps de boucle RTT obtenue au cours de l'étape 140: DMAX BDP = 8 x RTTmiN Au cours d'une étape 270, on estime le taux de congestion TCbif comme le rapport entre la quantité de données en transit BIF obtenue au cours de l'étape 230, en voie montante ou descendante, et la quantité de données à transmettre BDP obtenue au cours de l'étape 260, en voie montante ou descendante, soit TCbif = BBDIFp. Si ce taux TCbif est supérieur ou égal à un seuil x, typiquement compris entre 1 et 4, le protocole TCP peut être considéré comme non limitant.

Claims (17)

1. REVENDICATIONS1. Procédé d'évaluation de la performance et de la qualité relatives à l'utilisation du protocole de contrôle de transmissions TCP pour transmettre, 5 dans un réseau de données (10), au cours d'une session, des paquets de données: - depuis un premier terminal (12) vers un deuxième terminal (14) dans un premier sens; - depuis le deuxième terminal (14) vers le premier terminal (12), dans un 10 deuxième sens; le procédé comportant une étape de collecte (110) d'informations protocolaires comportant des marquages temporels, relatives à la session; caractérisé en ce qu'il comporte en outre au moins une étape de détermination (140), pour au moins un des paquets de la session, exprimé 15 relativement à un temps de référence commun au premier terminal (12) et au deuxième terminal (14), à partir des informations protocolaires, d'un temps de latence dans le premier sens, d'un temps de latence dans le deuxième sens; et/ou d'un temps de boucle, entre le premier terminal (12) et le deuxième terminal (14) en fonction du marquage temporel d'au moins un premier paquet 20 émis soit dans le premier sens soit dans le deuxième sens et du marquage temporel d'un second paquet émis dans un sens opposé au premier paquet comportant une référence au marquage temporel du premier paquet.
2. 2. Procédé selon la revendication 1, comportant en outre une 25 étape de détermination (130), à l'aide des marquages temporels collectés et d'une référence horaire locale, du temps de référence commun au premier terminal (12) et au deuxième terminal (14).
3. 3. Procédé selon l'une quelconque des revendications 30 précédentes, dans lequel informations protocolaires collectées, pour chacun des paquets de la session, comprennent un numéro de séquence et un numéro d'acquittement, le procédé comportant en outre les étapes suivantes: - estimation (150) de la quantité de données en cours de transit, dans le premier sens et le deuxième sens, entre le premier terminal (12) et le 35 deuxième terminal (14), à un instant t en:- déterminant une heure d'émission pour au moins un des paquets de la session, exprimées relativement au temps de référence commun, en fonction des marquages temporels dudit au moins un paquet; et, - identifiant un troisième paquet, émis soit dans le premier sens soit dans le deuxième sens, et dont le numéro de séquence est le plus grand parmi tous les numéros de séquence des paquets collectés ayant la même heure d'émission relativement au temps de référence commun que ledit au moins un paquet; - identifiant un quatrième paquet, émis dans le sens opposé au troisième paquet, dont le numéro d'acquittement est le plus grand parmi tous les numéros d'acquittement des paquets dont l'heure d'émission relativement au temps de référence commun est antérieure à l'instant t; - calculant la différence entre le numéro de séquence du troisième paquet et le numéro d'acquittement du quatrième paquet.
4. 4. Procédé selon l'une quelconque des revendications précédentes, comportant en outre une étape d'estimation (160) du taux de 20 congestion TClatence à l'instant t, obtenu en calculant le ratio entre le temps de latence dans le premier ou deuxième sens et la latence minimale.
5. 5. Procédé selon l'une quelconque des revendications précédentes, comportant en outre une étape d'estimation (160) du taux de 25 congestion TCRTT à l'instant t, obtenu en calculant le ratio entre le temps de boucle dans le premier ou deuxième sens et le temps de boucle RTT minimal.
6. 6. Procédé selon l'une quelconque des revendications précédentes, comportant en outre une étape d'estimation du taux de 30 congestion TCbif, à l'instant t, obtenu en calculant le ratio entre la quantité de données en transit et la quantité de données à transmettre pour atteindre le débit optimal TCP.
7. 7. Procédé selon la revendication 6, dans lequel une information 35 indiquant que l'utilisation du protocole TCP n'est pas considérée comme un facteur limitant relativement à la latence est produite, lorsque le taux decongestion TClatence est sensiblement supérieur à 2 et sensiblement inférieur à 4.
8. 8. Procédé selon la revendication 6, dans lequel une information 5 indiquant que l'utilisation du protocole TCP n'est pas considérée comme un facteur limitant relativement à la quantité de données en cours de transit est produite, lorsque le taux de congestion TCbif est sensiblement supérieur à 1.
9. 9. Procédé selon l'une quelconque des revendications 10 précédentes, dans lequel, la référence horaire commune au premier terminal (12) et au deuxième terminal (14) est obtenue en: - identifiant, pour la session, une heure locale de réception du paquet reçu en premier et une heure locale de réception du paquet reçu en dernier ; 15 - déterminant le temps total local V de la session à partir de l'heure locale de réception du paquet reçu en premier et du paquet reçu en dernier; - identifiant, pour la session, le marquage temporel du paquet reçu en premier et le marquage temporel du paquet reçu en dernier ; 20 - déterminant le temps total D de la session à partir des marquages temporels du paquet reçu en premier et du paquet reçu en dernier ; - calculant un niveau de précision P des marquages temporels des paquets pour la session, en fonction du temps total local V et du 25 temps total D.
10. 10. Procédé selon la revendication 9, dans lequel, on détermine, pour chaque paquet de la session, l'heure commune d'émission et de réception en: 30 - identifiant un temps de latence minimal correspondant au plus petit des temps de latence déterminés (140) pour les paquets de la session; et, - calculant un écart temporel local en multipliant le niveau de précision P des marquages temporels des paquets pour la 35 session par l'écart temporel entre le marquage temporel dudit paquet et le marquage temporel du premier paquet de la session;- soustrayant à l'écart temporel un ratio du temps de latence minimal.
11. 11. Procédé selon l'une quelconque des revendications précédentes, dans lequel, le temps de latence pour chaque paquet de la session est obtenu (140) en calculant un écart temporel entre le marquage temporel dans le temps de référence local du paquet et le marquage temporel dans le temps de référence commun dudit paquet.
12. 12. Procédé selon l'une quelconque des revendications précédente, dans lequel le réseau de données (10) est configuré pour gérer des équipements utilisateurs de type terminaux mobiles, le deuxième terminal (14) étant un équipement utilisateur adapté à être couplé au réseau en utilisant une interface radio, le procédé comportant en outre les étapes suivantes: - détermination (210) d'un débit maximal théorique atteignable parle deuxième terminal; - collecte (210) d'informations radio relatives à l'interface radio du deuxième terminal; - détermination (240, 250),à l'aide d'un modèle, d'un débit maximal de l'interface radio du deuxième terminal, en fonction des informations radio et du débit maximal théorique atteignable par le deuxième terminal, ; - estimation (260) d'une quantité de données à transmettre pour atteindre un débit maximal TCP en calculant le ratio entre le débit maximal et le temps de latence minimal.
13. 13. Procédé selon la revendications 12, dans lequel le temps de latence minimal est choisi égal à un temps de latence minimal de référence 30 correspondant à un réseau typique sans charge.
14. 14. Procédé selon l'une des revendications 12 ou 13, dans lequel, au cours de l'étape de détermination (240, 250) du débit maximal de l'interface radio du deuxième terminal, les informations radio utilisées par le modèle 35 comprennent une ou une combinaisons d'informations radio parmi la liste suivante: un indicateur de qualité d'une interface radio ou filaire utilisée par ledeuxième terminal pour la session, un taux de retransmission de données reçues affectés par des erreurs en fonction du nombre total de données reçus, meilleure stratégie d'efficacité spectrale compatible avec ce que peut recevoir l'équipement utilisateur, un niveau de variabilité de l'indicateur de qualité de l'interface radio ou filaire, une quantité de ressources allouées à un équipement utilisateur, un nombre d'équipements utilisateurs présents dans une cellule, une quantité ou proportion de temps au cours de laquelle un équipement utilisateur se voit attribué des ressources pour pouvoir émettre ou recevoir des données.
15. 15. Procédé selon la revendication 14, dans lequel, au cours de l'étape de détermination (240, 250) du débit maximal de l'interface radio du deuxième terminal, le modèle tient compte de l'une ou plusieurs des hypothèses parmi la liste suivante: l'indicateur de qualité de l'interface radio/filaire varie sensiblement de quelques décibels dB, le taux de retransmission moyen souhaité est sensiblement égale à un taux donné.
16. 16. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 20 à 15 lorsque ledit programme est exécuté par un processeur.
17. 17. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 25 à15.