WO2010058143A1 - Procédé de mesure des performances d'un réseau ip et système associé - Google Patents

Procédé de mesure des performances d'un réseau ip et système associé Download PDF

Info

Publication number
WO2010058143A1
WO2010058143A1 PCT/FR2009/052278 FR2009052278W WO2010058143A1 WO 2010058143 A1 WO2010058143 A1 WO 2010058143A1 FR 2009052278 W FR2009052278 W FR 2009052278W WO 2010058143 A1 WO2010058143 A1 WO 2010058143A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
requests
user
performance
request
Prior art date
Application number
PCT/FR2009/052278
Other languages
English (en)
Inventor
Frédérique POIVERT-BECQ
Original Assignee
Centre National D'etudes Spatiales
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Centre National D'etudes Spatiales filed Critical Centre National D'etudes Spatiales
Priority to US13/130,784 priority Critical patent/US8499076B2/en
Priority to ES09797071T priority patent/ES2396668T3/es
Priority to EP09797071A priority patent/EP2359535B1/fr
Publication of WO2010058143A1 publication Critical patent/WO2010058143A1/fr

Links

Classifications

    • 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/50—Testing arrangements
    • 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

Definitions

  • the subject of the invention is that of communication networks that support the IP ("Internet Protocol”) protocol. More particularly, the invention relates to a method for measuring the performance of an existing IP communication network.
  • IP Internet Protocol
  • An IP communication network consists of nodes and links connecting the nodes.
  • the links have different physical supports.
  • the network may for example have a short-range radio link, a long-range radio link, a wired link, or other types of links.
  • the individual performance of the network components is evaluated on the transfer of data bits belonging to the header portion of an IP datagram. It is therefore an evaluation of the network performance at the "lowest" layers of the OSI model, ie the layer 1 (physical) layer, the layer 2 (MAC) and the layer 3 (network), which are related to the transmission of the signal along the physical medium of the link.
  • the operator of the IP communication network seeks to characterize the communication in terms of offer to a user whose terminal is connected to the network. The user uses the network to access resources required when running applications on the user terminal. In Consequently, the user perceives the quality of the communication on the network through the good execution of these applications.
  • the performance of the IP network must therefore be evaluated at the "highest" layers of the OSI model, that is, the layer 4 (transport - TCP or UDP) and the layers of levels 5 to 7 ( application) or application layers.
  • the network operator wishes to evaluate, and preferably in a simple manner in terms of implementation, the performance of the IP communication network at any time during the operation of the latter, and in particular at a later date. updating a component, such as replacing switches or routers at nodes in the network.
  • the invention therefore aims to overcome these problems and to meet these needs.
  • the invention relates to a method for measuring the performance of a network, comprising the steps of: setting a plurality of requests, each request pointing to an accessible resource, via said network, from a user terminal connected to said network network, the parameterized queries being stored in a database;
  • test campaign consisting of:
  • the method comprises one or more of the following characteristics, taken in isolation or in any technically possible combination: - the test campaign consists of executing, in parallel, several user sessions;
  • the user sessions are executed by different user terminals connected to said network; during the step of creating a user session, a profile parameter is used as a criterion for selecting certain parameterized queries, the profile parameter defining a particular type of usage behavior of the available resources. on the network;
  • said at least one characteristic variable of the response is the time separating the transmission of a request on the network from the reception at the user terminal of the entirety of the data file corresponding to the resource indicated by the query;
  • resources accessed during the execution of a test campaign are stored on at least one terminal server connected to the network, the state of which is known during the execution of said test campaign;
  • said network supports the IP protocol; and, during the execution of a test campaign, the position and / or the speed of the user terminal are memorized during the transmission of each of the requests of the said at least one session, and the said aggregation step takes into account stored instantaneous positions and / or velocities for determining said estimator.
  • the invention also relates to a system for measuring a performance estimator of a network supporting the IP protocol, making it possible to implement the method presented above, and comprising:
  • a user session creation means for selecting a plurality of requests in the database
  • a means of executing a test campaign able to transmit, successively in time, the different requests of at least one session user and calculate, for each request issued, the value of at least one characteristic variable of the response received by the transmitting terminal;
  • FIG. 1 is a schematic representation of the implementation architecture of the method for measuring an estimator of the performance of an IP communication network
  • FIG. 2 is a representation, in the form of blocks, of a software whose execution on a user terminal of the architecture of FIG. 1 implements said measurement method; and, - Figure 3 is an algorithm representing the different steps of said measurement method.
  • the implementation of the method of measuring an estimator of the performance of an IP communication network makes it possible to test an existing network that supports communication between at least one user terminal and at least one server terminal.
  • a train 2 consisting of a locomotive 4 and several cars 6, runs along a track 8.
  • a communication service via the Internet 10 is offered to passengers 2.
  • a user uses a user terminal, such as computers 12 and 14, to access various resources stored on server terminals connected to the Internet 10, such as server 16.
  • an IP communication network 18 first comprises a wireless connection of the Wi-Fi type, which is established between each user terminal 12, 14 and a point of access. local access 20.
  • the train 2 is equipped with a plurality of local access points 20, for example a local access point 20 by car 6.
  • the various local access points 20 are connected to each other and to each other.
  • a gateway computer 22 located in the locomotive 4, by links of the Ethernet type, for example. So, the train 2 is equipped with a local network 23, forming a mobile section of the IP communication network 18.
  • the gateway 22 is equipped with means making it possible to establish a satellite link with a satellite 24.
  • the satellite 24 is connected with a base station 26, fixed to the ground.
  • the satellite 24 forms a communication relay between the mobile gateway 22 and the fixed base station 26.
  • the base station 26 constitutes an access point to the Internet network 10.
  • the IP communication network 18 to be tested is a composite network associating links having different physical supports.
  • This network 18 allows the communication between a user terminal on board a moving train and a server terminal on the ground.
  • test software 50 shown diagrammatically in FIG. 2, is executed on a computer having technical characteristics similar to those of a user terminal 12, 14.
  • the computer on which is executed the test software 50 is the user terminal 12.
  • the purpose of the execution of the test software 50 is to reproduce as faithfully as possible at least one and preferably several sessions of use of the Internet by several passengers, while calculating, in real time, the values of the characteristic variables of the response received as a result of issuing each of the IP requests constituting the sessions.
  • a request is a pointer to a resource available on a server terminal connected to the Internet 10 and accessible via the network 18 and the Internet 10.
  • a request associates a data transfer protocol (HTTP, FTP, etc.). ), the resource address (URL for "Universal Resource Locator"), the data file name, the data file extension, and possibly other parameters.
  • HTTP HyperText Transfer Protocol
  • FTP FTP
  • URL Universal Resource Locator
  • the extension of the data file indicates the format of the data present in the file and, consequently, the application adapted to the reading of this file.
  • data files may be transferred according to protocols different. Several protocols can be used during the same test campaign, so as to estimate the quality of the application layers of the network 18.
  • the test software 50 comprises a plurality of program instructions stored in storage means of the user terminal 12 and capable of being executed by a processor of the user terminal 12 to implement the method of measuring the performance of the IP communication network. .
  • the test software 50 comprises:
  • a module 52 making it possible to parameterize queries, to create user sessions, and to prepare test campaigns.
  • the module 52 optionally makes it possible to manage a user profile parameter, as will be described hereinafter in detail. Finally, the module 52 ensures the execution of a test campaign;
  • a module 54 making it possible to manage the different formats and protocols for transferring the resources accessed during a test campaign, and to associate with each of the formats and / or transfer protocols one or more variables that are characteristic of the quality of the communication;
  • a module 56 for aggregating and processing the results of one or more test campaigns and for determining the value of a performance estimator of the tested IP communication network;
  • a module 58 of database in which the modules 52, 54 and 56 are able to read and write data;
  • a module 60 constituting a human-machine interface offering to the operator conducting the test, various screens adapted to the execution of the modules 52, 54 and 56.
  • the method for measuring the performance of an IP network begins with the development of a test campaign.
  • the preparation comprises, in step 100, the preparation of a request.
  • the operator enters the necessary parameters for the request to point to a predetermined available resource via the network 18 and the Internet 10, for example on the server 16.
  • the request is saved in a query table in the database 58.
  • the operator develops and stores a plurality of requests.
  • the query table also includes a column for associating with a request a duration corresponding to a reading time by the user or use by an application of the data file associated with the query considered.
  • step 1 10 by creating a user session that corresponds to a group of requests representing the real behavior of a user.
  • the operator navigates the query table of the database 58 and selects some of the stored queries.
  • the identifiers of the selected queries are grouped in an ordered list associated with the created user session.
  • the list is finally stored in the database 58.
  • the operator can create a user session in several ways: it can be a random extraction of several requests from the database 58; it can be a user session dedicated to testing a particular application, and in this case the operator selects several requests pointing to resources having the same format; it can be a session reproducing the browsing behavior on the Internet of a particular type of user.
  • the query table's query criterion is a profile parameter representing different types of Internet usage behavior.
  • a "Professional" profile can be predefined for retrieving requests from the database pointing to resources corresponding to pages of an application of stock exchange Internet sites, to enterprise resources by means of a virtual private network (VPN) connection, and resources corresponding to the consultation of emails.
  • VPN virtual private network
  • the operator After creating one or more user sessions, the operator prepares, in step 120, a particular test campaign by selecting, in the database 58, one or more user sessions that will be run in parallel during the campaign. test thus prepared. Then, asynchronously with the preceding steps, in step 130, the operator, by means of the interface of the module 52, selects and then starts the execution of a particular test campaign comprising at least the session K.
  • the execution of the test campaign results in the transmission, by the user terminal 12 on the IP network 18, of the various requests grouped together in the session K.
  • the requests are transmitted according to a time sequence. which follows the order in which the requests are ordered in the list associated with the session K.
  • the requests are issued according to a random time sequence relative to the way in which queries are ordered in the list associated with the user session.
  • step 140 a first request is sent and the user terminal 12 waits (step 150) for the corresponding answer.
  • This wait lasts for a waiting time which is at most equal to a maximum waiting time Tmax.
  • the user terminal 12 receives a response in a time less than the maximum waiting time Tmax and the measurement method goes to step 170; Either the waiting time exceeds the maximum waiting time Tmax and the user terminal 12 associates with the first request a response of the type
  • step 170 the user terminal 12, having received a response to the transmitted request, calculates the value of a characteristic variable of the data reception following the transmission of a request.
  • a characteristic variable of the data reception following the transmission of a request As indicated in the second column of Table 1, different characteristic variables may be associated with a resource access service.
  • the value of the characteristic variable calculated for the current request is stored in the database 58 in step 180.
  • step 190 that the transmission of a first request has led to a failure or the calculation of a value of a characteristic variable, the execution of the software 50 passes to the next request in the list of requests from session K, unless the entire list has been browsed. In this case, when all the requests of the session K have been sent, the test campaign ends. Note that to get closer to a normal user session, a waiting time can be observed between the instant of receipt of the response to a request and the instant of issue of the next request. This waiting time is equivalent to the user's consultation time of the file of data of the response received. This waiting time can be a parameter entering into the development of the request.
  • the different user terminals used in the measurement campaign are not necessarily connected to each other. They can be independent of each other, provided they are synchronized on the same time base.
  • the results obtained by each of the user terminals are aggregated together, by means of the aggregation module 56.
  • the different values of the characteristic variables of the responses are processed. It consists of aggregating (step 200) the results of the different user sessions with each other and of collecting the values of the variables characterizing the same resource format and / or the same transfer protocol.
  • the processing continues in step 210 by calculating the value of a network performance estimator 18. For example, the measured response times for all requests relating to a resource of the type "Internet site page "Can be the subject of a statistical calculation.
  • the associated estimator is, for example, the average response time or the difference to this average.
  • the operator can, at the end of the processing, graphically display the results by means of the man-machine interface 60.
  • the method is implemented to estimate the quality of a network having a mobile section. Consequently, it is advantageous to associate, with the execution of a test campaign, information relating to the positioning and speed of the train 2.
  • This data is obtained by equipping the user terminal 12 with a positioning system. GPS ("Global Positioning System") type, so as to know the instantaneous position and speed of the train 2.
  • GPS Global Positioning System
  • measurements of the instantaneous position and speed of the train 2 are carried out during the delivery of a request, and are then stored in the database 58 together with the value of the characteristic variable of the response to this request. request.
  • the data processing module 56 associates these instantaneous positioning and speed measurements with the calculation of the estimator.
  • the iteration of a test campaign for different positions and / or speeds of the train 2 leads to the calculation of a series of estimators giving information on the impact of the position and the speed of the train 2 on the network performance 18.
  • the estimator In order for the estimator to best represent the network 18, it is advantageous for the requests to point to resources made available on a server terminal 16 whose state is known throughout the execution of the test campaign.
  • the terminal 16 is managed by the operator of the IP network 18.
  • metrics associated with a service are presented.
  • the characteristic variable "response time” corresponds to the time separating the instant of transmission of the request on the network 18 and the end of complete charging time, in a memory of the user terminal 12, the data file associated with the resource specified by this request.
  • VoIP Voice over IP
  • test session is interactive and the user is invited, through an adapted interface, to note the quality of the voice over IP service that has just been proposed to him.
  • An MOS estimator for "mean opinion score" in English is then used.
  • the server 16 executes an application specific to the voice over IP service that makes it possible to implement, in particular, the SIP and RTP protocols.
  • the voice over IP service test can be done in the client-server sense, but also in the server-client sound, provided that the specific application implementing the SIP protocol is adapted, in order to provide a return path for the quantities statistics computed by the server, to the client computer.
  • the server-client sense the server stores, in its storage means, a reference voice file which it transmits to the client, upon request thereof, during the execution of a voice service test session. over IP.
  • the server 16 executes an auxiliary application allowing, in collaboration with the test application executed on the client computer, to test this service, either in the client-server sense, or in the direction client server.
  • auxiliary characterization file of the UDP service to be tested.
  • This file includes for example:
  • the meaning of the data transfer to be tested (server-client or client-server); the profile of the data to be transmitted (random or fixed); the size of the useful data to be transmitted (fixed, random, alternating); the flow rate to be generated; and,
  • the auxiliary characterization file is read by the client computer.
  • the information contained in this auxiliary characterization file is used either by the test application of the client computer or by the auxiliary application running on the server computer.
  • the characteristic UDP estimators that are determined during the test are, for example:
  • the "transit delay” corresponding to the delay between the sending of a data packet and the reception of this packet.
  • the calculation of the transit delay requires that the client and the server are perfectly synchronized with each other. This is achieved by synchronizing the clocks of these two computers using, for example, satellite positioning means of the GPS type which deliver a clock signal.
  • the "loss rate” representing the percentage of lost packets.
  • the header of a transmitted UDP packet has a sequence number which is incremented by one unit each time a new packet is sent. The loss rate is then easily calculated by the receiver from the number of packets received and the sequence number of the last received packet.
  • jitter -The "jitter" (jitter) representing the time difference between the intervals between two packets when they are sent and when they are received. Jitter is given by the following formula:
  • TS the table containing the moments of transmission of the packets, information placed by the sender in the header of the packets and extracted by the receiver on receipt of the packet.
  • the auxiliary test application evaluates these statistical quantities, then the transfers to the client and the main test application.
  • a TCP connection dedicated to the repatriation of statistical quantities is planned.
  • the server 16 regularly transmits statistical quantities. If P is the periodicity of these data transfers, in case of absence of data for more than two successive periods, 2P, the link between the server and the client is supposed to fail and causes the interruption of the session of the test.
  • UDP protocol the periodicity of these data transfers
  • the auxiliary file provides the necessary information to the server to generate the data traffic required for the UDP protocol test. It is the client who then calculates the statistical magnitudes allowing the determination of the estimators of the UDP service.
  • test application executed by the client computer periodically sends a request "ping" to a machine predetermined network, and preferably the gateway 22 managed by the operator of the network.
  • the network is considered to be available when the "ping" request is followed by a response within a time limit whose value is configurable.
  • the "availability rate” estimator is calculated by dividing the number of "ping" requests with response in the allotted time, by the total number of "ping” requests issued.
  • the availability estimator is displayed in real time on the human-machine interface of the client computer, and in deferred time in addition to a metric such as that presented previously.
  • the initial phase of creating a session with an availability test involves the creation of an auxiliary file containing the information needed to implement this test.
  • This auxiliary file has the following parameters: the target machine of the ping request;
  • the sampling period for the calculation of the availability rate (evaluation over one hour for example).
  • the compression test makes it possible to highlight the capacity of a compressed data transfer, either upstream (client-server) or downstream (server-client).
  • the compression estimator which can be evaluated several times during the same session, is for example obtained by comparing the transfer duration of a reference file in compressed form with respect to the transfer duration of the same uncompressed file.
  • a trace is saved in a "log" file.
  • a "Log" file of the gateway computer 22 is used for the steps of setting up the requests and creating the sessions.
  • a log file is a text file grouping all the requests re-issued by the gateway computer 22 from the local network 23 to the network 18.
  • each request is dated.
  • the sessions of N actual users are recorded during a first movement of the train along a path.
  • the test campaign will consist of reissuing the requests of the log file, respecting the chronology of the log file, so as to reproduce the N previous user sessions during a new movement of the train along the same path.
  • the measurement system according to the invention has been described in the context of its use in a train, but it makes it possible to carry out measurement campaigns in any fixed or mobile node of any network.
  • the implementation of the invention makes it possible to measure the performance of an existing real network, and this from the point of view of the user whose terminal executes an application that accesses a particular resource.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de mesure des performances d'un réseau (18). Le procédé comporte les étapes consistant à : - paramétrer des requêtes pointant vers des ressources accessibles depuis un ordinateur connecté au réseau, les requêtes paramétrées étant mémorisées dans une base de données; - créer une session utilisateur consistant à regrouper différentes requêtes mémorisées; - exécuter une campagne de test consistant à enchaîner dans le temps rémission des différentes requêtes d'une session, chaque requête étant émise par un terminal utilisateur connecté au réseau; - pour chacune des requêtes émises, attendre une réponse et calculer la valeur d'au moins une variable caractéristique de la réponse reçue; et, - agréger les différentes valeurs de la variable caractéristique calculées au cours de la campagne de test pour déterminer la valeur d'un estimateur des performances du réseau.

