WO2008096086A2 - Procede de traitement de perte de paquets - Google Patents

Procede de traitement de perte de paquets Download PDF

Info

Publication number
WO2008096086A2
WO2008096086A2 PCT/FR2007/052462 FR2007052462W WO2008096086A2 WO 2008096086 A2 WO2008096086 A2 WO 2008096086A2 FR 2007052462 W FR2007052462 W FR 2007052462W WO 2008096086 A2 WO2008096086 A2 WO 2008096086A2
Authority
WO
WIPO (PCT)
Prior art keywords
packets
packet
window
lost
expected
Prior art date
Application number
PCT/FR2007/052462
Other languages
English (en)
Other versions
WO2008096086A3 (fr
Inventor
Gérard Babonneau
Serge Rigaudeau
Vincent Thiebaut
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2008096086A2 publication Critical patent/WO2008096086A2/fr
Publication of WO2008096086A3 publication Critical patent/WO2008096086A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1858—Transmission or retransmission of more than one copy of acknowledgement message
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1614—Details of the supervisory signal using bitmaps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements

Definitions

  • the invention relates to the retransmission of lost packets during packet stream transmission, in particular, in unicast and multicast mode adapted to real time flows.
  • some packets may be lost degrading the return of the data carried by the stream. These degradations can be more or less troublesome depending, in particular, the number of packets lost and the type of application.
  • timers or timers in English
  • timers are used to distribute in a time window the requests of several users concerning the same loss.
  • the detection of a loss opens a time window at the end of which the sending of an acknowledgment message of non-reception of packets to the source or a node of the network is triggered.
  • These solutions generally implement another timer, longer than the previous one, in order to detect if the retransmission has arrived and possibly decide to reiterate the request.
  • the RMTP2 (Abbreviation for Reliable Multicast Transfer Protocol for Reliable Multicast Transfer Protocol), is based on sequence number analysis to identify received packets for sending NACK declaring messages. packet loss. The escalation is based on the sequence numbers and is systematic (packet acknowledgment messages if there is no loss and acknowledgment message when there are losses). If this solution actually makes it possible to group several retransmission requests in a single packet loss declaration message, its main purpose is to distribute the forwarding to a node of the network of requests from a group of users. The receivers each go back in a message indicating their losses. In fact, so that users do not all go back together packet loss declaration messages, they wait each turn. The forwarding of the packet loss declaration NACK message depends on the sequence number of the packet. Therefore, when there are many users, the grouping window is large and incompatible with real time.
  • Triggering the sending of a NACK packet loss declaration message to the source or node of the network is accomplished by the sequence number of the received packets.
  • the collection time of packets lost before sending a packet loss declaration message is well calculated using the sequence numbers of the packets received.
  • the present invention provides a method of packet loss processing when transmitting a packet stream through a network.
  • the method comprises a grouping of information relating to packets, said grouping being performed for lost packets that were expected in a reception window (W1) whose size is equal to a number of packets greater than or equal to a fixed number N predefined packages.
  • the invention uses a reception window whose size is defined from a fixed number N of predefined packets, for example packets actually received or expected packets.
  • the packets are used as a measuring instrument for the size of the reception window and a grouping of information concerning the packets lost in this window is realized.
  • This is a very simple way to make a reception window.
  • the closing of the reception window is the cause of the triggering of the sending of a packet loss declaration message, and the noise is similar on the up and down channels, this allows for ensure a certain reliability of the network for the transmission of the packet loss declaration message.
  • the method according to the invention has the additional characteristics taken in isolation or in combination set out below: In the case where the Nth expected packet is itself lost, the reception window is extended to the first subsequent packet actually received.
  • the method further includes sending a loss declaration message including the grouped information on lost packets that were expected in said receive window.
  • the triggering of the sending of the loss declaration message depends on a state of the network.
  • a new reception window is opened on detecting a new lost packet.
  • a new reception window is opened at the expiry of said reception window, called "previous window", and it is expected to send a new loss declaration message containing the grouped information on lost packets that were expected in the previous reception window and not yet received and the information bundled on lost packets that were expected in the new reception window.
  • Sequence numbers being assigned to the packets of the stream the loss of packets is detected by analyzing the sequence numbers of the packets actually received.
  • the invention also relates to a computer program for a packet loss processing device having program code instructions for controlling the execution of the steps of the method as described above when said program is executed by the processing device. .
  • the invention also relates to a packet loss processing device comprising packet information means, said grouping being performed for lost packets that were expected in a reception window whose size is equal to one. number of packets greater than or equal to a fixed number N of predefined packets.
  • the packet loss processing device further comprises means for sending a loss declaration message comprising the grouped information on lost packets that were expected in said reception window.
  • the invention also relates to a node of a communication network comprising a packet loss processing device as described above.
  • the invention also relates to a communication terminal comprising a packet loss processing device as described above.
  • FIG. 1 a creation of a list of packets lost on a window of at least N packets expected when the Nth expected packet is correctly received
  • FIG. 2 a creation of a list of packets lost on a window of at least N packets expected when the Nth expected packet is lost
  • FIG. 3 a creation of a list of packets lost on a window of N received packets
  • FIG. 4 a schematic example of the format of the packet loss declaration message
  • FIG. 5 a first example of repetition of a NACK packet loss declaration message in the case of an isolated loss group
  • FIG. 6 a second example of multiple retransmissions of the NACK packet loss declaration messages in the case of distributed losses
  • FIG. 7 a third example of multiple retransmissions of the NACK packet loss declaration messages in the event that part of the lost and retransmitted packets have been received before the retransmission
  • FIG. 8 a fourth example of multiple retransmissions of the NACK packet loss declaration messages taking into account a threshold P 1
  • FIG. 9 a fifth example of multiple retransmission of NACK packet loss declaration as soon as the number of packets that has not been received reaches the threshold P and without waiting for the end of the last reception window
  • FIG. 9 a flowchart of a variant of the packet loss declaration method using a size window defined by a number of packets
  • FIG. 11 a block diagram of a communication system implementing the invention.
  • This invention aims to improve the quality perceived by the users based on retransmissions for particularly unicast streams such as those of video on demand (VOD).
  • VOD video on demand
  • the invention specifies means implemented to optimize requests for retransmissions from terminals to servers.
  • the invention makes it possible to avoid overloading the network because the decoders group several retransmission requests in a single packet loss declaration message.
  • the invention further allows packet loss reporting messages to be transmitted after a return to normal of the network. This return to normal of the network or the fact that the network is again reliable for this type of transmission is detected, for example, simply by the receiving a packet (especially in the case where the rising and falling channels are disturbed in the same way).
  • the invention is based on a simple means of detecting losses and restoring the transfer.
  • these two operations are obtained by the recognition of a discontinuity in the sequence number of the packets.
  • These sequence numbers of the packets are in particular either contained in the packets or in the headers (for example the RTP (Realtime Transport Protocol) headers).
  • This discontinuity indicates that packets have been lost. It also indicates that the transfer is reestablished, since a next packet has arrived in the terminal only then allowing to note that the sequence number of the last received packet is not a simple incrementation of one of the sequence number of the antéfugtmay package received. Receipt of the next packet then makes it possible, if necessary, to send the identification information of lost packets in a NACK packet loss declaration message.
  • the invention is therefore based on the analysis of received sequence numbers in order to organize the reporting of packet loss declaration messages (included in retransmission requests for certain variants). It can work in both multicast and unicast, but the following description is made in the example of a unicast mode, regardless of the bandwidth occupied by the Realtime Transport Control Protocol (RTCP) reports. real-time transport control) containing packet loss declaration messages
  • RTCP Realtime Transport Control Protocol
  • the application applies in particular to an ADSL network where the losses are distributed over time between the users of the same sub-network.
  • the invention is based on the use of a reception window W1, at the end of which the raising of a NACK packet loss declaration message containing a list of lost packets within the window.
  • the size of the window is determined to be sufficiently short to allow the sending of the packet loss declaration message to occur soon enough after receiving packets adjacent to the lost packets to allow the retransmitted packets to be used.
  • this window will be shorter in size (a few hundred milliseconds for example) - the temporal measurement of the window is here only to give an element of comparison, the size of the window being actually measured in number of packets) than in the case of other applications where the delay before using the received data allows a longer window (a few seconds for example).
  • a grouping (COLLECT) of information relating to packets is performed for lost packets that were expected in the reception window W1.
  • the size of the reception window W1 is equal to a number of packets greater than or equal to a fixed number N of predefined packets.
  • the grouping is triggered by the detection of a first lost packet.
  • the reception windows focus on the losses. The number of packet loss declaration messages can then be reduced.
  • the number N is relative to predefined packets which can be: - either actually received packets or expected packets, as illustrated by Figures 1 to 3.
  • Figure 1 shows the grouping of losses from the first detected lost packet.
  • the reception of the packets 22 and 24 makes it possible respectively to detect the losses of the packets 21 and 23.
  • the arrival of the packet 25 makes it possible to conclude that the size of the aggregation window has been reached, and the NACK packet loss declaration message. will be issued.
  • FIG. 2 shows the grouping of losses in the case where the Nth packet of the window (25) is not received.
  • the receiver waits to receive a packet (the 32 in the example), corresponding to the first subsequent packet received, in order to recover all the losses it has detected since the first loss.
  • the reception window is extended to the first subsequent packet actually received.
  • the receiver waits to receive N packets, regardless of the number of losses occurring between the first and the next N-1 received correctly (Figure 3).
  • the loss declaration message uses the extended format of the Feedback Feedback Information (FCI) message RFC4585 (RTCP Feedback).
  • FCI Feedback Feedback Information
  • RFC4585 RTCP Feedback
  • Figure 4 shows that this format includes the following elements: PID contains the sequence number of a first lost packet. BLP contains a sequence of bits indicating whether a packet is lost in a sequence of 16 packets following the first lost.
  • a NACK packet loss declaration message may contain a plurality of information for declaring losses on a packet sequence greater than 16.
  • the invention proposes to repeat the retransmission requests, to be sure that they have reached the source. This makes the retransmissions reliable.
  • This repetition uses a simple and inexpensive protocol especially in processing time by the small number of packet loss declaration messages to be managed by each end (the server and the server). terminal) and also in reaction time of the method which is particularly interesting in the case of real-time applications such as real-time video.
  • Figure 5 depicts a loss of some packets listed in a single NACK packet loss reporting message back to the source.
  • the receiver After sending the packet loss declaration message to the source, the receiver opens a new W2 window of N packets after which it returns the NACK packet loss declaration message that it has previously sent.
  • the operation is repeated a second time in order to obtain 3 successive transmissions.
  • This second sending of L1 makes it possible to increase the possibility of retransmission in the event of a loss in the network of the message containing L1.
  • the source will have to implement special means to avoid the duplication of retransmissions.
  • Figure 6 represents a more complete case with distributed losses. It assumes that the retransmissions have not yet reached the receiver, either because the source did not send them, or because the latency of the network is higher than in the case shown in Figure 5 and above the rehearsal period. loss notification messages.
  • the receiver After sending a first list L1, the receiver detects further losses on the packets 29, 30 and 31 that it places in a list L2. Also, at the end of the second window W2, it sends the lists L1 and L2.
  • Some requested packets may already be received during a reissue request.
  • a new reception window W2 (W3) is opened at the expiry of the previous reception window W1 (W2) and a new loss declaration message L1 + L2 (L1 + L2 + L3) is sent after the expiration of the new window W2 (W3).
  • This new message contains the information on the lost packets that were expected here in one of the three previous reception windows, whether or not they were received at the end of the new W2 window (W3), as well as the grouped information on lost packets that were expected in the new W2 reception window (W3).
  • the lost and retransmitted packets 21, 23 and 25 are received between the L1 + L2 emissions and the L1 + L2 + L3 preparation.
  • the receiver updates its lists of non-received packets, and in particular it replaces the list L1 with a new list L'1.
  • a new reception window W2 (W3) is opened on the expiry of the previous reception window W1 (W2) and a new loss declaration message L1 + L2 (the first one). + L2 + L3) is sent after the expiration of the new window W2 (W3).
  • This new message contains the grouped information about the lost packets that were expected here in one of the three previous reception windows and that have not yet been received at the end of the new W2 (W3) window.
  • the new message also includes the information on lost packets that was expected in the new W2 (W3) reception window.
  • the loss of at least one packet is detected by observing a discontinuity in a sequence of packets received. For this, during a transmission of a sequence of packets, a continuity analysis is performed on the received packet sequence comprising, said analysis for associating with a discontinuity of said received sequence a loss of one or more packets.
  • the continuity analysis also makes it possible to identify the packet (s) lost (s) as a function of at least one characteristic of said discontinuity.
  • the packets comprising a sequence number
  • the continuity analysis is performed on the sequence numbers of the packets received and the identification of the packets received is performed by their sequence numbers.
  • the lost packets are therefore those corresponding to the missing numbers in the received sequence.
  • This detection of lost packets can be implemented using a computer program.
  • An embodiment of the continuity analyzer of a packet sequence is then a programmable component comprising this computer program.
  • NACK packet loss declaration messages may not be sent. The invention thus proposes a solution not to go up NACK if the losses are too numerous.
  • P is the number of packets lost on a window W from which it is useless to send a NACK message because the retransmissions in time lost packets are no longer possible.
  • the size of the window W is a function of the size of the buffer between the reception and the use of the packets and the authorized bit rate for the retransmissions.
  • the size of the window W is given by the equation:
  • Nominal_rate is the nominal bit rate of the video stream.
  • rtx-time is a configuration parameter defined in RFC 4588. This parameter defines a window during which a server keeps the information in case of a retransmission.
  • D is an additional delay intended to compensate for the latencies of the networks and equipment used.
  • package_size is the size of the transmitted packets. The size of the window W is expressed in number of packets. It is thus easy to know the number of retransmissions that can be requested at a given moment. This solution is particularly accurate when the packets have a constant size.
  • the parameter P is set at most at 50% of the size of the window W.
  • the receiver Given the authorized bit rate for retransmissions, for example 50% of the normal transmission rate, the receiver can receive a maximum of 50% of the packets transmitted in this window. Consequently, the parameter P is set at most at 50% of the size of the window W. On a reliable network, the parameter P is set on the basis of a lower percentage, for example 5 to 10%.
  • FIG. 8 partially resumes FIG. 7 by adding the window W.
  • the number of packets that can be requested again must not exceed the parameter P.
  • the size of the window W is always greater than or equal to the sum of the sizes of the reception windows W1, W2, W3 without it being possible to prejudge the number of retransmissions to be requested in these windows.
  • the receiver can either decide to send nothing, or decide to send lists L1, L2 and a partial list L'3 containing only lost packet number 37.
  • the retransmission request lost packets having the numbers 38, 39 may be performed when the number of packets to be retransmitted will again be lower than P, for example when the packets 21, 23 and 25 will actually be received following a retransmission of these packets.
  • This request for retransmission of lost packets will be carried out in accordance with the NACK multiple transmission principle described in FIG.
  • This operating mode behaves like a time window driven not by a timer but by the reception of transmitted and / or retransmitted packets.
  • the window W begins before the opening of the reception window W1.
  • the window W can begin when the window W1 is open, for example, following the reception of the packet n ° 22.
  • FIG. 9 shows a variant embodiment in which the receiver sends a NACK message as soon as the number of packets to be retransmitted reaches P, without waiting for the end of the reception window W3.
  • the message sent containing L1 + L2 + L'3 is identical to the message as described above in Figure 8. This message is however transmitted faster, which is favorable for a real-time system.
  • FIG. 10 shows a block diagram of the invention in the particular case where lost packets are detected by continuity analysis of the packet sequence (block "CONTINUOUS").
  • block "CONTINUOUS" On receipt of a packet pj, schematized by the block pj, the continuity of the sequence between the packet pj and the last packet actually received is verified.
  • the credentials for the lost packets are grouped together (block "COLLECT in [pi.pj]"). It should be noted that the interval [pi.pj] corresponds to the current reception window, the size of which increases as packets are received.
  • the terminals pi and pj respectively represent the terminals of the current reception window, on receipt of the packet pj, pi being the first lost packet, having triggered the opening of the window Wk, and pj the last packet actually received.
  • account is taken of the state of the network, unfavorable [B] or favorable [G].
  • An unfavorable state of the network is notably detected in the case where the number of packets lost during a reception window is greater than P,
  • the TRIG NACK trigger is changed. It can simply be deleted (“STOP”) or delayed (“WAIT”) until the network has returned to a favorable transmission state.
  • the packet loss declaration message is transmitted SEND NACK.
  • the triggering (TRIG NACK) of the sending of the loss declaration message (SEND NACK) is a function of the state (B / G / P) of the network.
  • the state of the network is not taken into account.
  • the reception of the packet pj makes it possible to detect the end of the window, that is to say if the size of the window is at least equal to N packets [Size Wk ⁇ N], this directly triggers the transmission of a SEND NACK packet loss declaration message with the information packaged on lost packets that were expected in the reception window W1. Otherwise [Size Wk ⁇ N], we wait for the receipt of the next packet pj.
  • pj 25
  • the sending of the packet loss declaration message is therefore carried out at the latest at the end of window detection, ie as soon as the end of window detection, the packet loss declaration message is constituted and then sent without any particular delay. other than normal processing times except report.
  • the packet loss declaration message is sent without waiting for the detection of the end of the window.
  • the opening of the new window W2 does not depend on the reception of a lost packet, but the new window is opened as soon as the packet is closed after the closing of the previous reception window W1. This makes it possible to cover the entire sequence of packets.
  • a new reception window is opened on detecting a new lost packet. This makes it possible to cover all the losses without performing a treatment on the entire sequence some packages. This reduces the number of packet loss declaration messages sent.
  • Fig. 11 shows a packet loss processing apparatus for implementing the packet loss processing method according to the invention.
  • the processing device comprises a collector T20 on a window of size at least N packets of identification information for lost packets receiving in particular the identification information of the lost packets detected by a packet loss detector T10.
  • the processing device also comprises means for sending T30 packet loss declaration (NACK) messages including the information grouped on lost packets that were expected in the reception window. This information is provided by the T20 collector.
  • the transmitter T30 packet loss reporting messages informs, through an R network, a server S lost packets. This information is used by the server S so that the retransmission device of the lost packets
  • the collector T20 comprises in particular means for grouping information relating to packets, said grouping being carried out for lost packets that were expected in the reception window W1 whose size is equal to a number of packets greater than or equal to the number N fixed predefined packets.
  • the information may include information such as, for example, the identity of the node, the identity of the usage, the time of loss detection, etc.
  • the packet loss processing device further comprises a packet loss detector T10 by discontinuity of the packet sequence.
  • the packet loss processing device comprises a suitable T40 network analyzer. to cancel STOP sending a loss declaration message or to delay it WAIT / GO.
  • the invention also relates to a node of a network comprising the packet loss processing device.
  • the invention also relates to a communication terminal comprising the packet loss processing device.
  • the terminal is for example a television set, a computer equipped with a receiver (ADSL, radio frequency, Wifi, etc.), a telephone, etc.
  • the invention thus relates to the reception of data for triggering the transmission of retransmissions requests or packet loss declaration messages, the reception of a data packet indicating that the network has a high probability of being operational also for a transmission. information feedback.
  • the invention relates to waiting for at least N packets after detecting a loss to send a NACK packet loss reporting message.
  • the invention relates to sending requests
  • NACK containing queries already transmitted to compensate for any loss of NACK packet loss declaration messages (Repeat NACK packet loss declaration messages).
  • the invention relates to the comparison of the number of expected retransmissions to a threshold determining whether the reception of retransmissions can arrive in time for a real-time video stream.
  • the retransmission server (for example the source) according to a variant of the invention simply accepts retransmission requests from several receivers and sends the retransmission packets to the entire group.
  • the invention relates to a combination of a part or all the variants described.
  • the invention described in the case of a real-time unicast stream application for on-demand video streams is used without modification in any applications in which streams are transmitted per packet: communication, unicast, multicast, real time or not, regardless of the type of video, audio, data and service data: video on demand, network DVD player, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé de traitement de perte de paquets lors de la transmission d'un flux de paquets à travers un réseau. Le procédé comprend un groupement (COLLECT) d'informations relatives à des paquets, ledit groupement étant effectué pour des paquets perdus qui étaient attendus dans une fenêtre de réception (W1 ) dont la taille est égale à un nombre de paquets supérieur ou égal à un nombre N fixé de paquets prédéfinis.

