Patent Description:
This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present disclosure that are described and/or claimed below.

TCP (Transmission Control Protocol) is a network communication protocol designed to send data packets over the Internet Protocol (IP). It provides a reliable delivery for almost all the applications used over Internet, including the Web applications, File Transfer Protocol applications, Secure Shell applications, peer-to-peer file sharing, and even streaming media applications.

While TCP has been designed with an objective of accuracy rather than timely delivery, it has been largely used for video streaming, notably with the adoption of HTTP Adaptive Streaming (HAS).

In particular, HTTP adaptive video streaming technologies are pushed by various stakeholders to allow provision of over the top audiovisual delivery in the Internet. Such technologies allow a client device to receive video in the form of small successive segments (a few seconds long), so called chunk. Each segment is requested through the HTTP protocol and may exist in different variants (so called representations, for adaptive streaming protocols), allowing the client device to choose at any time an appropriate bit rate matching the network and device constraints.

In video streaming, the client device plays a central role by controlling video adaptation, since HTTP is a stateless protocol. It allows to deploy legacy HTTP servers and caches instead of specialized streaming equipment. HTTP-based delivery prevents from NAT (Network Address Translation) and firewall traversal issues.

As a reliable stream delivery service, the TCP protocol guarantees that all the received bytes will be identical to the bytes sent and in correct order. When sending a data packet (called segment in the TCP terminology), the transmitted data is put into a retransmission queue and timers associated with the data packets are triggered. When no acknowledgment for a segment is received before the timer runs out, a retransmission occurs, i.e. the segment is retransmitted up to its acknowledgement by the client device or until a (long) timeout expires (in that case, the connection is considered broken and will be closed).

Nevertheless, such a behavior can be inappropriate when delivered data have real time constraints (which is the case in video streaming). Indeed, a video segment has no reason to be delivered anymore when the time for processing and rendering at the destination application is exceeded.

The present disclosure has been devised with the foregoing in mind.

<CIT> discloses a method and a device for real time communication between two communication devices over an internet protocol.

XP055097789 is a paper titled "TECHNIQUES AND PROTOCOLS FOR DISTRIBUTED MEDIA STREAMING" and discloses techniques and protocols for distributed media streaming.

<CIT> discloses a method and system for quality service enhancement in networks for media streaming.

According to one or more embodiments, there is provided a network equipment configured to be in communication with a device through a network for delivering data packets according to independent claim <NUM> and a method to be implemented at a network equipment configured to be in communication with a device through a network for delivering data packets, according to independent claim <NUM>. Further embodiments of the network equipment and the method are provided in dependent claims <NUM>-<NUM>.

According to one or more embodiments, there is provided a computer program product at least one of downloadable from a communication network and recorded on a non-transitory computer readable medium readable by at least one of computer and executable by a processor, comprising program code instructions for performing a method to be implemented at a network equipment configured to be in communication with a device through a network for delivering data packets according to independent claim <NUM>.

According to one or more embodiments, there is provided a non-transitory program storage device, readable by a computer, tangibly embodying a program of instructions executable by the computer to perform a method to be implemented at a network equipment configured to be in communication with a device through a network for delivering data packets according to independent claim <NUM>.

The methods according to the one or more embodiments may be implemented in software on a programmable apparatus. They may be implemented solely in hardware or in software, or in a combination thereof.

Some processes implemented by elements of the one or more embodiments may be computer implemented. Accordingly, such elements may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as "circuit", "module" or "system". Furthermore, such elements may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since elements can be implemented in software, some aspects of the embodiments can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like.

The one or more embodiments thus provide a computer-readable program comprising computer-executable instructions to enable a computer to perform above mentioned methods.

Certain aspects commensurate in scope with the disclosed embodiments are set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of certain forms the one or more embodiments might take and that these aspects are not intended to limit the scope of the disclosure. Indeed, the disclosure may encompass a variety of aspects that may not be set forth below.

The disclosure will be better understood and illustrated by means of the following embodiments and execution examples, in no way limitative, with reference to the appended figures on which:.

Wherever possible, the same reference numerals will be used throughout the figures to refer to the same or like parts.