Description

Procédé de mesure des performances d'un réseau IP et système associé
L'invention a pour domaine celui des réseaux de communication supportant le protocole IP (« Internet Protocol »). Plus particulièrement, l'invention est relative à un procédé de mesure des performances d'un réseau de communication IP existant.
Un réseau de communication IP est constitué de nœuds et de liaisons reliant les noeuds. Dans le cas d'un réseau composite, les liaisons possèdent des supports physiques différents. Le réseau peut par exemple posséder d'une liaison radio de courte portée, une liaison radio de longue portée, une liaison filaire, ou d'autres types de liaisons.
Après qu'un réseau de communication IP a été déployé, l'exploitant doit pouvoir en connaître les performances.
En effet, il existe un écart entre les performances réelles et les performances théoriques d'un réseau IP, ces dernières étant définies par exemple dans un cahier des charges. Les performances théoriques du réseau sont calculées en ajoutant les performances individuelles des composants du réseau. Mais, d'une part, ces performances individuelles sont évaluées au moyen de simulations et non de tests réels, et, d'autre part, de nombreuses distorsions affectent les performances individuelles d'un composant lorsqu'il est intégré au réseau réel. En particulier, au niveau d'un noeud assurant un changement de support physique entre deux liaisons, les moyens qui permettent de relayer un datagramme IP, introduisent des retards ou des erreurs.
De plus, les performances individuelles des composants du réseau sont évaluées sur le transfert de bits de données appartenant à la portion d'en-tête d'un datagramme IP. Il s'agit donc d'une évaluation des performances du réseau au niveau des couches les plus «basses» du modèle OSI, c'est-à-dire la couche de niveau 1 (physique), la couche de niveau 2 (MAC) et la couche de niveau 3 (réseau), qui sont relatives à la transmission du signal le long du support physique de la liaison. Or, l'exploitant du réseau de communication IP cherche à caractériser la communication en termes d'offre à un utilisateur dont le terminal est connecté au réseau. L'utilisateur se sert du réseau pour accéder à des ressources requises lors de l'exécution d'applications sur le terminal utilisateur. En conséquence, l'utilisateur perçoit la qualité de la communication sur le réseau à travers la bonne exécution de ces applications. Les performances du réseau IP doivent donc être évaluées au niveau des couches les plus «hautes» du modèle OSI, c'est-à-dire la couche de niveau 4 (transport - TCP ou UDP) et les couches de niveaux 5 à 7 (application) ou couches applicatives.
Enfin, l'exploitant du réseau souhaite pourvoir évaluer, et de préférence de manière simple en termes de mise en œuvre, les performances du réseau de communication IP à tout moment de l'exploitation de celui-ci, et en particulier lors d'une mise à jour d'un composant, tel que le remplacement de commutateurs ou de routeurs aux nœuds du réseau.
L'invention a donc pour but de pallier ces problèmes et de répondre à ces besoins.
Pour cela, l'invention porte sur un procédé de mesure des performances d'un réseau, comportant les étapes consistant à : - paramétrer une pluralité de requêtes, chaque requête pointant vers une ressource accessible, via ledit réseau, depuis un terminal utilisateur connecté audit réseau, les requêtes paramétrées étant mémorisées dans une base de données ;
- créer au moins une session utilisateur en sélectionnant plusieurs requêtes paramétrées ;
- exécuter une campagne de test consistant à :
- enchaîner dans le temps l'émission, depuis un terminal utilisateur, des différentes requêtes de ladite au moins une session ; et, pour chacune des requêtes émises, - attendre une réponse et calculer la valeur d'au moins une variable caractéristique de la réponse reçue ;
- agréger les valeurs de ladite au moins une variable caractéristique calculées au cours de l'exécution de la campagne de test pour déterminer la valeur d'un estimateur de la qualité de la communication. Suivant des modes particuliers de l'invention, le procédé comporte une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : - la campagne de test consiste à exécuter, en parallèle, plusieurs sessions utilisateur ;
- les sessions utilisateur sont exécutées par des terminaux utilisateur différents, connectés audit réseau ; - au cours de l'étape de création d'une session utilisateur, on utilise un paramètre de profil en tant que critère pour effectuer la sélection de certaines requêtes paramétrées, le paramètre de profil définissant un type particulier de comportement d'utilisation des ressources disponibles sur le réseau ;
- ladite au moins une variable caractéristique de la réponse est le temps séparant l'émission d'une requête sur le réseau, de la réception, au niveau du terminal utilisateur, de l'intégralité du fichier de données correspondant à la ressource indiquée par la requête ;
- des ressources accédées durant l'exécution d'une campagne de test sont stockées sur au moins un terminal serveur connecté au réseau, dont l'état est connu au cours de l'exécution de ladite campagne de test ;
- ledit réseau supporte le protocole IP ; et, lors de l'exécution d'une campagne de test, on mémorise la position et/ou la vitesse du terminal utilisateur lors de l'émission de chacune des requêtes de ladite au moins une session, et ladite étape d'agrégation tient compte des positions et/ou des vitesses instantanées mémorisées pour déterminer ledit estimateur.
L'invention porte également sur un système de mesure d'un estimateur des performances d'un réseau supportant le protocole IP, permettant de mettre en œuvre le procédé présenté précédemment, et comportant :
- un moyen de base de données ; - un moyen de paramétrage de requêtes aptes à être émises par un terminal utilisateur connecté audit réseau pour accéder à une ressource disponible sur ledit réseau, lesdits paramètres des requêtes étant stockés dans le moyen de base de données ;
- un moyen de création de session utilisateur permettant la sélection d'une pluralité de requêtes dans la base de données ;
- un moyen d'exécution d'une campagne de test apte à émettre, successivement dans le temps, les différentes requêtes d'au moins une session utilisateur et à calculer, pour chaque requête émise, la valeur d'au moins une variable caractéristique de la réponse reçue par le terminal émetteur ; et,
- un moyen d'agrégation des valeurs de ladite au moins une variable caractéristique sur ladite campagne de test pour déterminer un estimateur de la qualité de la communication.
L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, prise uniquement à titre d'exemple, et faite en se référant aux dessins annexés, dans lesquels :
- la figure 1 est une représentation schématique de l'architecture de mise en œuvre du procédé de mesure d'un estimateur des performances d'un réseau de communication IP ;
- la figure 2 est une représentation, sous forme de blocs, d'un logiciel dont l'exécution sur un terminal utilisateur de l'architecture de la figure 1 met en œuvre ledit procédé de mesure ; et, - la figure 3 est un algorithme représentant les différentes étapes dudit procédé de mesure.
La mise en œuvre du procédé de mesure d'un estimateur des performances d'un réseau de communication IP permet de tester un réseau existant, support de la communication entre au moins un terminal utilisateur et au moins un terminal serveur.
En se référant à l'architecture de la figure 1 , un train 2, constitué d'une locomotive 4 et de plusieurs voitures 6, circule le long d'une voie 8. Un service de communication via l'Internet 10 est offert aux passagers du train 2. Un utilisateur se sert d'un terminal utilisateur, tel que les ordinateurs 12 et 14, pour accéder à diverses ressources, stockées sur des terminaux serveur connectés à l'Internet 10, tels que le serveur 16.
Depuis le terminal utilisateur 12 vers l'Internet 10 et le serveur 16, un réseau de communication IP 18 comporte d'abord une liaison sans fil du type Wi- Fi, qui est établie entre chaque terminal utilisateur 12, 14 et un point d'accès local 20. Eventuellement, le train 2 est équipé d'une pluralité de points d'accès locaux 20, par exemple un point d'accès local 20 par voiture 6. Les différents points d'accès locaux 20 sont connectés entre eux et à un ordinateur passerelle 22 située dans la locomotive 4, par des liaisons du type Ethernet par exemple. Ainsi, le train 2 est équipé d'un réseau local 23, formant une section mobile du réseau de communication IP 18. La passerelle 22 est équipée de moyens permettant d'établir une liaison satellitaire avec un satellite 24. Le satellite 24 est en liaison avec une station de base 26, fixe au sol. Le satellite 24 forme un relais de communication entre la passerelle 22 mobile et la station de base 26 fixe. La station de base 26 constitue un point d'accès au réseau Internet 10.
Ainsi, le réseau de communication IP 18 à tester est un réseau composite associant des liaisons ayant des supports physiques différents. Ce réseau 18 autorise la communication entre un terminal utilisateur embarqué à bord d'un train en mouvement et un terminal serveur au sol.
L'exploitant du réseau 18, qui met à disposition des passagers du train 2 le service de communication via l'Internet 10, souhaite connaître la qualité des communications effectivement établies au moyen du réseau 18.
Pour ce faire, un logiciel de test 50, représenté schématiquement sur la figure 2, est exécuté sur un ordinateur présentant des caractéristiques techniques similaires à celles d'un terminal utilisateur 12, 14. Dans ce qui suit, l'ordinateur sur lequel est exécuté le logiciel de test 50 est le terminal utilisateur 12.
L'exécution du logiciel de test 50 a pour but de reproduire aussi fidèlement que possible au moins une et de préférence plusieurs sessions d'utilisation de l'Internet par plusieurs passagers, tout en calculant, en temps réel, les valeurs de variables caractéristiques de la réponse reçue à la suite de l'émission de chacune des requêtes IP constituant les sessions.
Pour mémoire, une requête est un pointeur vers une ressource disponible sur un terminal serveur connecté à l'internet 10 et accessible via le réseau 18 et le réseau Internet 10. Une requête associe un protocole de transfert de données (HTTP, FTP, etc.), l'adresse de la ressource (URL pour « Universal Resource Locator »), le nom du fichier de données, l'extension du fichier de données, et éventuellement d'autres paramètres.
L'extension du fichier de données, indique le format des données présentes dans le fichier et, par conséquent, l'application adaptée à la lecture de ce fichier.
Comme l'indique la première colonne du tableau 1 , à la fin de la présente description, des fichiers de données peuvent être transférés selon des protocoles différents. Plusieurs protocoles peuvent être utilisés durant une même campagne de test, de manière à estimer la qualité des couches applicatives du réseau 18.
Le logiciel de test 50 comporte une pluralité d'instructions de programme stockées dans des moyens de mémorisation du terminal utilisateur 12 et aptes à être exécutées par un processeur du terminal utilisateur 12 pour mettre en œuvre le procédé de mesure des performances du réseau de communication IP. Le logiciel de test 50 comporte :
- un module 52, permettant de paramétrer des requêtes, de créer des sessions utilisateur, et de préparer des campagnes de test. Le module 52 permet éventuellement de gérer un paramètre de profil utilisateur, comme cela sera décrit ci-après en détail. Enfin, le module 52 assure l'exécution d'une campagne de test ;
- un module 54, permettant de gérer les différents formats et protocoles de transfert des ressources accédées lors d'une campagne de test, et d'associer à chacun des formats et/ou protocoles de transfert une ou plusieurs variables caractéristiques de la qualité de la communication ;
- un module 56, permettant d'agréger et de traiter les résultats d'une ou de plusieurs campagnes de test et de déterminer la valeur d'un estimateur des performances du réseau de communication IP testé;
- un module 58 de base de données, dans laquelle les modules 52, 54 et 56 sont aptes à lire et écrire des données ; et,
- un module 60 constituant une interface homme-machine offrant à l'opérateur conduisant le test, différents écrans adaptés à l'exécution des modules 52, 54 et 56.
En se reportant à la figure 3, le procédé de mesure des performances d'un réseau IP débute par l'élaboration d'une campagne de test.
L'élaboration comporte, à l'étape 100, la préparation d'une requête. Dans une fenêtre adaptée, ouverte sur l'écran du terminal utilisateur 12, l'opérateur saisie les paramètres nécessaires pour que la requête pointe vers une ressource prédéterminée disponible, via le réseau 18 et l'Internet 10, par exemple sur le serveur 16. Une fois paramétrée, la requête est sauvegardée dans une table de requêtes dans la base de données 58. L'opérateur élabore et stocke ainsi une pluralité de requêtes. Eventuellement, la table de requêtes comporte également une colonne permettant d'associer à une requête une durée correspondant à une temps de lecture par l'utilisateur ou d'utilisation par une application du fichier de données associé à la requête considérée.
Puis, l'élaboration se poursuit, à l'étape 1 10, par la création d'une session utilisateur qui correspond à un groupe de requêtes représentant le comportement réel d'un utilisateur. Pour créer une session utilisateur, l'opérateur navigue dans la table de requêtes de la base de données 58 et sélectionne certaines des requêtes mémorisées. Les identifiants des requêtes sélectionnées sont regroupés dans une liste ordonnée, associée à la session utilisateur crée. La liste est finalement stockée dans la base de données 58. L'opérateur peut créer une session utilisateur de plusieurs manières : il peut s'agir d'une extraction aléatoire de plusieurs requêtes de la base de données 58 ; il peut s'agir d'une session utilisateur dédiée au test d'une application particulière, et dans ce cas l'opérateur sélectionne plusieurs requêtes pointant vers des ressources ayant un même format ; il peut s'agir d'une session reproduisant le comportement de navigation sur l'Internet d'un type particulier d'utilisateur. Dans ce dernier cas, on utilise comme critère d'interrogation de la table de requêtes un paramètre de profil représentant différents types de comportement d'utilisation de l'Internet. On peut, par exemple, prédéfinir un profil «Professionnel» permettant d'extraire de la base de données des requêtes pointant vers des ressources correspondant à des pages d'une application de sites Internet de bourse, vers des ressources d'entreprise au moyen d'une connexion VPN (« Virtual Private Network »), et vers des ressources correspondant à la consultation de courriers électroniques. On peut également définir un profil «Loisir» pour lequel on sélectionne, dans la base de données 58, les requêtes pointant vers des ressources associées à des fichiers de musique ou de vidéo.
Après avoir créé une ou plusieurs sessions utilisateur, l'opérateur élabore, à l'étape 120, une campagne de test particulière en sélectionnant, dans la base de données 58, une ou plusieurs sessions utilisateur qui seront à exécuter en parallèle lors de la campagne de test ainsi préparée. Puis, de manière asynchrone avec les étapes précédentes, à l'étape 130, l'opérateur, au moyen de l'interface du module 52, sélectionne puis lance l'exécution d'une campagne de test particulière comportant au moins la session K. L'exécution de la campagne de test se traduit par l'émission, par le terminal utilisateur 12 sur le réseau IP 18, des différentes requêtes regroupées dans la session K. Selon une première variante de réalisation, les requêtes sont émises selon un enchaînement temporel qui suit l'ordre dans lequel sont ordonnées les requêtes dans la liste associée à la session K. Selon une seconde variante de réalisation, lors de l'exécution d'une compagne de test, les requêtes sont émises selon un enchaînement temporel aléatoire par rapport à la manière dont sont ordonnées les requêtes dans la liste associée à la session utilisateur.
Plus précisément, à l'étape 140, une première requête est émise et le terminal utilisateur 12 attend (étape 150) la réponse correspondante. Cette attente dure pendant un temps d'attente qui est au maximum égale à un temps d'attente maximum Tmax. Soit le terminal utilisateur 12 reçoit une réponse dans un temps inférieur au temps d'attente maximum Tmax et le procédé de mesure passe à l'étape 170 ; Soit le temps d'attente dépasse le temps d'attente maximum Tmax et le terminal utilisateur 12 associe à la première requête une réponse du type
« Echec » (étape 160).
A l'étape 170, le terminal utilisateur 12, ayant reçu une réponse à la requête émise, calcule la valeur d'une variable caractéristique de la réception de données suit à rémission d'une requête. Comme indiqué dans la seconde colonne du tableau 1 , différentes variables caractéristique peuvent être associées à un service d'accès à une ressource.
La valeur de la variable caractéristique calculée pour la requête en cours est stockée dans la base de données 58 à l'étape 180.
Finalement, à l'étape 190, que l'émission d'une première requête ait conduit à un échec ou au calcul d'une valeur d'une variable caractéristique, l'exécution du logiciel 50 passe à la requête suivante dans la liste des requêtes de la session K, à moins que l'ensemble de la liste ait été parcourue. Dans ce cas, lorsque l'ensemble des requêtes de la session K ont été émises, la campagne de test prend fin. On notera que pour se rapprocher d'avantage d'une session utilisateur normale, un temps d'attente peut être observé entre l'instant de réception de la réponse à une requête et l'instant d'émission de la requête suivante. Ce temps d'attente est équivalent au temps de consultation par l'utilisateur du fichier de données de la réponse reçue. Ce temps d'attente peut être un paramètre entrant dans l'élaboration de la requête.
Lorsqu'au cours d'une campagne de test plusieurs sessions utilisateurs sont exécutées en parallèle, elles le sont soit à partir d'un unique terminal utilisateur émulant plusieurs terminaux utilisateur ayant des adresses IP différentes, soit à partir de plusieurs terminaux utilisateur connectés entre eux. Dans ce dernier cas, les différents terminaux utilisateurs utilisés dans la campagne de mesure ne sont pas nécessairement connectés entre eux. Ils peuvent être indépendants les uns des autres, à condition d'être synchronisés sur une même base de temps. A l'issue de la campagne de test, les résultats obtenus par chacun des terminaux utilisateurs sont agrégés ensemble, au moyen du module d'agrégation 56.
A l'issue d'une campagne de test, les différentes valeurs des variables caractéristiques des réponses sont traitées. Il s'agit d'agréger (étape 200) les résultats des différentes sessions utilisateur entre elles et de rassembler les valeurs des variables caractérisant le même format de ressource et/ou le même protocole de transfert. Le traitement se poursuit à l'étape 210 par le calcul de la valeur d'un estimateur des performances du réseau 18. Par exemple, les temps de réponse mesurés pour l'ensemble des requêtes portant sur une ressource du type « page de site Internet » peut faire l'objet d'un calcul statistique. L'estimateur associé est, par exemple, la moyenne des temps de réponse ou l'écart à cette moyenne. L'opérateur peut, à l'issue du traitement, afficher graphiquement les résultats au moyen de l'interface homme-machine 60.
Dans le mode de réalisation décrit, le procédé est mis en œuvre pour estimer la qualité d'un réseau ayant une section mobile. En conséquence, il est intéressant d'associer à l'exécution d'une campagne de test, des informations relatives au positionnement et à la vitesse du train 2. Ces données sont obtenues en équipant le terminal utilisateur 12 d'un système de positionnement du type GPS (« Global Positionning System »), de manière à connaître la position et la vitesse instantanées du train 2. Lors de l'exécution de la campagne de test, des mesures de la position et de la vitesse instantanées du train 2 sont réalisées lors de rémission d'une requête, puis sont stockées dans la base de données 58 en même temps que la valeur de la variable caractéristique de la réponse à cette requête. Le module de traitement des données 56 associe ces mesures de positionnement et de vitesse instantanées, au calcul de l'estimateur. L'itération d'une campagne de test pour des positions et/ou des vitesses différentes du train 2 conduit au calcul d'une série d'estimateurs donnant des informations sur l'impact de la position et de la vitesse du train 2 sur les performances du réseau 18.
Pour que l'estimateur représente au mieux le réseau 18, il est avantageux que les requêtes pointent vers des ressources mises à disposition sur un terminal serveur 16 dont l'état est connu tout au long de l'exécution de la campagne de test. De préférence, le terminal 16 est géré par l'exploitant du réseau IP 18. Dans ce qui suit, des exemples de métriques associées à un service sont présentées.
Pour le protocole HTTP ou HTTPS, la variable caractéristique « temps de réponse » correspond au temps séparant l'instant d'émission de la requête sur le réseau 18 et l'instant de fin de chargement complet, dans une mémoire du terminal utilisateur 12, du fichier de données associé à la ressource indiquée par cette requête.
Pour le service de voix sur IP (VoIP), il peut s'agir d'une mesure subjective.
Dans ce cas, l'exécution de la session de test est interactive et l'on invite l'utilisateur, à travers une interface adaptée, à noter la qualité du service de voix sur IP venant de lui être proposé. Un estimateur MOS pour « mean opinion score » en anglais, est alors utilisé.
Il peut également s'agir d'une mesure objective. Dans ce cas, le calcul d'une variable pertinente a été définie par l'ETSI et est décrite dans l'annexe E de la spécification technique ETSI TS 101 329-5V1.1.2 (2002-01 ). Le calcul de l'estimateur dérive de la valeur du R-factor décrit dans cette spécification technique.
Pour la mise en œuvre de ce test objectif, le serveur 16 exécute une application spécifique au service voix sur IP qui permet de mettre en œuvre, en particulier, les protocoles SIP et RTP. Le test du service voix sur IP peut être fait dans le sens client-serveur, mais également dans le son serveur-client à condition d'adapter l'application spécifique mettant en oeuvre le protocole SIP, afin de fournir une voie de retour des grandeurs statistiques calculées par le serveur, vers l'ordinateur client. Dans le sens serveur-client, le serveur stocke, dans ses moyens de mémorisation, un fichier vocal de référence qu'il transmet au client, sur requête de celui-ci, lors de l'exécution d'une session de test du service voix sur IP.
Pour le service de transfert de données UDP, le serveur 16 exécute une application auxiliaire permettant, en collaboration avec l'application de test exécutée sur l'ordinateur client, de tester ce service, soit dans le sens client- serveur, soit dans le sens serveur-client.
Pour tester ce service, lors de la phase de création d'une session, l'utilisateur crée un fichier auxiliaire de caractérisation du service UDP à tester. Ce fichier comporte par exemple :
-l'adresse IP du serveur cible ;
-le sens du transfert de données à tester (serveur-client ou client-serveur) ; -le profil des données à transmettre (aléatoires ou fixes) ; -la taille des données utiles à transmettre (fixe, aléatoire, alternée) ; -le débit à générer ; et,
-la périodicité des échanges des grandeurs statistiques calculées. Lors de l'exécution de la session du test UDP, dans une phase initiale de celle-ci, le fichier auxiliaire de caractérisation est lu par l'ordinateur client. Les informations contenues dans ce fichier auxiliaire de caractérisation sont utilisées soit par l'application test de l'ordinateur client, soit par l'application auxiliaire exécutée sur l'ordinateur serveur.
Les estimateurs caractéristiques du protocole UDP qui sont déterminés lors du test sont par exemple :
-Le « délai de transit » correspondant au délai entre l'envoi d'un paquet de données et la réception de ce paquet. Le calcul du délai de transit impose que le client et le serveur soient parfaitement synchronisés entre eux. Ceci est réalisé en synchronisant les horloges de ces deux ordinateurs en utilisant, par exemple, des moyens de positionnement par satellite du type GPS qui délivrent un signal d'horloge. -Le « taux de perte » représentant le pourcentage de paquets perdus. L'entête (« header ») d'un paquet UDP émis comporte un numéro de séquence qui est incrémenté d'une unité à chaque émission d'un nouveau paquet. Le taux de perte est alors facilement calculé par le récepteur à partir du nombre de paquets reçus et du numéro de séquence du dernier paquet reçu.
-La "gigue" (« jitter ») représentant la différence de temps entre les intervalles séparant deux paquets lors de leur émission et lors de leur réception. La gigue est donnée par la formule suivante :
J=abs[TR(n)-TR(n-1 )-TS(n)+TS(n-1 )] où : abs () est la fonction retournant la valeur absolue, n est le numéro du paquet reçu, TR() la table des instants de réception des paquets, calculés localement par le récepteur, et
TS() la table contenant les instants de transmission des paquets, informations placées par l'émetteur dans l'en-tête des paquets et extraites par le récepteur à la réception du paquet. Ainsi, dans le sens client-serveur, l'application auxiliaire de test évalue ces grandeurs statistiques, puis les transferts vers le client et l'application principale de test. Pour ce faire, une connexion TCP dédiée au rapatriement des grandeurs statistiques est prévue. Le serveur 16 transmet régulièrement les grandeurs statistiques. Si P est la périodicité de ces transferts de données, en cas d'absence de données pendant plus de deux périodes successives, 2P, la liaison entre le serveur et le client est supposée en échec et entraîne l'interruption de la session du test du protocole UDP.
Dans le sens serveur-client, le fichier auxiliaire donne les informations nécessaires au serveur pour qu'il génère le trafic de données requis pour le test du protocole UDP. C'est le client qui calcule alors les grandeurs statistiques permettant la détermination des estimateurs du service UDP.
D'autres services peuvent être testés de manière quantitative : i) II peut s'agir par exemple d'un test de disponibilité consistant à ce que l'application test exécutée par l'ordinateur client émette périodiquement une requête « ping » vers une machine prédéterminée du réseau, et de préférence la passerelle 22 gérée par l'opérateur du réseau.
Le réseau est considéré comme disponible lorsque la requête « ping » est suivie d'une réponse dans un délai imparti dont la valeur est paramétrable. L'estimateur « taux de disponibilité » est calculé en divisant le nombre de requête « ping » avec réponse dans le temps imparti, par le nombre total de requête « ping » émises. L'estimateur de disponibilité est affiché en temps réel sur l'interface homme-machine de l'ordinateur client, et en temps différé en complément d'une métrique telle que celle présentée précédemment.
La phase initiale de création d'une session comportant un test de disponibilité comporte la création d'un fichier auxiliaire regroupant les informations nécessaires à la mise en œuvre de ce test. Ce fichier auxiliaire comporte les paramètres suivants : -la machine cible de la requête « ping » ;
-le délai entre deux requêtes successives ; -le délai imparti pour la réponse ;
-la période d'échantillonnage pour le calcul du taux de disponibilité (évaluation sur une heure par exemple). ii) II peut également s'agir d'un test de compression. Certains segments du réseau à tester transfèrent des données en les compressant. C'est en particulier le cas lorsque les données transitent par un satellite. Le test de compression permet de mettre en évidence la capacité d'un transfert de données compressées, soit en sens montant (client-serveur), soit en sens descendant (serveur-client). L'estimateur de compression, qui peut être évalué à plusieurs reprises au cours d'une même session, est par exemple obtenu en comparant la durée de transfert d'un fichier de référence sous forme compressée par rapport à la durée de transfert de ce même fichier non compressé. iii) II peut aussi s'agir par exemple encore d'un test de temps de réponse. Ce test est similaire au test de disponibilité à l'exception du fait que la requête n'est pas une simple requête « ping », mais une requête ICMP. Après l'émission d'une requête ICMP, la réponse doit être reçue dans un délai imparti, paramétrable. Si aucune réponse n'est reçue dans le temps imparti, une trace est enregistrée dans un fichier "log". En variante, un fichier « Log » de l'ordinateur passerelle 22 est utilisé pour les étapes de paramétrage des requêtes et de création des sessions. Pour mémoire, un fichier Log est un fichier texte regroupant toutes les requêtes réémise par l'ordinateur passerelle 22 depuis le réseau local 23 vers le réseau 18. Dans le fichier « log », chaque requête est datée. Au moyen de ce fichier Log, les sessions de N utilisateurs réels sont enregistrées au cours d'un premier déplacement du train le long d'un trajet. La campagne de test consistera à réémettre les requêtes du fichier Log, en respectant la chronologie du fichier Log, de manière à reproduire les N sessions utilisateur antérieures lors d'un nouveau déplacement du train selon le même trajet.
Alors que la description précédente a été faite en rapport avec un réseau supportant le protocole TCP-IP, d'autres protocoles respectant la norme ISO-OSI (acronyme anglais pour « Open Sytem Interconnection ») peuvent être testés en utilisant le présent procédé.
Le système de mesure selon l'invention a été décrit dans le cadre de son utilisation dans un train, mais il permet d'effectuer des campagnes de mesure en tout nœud, fixe ou mobile, d'un réseau quelconque.
Ainsi, la mise en œuvre de l'invention permet de mesurer les performances d'un réseau réel existant, et ceci du point de vue de l'utilisateur dont le terminal exécute une application qui accède à une ressource particulière.
Tableau I
Figure imgf000017_0001