Description

PROCEDE DE TRAITEMENT DE PERTE DE PAQUETS
L'invention concerne la retransmission de paquets perdus lors de la transmission de flux par paquets, en particulier, en mode unicast et multicast adaptée aux flux temps réels. Dans le cadre de la transmission de flux par paquets, certains paquets peuvent être perdus dégradant la restitution des données transportées par le flux. Ces dégradations peuvent s'avérer plus ou moins gênantes suivant, notamment, le nombre de paquets perdus et le type d'application.
Diverses techniques ont déjà été proposées à ce jour pour permettre ce type de retransmission. Néanmoins, la retransmission de paquets perdus dans le cadre de transmission de flux temps réel reste limitée à la requête immédiate d'un paquet détecté comme perdu. Or, même si les décodeurs (ou Set Top Box en anglais) remontent uniquement des informations sur les paquets non reçus (messages de pertes de paquets ou messages d'accusé non réception ou NACK abréviation de Non- ACKnowledgement), la surcharge d'un serveur pour traiter des requêtes est toujours un risque quand un serveur doit traiter en temps réel de très nombreuses émissions simultanées (> 1000, par exemple).
Des solutions existent pour optimiser la remontée de messages de déclaration de perte de paquets, principalement dans les protocoles de multicast fiable.
La plupart des solutions utilisent des minuteries (ou timers en anglais) pour collecter une liste de paquets perdus dans une fenêtre temporelle. Ces minuteries sont exploitées pour répartir dans une fenêtre temporelle les requêtes de plusieurs usagers concernant une même perte. La détection d'une perte ouvre une fenêtre temporelle à l'issue de laquelle l'envoi d'un message d'accusé de non réception de paquets vers la source ou un nœud du réseau est déclenché. Ces solutions mettent généralement en œuvre une autre minuterie, plus longue que la précédente, afin de détecter si la retransmission est bien arrivée et éventuellement décider de réitérer la requête.
Une autre solution, la solution RMTP2 (Abréviation de l'expression anglaise de Reliable Multicast Transfer Protocol pour protocole de transfert multicast fiable), est basée sur une analyse du numéro de séquence pour identifier les paquets reçus pour l'envoi de messages NACK de déclaration de perte de paquets. La remontée se base sur les numéros de séquence et est systématique (messages d'accusé réception de paquets s'il n'y a pas de perte et message d'accusé non réception lorsqu'il y a des pertes). Si cette solution permet effectivement de grouper plusieurs requêtes de retransmissions dans un unique message de déclaration de perte de paquets, son objectif est principalement de répartir la remontée vers un nœud du réseau des requêtes provenant d'un groupe d'usagers. Les récepteurs remontent chacun à leur tour un message indiquant leurs pertes. En effet, pour que les usagers ne remontent pas tous ensemble des messages de déclaration de perte de paquets, ils attendent chacun leur tour. La remontée du message NACK de déclaration de perte de paquets dépend du numéro de séquence du paquet. C'est pourquoi, quand il y a beaucoup d'usagers, la fenêtre de regroupement est grande et incompatible avec le temps réel.
Le déclenchement de l'envoi d'un message de déclaration de perte de paquets NACK vers la source ou un nœud du réseau est réalisé par le numéro de séquence des paquets reçus. La durée de collecte des paquets perdus avant l'envoi d'un message de déclaration de perte de paquets est bien calculée à l'aide des numéros de séquence des paquets reçus.
Deux problèmes se posent dans les remontées de messages de déclaration de perte de paquets : • Dans le cas de remontée immédiate : une remontée de trop nombreux messages de déclaration de perte de paquets peut charger inutilement le serveur et risque de dégrader ses performances.
• Dans le cas où un décodeur utilisant une technique de groupement : en raison de la nature temps réel des flux vidéo, les paquets de correction des pertes risquent d'arriver après le temps de fourniture des données au décodeur.
D'autre part, notamment sur les réseaux ADSL, si dos pertes apparaissent dans la voie descendante en raison d'un bruit, un bruit impulsif élevé en particulier dans le cas de notre exemple ADSL, il y a une forte probabilité que la même chose se produise aussi sur la voie remontante, même si les règles d'ingénierie ne sont pas exactement les mêmes.
La présente invention propose un procédé de traitement de perte de paquets lors de la transmission d'un flux de paquets à travers un réseau.
Le procédé comprend un groupement d'informations relatives à des paquets, ledit groupement étant effectué pour des paquets perdus qui étaient attendus dans une fenêtre de réception (W1) dont la taille est égale à un nombre de paquets supérieur ou égal à un nombre N fixé de paquets prédéfinis.
Ainsi, pour traiter la perte de paquets, l'invention utilise une fenêtre de réception dont la taille est définie à partir d'un nombre fixé N de paquets prédéfinis, par exemple des paquets effectivement reçus ou bien des paquets attendus. Les paquets sont utilisés comme instrument de mesure de la taille de la fenêtre de réception et un groupement d'informations concernant les paquets perdus dans cette fenêtre est réalisé. C'est une manière très simple de réaliser une fenêtre de réception. En outre, lorsque la fermeture de la fenêtre de réception est à l'origine du déclenchement de l'envoi d'un message de déclaration de perte de paquets, et que le bruit est similaire sur les voies montantes et descendantes, cela permet de s'assurer d'une certaine fiabilité du réseau pour la transmission du message de déclaration de perte de paquets.
Selon des modes de réalisations particuliers non limitatifs, le procédé selon l'invention présente les caractéristiques supplémentaires prises isolément ou en combinaison énoncées ci-après : Dans le cas où le Nième paquet attendu est lui-même perdu, la fenêtre de réception est prolongée jusqu'au premier paquet ultérieur effectivement reçu.
Le procédé comprend en outre l'envoi d'un message de déclaration de perte comprenant les informations groupées sur des paquets perdus qui étaient attendus dans ladite fenêtre de réception.
Le déclenchement de l'envoi du message de déclaration de perte est fonction d'un état du réseau.
Après l'expiration de ladite fenêtre de réception, une nouvelle fenêtre de réception est ouverte sur détection d'un nouveau paquet perdu.
Une nouvelle fenêtre de réception est ouverte à l'expiration de ladite fenêtre de réception, dite "fenêtre précédente", et il est prévu l'envoi d'un nouveau message de déclaration de perte contenant les informations groupées sur des paquets perdus qui étaient attendus dans la fenêtre de réception précédente et non encore reçus et les informations groupées sur des paquets perdus qui étaient attendus dans la nouvelle fenêtre de réception.
Des numéros de séquences étant affectés aux paquets du flux, on détecte la perte de paquets par analyse des numéros de séquences des paquets effectivement reçus.
L'invention concerne aussi un programme d'ordinateur pour un dispositif de traitement de perte de paquets comportant des instructions de code de programme pour commander l'exécution des étapes du procédé tel que décrit plus haut lorsque ledit programme est exécuté par le dispositif de traitement.
L'invention concerne également un dispositif de traitement de perte de paquets comportant des moyens de groupement d'informations relatives à des paquets, ledit groupement étant effectué pour des paquets perdus qui étaient attendus dans une fenêtre de réception dont la taille est égale à un nombre de paquets supérieur ou égal à un nombre N fixé de paquets prédéfinis.
Le dispositif de traitement de perte de paquets comporte en outre des moyens d'envoi d'un message de déclaration de perte comprenant les informations groupées sur des paquets perdus qui étaient attendus dans ladite fenêtre de réception.
L'invention concerne également un nœud d'un réseau de communication comprenant un dispositif de traitement de perte de paquets tel que décrit plus haut.
L'invention concerne aussi un terminal de communication comprenant un dispositif de traitement de perte de paquets tel que décrit plus haut.
Les caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description, faite à titre d'exemple, et des figures s'y rapportant qui représentent :
- Figure 1 , une création d'une liste des paquets perdus sur une fenêtre d'au moins N paquets attendus lorsque le Nième paquet attendu est correctement reçu,
- Figure 2, une création d'une liste des paquets perdus sur une fenêtre d'au moins N paquets attendus lorsque le Nième paquet attendu est perdu,
- Figure 3, une création d'une liste des paquets perdus sur une fenêtre de N paquets reçus,
- Figure 4, un exemple schématique de format du message de déclaration de perte de paquets,
- Figure 5, un premier exemple de répétition d'un message de déclaration de perte de paquets NACK dans le cas d'un groupe isolé de pertes, - Figure 6, un deuxième exemple de retransmissions multiples des messages de déclaration de perte de paquets NACK dans le cas de pertes réparties,
- Figure 7, un troisième exemple de retransmissions multiples des messages de déclaration de perte de paquets NACK dans le cas où une partie des paquets perdus et retransmis ont été reçus avant la retransmission,
- Figure 8, un quatrième exemple de retransmissions multiples des messages de déclaration de perte de paquets NACK en tenant compte d'un seuil P1
- Figure 9, un cinquième exemple de retransmission multiples de déclaration de perte de paquets NACK dès que le nombre de paquets qui n'a pas été reçu atteint le seuil P et sans attendre la fin de la dernière fenêtre de réception, - Figure 10, un organigramme d'une variante du procédé de déclaration de perte de paquets utilisant une fenêtre de taille définie par un nombre de paquets,
- Figure 11 , un schéma bloc d'un système de communication mettant en œuvre l'invention.
Cette invention vise une amélioration de la qualité perçue par les usagers à base de retransmissions pour des flux notamment unicast tel que ceux de la vidéo à la demande (en anglais Video On Demand VOD).
L'invention précise des moyens mis en œuvre pour optimiser les requêtes de retransmissions issues des terminaux vers les serveurs.
L'invention permet d'éviter une surcharge du réseau car les décodeurs regroupent plusieurs requêtes de retransmission dans un unique message de déclaration de perte de paquets.
L'invention permet en outre que les messages de déclaration de perte de paquets soient transmis après un retour à la normale du réseau. Ce retour à la normale du réseau ou le fait que le réseau est à nouveau fiable pour ce type de transmission est détecté, par exemple, simplement par la réception d'un paquet (notamment dans le cas où les voies montantes et descendantes sont perturbées de la même manière).
L'invention s'appuie sur un moyen simple de détection des pertes et de rétablissement du transfert. Notamment, ces deux opérations sont obtenues par la constatation en réception d'une discontinuité dans le numéro de séquence des paquets. Ces numéros de séquence des paquets sont en particulier soit contenus dans les paquets, soit dans les entêtes (par exemple les entêtes RTP (Realtime Transport Protocol en anglais pour protocole de transport temps réel)). Cette discontinuité indique que des paquets ont été perdus. Elle indique aussi que le transfert est rétabli, puisqu'un paquet suivant est arrivé dans le terminal permettant alors seulement de constater que le numéro de séquence du dernier paquet reçu n'est pas une simple incrémentation de un du numéro de séquence de l'antépénultième paquet reçu. La réception du paquet suivant permet alors de déclencher, le cas échéant, l'envoi des informations d'identification des paquets perdus dans un message de déclaration de perte de paquets NACK.
L'invention s'appuie donc sur l'analyse des numéros de séquence reçus afin d'organiser la remontée des messages de déclaration de perte de paquets (inclus dans des requêtes de retransmission pour certaines variantes). Elle peut fonctionner aussi bien en multicast qu'en unicast, mais la description suivante est faite dans l'exemple d'un mode unicast, sans se soucier de la bande passante occupée par les rapports RTCP (Realtime Transport Control Protocol en anglais pour protocole de contrôle de transport temps réel) contenant les messages de déclaration de perte de paquets
NACK.
L'application s'applique notamment à un réseau ADSL où les pertes sont réparties dans le temps entre les usagers d'un même sous-réseau.
L'invention est basée sur l'utilisation d'une fenêtre de réception W1 , à l'issue de laquelle on déclenche la remontée d'un message de déclaration de perte de paquets NACK contenant une liste de paquets perdus à l'intérieur de la fenêtre. La taille de la fenêtre est déterminée de façon à être suffisamment courte pour permettre que l'envoi du message de déclaration de perte de paquets intervienne suffisamment tôt après la réception des paquets adjacents aux paquets perdus pour permettre l'utilisation des paquets retransmis. Ainsi, dans le cas d'application temps réel, cette fenêtre sera de taille plus courte (quelques centaines de millisecondes par exemple - la mesure temporelle de la fenêtre n'est ici que pour donner un élément de comparaison, la taille de la fenêtre étant en réalité mesurée en nombre de paquets) que dans le cas d'autres applications où le délai avant utilisation des données reçues autorise une fenêtre plus longue (quelques secondes par exemple).
Un groupement (COLLECT) d'informations relatives à des paquets, est effectué pour des paquets perdus qui étaient attendus dans la fenêtre de réception W1. La taille de la fenêtre de réception W1 est égale à un nombre de paquets supérieur ou égal à un nombre N fixé de paquets prédéfinis. Dans l'exemple décrit ici, le groupement est déclenché par la détection d'un premier paquet perdu. Ainsi, les fenêtres de réception se focalisent sur les pertes. Le nombre de messages de déclaration de perte de paquets peut être alors réduit.
Les figures 1 à 3 montrent un exemple de fonctionnement avec une fenêtre de taille au moins égale à un nombre fixé N = 5 paquets prédéfinis, et avec une première perte de paquet se produisant pour le paquet ayant le numéro de séquence 21. Le nombre N est relatif à des paquets prédéfinis qui peuvent ici être : - soit des paquets effectivement reçus, soit des paquets attendus, comme illustré par les figures 1 à 3.
La figure 1 montre le regroupement de pertes à partir du premier paquet perdu détecté. La réception des paquets 22 et 24 permet de détecter respectivement les pertes des paquets 21 et 23. L'arrivée du paquet 25 permet de conclure que la taille de la fenêtre d'agrégation est atteinte, et le message de déclaration de perte de paquets NACK sera donc émis.
La figure 2 montre le regroupement de pertes dans le cas où le Nlème paquet de la fenêtre (25) n'est pas reçu. En cas de non réception du Nlème paquet, le récepteur attend de recevoir un paquet (le 32 dans l'exemple), correspondant au premier paquet ultérieur reçu, afin de remonter l'ensemble des pertes qu'il a détectées depuis la première perte. Ainsi, dans le cas où le Nιeme paquet attendu est perdu, la fenêtre de réception ost prolongée jusqu'au premier paquet ultérieur effectivement reçu.
Dans une option de l'invention, le récepteur attend de recevoir N paquets, indépendamment du nombre de pertes survenant entre le premier et les N-1 suivants reçus correctement (figure 3).
À noter que pour un réseau ADSL, la réception de ce paquet montre que la réception qui était rompue depuis le paquet 25 est rétablie, et par conséquent le récepteur peut en déduire que son message de déclaration de perte de paquets a beaucoup plus de chances d'aboutir à la source que lors d'une émission par expiration d'un timer.
Dans un mode particulier de réalisation, le message de déclaration de perte utilise le format étendu du message feedback FCI (pour Feedback Control Information en anglais, information de contrôle de retour) RFC4585 (RTCP Feedback). La figure 4 montre que ce format comprend les éléments suivants : PID contient le n° de séquence d'un premier paquet perdu. BLP contient une suite de bits indiquant si un paquet est perdu dans une suite de 16 paquets suivant Ie premier perdu.
Un message de déclaration de perte de paquets NACK peut contenir plusieurs informations permettant de déclarer des pertes sur une séquence de paquets supérieure à 16.
L'invention propose de répéter les requêtes de retransmission, pour être sûr qu'elles sont bien parvenues à la source. Cela permet de fiabiliser les retransmissions.
Cette répétition utilise un protocole simple et peu coûteux notamment en temps de traitement par le faible nombre de messages de déclaration de perte de paquets à gérer par chaque extrémité (le serveur et le terminal) et aussi en temps de réaction du procédé qui est particulièrement intéressant dans le cas d'applications temps réel telles que la vidéo temps réel.
La figure 5 décrit une perte de quelques paquets dont la liste tient dans un seul message de déclaration de perte de paquets NACK remonté vers la source. Après l'envoi du message de déclaration de perte de paquets vers la source, le récepteur ouvre une nouvelle fenêtre W2 de N paquets à l'issue de laquelle il renvoie le message de déclaration de perte de paquets NACK qu'il a précédemment émis. Dans la figure, l'opération est répétée une seconde fois afin d'obtenir 3 émissions successives. Optionnellement, W2 est calculé par W2 = N*coefficient et W3 = W2*coefficient. Ce second envoi de L1 permet d'accroître la possibilité de retransmission en cas de perte dans le réseau du message contenant L1. Cependant, la source devra mettre en œuvre des moyens particuliers pour éviter la duplication des retransmissions.
La figure 6 représente un cas plus complet avec des pertes réparties. Elle suppose que les retransmissions ne sont pas encore parvenues au récepteur, soit parce que la source ne les a pas envoyées, soit parce que la latence du réseau est plus élevée que dans le cas présenté à la figure 5 et supérieure à la période de répétition des messages de déclaration de perte.
Après l'envoi d'une première liste L1 , le récepteur détecte d'autres pertes sur les paquets 29, 30 et 31 qu'il place dans une liste L2. Aussi, à l'issue de la seconde fenêtre W2, il envoie les listes L1 et L2.
Ensuite, il attend une nouvelle fenêtre W3. Mais étant donné que le paquet 37, correspondant au N'ème paquet attendu de la fenêtre W3, n'est pas reçu, il attend la réception du paquet 40 pour détecter les pertes de 37 à 39 qu'il place dans une liste L3. Il envoie donc les trois listes L1 , L2 et L3 dans un seul message de déclaration de perte de paquets. Ensuite, la fenêtre suivante de N paquets est reçue sans anomalie. Le récepteur envoie donc les listes L2 et L3 pour respecter le nombre de 3 émissions, selon le fonctionnement déjà décrit dans la figure 5.
II se peut que certains paquets demandés soient déjà reçus lors d'une demande de réémission.
Dans le mode de réalisation de la figure 6, une nouvelle fenêtre de réception W2 (W3) est ouverte à l'expiration de la fenêtre de réception précédente W1 (W2) et un nouveau message de déclaration de perte L1 +L2 (L1 +L2+L3) est envoyé après l'expiration de la nouvelle fenêtre W2 (W3). Ce nouveau message contient les informations groupées sur les paquets perdus qui étaient attendus ici dans l'une des trois fenêtres de réception précédentes, qu'ils aient ou non été reçus à l'issue de la nouvelle fenêtre W2 (W3), ainsi que les informations groupées sur des paquets perdus qui étaient attendus dans la nouvelle fenêtre de réception W2 (W3).
Sur la figure 7, les paquets 21 , 23 et 25 perdus et retransmis sont reçus entre les émissions de L1 + L2 et la préparation de L1 + L2 + L3. Dans une option de l'invention, le récepteur met à jour ses listes de paquets non reçus, et en particulier il remplace la liste L1 par une nouvelle liste L'1.
Dans le mode de réalisation de la figure 7, une nouvelle fenêtre de réception W2 (W3) est ouverte à l'expiration de la fenêtre de réception précédente W1 (W2) et un nouveau message de déclaration de perte L1 +L2 (L'1 +L2+L3) est envoyé après l'expiration de la nouvelle fenêtre W2 (W3). Ce nouveau message contient les informations groupées sur les paquets perdus qui étaient attendus ici dans l'une des trois fenêtres de réception précédentes et qui n'ont pas encore été reçus à l'issue de la nouvelle fenêtre W2 (W3). Le nouveau message comprend également les informations groupées sur des paquets perdus qui étaient attendus dans la nouvelle fenêtre de réception W2 (W3).
Dans un mode de réalisation de l'invention, la perte d'au moins un paquet est détectée en observant une discontinuité dans une séquence de paquets reçue. Pour cela, lors d'une transmission d'une séquence de paquets, une analyse de la continuité est effectuée sur la séquence de paquets reçue comportant, ladite analyse permettant d'associer à une discontinuité de ladite séquence reçue une perte d'un ou plusieurs paquets.
Avantageusement, l'analyse de continuité permet en outre d'identifier le(s) paquet(s) perdu (s) en fonction d'au moins une caractéristique de ladite discontinuité. Avantageusement, les paquets comportant un numéro de séquence, l'analyse de la continuité est réalisée sur les numéros de séquence des paquets reçus et l'identification des paquets reçus est effectuée par leurs numéros de séquence. Les paquets perdus sont donc ceux correspondant aux numéros manquants dans la séquence reçue.
Cette détection des paquets perdus peut être mise en œuvre à l'aide d'un programme d'ordinateur. Un mode de réalisation de l'analyseur de continuité d'une séquence de paquets est alors un composant programmable comportant ce programme d'ordinateur.
Comme le récepteur ne connaît pas le contenu des paquets, il a intérêt à demander la retransmission d'un maximum de données pour perturber un minimum le fonctionnement du décodeur dans le cas de transmission d'une vidéo. Cependant, si des moyens d'analyse du réseau estiment que le temps de réception des paquets perdus sera tel que leur temps d'arrivée ne permettrait pas qu'ils soient pris en compte par le décodeur, des messages de déclaration de perte de paquets NACK peuvent ne pas être envoyés. L'invention propose ainsi une solution pour ne pas remonter de NACK si les pertes sont trop nombreuses.
Un paramètre P est défini. P est le nombre de paquets perdus sur une fenêtre W à partir duquel il ne sert à rien d'envoyer un message NACK car les retransmissions à temps des paquets perdus ne sont plus possibles.
Dans une première variante de l'invention, la taille de la fenêtre W est fonction de la taille du buffer entre la réception et l'utilisation des paquets et du débit autorisé pour les retransmissions. Dans une seconde variante, la taille de la fenêtre W est donnée par l'équation :
Taille de la fenêtre W = (débit_Nominal * rtx_time + D) / taille_paquet
débit_Nominal est le débit nominal du flux vidéo. rtx-time est un paramètre de configuration définit dans le RFC 4588. Ce paramètre définit une fenêtre pendant laquelle un serveur garde les informations en cas d'une éventuelle retransmission. D est un délai additionnel destiné à compenser les latences des réseaux et équipements mis en œuvre. taille_paquet est la taille des paquets transmis. La taille de la fenêtre W est exprimée en nombre de paquets. Il est ainsi simple de connaître le nombre de retransmissions qu'il est possible de demander à un instant donné. Cette solution est particulièrement précise quand les paquets ont une taille constante.
Dans le cas où le débit autorisé pour les retransmissions est limité à 50% du débit nominal, le paramètre P est fixé au maximum à 50% de la taille de la fenêtre W.
Compte-tenu du débit autorisé pour les retransmissions, par exemple 50% du débit normal d'émission, le récepteur ne peut recevoir qu'au maximum 50% des paquets émis dans cette fenêtre. Par conséquent, le paramètre P est fixé au maximum à 50% de la taille de la fenêtre W. Sur un réseau fiable, le paramètre P est fixé sur la base d'un pourcentage plus faible par exemple 5 à 10%.
La figure 8 reprend partiellement la figure 7 en ajoutant la fenêtre W. Dans cette fenêtre W le nombre de paquets qu'il est possible de redemander ne doit pas dépasser le paramètre P. La taille de la fenêtre W est toujours plus grande ou égale à la somme des tailles des fenêtres de réception W1 , W2, W3 sans qu'il soit possible de préjuger du nombre de retransmissions à demander dans ces fenêtres. Le récepteur connaît le nombre de paquets à retransmettre sur l'ensemble de la fenêtre W. Ainsi, lorsque le récepteur reçoit le paquet n°40, il connaît le nombre total de paquets à retransmettre sur les fenêtres W1 , W2, W3. Si le nombre total de paquets à retransmettre est inférieur à P, alors la requête est envoyée normalement. Par exemple si P= 12, le nombre total de paquets à retransmettre sur les fenêtres W1 , W2, W3 étant de 11 , la requête est envoyée normalement.
Dans le cas où P = 9, le récepteur peut soit décider de ne rien envoyer, soit décider d'envoyer les listes L1 , L2 et une liste partielle L'3 contenant uniquement le numéro de paquet perdus n° 37. La demande de retransmission des paquets perdus ayant les numéros 38, 39 pourra être effectuée lorsque le nombre de paquets à retransmettre sera de nouveau inférieur à P, par exemple lorsque les paquets 21 , 23 et 25 seront effectivement reçus suite à une retransmission de ces paquets. Cette demande de retransmission de paquets perdus s'effectuera conformément au principe de transmission multiple des NACK décrit en figure 7.
Ce mode de fonctionnement se comporte comme une fenêtre temporelle pilotée non par une minuterie mais par la réception de paquets transmis et/ou retransmis.
Cependant, si le principe de transmission multiple des NACK n'est pas mis en œuvre, il est toujours possible à la réception de retransmission de comparer le nombre de retransmissions en attente à P pour détecter le moment où il est possible d'émettre les requêtes en attente en utilisant le principe d'attendre N paquets avant l'envoi.
On notera que sur la figure 8, la fenêtre W commence avant l'ouverture de la fenêtre de réception W1. En variante, la fenêtre W peut commencer lorsque la fenêtre W1 est ouverte, par exemple, suite à la réception du paquet n°22.
La figure 9 présente une variante de réalisation dans laquelle, le récepteur envoie un message NACK dès que le nombre de paquets à retransmettre atteint P, sans attendre la fin de la fenêtre de réception W3. Ce message contient l'ensemble des requêtes qu'il doit normalement retransmettre complétée par tout ou partie des nouvelles détections de pertes. Par exemple, l'envoi de ce message est effectué dès la réception du paquet 35 car le seuil de P = 9 pertes est atteint. Le message envoyé contenant L1 + L2 + L'3 est identique au message telle que décrit plus haut à la figure 8. Ce message est cependant transmis plus rapidement, ce qui est favorable pour un système temps réel.
La figure 10 montre un schéma bloc de l'invention dans le cas particulier où les paquets perdus sont détectés par analyse de continuité de la séquence de paquets ( bloc "CONTINU?"). A la réception d'un paquet pj, schématisée par le bloc pj, la continuité de la séquence entre le paquet pj et le dernier paquet effectivement reçu est vérifiée.
Si une discontinuité est détectée [N] et si aucun regroupement n'a démarré [No Wk] parce qu'aucune fenêtre n'a été ouverte, alors une fenêtre dont la taille finale sera au moins égale au nombre N de paquets prédéfinis
(c'est-à-dire N paquets attendus ou N paquets effectivement reçus), démarre avec le premier paquet perdu, nommé ici pi (bloc "OPEN Wi" sur la figure 10).
En outre, les informations d'identification concernant les paquets perdus sont regroupées (bloc "COLLECT in [pi.pj]"). On notera que l'intervalle [pi.pj] correspond à la fenêtre de réception courante, dont la taille augmente au fur et à mesure de la réception de paquets. Les bornes pi et pj représentent respectivement les bornes de la fenêtre de réception courante, à la réception du paquet pj, pi étant le premier paquet perdu, ayant déclenché l'ouverture de la fenêtre Wk, et pj le dernier paquet effectivement reçu.
Si une discontinuité est détectée [N] et un regroupement démarré car une fenêtre ouverte [Wk open], les informations concernant les nouveaux paquets perdus entre pi et pj sont regroupés avec les informations concernant les autres paquets perdus sur cette fenêtre démarrée avec le paquet perdu pk.
Une fois, le cas échéant, les informations sur les paquets perdus regroupées, si la réception du paquet pj permet de détecter la fin de la fenêtre c'est-à-dire si la taille de la fenêtre est au moins égale à N paquets [Size Wk ≤r N], cela déclenche la transmission d'un message de déclaration de perte de paquets TRIG NACK comportant les informations de paquets perdus du début de la fenêtre à la détection de la fin de fenêtre.
En outre, dans une variante de réalisation de l'invention, s'il est détecté, à la réception du paquet pj, qu'un nombre P de paquets perdus
[LOST ≥ P] est atteint, le déclenchement de la transmission d'un message de déclaration de perte de paquets TRIG NACK est anticipé. Sinon [Size Wk <
N], on attend la réception du prochain paquet.
Dans une variante de l'invention, il est tenu compte de l'état du réseau, défavorable [B] ou favorable [G]. Un état défavorable du réseau est notamment détecté dans le cas où le nombre de paquet perdus durant une fenêtre de réception est supérieur à P,
Si l'état du réseau est défavorable, le déclenchement TRIG NACK est modifié. Il peut tout simplement être supprimé ("STOP") ou bien retardé ("WAIT") jusqu'à ce que le réseau soit revenu dans un état de transmission favorable.
Sinon l'état du réseau étant favorable [G], le message de déclaration de perte de paquets est transmis SEND NACK.
Ainsi, le déclenchement (TRIG NACK) de l'envoi du message (SEND NACK) de déclaration de perte est fonction de l'état (B/G/P) du réseau.
Dans une variante de réalisation, on ne tient pas compte de l'état du réseau. Ainsi, une fois les informations sur les paquets perdus regroupées, si la réception du paquet pj permet de détecter la fin de la fenêtre c'est-à-dire si la taille de la fenêtre est au moins égale à N paquets [Size Wk ≥ N], cela déclenche directement la transmission d'un message de déclaration de perte de paquets SEND NACK comportant les informations groupées sur des paquets perdus qui étaient attendus dans la fenêtre de réception W1. Sinon [Size Wk < N], on attend la réception du prochain paquet pj. Reprenons l'exemple de la figure 1 , si pj = 25, la réception de pj permet de détecter la fin de fenêtre et de transmettre les informations sur les paquets perdus pk = 21 et 23 dans la fenêtre uniquement. Alors que dans l'exemple de la figure 2, il faut attendre la réception du paquet pj=32 pour détecter la fin de la fenêtre (finissant avec le paquet 25), le message de déclaration de perte de paquets transmis comportera alors non seulement les paquets perdus dans la fenêtre à savoir les paquets 21 , 23 et 25 mais aussi les informations concernant les paquets perdus depuis la fin de la fenêtre jusqu'à sa détection par la réception d'un nouveau paquet pj=32 à savoir les paquets pk=26 à 31.
L'envoi du message de déclaration de perte de paquets est donc effectué au plus tard dès la détection de fin de fenêtre à savoir dès que la détection de fin de fenêtre, le message de déclaration de perte de paquets est constitué puis envoyer sans délai particulier autre que les délais de traitement normaux sauf report.
Dans des variantes de l'invention, si le nombre de paquets perdus atteint un nombre de paquets égal à la taille N de la fenêtre ou à un nombre de paquets prédéfinis maximum fonction du débit disponible du canal de retransmission et/ou du buffer de retransmission, le message de déclaration de perte de paquets est envoyé sans attendre la détection de la fin de la fenêtre.
Dans tous les cas, le procédé est réitéré avec le paquet suivant.
Dans une variante de l'invention, l'ouverture de la nouvelle fenêtre W2 ne dépend pas de la réception d'un paquet perdu mais la nouvelle fenêtre est ouverte dès le paquet suivant la fermeture de la fenêtre de réception W1 précédente. Ceci permet de couvrir la totalité de la séquence des paquets.
Dans une autre variante de l'invention, après expiration de la fenêtre de réception, une nouvelle fenêtre de réception est ouverte sur détection d'un nouveau paquet perdu. Ceci permet de couvrir la totalité des pertes sans pour autant effectuer un traitement sur la totalité de la séquence des paquets. Cela permet de réduire le nombre de messages de déclaration de perte de paquets envoyés.
La figure 11 montre un dispositif de traitement de perte de paquets pour la mise en œuvre du procédé de traitement de perte de paquets selon l'invention. Le dispositif de traitement comporte un collecteur T20 sur une fenêtre de taille au moins N paquets d'information d'identification des paquets perdus recevant notamment les informations d'identification des paquets perdus détectés par un détecteur de perte de paquets T10. Le dispositif de traitement comporte également des moyens d'envoi T30 de messages de déclaration de perte de paquets (NACK) comprenant les informations groupées sur des paquets perdus qui étaient attendus dans la fenêtre de réception. Ces informations sont fournies par le collecteur T20. L'émetteur T30 de messages de déclaration de perte de paquets informe, au travers d'un réseau R, un serveur S des paquets perdus. Cette information est utilisé par le serveur S de telle sorte que le dispositif de retransmission des paquets perdus
S10 retransmettent les paquets indiqués comme perdus dans les messages de déclaration de perte de paquets reçus par le serveur S.
Le collecteur T20 comporte notamment des moyens de groupement d'informations relatives à des paquets, ledit groupement étant effectué pour des paquets perdus qui étaient attendus dans la fenêtre de réception W1 dont la taille est égale à un nombre de paquets supérieur ou égal au nombre N fixé de paquets prédéfinis.
Les informations concernant peuvent outre l'information d'identification comporter des informations telles que, par exemple, l'identité du nœud, l'identité de l'usage, l'instant de détection de perte, etc.
Dans une variante de l'invention, le dispositif de traitement de perte de paquets comporte en outre un détecteur de perte de paquet T10 par discontinuité de la séquence de paquets.
Le dispositif de traitement de perte de paquets comporte dans un mode de réalisation particulier de l'invention un analyseur de réseau T40 apte à annuler STOP l'envoi d'un message de déclaration de perte ou à le retarder WAIT/GO.
L'invention concerne également un nœud d'un réseau comprenant le dispositif de traitement de perte de paquets.
L'invention concerne également un terminal de communication comprenant le dispositif de traitement de perte de paquets. Le terminal est par exemple un téléviseur, un ordinateur doté d'un récepteur (ADSL, radiofréquence, Wifi, etc.), un téléphone, etc.
L'invention concerne donc la réception de données pour déclencher l'émission des requêtes de retransmissions ou messages de déclaration de perte de paquets, la réception d'un paquet de données indiquant que le réseau a une forte probabilité d'être opérationnel aussi pour une remontée d'information.
En variante, l'invention concerne l'attente d'au moins N paquets après détection d'une perte pour envoyer un message de déclaration de perte de paquets NACK. Dans une autre variante, l'invention concerne l'envoi de requêtes
NACK contenant des requêtes déjà transmises pour compenser les éventuelles pertes des messages de déclaration de perte de paquets NACK. (Répétition des messages de déclaration de perte de paquets NACKs).
Dans une autre variante, l'invention concerne la comparaison du nombre de retransmissions attendues à un seuil déterminant si la réception des retransmissions peut arriver à temps pour un flux vidéo temps réel.
Dans le cas d'un transport multicast, le serveur de retransmission (par exemple la source) selon une variante de l'invention accepte simplement des requêtes de retransmission provenant de plusieurs récepteurs et envoient les paquets de retransmission à tout le groupe.
En outre, l'invention concerne une combinaison d'une partie ou de toutes les variantes décrites. L'invention décrite dans le cas d'une application flux temps réel unicast pour des flux de vidéo à la demande est utilisée sans modification dans toutes applications dans lesquels des flux sont transmis par paquet : communication, unicast, multicast, temps réel ou non, quelque soit le type de données vidéo, audio, data et de services : vidéo à la demande, lecteur DVD réseau, etc.