The following description illustrates some embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody some aspects of the embodiments and are included within their scope.

All examples and conditional language recited herein are intended for educational purposes to aid the reader in understanding the embodiments and are to be construed as being without limitation to such specifically recited examples and conditions.

Moreover, all statements herein reciting embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative circuitry embodying some aspects of the embodiments. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, read only memory (ROM) for storing software, random access memory (RAM), and nonvolatile storage.

In the claims hereof, any element expressed as a means and/or module for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

In addition, it is to be understood that the figures and descriptions of the present disclosure have been simplified to illustrate elements that are relevant for a clear understanding of the present embodiments, while eliminating, for purposes of clarity, many other elements found in typical digital multimedia content delivery methods, devices and systems. However, because such elements are well known in the art, a detailed discussion of such elements is not provided herein. Embodiments herein are directed to all such variations and modifications known to those skilled in the art.

Embodiments are depicted with regard to a streaming environment (such as adaptive streaming technologies) to deliver a multimedia content (such as video) to a client device through a delivery network. It should be naturally understood that the implementation of such embodiments is not limited to a streaming environment.

As shown in the exemplary embodiment of <FIG>, a Client-Server network architecture, including a first network <NUM> (e.g. a home network, an enterprise network) and a second network <NUM> (e.g. a broadband network such as the Internet), comprises a client device <NUM> in communication with a gateway <NUM> and network equipment <NUM> such as content servers (in <FIG>, three servers are represented). The first network <NUM> is for instance connected to the second network <NUM> through the gateway <NUM>.

The client device <NUM> - which is for instance a streaming client device connected to the gateway <NUM> through the network <NUM> (as a home network or an enterprise network) - wishes to connect to a server <NUM> (e.g. an HTTP server) through the broadband network <NUM> in order to launch a streaming session for retrieving a multimedia content from the Internet <NUM>. Once the connection is established with the client device <NUM>, the server <NUM> streams segments to the client device <NUM>, upon requests, using a streaming protocol over, for instance, one or more TCP/IP connections. According to the TCP terminology, a data packet is called segment.

As shown in the example of <FIG>, in one embodiment, a client device <NUM> of the first network <NUM> can comprise at least:.

As an example, the client device <NUM> is a portable media device, a mobile phone, a tablet or a laptop, a head mounted device, a TV set, a set-top box or the like. Naturally, the client device <NUM> might not comprise a complete video player, but only some sub-elements such as the ones for demultiplexing and decoding the media content and might rely upon an external means to display the decoded content to the end user.

Besides, in an embodiment, the gateway <NUM> can be, for instance, a Digital Subscriber Line (DSL) gateway, providing an Internet broadband access to the local network <NUM> through the DSL technology. Of course, the gateway could be any type of broadband gateway such as cable, fiber or wireless.

As shown in the example of <FIG>, a network equipment <NUM> can comprise at least:.

In the example of <FIG>, the timeline for the sequence of exchanged segments during a TCP connection establishment is the following:.

The client <NUM> and the server <NUM> maintain their own <NUM>-bit sequence number (randomly initialized) used to keep track of the amount of data they have sent. This sequence number is embedded on every transmitted segment and is acknowledged by the opposite host as an acknowledgement number to inform the sending host that the transmitted data was received successfully. The sequence number is incremented by one at each transmitted byte.

Every TCP segment comprises a TCP header specifying the sequence number (hereinafter noted SN) associated with the first byte of its payload (so called data block or data segment). Segments also carry an acknowledgment number which is the sequence number of the next expected data octet to be delivered in the reverse direction.

In the following, for clarity reasons, it is assumed that x = <NUM> and y = <NUM> so that, when a connection is established, the sequence numbers SN1 and SN2 respectively associated with the client device <NUM> and the server <NUM> are equal to <NUM> (i.e. SN1 = <NUM> and SN2 = <NUM>).

Besides, <FIG> shows an exemplary sequence of segments exchanged between the server <NUM> and the client <NUM> along a TCP connection, every segment being correctly received and acknowledged with ACK segments. According to the TCP protocol, the ACK segments are cumulative, i.e. they acknowledge that the receiver (in the example, the client <NUM>) has correctly received all bytes up to the acknowledged sequence number mentioned in the ACK minus one.