Claims

REVENDICATIONS
1.- Procédé de mesure des performances d'un réseau (18), caractérisé en ce qu'il comporte les étapes consistant à : - paramétrer (100) une pluralité de requêtes, chaque requête pointant vers une ressource accessible via ledit réseau (18), les requêtes paramétrées étant mémorisées dans une base de données (58) ;
- créer (1 10) au moins une session utilisateur en sélectionnant plusieurs requêtes paramétrées ; - exécuter (130) une campagne de test consistant à :
- enchaîner dans le temps l'émission (140), depuis un terminal utilisateur (12) connecté audit réseau, des différentes requêtes de ladite au moins une session utilisateur ; et, pour chacune des requêtes émises,
- calculer (170) la valeur d'au moins une variable caractéristique des performances du réseau ;
- agréger (200) les valeurs de ladite au moins une variable caractéristique calculées au cours de l'exécution de la campagne de test pour déterminer (210) la valeur d'un estimateur des performances du réseau.
2.- Procédé selon la revendication 1 , caractérisé en ce que la campagne de test consiste à exécuter (130), en parallèle, plusieurs sessions utilisateur.
3.- Procédé selon la revendication 2, caractérisé en ce que les sessions utilisateur sont exécutées par des terminaux utilisateur (12, 14) différents, connectés audit réseau (18).
4.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, au cours de l'étape de création (1 10) d'une session utilisateur, on utilise un paramètre de profil en tant que critère pour effectuer la sélection de certaines requêtes paramétrées, le paramètre de profil définissant un type particulier de comportement d'utilisation des ressources disponibles sur le réseau (18).
5.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite au moins une variable caractéristique des performances du réseau est calculée sur la base de la réception, par le terminal utilisateur (12), de l'intégralité du fichier de données correspondant à la ressource indiquée par la requête émise par ledit terminal utilisateur.
6.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que des ressources accédées durant l'exécution d'une campagne de test sont stockées sur au moins un terminal serveur (16), connecté audit réseau (18), dont l'état est connu au cours de l'exécution de ladite campagne de test.
7.- Procédé selon la revendication 6, caractérisé en ce que le serveur dont l'état est connu exécute une application auxiliaire permettant de calculer, au niveau du terminal serveur, la valeur d'au moins une variable caractéristique des performances du réseau, celle-ci étant calculée sur la base de la réception, par le terminal serveur, de la requête émise par un terminal utilisateur.
8. -Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit réseau supporte le protocole IP.
9.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une requête comporte un paramètre correspondant au service de transfert de données à utiliser pour transférer le fichier de données correspondant à la ressource mentionnée dans une requête.
10.- Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, lors de l'exécution d'une campagne de test, on mémorise la position et/ou la vitesse du terminal utilisateur lors de l'émission de chacune des requêtes de ladite au moins une session, et en ce que ladite étape d'agrégation tient compte des positions et/ou des vitesses instantanées mémorisées pour déterminer ledit estimateur.
1 1.- Système de mesure d'un estimateur des performances d'un réseau
(18), caractérisé en ce qu'il permet de mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 10, et en ce qu'il comporte :
- un moyen de base de données (58) ;
- un moyen de paramétrage de requêtes qui sont aptes à être émises par un terminal utilisateur connecté audit réseau pour accéder à une ressource disponible via ledit réseau, des paramètres desdites requêtes étant stockés dans le moyen de base de données ; - un moyen de création de sessions utilisateur permettant la sélection d'une pluralité de requêtes paramétrées dans la base de données ;
- un moyen d'exécution d'une campagne de test apte à émettre, successivement dans le temps, les différentes requêtes constitutives d'au moins une session utilisateur ;
- un moyen de calcul apte à calculer la valeur d'au moins une variable caractéristique des performances du réseau ; et,
- un moyen d'agrégation (56) des valeurs de ladite au moins une variable caractéristique sur ladite campagne de test pour déterminer un estimateur des performances du réseau.
PCT/FR2009/052278 2008-11-24 2009-11-24 Procédé de mesure des performances d'un réseau ip et système associé WO2010058143A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US13/130,784 US8499076B2 (en) 2008-11-24 2009-11-24 Method for measuring the performance of an IP network and associated system
ES09797071T ES2396668T3 (es) 2008-11-24 2009-11-24 Procedimiento de medida de las prestaciones de una red IP y sistema asociado
EP09797071A EP2359535B1 (fr) 2008-11-24 2009-11-24 Procédé de mesure des performances d'un réseau ip et système associé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0857947 2008-11-24
FR0857947A FR2938993B1 (fr) 2008-11-24 2008-11-24 Procede de mesure des performances d'un reseau ip et systeme associe

