AU2007344308A1

AU2007344308A1 - Method of real-time transmission/reception of data in packets between a server and a client terminal, corresponding server and terminal

Info

Publication number: AU2007344308A1
Application number: AU2007344308A
Authority: AU
Inventors: Laurent Cannieux; Philippe Ganthier; David Vincent
Original assignee: Telediffusion de France ets Public de Diffusion
Current assignee: Telediffusion de France ets Public de Diffusion
Priority date: 2007-01-09
Filing date: 2007-12-28
Publication date: 2008-07-24
Anticipated expiration: 2027-12-28
Also published as: CA2674414A1; FR2911231A1; WO2008087364A3; CN101632263B; CN101632263A; KR101438005B1; ES2561161T3; CA2674414C; DK2119141T3; EP2119141A2; AU2007344308B2; PL2119141T3; EP2119141B1; KR20090116700A; FR2911231B1; WO2008087364A2; AU2007344308A2

Description

Method for the real-time transmission/reception of data in packets between a server and a client terminal, corresponding server and terminal The invention relates to a method for the real-time transmission/reception 5 of data in packets, between a server and a client terminal, corresponding server and terminal. The real-time transfer of asynchronous data streams of the audio and video type is increasingly often carried out using streams, in particular IP (Internet Protocol) streams, by optical fibre, by satellite or by ADSL links for example. 10 The purpose of the present invention is to make the transfer of data in packets over links, particularly of the IP type, reliable in the case of an essentially real-time transmission, when the transmission data rate is imposed by the application server for an application such as radio or video for example. The protocols currently usable for routing data in real time are of two 15 types: Connected mode protocols, of the TCP (Transmission Control Protocol) type and, in non-connected mode, of the UDP (User Datagram Protocol) type. In connected mode, the TCP protocol provides an acknowledgement of 20 each data packet reception. This protocol was the subject of a detailed description in the document "TCP: Transmission Control Protocol" RFC 793, September 1981. Moreover, the DCP (Distribution and Communications Protocol) protocol has been defined in the context of a DRM (Digital Radio Mondiale) project for digitizing long, medium and short waves. DCP was the subject of a detailed 25 description in the ETSI (European Telecommunications Standards Institute) standard, referenced TS 102821. In non-connected mode, the UDP protocol allows only the addressing of packets. It was the subject of a detailed description in the document entitled "User Datagram Protocol", RDC 768, August 1980. 30 The DCP on UDP protocol has stream continuity indices, which make it possible to detect data packet losses. This protocol was the subject of a detailed description in the document entitled Distribution and Communication Protocol also referenced ETSI, TS 102821. Defined in the context of the DRM project, it makes it possible to protect, optionally, the transmitted data by a fragmentation associated with 2 a Reed Solomon code. The RTP (Real-time Transport Protocol) protocol is a continuous transmission protocol using a continuity counter making it possible to detect lost data packets. Used in association with the RTCP (Real Time Control Protocol), it also 5 makes it possible to estimate the quality of the link. The aforementioned protocols are defined in the following documents: - "RTP: A Transport Protocol for Real Time Applications", STD 64, RFC 3550, July 2003; - "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, 10 January 1996. The abovementioned protocols of the prior art have drawbacks. In connected mode, the principal drawback is that these protocols necessitate a fast bidirectional link, in order to acknowledge each of the data packets received. This constraint is incompatible with monodirectional links, such as a 15 satellite or optical fibre link. In particular, the transport of a real-time stream by the TCP protocol has several drawbacks when there is a break in the link: - a break longer than the network timeout period necessitates a long reconnection time; 20 - the time for reconstituting the buffer memory for several frames of data packets, used by the client terminal in order to compensate for the jitter in the network, is added to the break time; - during the reconnection, if the timeout has not been exceeded, the server sends all of the data that it has not been able to transmit, 25 including the obsolete data, which slows down the resumption of the useful transmission. The aforementioned protocol requires a connexion and a replication of the stream for each client terminal, because it does not allow multicast broadcasting. It therefore requires significant resources both at the server level and at the network 30 level. In non-connected mode, the UDP protocol does not guarantee the delivery of packets and has no error protection mode. The DCP/UDP protocol, the DCP protocol associated with the UDP protocol, provides error protection with continuity metering. However, this protection 3 remains very weak, because it makes it possible to correct a maximum of 20% of the transmitted packets; this protection being constituted by a fragmentation of the transmitted packets, associated with a Reed Solomon code. The RTP protocol, even though making it possible to detect the lost 5 packets and to estimate the quality of the link, does not make it possible to recover the lost data. A subject of the present invention is to make the real-time transmission of data, transported by any IP stream, reliable by overcoming the drawbacks of the protocols known in the prior art by the correction of link breaks longer than for the 10 DCP/UDP protocol, in the absence of the drawbacks of the TCP protocol. In particular, a subject of the invention is a method of real-time transmission of data in packets between a server and a client terminal in which the length, in duration, of the link breaks that can be corrected depends, on the one hand, on the size of the memory used as a buffer memory, on both the application server 15 side and on the client terminal side, and, on the other hand, on the connection time between the server and the client terminal. Another subject of the present invention is the implementation of a method of real-time transmission of data in packets, including a function of the repetition of the transmitted packets, only a break in transmission longer in duration 20 than the capability or duration of repetition being observed at the level of the client terminal, this break then appearing as equal to the length in duration of the link break, reduced by capability of repetition. Finally, the present invention also relates to the implementation of a method of real-time transmission/reception of data in packets between server and 25 client terminal, making it possible to maintain a stream compatible with client receiving equipments which do not manage the packet repetition request. The method of real-time transmission/reception data in packets in an IP network between a server and a client terminal, which is a subject of the invention, is noteworthy in that it consists at least, on the server side, in assigning a transmission 30 continuity index to each packet to be transmitted, successively transmitting each of the packets and their continuity index to the client terminal, and, on the client terminal side, in detecting any break in the stream of packets received on the basis of the continuity index associated with each packet received and, on detection of a stream discontinuity, transmitting from the client terminal to the server at least one request 4 for retransmission of at least one missing packet, for as long as this missing packet has not been received by this client terminal and for as long as this packet is not obsolete. The method, which is a subject of the invention is, moreover, noteworthy 5 in that it consists, on the server side and on the client terminal side, in continuously storing a same plurality of successive packets, except for the packets not received on the client terminal side, each packet being stored and accompanied by its continuity index. The method, which is a subject of the invention is, moreover, noteworthy 10 in that, on the server side, the step consisting of transmitting consists of transmitting the packets according to the UDP protocol and of transmitting the continuity index according to the DCP or RTP protocol. The method, which is a subject of the invention is also noteworthy in that the step of detection of any break in continuity is carried out by analysis of the DCP 15 or RTP stream alone. The method of the invention is, moreover, noteworthy in that the step consisting of continuously storing consists of storing each packet of the plurality of successive packets in a buffer memory of the FIFO type. According to another noteworthy aspect of the method according to the 20 invention, the size of the aforementioned FIFO memory in number of packets is a function of the transmission parameters of the packet transmission network. According to another noteworthy aspect of the method according to the invention, the size of the aforementioned FIFO memory is adaptive. This makes it possible to optimize the compensation of transmission breaks, to within the forward 25 and return time, between the client terminal and the server. The method, which is a subject of the invention is also noteworthy in that the transmission of the information, necessary for the client to make the repetition requests, is carried out by the transmission of information including 'at least the destination address of any request for retransmission of packets and the memory size 30 of the buffer memory for storing the plurality of successive packets. The method, which is a subject of the invention is, moreover; noteworthy in that the step consisting of transmitting from the client terminal to the server a request for retransmission of at least one packet is executed according to the UDP/IP protocol.