The example of <FIG> further depicts the case wherein one segment (the segment with associated sequence number equal to <NUM>) sent by the server <NUM> does not reach the client device <NUM>. According to RFC <NUM>, the receiver (i.e. the client <NUM>) sends an immediate duplicated ACK segment (i.e. the same ACK used for acknowledging a previously received segment) when an out-of-order segment arrives. This duplicated ACK segment is used to inform the sender (i.e. the server <NUM>) that a segment was received out-of-order and which sequence number is expected.

In <FIG>, the server <NUM>, being not aware that something is wrong, sends segments belonging to a sliding window defined hereinafter. The client <NUM> receives a segment with a discontinuity in sequence number (i.e. segment with SN = <NUM>) and then generates a duplicated ACK segment (comprising the sequence number <NUM> acknowledging the first received segment). When the server <NUM> has received three duplicated ACK segments for the sequence number equal to <NUM>, it retransmits the segments following this sequence number. According to TCP paradigm, while a segment is not acknowledged, the sender will try to retransmit it.

It should be noted that the duplication of ACK segments is not the only way to manage the loss of segments and their subsequent retransmissions (for instance, a timeout can also be implemented).

Further to a limitation by available bandwidth on the communication path, the maximum achievable throughput for a single TCP connection is determined by a flow control called sliding window protocol, allowing the sender to transmit multiple segments before stopping and waiting for an acknowledgement.

The TCP sliding window protocol relies on two different variables:.

The sender can transmit up to the minimum of the congestion window and the advertised receiver window.

In particular, the congestion window is maintained by the source (e.g. the server <NUM>) and determines the amount of data that can be transmitted to avoid congestion in the network. When a new connection is established with a host on another network (congestion can occur with routers or links with different bit rates on the path between the two endpoints), the congestion window is initialized at a value depending on the largest segment the sender can transmit (such a value is typically around <NUM> bytes as specified in the slow start strategy of RFC <NUM>). Each time an ACK segment is received, the congestion window is increased by one segment. The slow start algorithm is used when the congestion window size is under a certain threshold, while the congestion avoidance algorithm is used otherwise. During congestion avoidance, the congestion window size is incremented by roughly one full-sized segment per round-trip time (RTT). Congestion avoidance continues until a congestion is detected.

An exemplary evolution of a sliding window <NUM> is depicted in <FIG>. The window (rwnd) offered by the receiver can accept <NUM> bytes. At a time t1, the sliding window <NUM> covers bytes <NUM> through <NUM> (i.e. the sender has transmitted bytes <NUM> to <NUM> and the receiver has already acknowledged the reception of the first three bytes). Over time, the sliding window <NUM> moves (to the right in <FIG>), as the receiver acknowledges data. At time t2, bytes <NUM> and <NUM> are received but not acknowledged yet by the receiver, so that the left edge of the sliding window <NUM> moves to the right (in TCP terminology, the window closes). While those bytes are in the reception buffer, the receiver reduces its window size to <NUM> bytes. Once the bytes <NUM> and <NUM> have been read by the application at the receiver side, freeing up space in the TCP receiver buffer, the receiver may announce a window of <NUM> bytes at time t3 (in TCP terminology, the window opens), i.e. the right edge of the sliding window <NUM> moves to the right.

When the left edge reaches the right edge of the sliding window <NUM> (called a zero window), the sender stops delivering any data.

In the example of <FIG> representing a sequence of segments (data segments and ACK segments) of the data transfer previously described in relation to <FIG>, the first line is a temporal representation of the data segments <NUM> to <NUM> sent or to be sent by a sender Tx (such as the server <NUM>). The second line shows the acknowledgments positioned as they are received by the sender Tx from the receiver Rx (e.g. the client device <NUM>). The Announced Receiver Window corresponds to the current receiver window <NUM> and is aligned with the sequence of segments to be transmitted at time t0.