Claims

REVENDICATIONS
1. Procédé de traitement de perte de paquets lors de la transmission d'un flux de paquets à travers un réseau ledit procédé comprenant : - un groupement (COLLECT) d'informations relatives à des paquets, ledit groupement étant effectué pour des paquets perdus qui étaient attendus dans une fenêtre de réception (W1) dont la taille est égale à un nombre de paquets supérieur ou égal à un nombre N fixé de paquets prédéfinis.
2. Procédé de traitement selon la revendication 1 , dans lequel le nombre N est relatif à des paquets effectivement reçus.
3. Procédé de traitement selon la revendication 1 , dans lequel le nombre N est relatif à des paquets attendus.
4. Procédé de traitement selon la revendication 3, dans lequel dans le cas où le Nième paquet attendu est perdu, la fenêtre de réception est prolongée jusqu'au premier paquet ultérieur effectivement reçu.
5 Procédé de traitement selon l'une quelconque des revendications précédentes, comprenant en outre :
- un envoi d'un message (SEND NACK) de déclaration de perte comprenant les informations groupées sur les paquets perdus qui étaient attendus dans ladite fenêtre de réception.
6. Procédé de traitement selon la revendication précédente, dans lequel le déclenchement (TRIG NACK) de l'envoi du message (SEND NACK) de déclaration de perte est fonction d'un état (B/G/P) du réseau.
7 Procédé de traitement selon l'une quelconque des revendications précédentes, dans lequel après l'expiration de ladite fenêtre de réception, une nouvelle fenêtre de réception est ouverte sur détection d'un nouveau paquet perdu.
8. Procédé de traitement selon l'une quelconque des revendications 1 à 6, dans lequel une nouvelle fenêtre de réception est ouverte à l'expiration de ladite fenêtre de réception, dite "fenêtre précédente", et il est prévu l'envoi d'un nouveau message de déclaration de perte contenant :
- les informations groupées sur des paquets perdus qui étaient attendus dans la fenêtre de réception précédente et non encore reçus et;
- les informations groupées sur des paquets perdus qui étaient attendus dans la nouvelle fenêtre de réception.
9 Procédé de traitement selon l'une quelconque des revendications précédentes, dans lequel des numéros de séquences étant affectés aux paquets du flux, on détecte la perte de paquets par analyse des numéros de séquences des paquets effectivement reçus.
10. Programme d'ordinateur pour un dispositif de traitement de perte de paquets comportant des instructions de code de programme pour commander l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté par le dispositif de traitement.
11. Dispositif de traitement de perte de paquets comportant :
- des moyens de groupement d'informations relatives à des paquets, ledit groupement étant effectué pour des paquets perdus qui étaient attendus dans une fenêtre de réception (W1) dont la taille est égale à un nombre de paquets supérieur ou égal à un nombre N fixé de paquets prédéfinis.
12 Dispositif de traitement de perte de paquets selon la revendication
11 , comportant en outre : - des moyens d'envoi (T30) d'un message de déclaration de perte comprenant les informations groupées sur des paquets perdus qui étaient attendus dans ladite fenêtre de réception.
13. Nœud du réseau comprenant un dispositif de traitement de perte de paquets selon l'une des revendications 11 et 12.
14. Terminal de communication comprenant un dispositif de traitement de perte de paquets selon l'une des revendications 11 et 12.
PCT/FR2007/052462 2006-12-08 2007-12-07 Procede de traitement de perte de paquets WO2008096086A2 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
EP06301231 2006-12-08
EP06301231.4 2006-12-08
FR0755549 2007-06-07
FR0755549 2007-06-07
FR0755547 2007-06-07
FR0755547 2007-06-07