Publications (1)

Publication Number Publication Date
WO2010058143A1 true WO2010058143A1 (fr) 2010-05-27

Family

ID=40602527

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/052278 WO2010058143A1 (fr) 2008-11-24 2009-11-24 Procédé de mesure des performances d'un réseau ip et système associé

Country Status (5)

Country Link
US (1) US8499076B2 (fr)
EP (1) EP2359535B1 (fr)
ES (1) ES2396668T3 (fr)
FR (1) FR2938993B1 (fr)
WO (1) WO2010058143A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9401813B2 (en) * 2009-12-29 2016-07-26 Iheartmedia Management Services, Inc. Media stream monitor
DE102012208641B4 (de) * 2012-05-23 2019-11-21 Bayerische Motoren Werke Aktiengesellschaft Kleinst-Funkzellen-Basisstation und Kommunikationssystem für ein Fahrzeug
US10708161B2 (en) * 2018-09-21 2020-07-07 Juniper Networks, Inc. Network performance monitoring using an active measurement protocol and relay mechanism

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070115847A1 (en) * 2005-11-18 2007-05-24 Strutt Guenael J Method and apparatus to estimate link performance in a packetized communication network
US20080239967A1 (en) * 2007-03-27 2008-10-02 Fujitsu Limited Network performance estimating device, network performance estimating method and storage medium having a network performance estimating program stored therein
WO2008121062A1 (fr) * 2007-03-29 2008-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et dispositif pour évaluer des services dans des réseaux de communication

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007207328A (ja) * 2006-01-31 2007-08-16 Toshiba Corp 情報記憶媒体、プログラム、情報再生方法、情報再生装置、データ転送方法、及びデータ処理方法
US8127336B2 (en) * 2007-03-01 2012-02-28 Bridgewater Systems Corp. Systems and methods for policy-based service management
GB0803967D0 (en) * 2008-03-03 2008-04-09 Colt Telecom Group Plc Queing System
US9665838B2 (en) * 2008-12-03 2017-05-30 Whirlpool Corporation Messaging architecture and system for electronic management of resources
US10298977B2 (en) * 2009-11-20 2019-05-21 Time Warner Cable Enterprises Llc Policy management arbitration by service group

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070115847A1 (en) * 2005-11-18 2007-05-24 Strutt Guenael J Method and apparatus to estimate link performance in a packetized communication network
US20080239967A1 (en) * 2007-03-27 2008-10-02 Fujitsu Limited Network performance estimating device, network performance estimating method and storage medium having a network performance estimating program stored therein
WO2008121062A1 (fr) * 2007-03-29 2008-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et dispositif pour évaluer des services dans des réseaux de communication

