FR3020537A1 - MEANS FOR PERFORMANCE EVALUATION IN A DATA NETWORK - Google Patents
MEANS FOR PERFORMANCE EVALUATION IN A DATA NETWORK Download PDFInfo
- Publication number
- FR3020537A1 FR3020537A1 FR1453701A FR1453701A FR3020537A1 FR 3020537 A1 FR3020537 A1 FR 3020537A1 FR 1453701 A FR1453701 A FR 1453701A FR 1453701 A FR1453701 A FR 1453701A FR 3020537 A1 FR3020537 A1 FR 3020537A1
- Authority
- FR
- France
- Prior art keywords
- time
- terminal
- packet
- session
- tcp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000011156 evaluation Methods 0.000 title 1
- 238000000034 method Methods 0.000 claims abstract description 51
- 230000002123 temporal effect Effects 0.000 claims abstract description 23
- 230000005540 biological transmission Effects 0.000 claims abstract description 16
- 238000004590 computer program Methods 0.000 claims description 4
- 230000003595 spectral effect Effects 0.000 claims description 3
- 238000005259 measurement Methods 0.000 description 20
- 238000004458 analytical method Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 8
- 238000012546 transfer Methods 0.000 description 7
- 238000011144 upstream manufacturing Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 230000001174 ascending effect Effects 0.000 description 3
- 238000004513 sizing Methods 0.000 description 3
- 230000001364 causal effect Effects 0.000 description 2
- 238000011835 investigation Methods 0.000 description 2
- 238000000691 measurement method Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- GZPBVLUEICLBOA-UHFFFAOYSA-N 4-(dimethylamino)-3,5-dimethylphenol Chemical compound CN(C)C1=C(C)C=C(O)C=C1C GZPBVLUEICLBOA-UHFFFAOYSA-N 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000003776 cleavage reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 230000007017 scission Effects 0.000 description 1
- 238000012731 temporal analysis Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/026—Capturing of monitoring data using flow identification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0858—One way delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0864—Round trip delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
- H04L43/0882—Utilisation of link capacity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
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.The invention relates to a method for evaluating the performance and quality of the use of the TCP transmission control protocol for transmitting, in a data network, during a session, data packets. : • from a first terminal to a second terminal in a first direction; • from the second terminal to the first terminal, in a second direction. The method comprises a step of collecting protocol information, including temporal markings, relating to the session. The method further comprises the following steps: for at least one of the packets of the session, determination, expressed relative to a reference time common to the first terminal and to the second terminal, from the protocol information, a time of latency in the first sense, latency in the second sense; and / or ○ a loop time between the first terminal and the second terminal as a function of the time marking of at least a first transmitted packet in the first direction or in the second direction and the temporal marking of a second packet transmitted in a direction opposite to the first packet having a reference to the time stamping of the first packet.
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».The present invention relates to means for evaluating quality and performance, within a data network according to the transmission control protocol, more generally designated by the acronym "TCP" for "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.It relates more particularly to means adapted to be implemented on a terminal, to estimate the optimal sizing of the congestion window, the latency in each direction of transmission, as well as the loop time throughout a TCP session. In the context of operating a data network built around the protocols of the TCP / IP suite, measuring the quality and performance of the TCP protocol, particularly at the terminal level, is a major challenge, particularly in determining if the use of the TCP protocol is a factor limiting the performance and / or the quality of the data services between a terminal and an issuer, and identify the optimizations that can be envisaged to optimize the performance and / or the quality noted. In the case of a data transfer between a transmitter and a receiver according to the TCP protocol, the determination of the following information, in real time, is particularly useful to establish reliable measurements of performance and quality at a given moment: the latency between the receiver and the transmitter, in uplink and downlink, during a TCP session, and typically measured in milliseconds; the loop time in uplink and downlink between the transmitter and the receiver within a TCP session, more generally designated by the acronym "RTT" for "Round Trip Time", and typically measured in milliseconds; the amount of data in transit between the transmitter and the receiver in upstream and downstream channel, more generally designated by the acronym "BIF" for "Bytes In Flight", and typically measured in kilobytes, or the size of the corresponding TCP congestion window in number of packets, designated by the acronym "CWND" for "Congestion Window"; the amount of data to be transmitted to reach the maximum TCP throughput between the transmitter and the receiver, and saturate the corresponding channel ("bit pipe" in English), more generally designated by the acronym "BDP" for "Bandwidth Delay Product ", typically measured in kilobytes.
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.However, during the TCP / IP protocol exchanges, the latency, the RTT loop time, the size of the congestion window, the amount of data in transit BIF between the transmitter and the receiver, the minimum amount of data and / or optimal BDP to transmit to achieve the maximum TCP throughput between the transmitter and the receiver, are not exposed. In addition, in the case of a network configured to manage user devices of the mobile terminal type, the critical analysis of downstream and / or upstream TCP performance for a given terminal is made difficult by the large number and variability of Contributing indicators to the overall performance of the protocols used. In particular, for these reasons, it is difficult to know if a given terminal was able to obtain the maximum performance or the optimal quality achievable on the network. Indeed, such a performance or such quality depends on the radio conditions, the current load of the network cell supporting TCP data transfer as well as the load of equipment and links traversed by the TCP communication. But these parameters can fluctuate very quickly, typically in milliseconds. This is why there is also a need for means for verifying whether the TCP protocol, used for the transport of downstream and / or upstream data services by the terminal, is a limiting factor, at a given instant, of the performance and / or quality that can be delivered by the network. One of the objects of the invention is to provide means for determining, at a given moment, the amount of data in transit BIF, between the sender and the receiver, and / or the size of the TCP congestion window. corresponding. One of the objects of the invention is to provide means for enabling the analysis and investigation of TCP performance and quality, in particular to provide information relating for example to the uplink latency between a terminal and another party. at a given time, a TCP session; and / or, at the downstream latency between the other party and the terminal, at a given time, a TCP session; and / or, at an uplink RTT loop time, between the terminal and the other party, at a given instant, of a TCP session; and / or, at a downstream RTT loop time, between the other party and the terminal, at a given time, a TCP session; and / or, at the optimal BDP size of the upstream and downstream congestion window, to allow for example to obtain the maximum throughput to ensure that the TCP protocol is not a limiting factor, at a given moment given; and / or, at the size of the congestion window of a TCP transmitter, at a given instant; and / or, the amount of BIF in-transit bytes of a TCP session between the sender and the receiver, at each instant; and / or, at the comparison, at a given instant, between the latency in each direction and the minimum latency in each direction to reach an optimal TCP quality at the comparison, at a given moment, between the size of the TCP congestion window (or the amount of BIF in-transit bytes) and the minimum and / or optimal amount of BDP data to be transmitted to achieve the maximum TCP performance; 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.Another object of the invention is to provide measurements by collecting TCP / IP capture data, whether this collection is carried out on the transmitter, the terminal or on any other element of the network in disconnection between the transmitter and the receiver . One of the objects of the invention is to allow a causal analysis of the factors limiting the performance during a TCP data service in the upstream or downstream direction. Another object of the invention is to provide means adapted to be deployed and implemented efficiently on a network using the TCP protocol, operated by operators, companies, infrastructure providers. Another object of the invention is to provide reliable tools for testing, measuring, analyzing and investigating TCP / IP performance. More particularly, in the case in particular of a network configured to manage user equipment of the mobile terminal type, the object of the invention is to provide estimation means, at each instant, from data collected on a terminal enabling the capture of radio and TCP / IP traces: on the one hand, the maximum achievable bit rate for a user on an interface, for example an interface called high-speed uplink packet access and / or downlink interface, more commonly referred to as acronym "HSDPA" and "HSUPA" for "High Speed Downlink Packet Access" and "High Speed Uplink Packet Access", a mobile type interface such as "LTE" for "Long Term Evolution" in English, or a wireless interface like "WiFi"; and on the other hand, the minimum and / or optimal amount of data the TCP, from the transmitter's point of view, must provide to an interface to achieve this maximum throughput. Another object of the invention is to provide means for identifying the situations, at each instant, in which the sizing of the TCP congestion window is sufficient or limiting, in order to obtain the maximum achievable bit rate during a data transfer in downward and / or upward path. Another object of the invention is to provide means for the causal and temporal analysis of the factors limiting the performance during downlink and / or upstream data transfer. Another object of the invention is to provide means adapted to be deployed and implemented effectively on a network operated by operators, companies, infrastructure providers. Another object of the invention is to provide reliable tools for testing, measuring, analyzing and investigating TCP performance and quality. One or more of these objects are filled by the method according to the independent claims. The dependent claims further provide solutions to these objects and / or other advantages. More particularly, according to a first aspect, the invention relates to a method for evaluating the performance and quality relating to the use of the TCP transmission control protocol for transmitting, in a data network, during the a session, data packets: from a first terminal to a second terminal in a first direction; from the second terminal to the first terminal, in a second direction. The method comprises a step of collecting protocol information, including temporal markings, relating to the session. The method further comprises at least one determination step, for at least one of the packets of the session, expressed relative to a reference time common to the first terminal and the second terminal, from the protocol information, a latency time. in the first sense, a latency time in the second sense; and / or a loop time between the first terminal and the second terminal as a function of the time marking of at least a first transmitted packet in the first direction or in the second direction and the temporal marking of a second transmitted packet in a direction opposite to the first packet having a reference to the time stamping of the first packet. In particular, the method according to the first aspect may further comprise a step of determining, using the collected time stamps and a local time reference, the reference time common to the first terminal and the second terminal. The use of a common reference time between the first terminal and the second terminal makes it possible to time-adjust the temporal information included in the time markings and in the end makes it possible to create metrics for measuring the time between transmitting and receiving events. Without the use of a common reference time, any comparison of the time information included in the packets is distorted because the first terminal and the second terminal have timestamps expressed in different time frames.
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.In addition, the method can be implemented by collecting TCP / IP capture data, whether this collection is carried out on the first terminal, on the second terminal, or on any other element of the network in cleavage between the first terminal and the terminal. second terminal. The time marking of the packets is for example a field, included in the header of a TCP packet, whose value corresponds to a time stamp or "timestamp" in English, as described in document RFC 1323, "TCP 1323, The Internet Engineering Task Force (IETF), May 1992. TCP protocol information is understood to mean, for example, the information included in the TCP packet headers, in particular the value of TCP packets. SYN and SYN / ACK flags, the value of the time stamp field, or the sequence or acknowledgment number for each packet in the session. The time reference can be determined using a means for measuring the time used on a device hosting a measurement module, for example an internal clock. When the protocol information collected, for each of the packets of the session, comprises a sequence number and an acknowledgment number, the method according to the first aspect may further comprise the following steps: estimation of the amount of data in progress transit, in the first direction and the second direction, between the first terminal and the second terminal, at a time t by: - determining a transmission time for at least one of the packets of the session, expressed relative to the common reference time , according to the temporal markings of said at least one packet; and, - identifying a third packet, transmitted either in the first direction or in the second direction, and whose sequence number is the largest of all the sequence numbers of the collected packets having the same transmission time, relative to the time common reference, that said at least one packet; identifying a fourth packet, transmitted in the opposite direction to the third packet, whose acknowledgment number is the largest among all the acknowledgment numbers of the packets whose transmission time, relative to the common reference time, is prior to time t; calculating the difference between the sequence number of the third packet and the acknowledgment number of the fourth packet. The method may further comprise a step of estimating the congestion rate TClatence at time t, obtained by calculating the ratio between the latency time in the first or second direction and the minimum latency.
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.In particular, information indicating that the use of the TCP protocol is not considered as a limiting factor with respect to the latency can be produced, when the congestion rate TClatence is substantially greater than 2 and substantially less than 4. The time of Minimum latency can be calculated as substantially equal to the 90th percentile of the minimum value of all latencies determined for session packets in this sense. The method may further comprise a step of estimating the congestion rate TCRTT at time t, obtained by calculating the ratio between the loop time and the minimum loop time. In particular, information indicating that the use of the TCP protocol is not considered as a limiting factor with respect to the loop time can be produced, when the congestion rate TCRTT is substantially greater than 2 and substantially less than 4. The time the minimum loop being calculated as substantially equal to the 90th percentile of the minimum value of all the loop times determined for the packets of the 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.The method may further comprise a step TCbif congestion rate estimation, at time t, obtained by calculating the ratio between the amount of data in transit and the amount of data to be transmitted to reach the optimal TCP rate. In particular, information indicating that the use of the TCP protocol is not considered as a limiting factor relative to the amount of data in transit is produced, when the TCbif congestion rate is typically between 1 and 4. common time reference to the first terminal (terminal 1) and the second terminal (terminal 2) can be obtained by: - identifying, for the session, a local time of reception of the received packet first and a local time of reception of the received packet; latest; determining the total local time V of the session from the local time of the packet received first and the packet received last; identifying, for the session, the temporal marking Tterminal1 and Tterminal2 of the packet received first and the temporal marking Tterminal1 and Tterminal2 of the packet received last; determining the total times Dterminal1 and Dterminal2 of the session from the time markings of the packet received first and the packet received last; calculating a level of precision Pterminal1 and Pterminal2 of the temporal markings of the packets for the session, as a function of the total local time V and the total times Dterminal1 and 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.The common transmission and reception time can be determined, for each packet of the session, by: identifying a minimum latency time corresponding to the smallest of the latencies determined for the packets of the session; and, - calculating a local time difference by multiplying the accuracy level P of the temporal markings of the packets for the session by the time difference between the time stamping of said packet and the time stamping of the first packet of the session; - subtracting a minimum latency ratio from the time difference. The latency time for each packet of the session can be obtained by calculating a time difference between the time stamp in the local reference time of the packet and the time stamp in the common reference time of said packet. More particularly, for latency in one direction: calculating a time difference between the local time of the packet and the time stamp "transmitter" of said packet - for latency in the other direction: calculating a time difference between the loop time and the latency time already calculated The RTT loop time for each packet of the session can be obtained by calculating a time difference between the local time of the packet and the time stamp "receiver" of said packet The RTT loop time for each packet of the session can also be obtained by: - selecting at least one of the packets of the session, issued in the first or second sense; determining the time H1 at which said packet was collected; - Searching and determining the H2 collection time of a session packet, sent in the opposite direction to said packet, having a common time stamp with said at least one packet; calculating the difference between the time H2 and the time H1: RTT = H2-H1 The RTT loop time for each packet of the session can also be obtained, by analyzing three packets, without necessarily using the capture clock, by: - selecting at least one of the packets of the session, transmitted in the first or second direction, and determining the time stamping Ti of said at least one packet; seeking a fifth packet, transmitted in the opposite direction to said packet, having a common time stamp with said at least one packet; seeking a sixth packet, sent in the opposite direction to the fifth packet, having a common time stamp with the fifth packet; determining the temporal marking T2 of the sixth packet; calculating the difference between the temporal marking T2 and the temporal marking Ti; calculating the RTT loop time as equal to the product of the accuracy level of the time markings and of the T2-T1 difference, ie RTT = (T2-T1) xP. In one embodiment, the data network is configured to manage user devices of the mobile terminal type, the second terminal being a user equipment adapted to be coupled to the network using a radio interface. The method then further comprises the following steps: determining a theoretical maximum flow rate attainable by the second terminal; - collecting radio information relating to the radio interface of the second terminal; - determination, using a model, a maximum rate of the radio interface of the second terminal, according to the radio information and theoretical maximum rate achievable by the second terminal; estimating a quantity of data to be transmitted in order to reach an optimal TCP bit rate by calculating the ratio between the maximum bit rate and the minimum idle time. The method can also answer several questions relating to the analysis and the investigation of the performance of a mobile network, in particular: What is the maximum bit rate that can be reached at any moment by a terminal during a TCP data transfer? downhill or rising? Does the measured flow rate comply with the maximum achievable flow rate? What is the minimum / optimal dimension of the TCP congestion window of the TCP transmit window of a TCP transmitter, at any given time, to obtain the expected maximum downlink / uplink rate? Is the sizing of the TCP congestion window sufficient or limiting, at any given moment, to obtain the maximum downlink / uplink rate achievable by the network? The minimum latency time can be chosen equal to a minimum reference latency corresponding to a typical network without load. During the step of determining the maximum rate of the second terminal's radio interface, the radio information used by the model may include one or a combination of radio information from the following list: a quality indicator of an interface radio or wired used by the second terminal for the session, a retransmission rate of received blocks affected by errors according to the total number of blocks received, best spectral efficiency strategy compatible with what can receive the user equipment, a level of variability of the quality indicator of the radio or wired interface, a quantity of resources allocated to a user equipment, a number of user equipment present in a cell or a user connection node, a quantity or proportion of time during which a user equipment is allocated resources to be able to transmit or receive data. During the step of determining the maximum rate of the second terminal's radio interface, the model can take into account one or more of the assumptions such as for example: the quality indicator of the radio / wired interface varies substantially a few dB (eg 1 dB); the desired average retransmission rate is substantially x%, for example 10%. According to a second aspect, the invention relates to a computer program comprising instructions for performing the steps of the method according to the first aspect, when said program is executed by a processor. Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any form what other form is desirable. In particular, it is possible to use scripting languages, such as tcl, javascript, python, perl, which allow "on demand" code generation and do not require significant overhead for their generation or 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.According to a third aspect, the invention relates to a computer-readable recording medium on which is recorded a computer program comprising instructions for executing the steps of the method according to the first aspect. The information carrier may be any entity or any device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a diskette or a hard disk. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed by an electrical or optical cable, by radio or by other means. The program according to the invention can be downloaded in particular on an Internet or Intranet network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. Other features and advantages of the present invention will appear in the following description of embodiments, with reference to the accompanying drawings, in which: - Figure 1 is a diagram of a data network, adapted to implement implementing data transfers according to the protocols of the TCP / IP suite and comprising a module for measuring performance and quality relating to the TCP protocol, according to an embodiment of the invention; FIG. 2 is a block diagram of a method for measuring performance and quality relating to the TCP protocol, according to one embodiment of the invention; FIG. 3 is a block diagram of a method for measuring performance and quality relating to the TCP protocol, in an HSDPA network, according to one embodiment of the invention; In the remainder of the description, reference to the acronym TCP refers to the transmission control protocol, more generally designated by the acronym "TCP" for "Transmission Control Protocol", and as described in particular by the "Transmission control protocol", Request for comments No. 793, The Internet Engineering Task Force (IETF), September 1981. FIG. 1 schematically illustrates a data network 10, adapted to implement data transfers according to the protocols of FIG. the TCP / IP suite. The network 10 typically comprises usual interconnection means (not shown in the figure) to enable the routing of data, such as routers, bridges, firewalls, switches, etc. FIG. 1 shows a first terminal 12 and a second terminal 14, each provided with means for coupling to the network 10, and means for implementing a TCP / IP protocol stack. The first terminal 12 and the second terminal 14 may be of one of the following types: computer, mobile phone, tablet, server, and more generally any device capable of exchanging data according to the TCP / IP protocols. The second terminal 14 comprises a module 16 for measuring performance and quality relating to the TCP protocol, according to one embodiment of the invention. For the sake of clarity, in the following description, it is assumed that the measurement module 16 is located on the second terminal 14. However, the measurement module 16 could be implemented at any point of the network 10 and / or on any device belonging to the network 10, from which it is possible to capture or observe data exchanges between the first terminal 12 and the second terminal 14. This includes, but is not limited to, the first terminal 12, the routing devices used to route the data between the first terminal 12 and the second terminal 14, or any other intermediate device located between the first terminal 12 and the second terminal 14. In the following description, it is assumed that a session S, of TCP session type, is established between the first terminal 12 and the second terminal 14. In addition, the following acronyms are used in the following description: TCP / SYN: TCP packet whose header includes a SYN flag corresponding to a synchronization or connection establishment request; TCP / SYN / ACK packet: A TCP packet whose header contains an ACK flag to indicate that the packet is an acknowledgment of receipt. In addition, in the following description, it is taken as an example TCP packets having, in their header, a field whose value corresponds to a time stamp or "timestamp" in English. Document RFC 1323, "TCP Extensions for High Performance", Request for comments No. 1323, The Internet Engineering Task Force (IETF), May 1992, describes such a header, and the presence of such a field: the packets TCP, meeting this specification for time stamping, therefore fulfill this criterion. However, other means of temporal markings may prove to be adequate, since the latter make it possible to obtain temporal information on the date on which the packet was transmitted. As a reminder and for the sake of clarity, it is recalled that the TCP packets including a time stamp according to the document RFC 1323 include in their header in particular: - a field TSVal, or "TimeStamp Value" in English, adapted to be provided by the transmitter of the packet, with a time stamp obtained from its local clock, and function of the time of emission of the packet; and, a field TSEcR, or "TimeStamp Echo Reply" in English, adapted to be filled in, by the sender of the packet, with the value of the TSval field of the last packet received, at the time of transmission, in the session in Classes. FIG. 2 illustrates, by a block diagram, a method of measuring performance and quality relating to the TCP protocol, according to a first embodiment of the invention. The method is particularly adapted to be implemented by the measurement module 16. During a step 110, the TCP protocol information of the data stream Fd exchanged during the session S between the first terminal 12 and the second terminal 14 are captured. This step 110 can be performed continuously, in real time or near real-time, so as to intercept TCP protocol information instantaneously and allow performance analysis and continuous TCP quality. The protocol information of the data flow Fd can also be acquired and then recorded so as to allow a subsequent performance analysis. By TCP protocol information is meant in particular the information included in the headers of the TCP packets, in particular the value of the SYN and SYN / ACK flags, the value of the time stamp field, or the number of the packets in the session S During step 110, the local arrival time of the packets received at the device hosting the measurement module 16, in this case the second terminal 14, is determined and recorded. In particular, for any packet observed on the measurement module 16, it is possible to record a local time of arrival thanks to a clock installed on the measurement module 16. It is considered that a local time is expressed in the form a number of milliseconds or microseconds since an origin date managed by the clock of the measurement module 16. During an optional step 120, it is checked whether the time marking field is present and / or indicated in the packets. TCP captured from the session S. For example, during the session S, the second terminal 14 having transmitted a TCP / SYN packet and the first terminal 12 transmitted a TCP / SYN / ACK packet, it is possible to carry out this verification by reading in the TCP / SYN and TCP / SYN / ACK packet headers the TCP options used. If these include the corresponding time stamp option as described in (TCP Extensions for High Performance, Request for comments # 1323, The Internet Engineering Task Force (IETF), May 1992, then the In a step 130, for the session S, the local arrival time H i, the first received packet Piet, the local arrival time H, of the last received packet P, is identified. at the level of the device hosting the measurement module 16, in this case the second terminal 14. The total local time V of the session S is then determined by subtracting the local arrival time H, at the time of local arrival H1, ie V = H, -Hi.For the same, in step 130, the first received packet PEicomportant a field TSEcR filled in, for the session S, is identified.The last received packet PEn having a field TSEcR filled in, for session S, is also identified. ur D1 by subtracting the value TSEcREi from the field TSEcR of the packet PEi with the value TSEcRE of the field TSEcR of the packet PEN, that is D1 = TSEcRE, - TSEcREi.A first precision P1 of the time stamping for the session S, calculated for the first terminal, is then calculated, for example by dividing the value D1 by the total local time V, ieP1 = r. In addition, during step 130, the first received packet PE having a field TSval filled, for the session S, is identified. The last received packet PEn having a TSval field filled in, for the session S, is also identified. The value D2 is then determined by subtracting the value TSvalEi from the field TSval from the packet PEi to the value TSvalEn of the field TSval of the packet PEN, that is D2 = TSvalEn - TSval El. The precision P2 of the time stamping for the session S, calculated for the second terminal, is then calculated, for example by dividing the value D2 by the total local time V, ieP2 = f'.Dans a typical nominal case, the accuracy P1 and accuracy P2 can vary substantially between 1 ms and 100 ms. The use of the time stamps according to the specifications of the document RFC 1323, included in the TCP headers of the packets, makes it possible to create a reference time, common between the first terminal 12 and the second terminal 14, allowing accurate time stamping, according to the same shared time frame, the packets exchanged during the session S. During a step 140, the RTT loop time, for each segment of the session S, up and down, is estimated. A first embodiment of the step 140 for estimating the loop time for each segment of the session S, up and down, will now be described. For each packet, the value R1 of the field TSEcR and the local time H1 of local arrival of said packet are recorded.
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.The time difference Tbeta between TSEcR and TSEcRref of the referent packet (for example, the first packet of the session or packet generating the smallest RTT) is calculated by multiplying by the time precision P1 or P2 as a function of the upward or downward direction calculated at the first time. Step 130. The local time difference Hbeta between H1 and Href of the reference packet is calculated. The loop time is calculated as the difference between Hbeta and Tbeta. A second embodiment of the step 140 for estimating the loop time for each segment of the session S, uplink and downlink, will now be described. For each packet received, the value El of the field TSVal and the local time Hy1 of local arrival of said packet are recorded. The packet, subsequently received during the session S, is then searched whose field value TSEcR is equal to the value E1 in order to determine the local arrival local time Hy2 of said packet. An estimate of the RTT loop time is then determined by calculating the difference between the local time He and the local time He, ie RTT = H2-H1. It should be noted that, in the event that the measurement module 16 is located on a device of the network 10 between the first terminal 12 and the second terminal 14, it is possible to measure the RTT loop time in both directions (between the measurement point and the first terminal, between the measurement point and the second terminal). terminal). A third embodiment of the step 140 for estimating the loop time for each segment of the session S, upstream and downstream, will now be described. The RTT loop time for each session packet can also be obtained by analyzing three packets, without necessarily using the capture clock, by: - selecting at least one of the packets of the session, transmitted in the first or second sense and determining the temporal marking Ti of said packet; seeking a fifth packet, transmitted in the opposite direction to said packet, having a common time stamp with said packet; seeking a sixth packet, sent in the opposite direction to the fifth packet, having a common time stamp with the fifth packet; determining the temporal marking T2 of the sixth packet; calculating the difference between the temporal marking T2 and the temporal marking Ti; calculating the RTT loop time as equal to the product of the accuracy level of the time markings and of the T2-T1 difference, ie RTT = (T2-T1) xP. During a step 150, the amount of BIF data in transit between the first terminal 12 and the second terminal 14, for the session S, is estimated. The amount of data in transit BIF can be estimated, whatever the device to which the measurement module 16 is coupled. More particularly, one embodiment of estimating the amount of BIF in-transit data during step 150 will now be described. A first embodiment of step 150 for computing the amount of data in transit BIF between the first terminal 12 and the second terminal 14 will now be described. For each packet Pa, the value Ea of the field TSVal, the local time Ha of local arrival of said packet and the value Seqa of the sequence number are read. The time difference Ta between TSVaI and TSvalref of the referent packet (for example, the first packet of the session or packet having generated the smallest RTT) multiplied by the time accuracy P1 or P2 as a function of the upward or downward direction is calculated. calculated in step 130. In the past a Pb packet of direction opposite to Pa having the highest Ackb acknowledgment number (ACK or SACK) whose time difference multiplied by its temporal accuracy is less than the calculated one is searched for in the past. for Pa. The BIF is then the difference between Seqa and Ackb. A second embodiment of step 150 for computing the amount of BIF data in transit between the first terminal 12 and the second terminal 14 will now be described. Among all the RTT loop time estimations calculated during a step 140, the minimum value RTTmin for all the packets transmitted during the session S is searched for. For all the packets transmitted during the session S, one calculates a local time of reference HEx obtained as follows: HEx = (Ex- E0) x P -0 RTTmin (ER) with - Ex the value of the field TSEcR, for the packet of which it is desired to calculate I local time of reference Hi, The accuracy of the time marking for all the packets transmitted during the session S, as calculated during the step 130; where û is between 0 and 1. For a given segment x whose sequence number is equal to SEQx, or for a given acknowledgment x whose acknowledgment number is equal to ACKX, 25 - the local time of HEx reference corresponding to segment x; in all the segments received during the session S, the segment y having the largest sequence number SEQmax and the reference local time HEy is less than or equal to the local reference time HEx is searched for ; in all the acknowledgments received during the session S, the acknowledgment z having the highest acknowledgment number ACQmax (ACK or SACK) and whose local reference time HEz is less than or equal to Hex local reference time; The amount of data in transit BIF is then estimated by calculating the difference between the largest sequence number SEQmax and the largest acknowledgment number ACKmax, namely: 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.A third embodiment of step 150 for calculating the amount of data in transit BIF between the first terminal 12 and the second terminal 14 will now be described. For each packet received, the value El of the field TSVal and the sequence number SEQ of said packet are read. the search is carried out, in the same direction, having the largest sequence number SEQ and having the same time stamp, which may be the packet itself; - We then search the packet, received previously during the session S, whose field value TSEcR is equal to the value El, and having the largest ACK acknowledgment number (or SACK). The BIF is then determined to be SEQ-ACK or (SEQ-SACK). During a step 160, the TCP congestion rate T is estimated, by calculating, for each value of the RTT loop time obtained during step 140: RTT T = xx RTTmin with: - RTTMIN the 90th percentile of the minimum value of all the RTT loop times between the two parts of the S session; a real number between 2 and 3. According to a variant of the method presented in FIG. 1, during a step 140 ', the latency time L for each packet of the session can be obtained by calculating a time difference between time stamping in the local reference time of the packet and time stamping in the common reference time of said packet. More particularly, for the latency L in one direction: calculating a time difference between the local time of the packet and the time stamp "transmitter" of said packet - for the latency L in the other direction: calculating a time difference between the time of loop and the latency time already calculated According to said variant of the method, it is possible to use a second embodiment of the step 160 of calculating the congestion rate T, the congestion rate being defined as follows: T = XX LmIN with: - Lm the 90th percentile of the minimum value of all L latencies in a given direction, between the two parts of the S session; - x a real number between 2 and 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.FIG. 3 illustrates, by a block diagram, a method of measuring performance relating to the TCP protocol, according to one embodiment of the invention. The method is written below in the context of an HSDPA network. However, the method could be used, both uplink and downlink, to measure the performance of other types of radio interfaces, in particular HSUPA interfaces, mobile telephony type interfaces such as LTE, or a wireless interface. like WiFi. The method is particularly adapted to be implemented by the measurement module 16. The method is adapted for use with the method described in FIG. 2, in particular to provide additional performance measurements relating to the HSDPA network. More particularly, in the remainder of the description, it is taken into account that the network 10 is configured to manage user devices of the mobile terminal type using a high speed downlink packet access protocol, more commonly referred to as English acronym HSDPA for High Speed Downlink Packet Access. The HSDPA protocol is described in particular in the 3GPP specification, TS 25.308, High Speed Downlink Packet Access (HSDPA); Overall description; Stage 2 ", Rel. 11, 2012-09-12.Furthermore, in the following example, the second terminal 14 is a user equipment, or "user equipment" in English, for example a mobile telephone, adapted to be coupled to the network using the HSDPA protocol. User equipment means any terminal used by a user of the HSDPA network, and characterized in particular by an HSDPA category designating its maximum capacity and performance, on the downstream path, in particular the maximum number of codes that it can decode in parallel, the supported modulations, etc. The method makes it possible to estimate at any given moment, from data collected on a terminal for capturing radio traces and TCP / IP: firstly, the maximum achievable bit rate for a user on an HSDPA interface; and on the other hand, the minimum and / or optimal amount of data the TCP, from the transmitter's point of view, must provide to an HSDPA interface to achieve this maximum throughput.
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%.During a step 210, the TCP protocol information of the data flow Fd exchanged during the session S between the first terminal 12 and the second terminal 14 are captured. During a step 210, the radio information relating to the HSDPA radio interface is also captured. Similarly, during step 210, the HSDPA category of the second terminal 14 is determined, for example by exploiting the information exchanged between the second terminal 14 and the HSDPA network relating to the radio interface. This step 210 can be performed continuously, in real time or near real-time, so as to intercept instantaneously the TCP protocol information and the information relating to the HSDPA radio interface and allow continuous analysis of TCP and HSDPA performance. . The protocol information of the data flow Fd and the radio information relating to the HSDPA radio interface can also be acquired and then recorded so as to allow a subsequent performance analysis. By information relating to the HSDPA radio interface, the HSDPA category of the second terminal 14 is especially understood. During the step 210, the local arrival time of the packets received at the device hosting the measurement module 16, in this case the second terminal 14 is determined and recorded. The local arrival time of a packet of the session S is determined using a means for measuring the time implemented on the device hosting the measurement module 16. For example, an internal clock of the second terminal 14 can be exploited for this purpose. During a step 220, the minimum RTT loop time of the network is estimated or calculated. For this, it is possible to implement steps 120, 130 and 140 of the performance measurement method relating to the TCP protocol, as described above and illustrated in FIG. 2. Alternatively, the minimum RTTmIN loop time can be considered as equal to a minimum reference RTTmIN loop time corresponding to a typical HSDPA network, without load, and equal for example substantially to 60 ms. During a step 230, the amount of BIF data in transit is estimated or calculated between the first terminal 12 and the second terminal 14. For this, it is possible to implement step 150 of the performance measurement method relating to the TCP protocol, as described above and illustrated in FIG. 2. During a step 240, an HSDPA performance model is chosen according to the HSDPA category of the second terminal 14, obtained during step 210 An HSDPA performance model is understood to mean a model for evaluating the maximum bit rate achievable by a user equipment belonging to said HSDPA category as a function, for example, of a quality indicator of the channel used by the second terminal for the HSDPA. session S, and a received HDSPA block rate affected by errors based on the total number of HDSPA blocks received. The quality indicator of the channel used by the second terminal for session S is for example the HDSPA indicator designated by the acronym "CQI" for "Channel Quality Indicator", expressed on a logarithmic scale of 1 to 30 , and sent by the user equipment to a node of the so-called "NodeB" network to express the quality of the HSDPA signal. The CQI is used by the node "NodeB" to select the best spectral efficiency strategy compatible with what the user equipment can receive. The ratio of HDSPA blocks received affected by errors as a function of the total number of HDSPA blocks received is, for example, the indicator of the HDSPA error block rate designated by the acronym "BLER" for "Block Error Rate". In addition, the HSDPA performance model can take other parameters into account in determining the maximum achievable bit rate, for example the variability of the CQI, the number of HSDPA codes that a user equipment can be allocated, the number of user equipment present in the same cell, the scheduling rate as a function of the terminal time, etc. The scheduling rate in a time and shared resource system corresponds, over a given observation period, to the number of times an element (here our terminal) has been allocated resources. The HSDPA performance model can be a theoretical model, a model built from laboratory and / or field performance measurements, or a combination of the two types of models mentioned above. During a step 250, from the radio information relating to the HSDPA radio interface collected in step 210, using the HSDPA performance model chosen in step 240, the flow is calculated. maximum DmAx, expressed in megabits per second (symbol Mbit / s). For example, the following simplifying assumptions can be used to facilitate calculations: - the CQI indicator can vary rapidly from 1 to 2 dB; the second terminal 14 is assumed to be alone in its HSDPA cell, can obtain all the HSDPA codes, and be scheduled 100% of the time; the average desired BLER error block rate is substantially 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.During a step 260, the amount of data to be transmitted BDP, in ascending or descending lane, is estimated to reach the maximum bit rate TCP, in kilobytes, by applying the following formula for each value of the RTT loop time. obtained during step 140: DMAX BDP = 8 × RTTmiN During a step 270, the congestion rate TCbif is estimated as the ratio between the amount of BIF data in transit obtained during step 230, in ascending or descending channel, and the amount of data to be transmitted BDP obtained during step 260, in ascending or descending way, TCbif = BBDIFp. If this rate TCbif is greater than or equal to a threshold x, typically between 1 and 4, the TCP protocol can be considered as not limiting.
Claims (17)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1453701A FR3020537B1 (en) | 2014-04-24 | 2014-04-24 | MEANS FOR PERFORMANCE EVALUATION IN A DATA NETWORK |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1453701A FR3020537B1 (en) | 2014-04-24 | 2014-04-24 | MEANS FOR PERFORMANCE EVALUATION IN A DATA NETWORK |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3020537A1 true FR3020537A1 (en) | 2015-10-30 |
| FR3020537B1 FR3020537B1 (en) | 2017-08-25 |
Family
ID=51063667
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1453701A Active FR3020537B1 (en) | 2014-04-24 | 2014-04-24 | MEANS FOR PERFORMANCE EVALUATION IN A DATA NETWORK |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3020537B1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3138591A1 (en) | 2022-07-28 | 2024-02-02 | Bouygues Telecom | Characterization of at least part of an internet network |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070195797A1 (en) * | 2006-02-23 | 2007-08-23 | Patel Alpesh S | Network device that determines application-level network latency by monitoring option values in a transport layer message |
| EP2611094A1 (en) * | 2011-12-30 | 2013-07-03 | British Telecommunications Public Limited Company | Obtaining information from data items |
-
2014
- 2014-04-24 FR FR1453701A patent/FR3020537B1/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070195797A1 (en) * | 2006-02-23 | 2007-08-23 | Patel Alpesh S | Network device that determines application-level network latency by monitoring option values in a transport layer message |
| EP2611094A1 (en) * | 2011-12-30 | 2013-07-03 | British Telecommunications Public Limited Company | Obtaining information from data items |
Non-Patent Citations (2)
| Title |
|---|
| BORMAN QUANTUM CORPORATION B BRADEN UNIVERSITY OF SOUTHERN CALIFORNIA V JACOBSON GOOGLE D ET AL: "TCP Extensions for High Performance; draft-ietf-tcpm-1323bis-21.txt", TCP EXTENSIONS FOR HIGH PERFORMANCE; DRAFT-IETF-TCPM-1323BIS-21.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 11 April 2014 (2014-04-11), pages 1 - 49, XP015098640 * |
| YIN XU ET AL: "Dynamic regulation of mobile 3G/HSPA uplink buffer with Receiver-side Flow Control", NETWORK PROTOCOLS (ICNP), 2012 20TH IEEE INTERNATIONAL CONFERENCE ON, IEEE, 30 October 2012 (2012-10-30), pages 1 - 10, XP032329239, ISBN: 978-1-4673-2445-8, DOI: 10.1109/ICNP.2012.6459976 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3138591A1 (en) | 2022-07-28 | 2024-02-02 | Bouygues Telecom | Characterization of at least part of an internet network |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3020537B1 (en) | 2017-08-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP4082174B1 (en) | System and method for estimation of quality of experience (qoe) for video streaming | |
| US8737243B2 (en) | Methods and apparatus for monitoring network link quality | |
| US10623280B2 (en) | Diagnostic testing | |
| EP3295612B1 (en) | Uplink performance management | |
| JP2014502459A (en) | System and method for measuring available capacity and narrow link capacity of an IP path from a single endpoint | |
| CN114009089A (en) | Estimating quality metrics for delay sensitive traffic flows in a communication network | |
| EP2862324B1 (en) | Method and device for quick, unobtrusive estimation of the available bandwidth between two ip nodes | |
| EP3560152B1 (en) | Determining the bandwidth of a communication link | |
| JPWO2015174069A1 (en) | COMMUNICATION SYSTEM, RECEPTION DEVICE, TRANSMISSION DEVICE, AND COMMUNICATION METHOD | |
| McQuistin et al. | Is Explicit Congestion Notification usable with UDP? | |
| JP5052653B2 (en) | TCP communication quality estimation method and TCP communication quality estimation apparatus | |
| Dinh-Xuan et al. | Study on the accuracy of QoE monitoring for HTTP adaptive video streaming using VNF | |
| EP2396086B1 (en) | Communication method | |
| FR3020537A1 (en) | MEANS FOR PERFORMANCE EVALUATION IN A DATA NETWORK | |
| US20050102391A1 (en) | Method and apparatus providing an asymmetric ping procedure | |
| JP2009296304A (en) | Tcp communication quality estimating method and tcp communication quality estimating device | |
| Lübben et al. | Estimation method for the delay performance of closed-loop flow control with application to TCP | |
| JP2014116840A (en) | Communication quality estimation device | |
| EP3963842A1 (en) | Methods and devices for measuring reputation in a communication network | |
| Kato et al. | Inferring TCP Congestion Control Algorithms by Correlating Congestion Window Sizes and their Differences | |
| WO2023169938A1 (en) | Method for managing a retransmission of data exchanged on a path established between a first communication equipment and a second communication equipment by way of a value of an intermediate performance parameter determined by an intermediate node belonging to said path | |
| WO2023078993A1 (en) | Method for managing retransmission of data exchanged on a path established between a first communication equipment and a second communication equipment by way of a value of an intermediate performance parameter | |
| WO2023078995A2 (en) | Method for checking the reliability of a first value of a flow control parameter relating to a connection intended to be established between a first communication device and a second communication device linked by a path comprising at least one intermediate node by means of a value of an intermediate performance parameter determined by the intermediate node | |
| EP4135291A1 (en) | System, device, and method of measuring directional latency and congestion in a communication network | |
| US20230412893A1 (en) | Identification of Session Boundaries in Encrypted Video Streams |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20151030 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| TP | Transmission of property |
Owner name: SOFTATHOME, FR Effective date: 20210302 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 9 |
|
| PLFP | Fee payment |
Year of fee payment: 10 |
|
| PLFP | Fee payment |
Year of fee payment: 11 |