Publications (2)

Publication Number Publication Date
WO2008096086A2 true WO2008096086A2 (fr) 2008-08-14
WO2008096086A3 WO2008096086A3 (fr) 2009-02-19

Family

ID=39682155

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/052462 WO2008096086A2 (fr) 2006-12-08 2007-12-07 Procede de traitement de perte de paquets

Country Status (1)

Country Link
WO (1) WO2008096086A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010072107A1 (fr) * 2008-12-24 2010-07-01 华为技术有限公司 Procédé et dispositif de déduction de facture de flux de service d'utilisateur
CN102388634A (zh) * 2011-09-05 2012-03-21 华为技术有限公司 一种流量业务计费方法、装置和系统
WO2023133697A1 (fr) * 2022-01-11 2023-07-20 华为技术有限公司 Procédé et appareil de traitement de perte de paquets, commutateur, dispositif d'envoi et système de transmission de données

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5636230A (en) * 1994-05-31 1997-06-03 Motorola, Inc. Method for eliminating a receiving data unit as a source of excessive resend requests
EP1018817A2 (fr) * 1999-01-08 2000-07-12 Nortel Networks Corporation Procédé et système d'ordonnancement séquentiel des numéros de séquences manquants dans des trames SREJ dans un système de communications
WO2000062466A2 (fr) * 1999-04-09 2000-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Procede pour minimiser les reponses de reaction dans des protocoles arq
WO2002043403A2 (fr) * 2000-11-21 2002-05-30 At & T Wireless Services, Inc. Mecanisme ameliore de rejet selectif de couche de liaison de donnees dans un environnement sans fil bruyant
WO2006015252A1 (fr) * 2004-07-30 2006-02-09 Nokia Corporation Systeme et procede destines a des accuses de reception de longueur variable dans un reseau a ressources partagees

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5636230A (en) * 1994-05-31 1997-06-03 Motorola, Inc. Method for eliminating a receiving data unit as a source of excessive resend requests
EP1018817A2 (fr) * 1999-01-08 2000-07-12 Nortel Networks Corporation Procédé et système d'ordonnancement séquentiel des numéros de séquences manquants dans des trames SREJ dans un système de communications
WO2000062466A2 (fr) * 1999-04-09 2000-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Procede pour minimiser les reponses de reaction dans des protocoles arq
WO2002043403A2 (fr) * 2000-11-21 2002-05-30 At & T Wireless Services, Inc. Mecanisme ameliore de rejet selectif de couche de liaison de donnees dans un environnement sans fil bruyant
WO2006015252A1 (fr) * 2004-07-30 2006-02-09 Nokia Corporation Systeme et procede destines a des accuses de reception de longueur variable dans un reseau a ressources partagees

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010072107A1 (fr) * 2008-12-24 2010-07-01 华为技术有限公司 Procédé et dispositif de déduction de facture de flux de service d'utilisateur
CN102388634A (zh) * 2011-09-05 2012-03-21 华为技术有限公司 一种流量业务计费方法、装置和系统
WO2012149725A1 (fr) * 2011-09-05 2012-11-08 华为技术有限公司 Procédé, dispositif et système de facturation de service de volume
CN102388634B (zh) * 2011-09-05 2015-07-29 华为技术有限公司 一种流量业务计费方法、装置和系统
WO2023133697A1 (fr) * 2022-01-11 2023-07-20 华为技术有限公司 Procédé et appareil de traitement de perte de paquets, commutateur, dispositif d'envoi et système de transmission de données