In <FIG>, the acknowledgment <NUM> of received segments implements the Selective Acknowledgment (SACK) scheme as defined in RFC <NUM> (TCP Selective Acknowledgment Options) for improving performance when multiple segments are lost from one TCP sliding window of data. According to the Selective Acknowledgment scheme, the receiver can acknowledge segments received out of order. The receiver can then inform the sender about all segments that have been received successfully, so the sender needs to retransmit only the segments that have actually been lost (instead of everything from the first missing segment). The Selective Acknowledgement scheme is implemented in the form of an option in TCP protocol comprising a list of the blocks of a contiguous sequence space occupied by data that have been received and queued. According to the TCP terminology, a SACK is an ACK with SACK option providing two types of information:.

For the sake of explanation, it is considered in the example of <FIG> that all segments <NUM> to <NUM> have the same size of <NUM> bytes and that the receiver maintains its window <NUM> at a size of <NUM> bytes (i.e. corresponding to four segments). The receiver window (rwnd) size is embedded in the TCP header of the acknowledgement segment, so that every ACK (or SACK) segment is transmitted by the receiver with a Window Size field set to <NUM> bytes. Consequently, the sliding window <NUM> moves to the right at each reception of a SACK acknowledging the first segment of the window.

It should be understood that maintaining the receiver window size at a constant value means that the reception of a segment from the network and the transmission of said received segment to an upper layer (or application) is performed at a same rate, in the TCP layer implemented at the receiver.

In <FIG>, the sender Tx wishes to send Segment <NUM> to Segment <NUM> (<NUM> to <NUM>) to the receiver Rx announcing a receiver window of <NUM> bytes size. A time t0, the sender Tx delivers the Segment <NUM> to Segment <NUM>. The receiver acknowledges reception of each of these segments (when received) with a cumulative ACK specifying the sequence number of the received segment plus one. Segment <NUM> cannot be transmitted while Segment <NUM> has not been acknowledged by the receiver, according to the sliding window mechanism. When Segment <NUM> is acknowledged at time t1, the sliding window <NUM> moves to the right allowing the transmission by the sender Tx of Segment <NUM>. This scheme is repeated when delivered segments are properly acknowledged.

The example illustrated in <FIG> is similar to the one shown in <FIG> except that the Segment <NUM> (<NUM>) is not acknowledged by the receiver Rx, Segment <NUM> never reaching the receiver Rx. The sliding window <NUM> is then blocked at position <NUM> (wherein Segments <NUM> to <NUM> are delivered by the sender Tx) and, consequently, Segment <NUM> cannot be sent. Once segments <NUM>, <NUM> and <NUM> (<NUM> to <NUM>) have been sent and acknowledged with an ACK with a SACK option (<NUM>), the data transfer from the sender Tx is here reduced to the retransmission of Segment <NUM>. When the data stream defined by the sequence of Segments <NUM> to <NUM> (<NUM> to <NUM>) is dedicated to a real time application (such as video streaming), the data transfer can be blocked or dramatically reduced in order to attempt to deliver a segment (in the example, Segment <NUM>) which will never be used by the application if it arrives too late.

In an embodiment, to overcome such a situation, a method <NUM> as shown in <FIG> is implemented at the server <NUM> in communication with the device <NUM> through the network <NUM>, for instance during a streaming session for delivering a multimedia content (such as a video content and/or an audio content) split into segments. In the illustrative example of a TCP connection, every segment notably comprises a TCP header and a TCP data field (i.e. a payload) and carries a sequence number (the data bytes being delivered by the TCP layer according to their sequence number).

In a step <NUM>, an expiration time for the initial payload of each data segment <NUM>,. , <NUM> to be delivered to the device is obtained by the server <NUM> (e.g. thanks to its processor(s) <NUM> and/or its streaming controller <NUM>). By implementing such an expiration time for the initial payload of each segment conveying data of the multimedia content, one can prevent the server <NUM> from using resources to send useless data (i.e. data which will never be used by the client device <NUM>).