Also Published As

Publication number Publication date
US8499076B2 (en) 2013-07-30
FR2938993A1 (fr) 2010-05-28
ES2396668T3 (es) 2013-02-25
US20110264799A1 (en) 2011-10-27
EP2359535B1 (fr) 2012-09-26
EP2359535A1 (fr) 2011-08-24
FR2938993B1 (fr) 2010-12-24

Similar Documents

Publication Publication Date Title
US8159957B2 (en) Hardware time stamping and synchronized data transmission
US7676570B2 (en) Determining client latencies over a network
Hei et al. Inferring network-wide quality in P2P live streaming systems
CN107071399B (zh) 一种加密视频流的质量评估方法及装置
JP2005506605A (ja) 任意のアプリケーション用のサーバサイトでの応答時間の計算
CN110535684A (zh) 一种基于dpi实现网页浏览业务感知评估的方法和装置
Basso et al. Measuring DASH streaming performance from the end users perspective using neubot
WO2012078316A1 (fr) Système de surveillance d'un web d'extrémité et méthode de mesure de la popularité d'un service ou d'une application sur un serveur web
US20150249589A1 (en) Method and apparatus for determining automatic scanning action
EP2359535B1 (fr) Procédé de mesure des performances d'un réseau ip et système associé
CN109982068A (zh) 合成视频质量评估方法、装置、设备及介质
EP1306689B1 (fr) Procédé et système d'enregistrement et lecture synchronisée de données provenant d'une pluralité d'équipements terminaux
Marshak et al. Evaluating web user perceived latency using server side measurements
FR2849559A1 (fr) Outil et methode d'analyse de chemin dans un reseau de transmission de donnees comprenant plusieurs systemes autonomes internet
CN106899843B (zh) 一种视频业务质量评估方法及装置
CN113453076A (zh) 用户视频业务质量评估方法、装置、计算设备和存储介质
Byun et al. Wireless broadband measurement in California
JP2011142473A (ja) ユーザ待ち時間推定装置、ユーザ待ち時間推定方法、及びプログラム
WO2021009134A1 (fr) Système et procédé d'estimation de la qualité de réseaux ou de services par l'intermédiaire d'une production participative
CN106412661A (zh) 智能电视网络视频播放信息采集方法及系统
Rea et al. Italian QoS Monitoring network: impact on SLA control
JP2011142474A (ja) ユーザ待ち時間推定装置、ユーザ待ち時間推定方法、及びプログラム
JP7067360B2 (ja) 処理装置、処理方法、プログラムおよびシステム
KR20200108293A (ko) 네트워크 중립성 시험을 위한 시스템 및 방법
US20120284361A1 (en) Determination of the transmission capacity in data networks

Legal Events

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

Ref document number: 09797071

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009797071

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13130784

Country of ref document: US