Also Published As

Publication number Publication date
WO2008096086A3 (fr) 2009-02-19

Similar Documents

Publication Publication Date Title
CA2674414C (fr) Procede de transmission/reception en temps reel de donnees par paquets entre un serveur et un terminal client, serveur et terminal correspondants
EP2885899B1 (fr) Dispositif et procédé de transfert unidirectionnel de données
WO2006111635A1 (fr) Procede et systeme de transmission d’un flux multicast en reseau d’echange de donnees
FR2926939A1 (fr) Procede de transmission de donnees avec anticipation des acquittements, dispositif d&#39;entree, produit programme d&#39;ordinateur et moyen de stockage correspondants
EP1418698A1 (fr) Procédé de transmission de données en mode acquitté
EP1908259B1 (fr) Appareil et procede d&#39;estimation du taux de remplissage des tampons d&#39;entree de clients d&#39;une distribution de contenu temps reel
EP3238406B1 (fr) Procédé de traitement d&#39;une requête de livraison de données
EP2724486A1 (fr) Retransmission de donnees perdues entre un emetteur et un recepteur
EP2156597B1 (fr) Procede de reception de paquets de donnees et procede de transmission correspondant
EP2939450B1 (fr) Transmission d&#39;un message multimédia doublée par émission d&#39;un message textuel
EP2282432B1 (fr) Procédé de transmission de données multimedia dans des réseaux de communication ad hoc
WO2008096086A2 (fr) Procede de traitement de perte de paquets
FR2826211A1 (fr) Procede et dispositif d&#39;allegement de la charge de signalisation d&#39;un protocole &#34;pluri-transmission&#34; utilisant un support de transmission ne permettant pas l&#39;ecoute mutuelle entre terminaux d&#39;un reseau
EP1617591A1 (fr) Procédé et serveur de référencement de diffusion poste à poste de fichiers demandés par téléchargement à ce serveur
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d&#39;un flux de données selon un mode de transmission multipoint
FR2946164A1 (fr) Procede de telechargement de donnees de grande taille vers un grand nombre de machines clientes en reseau a partir d&#39;un serveur unique
EP1411689B1 (fr) Procédé de contrôle de retransmission de données et unité de contrôle pour mettre en oeuvre le procédé
EP1745603B8 (fr) Procede et dispositif d&#39;emission de paquets de donnees
EP2645647B1 (fr) Procédé d&#39;optimisation du débit descendant d&#39;une ligne d&#39;accès asymétrique, dispositif, produit programme d&#39;ordinateur et support de stockage correspondants.
FR2935576A1 (fr) Procede de gestion d&#39;une transmission de flux de donnees sur un tunnel multi-canal, tete de tunnel, produit programme d&#39;ordinateur et moyen de stockage correspondants.
FR3129049A1 (fr) Procédé de gestion d’une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d’une valeur d’un paramètre de performance intermédiaire déterminée par un nœud intermédiaire appartenant audit chemin
EP2047653A1 (fr) Transmission de flux de donnees en fragmentation des messages
WO2007090992A2 (fr) Procede, dispositif et systeme de diffusion de paquets de donnees dans un reseau
FR3032077A1 (fr) Procede de diffusion multipoint d&#39;un flux de donnees au format ip
WO2007028889A1 (fr) Relachement de session dans un reseau ip

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: 07871894

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07871894

Country of ref document: EP

Kind code of ref document: A2