For every segment i to be delivered to the client device <NUM>, the server <NUM> determines a decoding time Ti at the client side. When the multimedia content to deliver is a video or audio file, a series of compressed data (video or sound) are stored with associated decoding time in the video or audio file, so that the segmentation of the multimedia content by the server <NUM> implies to be audio or video coding aware. In that case, knowing the decoding time of the first frame (or picture) or audio sample, the server <NUM> is able to determine the decoding time of all the other frames or samples. In certain file formats, the decoding time of a frame or an audio sample is provided, for instance in the form of a timestamp.

In an embodiment, as shown in <FIG>, the expiration time t<NUM>,EX of the initial payload <NUM> of a segment (and more particularly to the first sample of the segment) to be delivered is obtained as follows: <MAT> wherein:.

From the determined expiration time t<NUM>,EX of the initial payload of a segment, the server <NUM> can derive the expiration time for the ith sample of the content of said segment as follows: <MAT> wherein SP corresponds to the Sample Period (i.e. the frame period in case of video; or the audio sample for sound).

It should be understood that the expiration time of the initial payload of a segment corresponds to the expiration time of the first video frame or the first audio sample to be processed of that segment.

In a step <NUM>, the server <NUM> starts delivering (e.g. via streaming controller <NUM> and/or communication circuitry <NUM> and/or its processor(s) <NUM>) to the client device <NUM> segments belonging to a sliding window <NUM> as defined above. A new specific header <NUM> is added to the payload of every segment delivered by the server <NUM>. The specific header <NUM> (e.g. arranged at the beginning of the payload) comprises a length of the payload of the segment and a segment number. The length field of the specific header allows an application layer to locate the position of the next segment (which can be needed since the segment length is known by the TCP stack but cannot be made accessible to an upper application layer). The segment number allows to reorder data before processing.

In a step <NUM>, the server <NUM> (e.g. via its streaming controller <NUM> and/or processor <NUM>) determines that the expiration time of the initial payload of a segment belonging to the sliding window <NUM> is reached without reception of a corresponding acknowledgment from the device <NUM>.

In a step <NUM>, when the expiration time of the initial payload of a segment belonging to the sliding window <NUM> is reached without reception of a corresponding acknowledgment from the device <NUM>, the server <NUM> resends said non-acknowledged segment with a new payload corresponding to the initial payload of the next segment to be transmitted through the sliding window <NUM>. The sequence number associated with the resent segment remains unchanged, only the initial payload is modified.

It should be noted that the next segment to be transmitted through the sliding window is not necessarily the segment adjacent to the sliding window <NUM> (especially when the content of said adjacent segment is also obsolete, i.e. the expiration time of the initial payload of this segment is reached). In addition, in another embodiment, when the length of the payload differs between segments (i.e. the length of the payload is not constant and identical for every segment), the new payload of the non-acknowledged segment can comprise the initial payloads of several next segments to be transmitted through the sliding window (e.g. the sum of the lengths of the initial payloads of next segments to be transmitted is equal to the length of the initial payload of the non-acknowledged segment). In a variant, the new payload of the non-acknowledged segment can comprise a part of the initial payload of a next segment to be transmitted through the sliding window, when the initial payload of the next segment exceeds the initial payload of the non-acknowledged segment.

To that end, the server <NUM> can further check whether the new payload replacing the initial payload of the non-acknowledged segment (i.e. Segment <NUM> in the example of <FIG>) is obsolete (i.e. the associated expiration time is reached). In case the new considered payload is also expired, the server <NUM> will consider the initial payload of a next segment, for instance adjacent to the segment embedding the considered payload, also expired.

As shown in <FIG>, TCP providing reliable, ordered, and error-checked delivery of a stream of bytes between applications running on hosts communicating via an IP network, once the non-acknowledged segment embedding the new payload has been received, the TCP layer delivers to the upper layer the segments of the sliding window <NUM> in the segment order as those segments are seen as a contiguous series of data. The upper layer will be informed that the non-acknowledged segment needs to be reordered before processing, thanks to the added specific header of the payload.