5 According to another noteworthy aspect of the method according to the invention, each retransmission request includes at least the identification and the destination address of the packet or packets to be retransmitted. Finally, the method, which is a subject of the invention, is noteworthy in 5 that the step consisting of successively transmitting each of the packets is carried out by transmission in unicast or multicast mode. The transmission/reception server for data in packets in an IP network between this server and a client terminal according to the invention is noteworthy in that it comprises at least, in addition to the resources for the transmission of 10 consecutive data packets constitutive of at least one transmission stream, a module for the generation and transmission of continuity of the transmitted packets signalling data, a module for storing a series of a number of successive data packets sent for at least one stream of transmitted data and a module for receiving and processing requests for the retransmission of data packets that are still present in the storage 15 module of the series of a number of successive data packets, the module for receiving and processing repetition requests controlling the storage and transmission module. The client terminal adapted for the reception of streams of data in packets in an IP network, accompanied by stream continuity signalling data, which is a subject of the present invention is noteworthy in that it comprises, moreover, a module for 20 detecting stream breaks by analysis of continuity signalling data, a module for storing a series of a number of successive data packets received for at least one data stream, a module for the transmission of requests for the retransmission of data to a specific address and a module for resequencing the packets received in the module for storing a series of a number of successive data packets received, taking account of the 25 retransmitted packets. The server and the client terminal which are subjects of the present invention are, moreover, noteworthy in that the data packets are transmitted by the server and respectively received by the client terminal in UDP mode and in that the continuity data is transmitted by the server and respectively received by the client 30 terminal in DCP or RTP mode. They will be better understood on reading the description and on observing the following drawings in which: - Figure 1 shows, by way of illustration, a general flowchart of the stages of implementation of method of real-time transmission/reception of 6 data in packets between a server and a client terminal, according to the present invention; - Figure 2a shows, by way of illustration, a functional block diagram of the architecture of a server for the transmission/reception of data in 5 packets in an IP network, according to the present invention; - Figure 2b shows, by way of illustration, functional block diagram of the operating mode of the server according to the present invention, such as shown in Figure 2a; - Figure 3a shows, by way of illustration, a functional block diagram of 10 the architecture of a client terminal adapted for the reception/transmission of data in packets in an IP network according to the invention; - Figure 3b shows, by way of illustration, a functional block diagram of the operating mode of the client terminal according to the invention, as 15 shown in Figure 3a; - Figure 4a shows, by way of illustration, the structure of an information message for the transmission of data in packets in an IP network using the DCP protocol between a server and a client terminal, according to the invention; 20 - Figure 4b shows, by way of illustration, the structure of a message requesting the retransmission of transmitted packets, using the DCP protocol, by a client terminal shown in Figures 3a and 3b, to a server such as shown in Figures 2a and 2b, according to the invention. A more detailed description of the method of real-time transmission of 25 data in packets in an IP network between a server S and a client terminal CT, according to the present invention, will now be given with reference to Figure 1 and the subsequent figures. In general, it is considered that the server S is accessible via the IP network by using its address @S as well as the client terminal CT by using its address 30 @CT. The method according to the invention consists at least, on the server side, of assigning a transmission continuity index, referenced Ck, in Step 1, to each packet to be transmitted. The operation is indicated in Step A of Figure 1 by the expression Pk -> Ck, Pk. In this expression Ck indicates the transmission continuity index assigned to the data packet to be transmitted Pk. More specifically, it is stated that the continuity index Ck assigned to each 5 data packet Pk can be constituted by an increasing numerical value, as a function of the rank of the transmitted packet, and thus constitutes a series of continuity signalling data of the transmitted data packets. By way of non-limitative example, it is stated that each continuity index value Ck can be calculated on the basis of an increasing monotonic function of the 10 rank of each packet for example. This type of operation is known in the prior art and for this reason will not be described in detail. Step A is followed two simultaneous Steps B and C. Step B consists of successively transmitting each of the packets Pk and their continuity index Ck to the client terminal CT using the address @CT of the latter. Step C consists of storing each 15 of the packets Pk and their continuity index Ck in the memory of the server terminal S. In Step B of Figure 1, the transmission operation is expressed as follows: S DCP(Ck),UDP(Pk) > CT. In the preceding expression: - DCP (Ck) represents the transmission of each continuity index Ck 20 preferably, but in a non-limitative way, according to the DCP protocol; and - UDP (Pk) represents the transmission of each packet Pk preferably, but in a non-limitative way, according to the UDP protocol. In Step C, the storage operation is represented by the expression: 25 Storage {Pk Ck } -x where N-X and N-1 denote the ranks of the successive packets and the corresponding continuity index values stored at the level of the server terminal S. According to a preferred and non-limitative embodiment of the method according to the invention, the storage step represented in Step C on the server S side 30 can advantageously be executed by the intermediary of a FIFO memory whose size is adapted for the storage of the successive packets Pk transmitted on the server S side as well as continuity indices Ck which have been associated to them during Step A. Following Steps A , B and C of Figure 1 executed at the level of the server S, the method, which is a subject of the invention consists, on the client terminal CT side, of executing two simultaneous Steps G and J. Step G consists of detecting any break in continuity of the stream of packets received Pk on the basis of the continuity indices associated with each packet received as well as of ensuring that 5 the packet received Pk is not a retransmitted packet in order to not take into account the continuity break generated by the reception of the repeated packets. In Step G, the operation consisting of detecting any break in continuity of the stream of packets received is represented symbolically as: Ck+1 .k+1 ? 10 By this notation, it is understood that the detection operation consists, on the basis of the inverse monotonic function for example used on transmission, of checking that the continuity index of rank k+1 referenced Ck.1 has been received after reception of the continuity index value Ck and therefore immediately after the packet Pk, the notion of immediacy following the reception being symbolically indicated by 15 Ck+1. It is thus understood that Step G, executed on the client terminal CT side, of detection of any break in continuity is carried out by analysis solely of the DCP stream allowing the transmission of the continuity indices at the level of the client terminal CT. 20 In Step G, the operation consisting of checking that the packet received is not a packet retransmitted by request is indicated symbolically as follows: Ck e (CPk \ CRk) By this notation, it is understood that the checking operation consists of checking that the continuity index of the packet received Ck does not belong to the set 25 of identifiers of the packets lost during the transmission. This set is defined as the set of packets transmitted by the server terminal CPk minus the set of the continuity indices of the packets already present in the memory of the client terminal CT: CRk. On detection of a real stream discontinuity, i.e. when the conditions tested 30 in Step G are verified, then a stream discontinuity exists after reception of the continuity index Ck, designated as continuity index of break Ckr. The stream discontinuity can concern several non-received packets, of continuity index value referenced {Ck+, ... , Ck+p} for example. The method of the invention consists, in a Step H, of transmitting from the client terminal CT to the server S, using the return shown in dotted line in Step I, a retransmission request as indicated in Step H: RR (Ckr, @CT) to the server S, i.e. to the address @S of the latter. This operation of return in Step I and transmission of the aforementioned request is carried out for as long as the missing packet or packets Ck+l, Ck+p has or 5 have not been received by the client terminal CT and for as long as the missing packets Ck+1, Ck+p are not obsolete, i.e. for as long as the continuity index Ckr of the packet to be retransmitted remains between CN-1 and CN-X, the limit continuity indices of the continuity indices of the packets present in the memory of the client terminal. The return Step I, symbolized by the dotted line arrow, returns to Step D 10 at the level of the server S. Step J of the client terminal, simultaneous with Step G, consists of analysing the continuity index of the received packet Ck in order to detect the packets already received and stored as well as the packets that are not obsolete. In Step J the operations consisting of checking the validity of the packets 15 received is indicated symbolically as follows: (Ck < CN-X ) v ( Ck E CRk) By this notation, it is understood that a packet is considered as useless if its continuity index Ck is older than the continuity index of the oldest packet stored on the client terminal side CN-X or if the continuity index of the 20 packet received already belongs to the set CRk of continuity indices of the packets already stored on the client terminal side. If there is a positive response to the tests in Step J, the useless packet is destroyed in Step K. Of course, if there is a negative response to the tests in Step J of Figure 1, 25 the method, which is a subject of the invention consists, in Step E, of sequencing and then of storing the received data packet Rk. The corresponding storage operation is represented by the expression: Storage {Pk Ck N1 where N-X and N-1 denote the ranks of the successive packets and the corresponding continuity index values stored at 30 the level of the client terminal CT. According to a preferred and non-limitative embodiment of the method which is a subject of the invention, the storage step shown in Step E on the client terminal CT side can advantageously be executed by the intermediary of a FIFO 10 memory whose size is adapted for the storage of the successive packets Rk received on the client terminal side and of the continuity indices Ck corresponding to them. Once Step E is completed, i.e. the packet leaves the FIFO memory used in Step E, the packet undergoes the processing procedure symbolized by Step F. 5 Step D, on the server terminal side corresponds to the analysis of the repetition request sent by the client terminal CT to the server terminal S. Step D consists of detecting if the packet or packets identified in the retransmission request are still present in the memory of the server. This detection can be indicated symbolically as follows: 10 CN- CK N-X By this notation, it is understood that the operation consists of verifying that the continuity index of rank k denoting the packet to be repeated must be included between the continuity index CN of the last packet added to the FIFO and the continuity index CN-X of the oldest packet added to the FIFO. 15 When there is a negative response to the test in Step D of Figure 1, the method which is a subject of the invention consists of ignoring the request sent by the client CT to the server terminal S. When there is a positive response to the test in Step D of Figure 1, the method which is a subject of the invention consists, in a Step L, of the retransmission 20 of the packets designated in the request transmitted during Step I by the client terminal CT to the server terminal S. According to a preferred and non-limitative implementation of the method which is a subject of the invention, the retransmission step shown in Step L, on the server S side, can advantageously be executed by searching for packets to be retransmitted in the FIFO memory used in Step C and then 25 by retransmitting these same packets using Step B of the client terminal CT. In order to allow the smooth execution of the implementation of the method according to the invention, the latter consists, as shown in Figure 1, on the client terminal CT side, on the one hand, and on the server S side, on the other hand, 30 of continuously storing a same plurality of successive packets to be transmitted and received respectively, accompanied by their continuity indices. The corresponding operations are represented in Step C at the level of the server S and in Step E at the level of the client terminal CT respectively. The general functioning and the operating procedure of the method which 11 is a subject of the invention, such as shown in Figure 1 is then as follows, when the UDP protocol allowing the transmission of the successive packets Pk and the DCP protocol allowing the transmission the continuity indices Ck are used. One of the channels routes the stream in real time from the server S to the 5 client terminal CT by the UDP protocol and the other channel allows the client terminal CT to send, to the server S specified in the stream, the packet retransmission requests using the UDP protocol. The continuity indices contained in the stream transmitted by the DCP protocol are used for detecting the stream breaks on the client terminal CT side. 10 When the latter detects a break in the continuity of transmission of the packets Pk, it then requests the retransmission of the packets not received by sending a request to the server S, the request RR (Ckr,@CT) previously mentioned in Step H of Figure 1. The server S then retransmits the missing packets. In order to maintain the continuity of the stream in real time, the storage 15 of the data received on the client terminal CT side whilst waiting for the reception of' the lost packets, as well as the storage of the data transmitted on the server S side, makes it possible to obtain the aforementioned continuity. This operation is executed thanks to the use of the FIFO memories on both the server S side and on the client terminal CT side. 20 According to one feature of the method which is a subject of the invention, the FIFO memory used, both on the server S side and on the client terminal CT side, can be defined from the point of view of its size in number of packets and according to the transmission parameters of the transmission network of the packets in question. 25 More specifically, the size of the FIFO memory used, on the server S side and on the client terminal CT side, can then be made adaptive for the particularly advantageous purpose of optimising the compensation for breaks in the transmission of successive data packets, to within the forward and return transmission time between the client terminal CT and the server S, as will be described later in the 30 description. It is however pointed out that the choice of the size of the memory used on the client terminal side affects the delay time introduced on reception. By way of non-limitative example, the size of the FIFO memory can be determined as a function of the aforementioned forward and return transmission time 12 between the server S and the client terminal CT and of the maximum size of the transmission breaks that it is desired to be able to correct. The forward and return transmission time between the client terminal and the server terminal can be measured by conventional operations on the server side, for example, by transmission of 5 appropriate commands, which will not be described in greater detail for this reason. More specifically, it is stated that the transmission of the information, necessary for the client to be able to make the requests for repetition, between the server S and the client terminal CT, is carried out by transmission of a DCP information tag. This tag can include at least the destination address of any request for 10 the retransmission of packets i.e. the address @S of the server S and the memory size of the buffer memory for storage of the plurality of successive packets. As mentioned previously in the description, this memory. size can be determined adaptively at the level of the server S and then configured at the level of the client terminal CT in question. 15 Finally, with regard to the transmission from the client terminal to the server S of a request for retransmission of at least one packet, this operation, represented in Step I of the Figure 1, is advantageously executed according to the UDP/IP protocol. Of course, each retransmission request includes the identifier of the first 20 packet to be retransmitted, i.e. the continuity index Ckr for which the break has been detected, the number of packets to be retransmitted, as well as the destination address of the packet or packets to be retransmitted, i.e. the address @CT of the client terminal CT. With regard to the step consisting of successively transmitting each of the 25 packets Pk, this can be advantageously carried out by transmission in unicast mode or even in multicast mode. A more detailed description of a server for the transmission of data in packets in an IP network and a client terminal allowing the implementation of the method according to the present invention, will now be given with reference to 30 Figures 2a and 2b, and to 3a and 3b respectively. With reference to Figure 2a, it is indicated that the server for the transmission of data in packets in an IP network which is a subject of the invention, the server S, between this server and a client terminal CT, comprises in a conventional manner input/output devices, referenced 1/0, a central processing unit CPU, an access 13 control module AC controlling access to the server making it possible to manage any request, from the access and security point of view, to a service or application transmitted by this server S. The assembly is managed by a program module Mo making it possible, in 5 particular, to provide the server function for one or more applications in question. The program module Mo makes it possible, in particular, to manage the transmission of data packets Pk constitutive of at least one transmission stream for an application in question. In addition to the aforementioned conventional elements, the server for 10 transmission of data in packets in an IP network which is a subject of the invention comprises a module M 1 generating the transmission of data signalling the continuity of the transmitted data packets Pk. The aforementioned module M 1 can be constituted by a software module executing, for example, the increasing monotonic function making it possible to 15 calculate the successive values of continuity index Ck assigned to each of the transmitted packets Pk. Moreover, as shown in Figure 2a, it comprises a module M 2 x for the storage of a series of a number of successive data packets sent for at least one stream of transmitted data, the storage preferably being executed by the storage of the 20 packets Pk over a number X of packets according to the expression shown in Step C of Figure 1. Finally, the server S according to the invention comprises a module M 3 for the reception and processing of requests for retransmission of data packets Pk still present in the module M 2 x for the storage of the series of a number of successive data 25 packets Pk. The storage module M 2 x is preferably constituted by a buffer memory of the FIFO type the size of which defines the retransmission capability of the server S in number of data packets, and, of course, in duration of retransmission. The module M 3 for the reception and processing of the aforementioned 30 requests is advantageously constituted by a software module making it possible to process the request message previously described in the description. The reception and processing module M 3 controls the packet transmission resources and the module

M

2 x containing the packets necessary for the retransmission. Moreover, as mentioned previously in the description, the module M 3 for 14 the reception and processing of the requests controls the module for the transmission of the successive packets Pk which must be retransmitted, either in unicast mode or in multicast mode. The operating procedure of the server S according to the invention shown 5 in Figure 2a will now be described with reference to Figure 2b. The function of the server S is: - to insert into the stream signalling data that the client terminal CT uses for transmitting requests for the retransmission of packets Pk; - to retain in the buffer memory, a FIFO memory, a portion of the stream 10 already sent. It is particularly advantageously indicated that a single buffer memory is necessary per stream transmitted by the server and that this is so whatever the number of client terminals TC receiving the stream in question may be; The size of the buffer memory M 2 x in fact determines the 15 retransmission capability of the server S. The number of connection breaks able to be corrected becomes greater as the size of the buffer memory becomes greater. By way of non-limitative example, if the server S and the client terminal CT store for example 10 seconds of stream of transmitted data 20 packets and if the forward and return connection between the client terminal CT and the server S requires 2 seconds, then it is possible to correct transmission breaks of up to eight seconds without losses; - to process the requests for retransmission of packets Pk sent by the client terminals CT and to retransmit the packets still present in the 25 FIFO buffer memory situated at the level of the server terminal. In the case of a multicast transmission of the packets still present in the aforementioned buffer memory, if several terminals CT re-request the same packet, the server can retransmit the data in multicast mode instead of retransmitting it for each client terminal CT. 30 The aforementioned operating procedure is shown in Figure 2b where M 3 represents the module for the reception and processing of the requests for retransmission of data packets, constituted by a packet repetition manager, in the form of adapted software. The aforementioned module M 3 controls in particular the buffer memory M 2 x for reading the continuity index of the packets or, if appropriate, the 15 packets to be retransmitted themselves and also controls the packet retransmission module Mo. A more detailed description of a client terminal which is a subject of the invention and adapted for the reception of streams of data in packets in an IP network 5 accompanied by stream continuity signalling data transmitted by a server S such as shown in Figures 2a and 2b will now be given with reference to Figures 3a and 3b. As shown in Figure 3a, the client terminal CT according to the invention comprises in a conventional manner an input/output unit 1/0 connected to a central processing unit CPU which controls a program memory M'o making it possible to 10 manage the data exchanges between any client terminal CT and any terminal or server connected to the IP network. The terminal CT according to the invention moreover comprises, in a particularly advantageous manner, a module M', for detecting stream breaks by analysis of the continuity signally data, the aforementioned module M', operating as 15 described previously in the description with reference to Figure 1, in Steps G and J. This module can be constituted by a software module executed by the central processing unit CPU. It comprises moreover a module M' 2 x for the storage of a series of a number of successive data packets received for at least one specified data stream. The 20 module M' 2 x constitutes the buffer memory of the FIFO type previously described in the description and used in Step E of Figure 1. It also comprises, as shown in the same Figure 3a, a module M' 3 for the transmission of requests for retransmission of data packets to a specific address, to the address of the server @S previously described in the description. The module M' 3 25 makes it possible to construct the retransmission request messages RR (Ckr, @CT) previously described with reference to Figure 1. Finally, the client terminal CT which is a subject of the invention comprises a module M' 4 for the resequencing of the packets received in the module

M'

2 x for storing the series of a number of successive data packets received, taking 30 account of the packets transmitted by retransmission. According to a noteworthy aspect of the client terminal CT which is a subject of the invention, the module M' 3 for the transmission of retransmission requests operates according to the UDP/IlP protocol in order to ensure the transmission of the aforementioned retransmission requests.

16 The operating procedure of the client terminal CT will now be described with reference to Figure 3b. The purpose of the client terminal CT is: - to detect breaks in the stream by analysing the continuity indices as 5 described with reference to Figure 1 in Step G; - to send repetition requests to the address specified in the stream, i.e. to the address @S previously described with reference to Figure 1. These repetition requests advantageously use the UDP/IP protocol and, as this protocol does not ensure the correct reception of the requests, the latter 10 must be repeated until the reception of the requested packets or the obsolescence of the missing data. The repetition frequency of the retransmission requests can therefore be determined according to the type of network and to the intrinsic qualities of the latter; - to store in the buffer memory the data, i.e. the successive packets Rk 15 received by the client terminal and their continuity indices in order to ensure the continuity of the stream in real time. After a break in the transmission of the data stream, the buffer memory used at the level of the client terminal CT is rapidly reconstituted, with a data rate very much higher than that which is strictly useful for 20 routing the data packets without error; - to resequence the packets received in the buffer memory because the repeated packets are received with a delay. In the case of multiple repetitions, the client terminal CT must moreover delete the packets already received. 25 A diagram representing the operating procedure of the client terminal CT is shown in Figure 3b where the modules M', and M' 4 constituted by software modules make it possible to ensure the analysis of the continuity of the, stream. The aforementioned modules make it possible to reorganise the succession of packets stored in the storage module M' 2 x and of course to control the repetition requests 30 using the module M' 3 . For the implementation of the method of the server S and of the client terminal CT, which are subjects of the present invention, as described previously in the description, it is stated that the latter become more efficient as the transmission network of the IP type supports data rates that become higher, at least momentarily, 17 than the data rates used for the transport of the data packets Pk for the purpose of retransmitting the lost packets before the FIFO buffer memory of the client terminal CT becomes empty. Moreover, the delay induced by the installation of the buffer memory, at 5 the level of the server S and the client terminal CT, is equalized with the delay of the buffer memory used for absorbing the jitter of the IP transmission network. If the size of the buffer memory of the server S is specified in the data transmission stream which, according to the invention, is produced, and in particular adaptively, the client terminal CT is then able to adapt the size of its buffer memory to 10 a substantially identical size or, if appropriate, a slightly smaller size, in order to take account of the retransmission of the non-received data packets delay. The client terminal CT can then automatically adapt to the types of data streams received. On detecting, in the transmitted stream of data packets, information identifying the source of repetition, i.e. the server S for example, the aforementioned 15 client terminal CT automatically activates the lost packets repetition option. Otherwise, in the contrary case, the latter then adopts the operation using the standard DCP protocol. A more detailed description of an information message, for the transmission of data in packets in an IP network between the server S and a client 20 terminal CT previously described in the description, will now be given with reference to Figure 4a. With reference to the aforementioned Figure 4a, it is stated that the information message allowing the transmission of continuity of the data stream information is formed by a DCP tag such as shown in Figure 4a for example. 25 The aforementioned tag comprises at least one tag name in a leading field which has to be encoded in 4 bytes, "AUDP" for example, this name corresponding to an obligatory field of the DCP standard. The DCP tag must moreover comprise, as shown in the drawings of Figure 4a, a tag length field which gives the length of the tag in bits. The tag has a 30 constant length of 64 bits according to the obligatory field of the aforementioned DCP standard. Moreover, the tag also comprises a UDP port number to which is transmitted the requests for retransmission of packets whose transmission discontinuity has been detected. This port number, called PORT in Figure 4a, can be 18 encoded in 16 bits for example. The tag comprises moreover a field for the IP address to which the packet retransmission requests are sent. This address, called "IP SERVER", can be encoded in 32 bits and corresponds to the IP address to which the packet retransmission 5 requests are sent. This address can be different from that of the server S from which the stream comes. Finally, as shown in Figure 4a, the aforementioned tag comprises a field encoded in 16 bits representing the size of the FIFO memory. The size of the FIFO memory can be defined by the number of frames available. The frame type can be 10 PFT or AF depending on the chosen transmission mode, according to the provisions of the DCP standard. The use of a DCP tag makes it possible to make the transmitted data stream compatible with client terminals CT which do not take charge of the lost packets retransmission request. 15 In order to increase the efficiency of implementation of the method, and of course of the server S and of any terminal CT according to the invention, the signalling in the stream can advantageously contain the memory size of the buffer memory used on the server S side. This makes it possible to avoid requests for the repetition of data which is no longer present in the buffer memory. It is understood in 20 particular that, on the basis of a substantially identical buffer memory size in both of the buffer memories implementing Steps C and E of the method as shown in Figure 1, it is thus possible to discriminate the packets Pk, and of course their continuity indices, which are no longer present in the buffer memory. Finally, in order to limit the data rate necessary for the implementation of 25 the method according to the invention, it is possible for this information not to be present in each stream packet. However, and according to a noteworthy aspect of the method according to the invention, this data is then present at a sufficient frequency for the client terminal CT to be able to use it rapidly. In a variant implementation, the same method can be applied to the 30 RTP/IP protocol. The information sent by the server to allow clients to make repetition requests will be included in the RTP headers in the format provided by this protocol. The information to be included is: - the IP address and the port to which the repetition requests are to be sent - the size of the FIFO on the server side.

19 The continuity index used on the client side for detecting the breaks is the 16-bit "sequence number" field of the RTP header as provided in the standard. The identification of the packets to be repeated is carried out by using the "sequence number" field of the RTP header. The repetition request messages sent from the client 5 terminal to the server terminal therefore then contain the following data: - the IP address and the port to which the packets to be repeated must be sent, - the identifier of the first packet of the break: value in 16 bits of the "sequence number" field. 10 - the number of packets lost in the break (encoded in 16 bits). Similarly, a more detailed description of a request for the retransmission of packets RR (Ckr, @CT) will now be given with reference to Figure 4b. With reference to the aforementioned figure, any request for the retransmission of packets transmitted by a client terminal CT to a server S for the 15 transmission of data in packets in an IP network according to the invention, is noteworthy in that such a request contains at least one identification of the data packet or packets to be retransmitted, in particular the continuity index of the first lost packet, when, in particular, this index is calculated on the basis of the increasing monotonic function previously mentioned in the description, the number of packets to 20 be repeated on the basis of this index and, of course, the address to which the packets in question must be sent, i.e. the address of the client terminal CT which is requesting the repetition. It is of course understood that the previously mentioned fields of the retransmission request are not the only ones, the method, the server S and the client 25 terminal CT which are subjects of the present invention being able to be used in a particularly advantageous manner under the following conditions. In fact, the source of retransmission of packets can be different from the initial server S. For example, in the case of a monodirectional broadcast of the stream, 30 such as that carried out by one satellite or another for example, it is possible to specify the address of a secondary server in the network, which is then in charge of distributing the lost frames, for example via a switched telephone network STN, an integrated services digital network ISDN or, finally, by any type of network for example.

20 The client terminal CT, when the latter has detected the loss of one or more packets Pkr, must then send a repetition request to the server S. This repetition request must then contain at least the aforementioned two types of information and the packet can be structured as follows: 5 - packet or tag: name of the tag, the name of the tag encoded in 4 bytes for example and, in the case of Figure 4b, AREP as a non-limitative example; - length of the packet: the packet has a variable length of 80, 104 or 132 bits depending on the chosen transmission mode; 10 - PORT: encoded in 6 bits, the number of the port where the repetition must be carried out; - IP client: encoded in 32 bits, the IP number where the repetition must be carried out, i.e. definitively the address @CT of the client terminal; - PFT: field encoded in 1 bit, a flag used for signalling that the PFT 15 mode with fragmentation is used and that the index field F is therefore present; - address field Addr: encoded in 1 bit, a flag used for signalling that addressing is used and that the PFT destination field and PFT Dest are present. This option is usable only if the PFT field is valid, flag value 20 PFT = 1, the addressing being linked with the PFT; - Number of fragments field, NbFrag, encoded in 14 bits AF or PF depending on the repetition mode on the basis of the continuity index defined by the SEQ and Findex fields. For example, if the number of fragments NbFrag = 3 and if PsEQ = 50, the packets Pk of rank k = 50, 25 51 to 52 must be repeated; - SEQ field encoded in 16 bits, this champ corresponds with the SEQ field of the packet AF to be repeated if the PFT field has the value 0. If the PFT field has the value 1, the SEQ field corresponds to the PsEQ field of the packet PF to be repeated. The SEQ field is therefore a part 30 used for the identification of the stream containing the packets to be repeated; - Findex field: a field encoded in 24 bits. This field is optional. It is present only if the PFT field has the value 1. This field contains the value of the Findex field of the packet PF to be repeated. It is used for 21 the identification of the first packet to be repeated; - PFT Dest: a field encoded in 16 bits. This field is also optional. It is present only if the Addr field is equal to 1. The PFT Dest field contains the value of the Dest field of the PFT addressing of the packet to be 5 repeated. This field is used for the identification of the first packet to be repeated; - PFT Src field encoded in 16 bits. This field is optional. It is present only if the Addr field has the value 1. The PFT Src field contains the value of the Src field of the PFT addressing of the packet to be 10 repeated. This champ is used for the identification of the first packet to be repeated. Finally, the invention relates to a computer program encoded in a monolithic or modular manner and stored on a storage medium of a computer or of a dedicated device constitutive of a server for the transmission/reception of data in 15 packets in an IP network between this server and a client terminal. The computer program according to the invention is noteworthy in that, during its execution, this computer program executes the steps of assignation of a transmission continuity index to each packet to be transmitted and the successive transmission of each of the packets and their continuity indices to the client terminal, 20 as described previously in the description with reference to Figure 1. The invention also relates to a computer program encoded in monolithic or modular form and stored on a storage medium of a computer constitutive of a client terminal for the transmission/reception of data in packets in an IP network between this client terminal and a server. 25 This computer program is noteworthy in that, during its execution, this computer program executes the steps of detection of any break in continuity of the stream of packets received on the basis of the continuity indices associated with each packet received, and, on detection of a stream discontinuity, the transmission from the client terminal to the aforementioned server of at least one request for the 30 retransmission of at least one missing packet, as long as this missing packet or these missing packets have not been received by the client terminal.

Claims

1. Method for the real-time transmission/reception of data in packets in an IP network between a server and a client terminal, characterized in that it 5 consists at least of, on the server side: - assigning a transmission continuity index to each packet to be transmitted; - successively transmitting each of the packets according to the UDP protocol and their continuity index according to the DCP or RTP protocol to said 10 client terminal; and, on the client terminal side: - detecting any break in the continuity of the stream of packets received on the basis of the continuity indices associated with each packet received; and, on detection of a stream discontinuity, 15 - transmitting, from the client terminal to the server, at least one request for the retransmission of at least one missing packet, for as long as said at least one missing packet has not been received by said client terminal.

2. Method according to claim 1, characterized in that it consists moreover, on the 20 client terminal and server side, of continuously storing a same plurality of successive packets, to be transmitted and received respectively, accompanied by their continuity index.

3. Method according to claim 1, characterized in that the step of detection of any 25 continuity break is carried out by analysis of the DCP or RTP stream alone.

4. Method according to one of the claims 2 to 3, characterized in that said step consisting of continuously storing consists of storing each packet of said plurality of successive packets in a buffer memory of the FIFO type. 30

5. Method according to claim 4, characterized in that the size of said FIFO memory in number of packets is a function of the transmission parameters of the transmission network of the packets. 23

6. Method according to claim 5, characterized in that the size of said FIFO memory is adaptive, which makes it possible to optimize the compensation of transmission breaks to within the forward and return transmission time between the client terminal and the server. 5

7. Method according to one of the claims 1 to 6, characterized in that the transmission of said continuity indices is carried out by transmission at specified intervals of a DCP tag containing information including at least the destination address of any request for the retransmission of packets and the size 10 of the buffer memory for storing said plurality of successive packets.

8. Method according to one of the claims 1 to 6, characterized in that the transmission of said continuity indices is carried out by transmission of an extension of the RTP header. 15

9. Method according to one of claims 1 to 7, characterized in that said step consisting of transmitting, from client terminal to the server, a request for the retransmission of at least one packet is executed according to the UDP/IP protocol. 20

10. Method according to claim 8, characterized in that each retransmission request includes at least: - the identifier of the packet or packets to be retransmitted; - the destination address of the packet or packets to be retransmitted. 25

11. Method according to one of the claims 1 to 9, characterized in that the step consisting of successively transmitting each of the packets is carried out by transmission in unicast or multicast mode. 30

12. Server for the transmission/reception of data in packets in ai IP network, between this server and a client terminal, characterized in that said server comprises at least, in addition to the means for transmitting data packets constitutive of at least one transmission stream, - means for generating and transmitting data signalling continuity of the 24 transmitted data packets; - means of storage of a series of a number of successive data packets sent for at least one stream of transmitted data, said storage means being constituted by a buffer memory whose size defines the retransmission capability of the server in 5 number of data packets and in duration of retransmission; - means of reception and processing requests for retransmission of data packets still present in the means of storage of the series of a number of successive data packets, said reception and processing means controlling said means of transmission in unicast or multicast mode and said means of generating and 10 transmitting signalling data in DCP or RTP mode.

13. Client terminal adapted for the transmission/reception of streams of data in packets in an IP network, accompanied by stream continuity signalling data, transmitted by a server, characterized in that said client terminal comprises 15 moreover: - means of detection of the stream breaks by analysis of the continuity signalling data; - means of storage of a series of a number of successive data packets received for at least one data stream; 20 - means of transmission of requests for the retransmission of data packets to a specific address, said means of transmission of retransmission requests operating according to the UDP/IP protocol; - means of resequencing the packets received in said means of storage of a series of a number of successive data packets received, taking account of the 25 packets transmitted by retransmission.

14. Information message for the transmission of data in packets in an IP network between a server and a client terminal, characterized in that said information message is formed by a DCP tag or by an extension of the RTP header, 30 comprising at least: - a UDP port number to which the requests for retransmission of packets whose transmission discontinuity has been detected are to be transmitted; - an IP address to which the retransmission requests are to be transmitted; - the size of the buffer memory in number of stored successively transmitted 25 frames/packets.

15. Request for the retransmission of packets transmitted by a client terminal to a server for the transmission of data in packets in an IP network, characterized in 5 that said request contains at least: - an identification of the data packet or packets to be retransmitted; - the address to which said packet or packets must be sent.

16. Computer program stored on a storage medium of a computer or a dedicated 10 device constitutive of a server for the transmission/reception of data in packets in an IP network between this server and a client terminal, characterized in that, during the execution of its instructions, said computer program executes the steps of assignment of a transmission continuity index to each packet to be transmitted and of successive transmission of each of the packets and their 15 continuity indices to this client terminal according to one of claims I to 11.

17. Computer program stored on a storage medium of a computer constitutive of a client terminal for the transmission/reception of data in packets in an IP network between this client terminal and a server, characterized in that, during 20 its execution, said computer program executes the steps of detection of any break in continuity of the stream of packets received on the basis of their received continuity index, and, on detection of a stream discontinuity, the transmission from the client terminal to said server of at least one request for retransmission of at least one missing packet, as long as this or these missing 25 packets have not been received by this client terminal.