Besides, the subsequent segments of the sequence of segments conveying the multimedia content which are not yet delivered through the sliding window <NUM> will also have their initial payload transferred to a previous segment (not yet transmitted) in the sequence order. Their initial payload will be further replaced, for instance, by the payload of a next adjacent segment to be transmitted in the sequence order. Nevertheless, the sequence number of the segments for which the initial payload is replaced remains unchanged.

In the example of <FIG> similar to the one of <FIG> except that the method <NUM> is now implemented at the server <NUM>, the sliding window <NUM> is blocked in position <NUM> due to the absence of acknowledgment by the device <NUM> of Segment <NUM> (associated with the sequence number <NUM>) sent by the server <NUM>. In position <NUM> of the sliding window <NUM>, Segments <NUM> to <NUM> can be transmitted by the server <NUM> to the device <NUM>. At the expiration time of the initial payload of Segment <NUM>, Segments <NUM> to <NUM> (<NUM> to <NUM>) have already been transmitted and acknowledged by the device <NUM> with ACK messages comprising the SACK option. Segment <NUM> (<NUM>) cannot be sent by the server <NUM> since it is outside of the sliding window <NUM>, but will be the next segment to be transmitted through the sliding window <NUM> (once shifted in Position <NUM>).

The absence of reception of an ACK message (with SN = <NUM>) acknowledging Segment <NUM> (<NUM>) prevents the server <NUM> from updating the sliding window <NUM> to Position <NUM>. When the server <NUM> receives the acknowledgment for Segment <NUM> through an ACK (with SN = <NUM>) having the SACK option (SN = <NUM> to SN = <NUM>), it cannot update the sliding window <NUM> to Position <NUM> because of the acknowledgment of Segment <NUM> is missing. The same behavior occurs upon reception of the ACK (with SN = <NUM>) having the SACK option (SN = <NUM> to SN = <NUM>) for acknowledgment of Segment <NUM> and of the ACK (with SN = <NUM>) having the SACK option (SN = <NUM> to SN = <NUM>) for acknowledgment of Segment <NUM>.

However, thanks to the method <NUM>, the initial payload of the Segment <NUM> (<NUM>) can be sent with Segment <NUM> (<NUM>), instead of the initial payload of Segment <NUM>, now obsolete. This is transparent for the TCP layer of the client <NUM> since it does not process data within the segments. The Segment <NUM> is now seen as Segment <NUM>, i.e. a segment of <NUM> bytes numbered between <NUM> and <NUM>. The TCP header of the Segment <NUM> as modified remains unchanged (except checksum), only its initial payload is changed.

When the client device <NUM> finally receives the Segment <NUM> with the initial payload of Segment <NUM>, it acknowledges with an ACK message specifying the sequence number associated with the next expected byte (i.e. the first byte of the initial payload of Segment <NUM> corresponding to SN = <NUM>, which has already been transmitted with Segment <NUM>). Upon reception of such an ACK, the server updates the TCP window <NUM> to Position <NUM>.

Due to the change of the initial payload of Segment <NUM> with the initial payload of a Segment <NUM>, the server <NUM> continues to deliver segments through the sliding window <NUM> by replacing their initial payload. For example, the initial payload of Segment <NUM> (if not expired) is transmitted with Segment <NUM>, sequence number identified in Segment <NUM> remaining unchanged (i.e. SN = <NUM>). Similarly, the initial payload of Segment <NUM> (if not expired) is transmitted with Segment <NUM>, sequence number identified in Segment <NUM> being unchanged (i.e. SN = <NUM>).

In case the initial payload of a segment to be transferred to a previous segment in the sequence order for transmission is also obsolete, the initial payload of a next segment in the sequence order can be considered.

<FIG> shows the payloads of the received Segment <NUM> to <NUM> delivered by the TCP layer of the device <NUM> to the upper layer. As shown, the payloads are delivered according to the sequence number of their corresponding segments, so that the initial payload of Segment <NUM> transmitted by Segment <NUM> is delivered before the initial payload of Segments <NUM> to <NUM>. The segment number of the added specific header is then used by the upper layer to reorder data in a proper order as illustrated in <FIG>.

The implementation of the above described method can allow to improve the bandwidth usage by avoiding unnecessary retransmission of obsolete data, for example during a streaming session, while preserving the reliability of the network protocol (such as TCP) supporting the data delivery. The network resources are then used to deliver data which will be really used by the client devices instead of useless data. In addition, it can allow to reduce the latency when facing packet loss and/or delay in the network and to reduce the buffering size in TCP transmitter. Such an implementation remains compliant with the TCP protocol.

While the above-mentioned embodiments have been described with an implementation of a TCP connection, other appropriate network protocols might further be used.

It should also be understood that, from an application point of view, to implement the method <NUM>, the application will inform the server <NUM> that it does support non ordered data.

More generally, in an embodiment, a network equipment configured to be in communication with a device through a network for delivering data packets comprising an initial payload, comprises one or more processors configured for:.

In another embodiment, a method to be implemented at a network equipment configured to be in communication with a device through a network for delivering data packets comprising an initial payload, comprises:.

In an embodiment, the expiration time of the new payload of the resent data packet is not reached yet.

In an embodiment, when at least one data packet has been resent with a new payload, the initial payload of a subsequent packet not transmitted yet through the sliding window is transferred to one or more previous packets for delivery.

In an embodiment, each data packet being associated with a sequence number, the sequence number associated with said resent data packet remains unchanged.

In an embodiment, when the TCP protocol is implemented for transmitting the data packets, the TCP header of the resent data packet remains unchanged, except checksum.

In an embodiment, the expiration time of the initial payload of a data packet corresponds to an expiration time of a first video frame or a first audio sample to be processed of that data packet.

In an embodiment, wherein the expiration time of the initial payload of a data packet depends on a maximum time before rendering and a time of transmission of the data packet from the network equipment to the device.

In an embodiment, wherein the maximum time before rendering of a data packet depends on a maximum buffering time of the data packet at the device before processing and a decoding time.

In an embodiment, a specific header is added to the initial payload of every data packet.

In an embodiment, the specific header of a data packet comprises a length of the initial payload of the data packet and a packet number.

References disclosed in the description, the claims and the drawings may be provided independently or in any appropriate combination. Features may, where appropriate, be implemented in hardware, software, or a combination of the two.

Reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one implementation of the method and device described.

Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Although certain embodiments only of the disclosure have been described herein, it will be understood by any person skilled in the art that other modifications, variations, and possibilities of the disclosure are possible. Such modifications, variations and possibilities are therefore to be considered as falling within the scope of the disclosure and hence forming part of the disclosure as herein described and/or exemplified.

The flowchart and/or block diagrams in the Figures illustrate the configuration, operation and functionality of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, or blocks may be executed in an alternative order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of the blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. While not explicitly described, the present embodiments may be employed in any combination or sub-combination.

Claim 1:
A network equipment (<NUM>) configured to be in communication with a device (<NUM>) through a network (<NUM>, <NUM>) for delivering data packets (<NUM> to <NUM>) comprising an initial payload (<NUM>),
said network equipment (<NUM>) comprising one or more processors (<NUM>, <NUM>, <NUM>) configured for:
- obtaining (<NUM>) an expiration time (t<NUM>,EX) for the initial payload (<NUM>) of the data packets (<NUM> to <NUM>) to be delivered to the device (<NUM>),
- delivering (<NUM>) to the device (<NUM>) data packets belonging to a sliding window (<NUM>) moving according to data packet acknowledgments (<NUM>),
- when the expiration time (t<NUM>,EX) of the initial payload of a data packet (<NUM>) belonging to the sliding window (<NUM>) is reached without reception of a corresponding acknowledgment from the device, resending (<NUM>) said data packet (<NUM>) with a new payload replacing the initial payload of said data packet, said new payload corresponding to the initial payload of at least one next data packet (<NUM>) to be transmitted through the sliding window (<NUM>) when the expiration time (t0,EX) of said new payload of the resent data packet (<NUM>) is not reached yet,
wherein the expiration time (t<NUM>,EX) of the initial payload of a data packet depends on a maximum time before rendering and a time of transmission of the data packet from the network equipment to the device, said maximum time before rendering depending on a maximum buffering time of the data packet at the device before processing and a decoding time.