WO2013160042A1

WO2013160042A1 - System for packet loss recovery

Info

Publication number: WO2013160042A1
Application number: PCT/EP2013/056206
Authority: WO
Inventors: George MIKELADZE; Davit MISHELASHVILI; Levan NATROSHVILI
Original assignee: Qarva Ltd.
Priority date: 2012-04-23
Filing date: 2013-03-25
Publication date: 2013-10-31
Also published as: GB2501474A; GB201207046D0

Abstract

The application discloses a system for packet loss recovery in a streaming media connection between aa sender and receiver, including a Retransmission Server, wherein a Local Retransmission Module, being adapted to handle packet loss recovery and data prefetch for fast channel change, is provided at the receiver side, communicating with the Retransmission Server, to which a client application, running on the receiver side, is connectable to receive a corrected stream.

Description

Title: System for packet loss recovery

[0001] The present invention is directed at a system and method for packet loss recovery in a streaming media connection between a sender and receiver, as described in the preamble of the independent patent claims enclosed herewith.

[0002] It is a known problem that packet loss in a streaming media connection between a sender and receiver may significantly degrade the quality of the media received at the client, where the streamed media is being consumed. Several techniques, such as Forward Error Correction (FEC), retransmissions, or interleaving, have been considered to increase packet loss resiliency.

[0003] When choosing a repair technique for a particular application, the tolerable latency of the application has to be taken into account. In the case of multimedia conferencing, the end-to-end delay has to be at most a few hundred milliseconds in order to guarantee interactivity, which usually excludes the use of retransmission. With sufficient latency, the efficiency of the repair scheme can be increased. The sender may use the receiver feedback in order to react to losses before their play out time at the receiver.

[0004] On the other hand, in the case of multimedia streaming, the user might tolerate an initial latency as part of the session set-up and thus an end-to-end delay. However, with an increasing number of customers consuming TV or other Multimedia over networks such as the Internet, even in this area, and in particular with respect to switching channels, there is a strong desire to reduce the initial latency during session set-up and the end-to-end delay, in particular, when customers expect a Fast Channel Change (FCC), as is the usual case these days.

[0005] In order to support the largest variety of payload formats, a receiver must be able to derive how many and which packets were lost as a result of a gap in received sequence numbers. This requirement is referred to as sequence number preservation.

[0006] Without such a requirement, it would be impossible to use retransmission with payload formats, such as conversational text or most audio/video streaming applications, that use the sequence number to detect lost packets. [0007] When designing a solution for retransmission, several approaches may be considered for the multiplexing of the original packet and the retransmitted packets. One approach may be to retransmit the packet with its original sequence number and send original and retransmission packets in the same stream. The retransmission packet would then be identical to the original packet, with the same header, the same sequence number, and the same payload. Such an approach could corrupt the statistics, however, which, for example in the case of Real Time Transport Control Protocol (RTCP), require that for every RTP packet within the RTP stream, the sequence number be increased by one.

[0008] Another approach may be to multiplex original packets and retransmission packets in the same stream using different payload type values. With such an approach, the original packets and the retransmission packets would share the same sequence number space. As a result, the receiver would not be able to infer how many and which original packets and which sequence numbers were lost.

[0009] Furthermore, the original and retransmission packets may be sent in two separate streams. These two streams may be multiplexed either by sending them in two different sessions, i.e. session-multiplexing, or in the same session using different Synchronization Source (SSRC) values, i.e., SSRC-multiplexing.

[0010] Whether or not a receiver chooses to request a packet is an implementation issue. An actual receiver implementation must take into account such factors as the tolerable application delay, the network environment, and the media type. The receiver should generally assess whether the retransmitted packet would still be useful at the time it is received. The timestamp of the missing packet can be estimated from the timestamps of packets preceding and/or following the sequence number gap caused by the missing packet in the original stream. In most cases, some form of linear estimate of the timestamp is used.

[0011] Furthermore, a receiver should compute an estimate of the round-trip time (RTT) to the sender. This can be done, for example, by measuring the retransmission delay to receive a retransmission packet after a request has been sent for that packet. This estimate may also be obtained from past observations.

[0012] The receiver should not send a retransmission request as soon as it detects a missing sequence number but should add some extra delay to compensate for packet reordering. This extra delay may, for example, be based on past observations of the experienced packet reordering.

[0013] It should be noted that, in environments where packet reordering is rare or does not take place, e.g., if the underlying data link layer affords ordered delivery, the delay may be extremely low or even take the value zero. In such cases, an appropriate "reorder delay" algorithm may not actually be timer based, but packet based. For example, if a number of packets are received after a gap is detected, then it may be assumed that the packet was truly lost rather than out of order.

[0014] Furthermore, the receiver may add extra delay to group the packet retransmission requests, thus request retransmission of multiple lost packets with a single command. It helps to reduce communication overheads, especially in environments with a "stable" packet loss.

[0015] A possible implementation of a system and method for packet loss recovery in a streaming media connection between a sender and receiver is a minimal receiver implementation. With this implementation, it is possible to retransmit lost packets, detect efficiently the loss of retransmissions, and perform multiple retransmissions, if need be. With such a minimal receiver implementation most of the necessary processing is done at the server.

[0016] In this implementation example, the required receiver processing to handle retransmission is kept to a minimum. The receiver detects packet loss from the gaps observed in the received sequence numbers. It signals lost packets to the sender, while taking into account the signaled sender retransmission buffer length in order to dimension its own reception buffer. It also derives from the buffer length the maximum number of times the retransmission of a packet can be requested.

[0017] The sender then retransmits the packets selectively. It chooses whether to retransmit a requested packet depending on the packet importance, the observed Quality of Service (QoS), and congestion state of the network connection to the receiver.

[0018] Obviously, the sender processing increases with the number of receivers as information and processing load must be allocated to each receiver. [0019] The main problem with such a monolithic solution is that multimedia streaming environments, such as IPTV ecosystems, are rarely monolithic but evolve over time with different evolution speeds in different sectors.

[0020] The reality is that at some moment the decision is taken for example by a telecom operator to introduce/integrate Fast Channel Change (FCC) technology into an existing IPTV ecosystem, such as a telecom operator's ecosystem of interconnected and integrated components that form the IPTV service.

[0021] In this case the need arises to integrate set top box (STB) software, Middeware, etc. with the FCC Solution, which requires participation of the vendors of corresponding components, and software modifications, bringing with it all kinds of requirements for resources, time and cost, as everything is integrated at the lower level FCC API (library).

[0022] This does not post a problem, when IPTV is introduced into the entire network of a provider for the first time, with all the necessary integrations that take place anyway. It is much harder to achieve at a later phase, however, when some time has passed already, and a "legacy" system is in place already. In this kind of situation it is impossible sometimes to integrate Fast Channel Change at all.

[0023] Furthermore, in some cases, when the Set Top Box or the client chip is hardwired to do all the work, i.e. joining multicast, rerouting traffic from network to decoder, decoding, etc., no software modification is possible by any software developer other than the chipmaker itself, which would make any modifications, and thus any improvements regarding packet loss recovery, virtually impossible.

[0024] Accordingly, there is a need for a system and method for packet loss recovery in a streaming media connection between a sender and receiver that overcomes the above mentioned problems, which can be introduced even in legacy IPTV environments with as little effort and software modification during installation and operation as possible.

[0025] To solve the above mentioned problems, a system and method for packet loss recovery in a streaming media connection between aa sender and receiver including a Retransmission Server is proposed, wherein a Local Retransmission Module is provided at the receiver side, which can be either a software package that runs in the Set Top Box or a hardwired device to which the Set Top Box, or any other client application, may be connected.

[0026] The Local Retransmission Agent or Module according to the invention is an autonomous module that can be implemented and embedded into the client device as a software or hardware.

[0027] The Retransmission Server is a software/hardware implementation of a packet cache that can be used by the client for streaming data pre fetch and lost packet recovery. In an actual implementation, the communication between the client may be accomplished by a connection oriented protocol, such as TCP, or by other protocols, such as UDP, IP, etc.

[0028] The communication between the client Application and Local Retransmission Module may be done in many ways. In a preferred implementation a HTTP protocol and the TCP based custom text protocol is used. However, any other protocols and IPC (inter-process communications) techniques may be used for this purpose. Such communication may even be implemented without an explicit protocol, with the Local Retransmission Module tracing (on OS or IGMP level) multicast join/leave requests from a client application and consider them as implicit commands, thus providing a 100% transparent system.

[0029] The Local Retransmission Module or Agent is a transparent service, handling packet loss recovery and data prefetch for fast channel change, and sends a UDP stream to the local network/loopback interface of the Set Top Box.

[0030] The Local network/loopback interface is a local network interface (real or simulated) that resides on the STB and can be accessed by the Client Application (for example: lo, ethO, ethl ...). Because the interface is local, there is practically no packet loss, and the stream can be reliably passed from the Local Retransmission Module to the Client Application.

[0031] Accordingly, the Client Application running on the Set Top Box will be able to receive and play streams without any need to integrate an external library for packet loss recovery into the application itself, as all packet loss recovery tasks are being taken over by the Local Retransmission Agent.

[0032] Now, this new "Transparent" technology enables integration of Fast Channel Change into existing IPTV ecosystems without the problems, connected with involving vendors of existing IPTV components. It means no software modification is needed because the transparent FCC is invisible for existing software components that run on STB - they just think they are working the usual way by joining network multicasts etc.

[0033] The client software on the Set Top Box communicates with the Local Retransmission Module for example via a TCP connection using custom text based protocol, or standard HTTP protocol, which could be simply accomplished for example using JavaScript. The client can send various stream related or configuration commands to the Local Retransmission Module, such as: tune, stop etc.

[0034] The Local Retransmission Module works with the Retransmission Server, establishing a reliable TCP connection to handle lost packet recovery, and data prefetch for fast channel change.

[0035] Providing the Local Retransmission Module on the side of the receiver dramatically reduces channel change time, if data prefetch and video stream keyframe indexing (MPEG2/MPEG4-H264) implemented in the Retransmission Server is used.

[0036] The typical channel change time is about 0.4 - 0.6 seconds, wherein the actual time depends on stream bitrate and encoding options, player video decoder settings, and line bandwidth.

[0037] Summing up, the advantages of using an approach as disclosed herein are:

• Transparency. The client application or Set Top Box simply receives the UDP stream from the Local Retransmission Module, with no need to interact with the UDP Retransmission Server directly.

• Easy integration. There is no need to link the client application running on a set top box with an external library.

• Simple command interface. Standard HTTP protocol, or custom TCP text based protocol may be used for the client application to communicate with the Local Retransmission Module.

[0038] Further features and advantages may be taken from the following description of a preferred embodiment of the invention with reference to the figures enclosed herewith, showing in: [0039] Fig. 1 a schematic diagram of a system according to the invention,

[0040] Fig. 2 a schematic flow diagram of the method steps on the side of the client module of the system according to Fig. 1, and

[0041] Fig. 3 a schematic flow diagram of the method steps on the side of the Local Retransmission Module of the system according to Fig. 1.

[0042] Fig. 1 shows a schematic view of a preferred embodiment of the proposed system according to the present invention.

[0043] What can be seen in Fig. 1 more specifically is a RTP/UDP Local Retransmission Agent (RRLA) 2, which is an autonomous module, that can be implemented and embedded into the client device 4 as a software or, as in the embodiment shown, hardware component in the form of a set top box (STB), which comprises the client module 6 as such.

[0044] What can be taken from Fig. 1 as well is RTP/UDP Retransmission Server 8, which is a software/hardware implementation of a packet cache, that can be used by the client device 4 and more particularly the Local Retransmission Agent 2 for stream data prefetch and lost packet recovery. In the actual implementation as shown in Fig. 1, the communication between the Local Retransmission Agent 2 and the Server 8 is accomplished by a connection oriented protocol (such as TCP) or by other protocols (UDP, IP, etc.)

[0045] The client module 6 in the embodiment as shown, is an application that plays a RTP/UDP stream. The RTP/UDP in this embodiment is not received from the RTP/UDP Server 8 directly, however, but from the Local Retransmission Agent (RRLA) 2, which adds the capability of fast channel change and lost packet recovery to the Client module 6 in a transparent manner.

[0046] The RTP/UDP Local Retransmission Agent (RRLA) 2 of the embodiment as shown is a transparent service, designed to run on client side, as for example a set top box device. It handles RTP packet loss recovery and data prefetch for fast channel change, and sends the UDP stream to the local network/loopback interface of the client module 6. Thus the client module 6 will be able to receive and play RTP/UDP streams without any need to integrate an external library into the client application. The client software of the module 6 communicates with the RRLA module 2 via a TCP connection using custom text based protocol, or standard HTTP protocol, which can be simply accomplished even with a high level language such as JavaScript. The client module 6 can send various stream related or configuration commands to the RRLA module 2, such as tune, stop etc. The RRLA module 2 works with RTP/UDP Retransmission Server 8. It establishes a reliable TCP connection to handle lost RTP/UDP packet recovery, and data prefetch for fast channel change. Channel change time is dramatically reduced by using data prefetch and video stream key-frame indexing (MPEG2/MPEG4-H264) implemented in the RTP/UDP Retransmission Server 8. The typical channel change time is about 0.4 - 0.6 seconds, while the actual time depends on the stream bitrate and encoding options, player video decoder settings, and line bandwidth.

[0047] As can be taken from Fig. 2, which shows a flow diagram of the method steps as performed by the client module 6 of the set top box 4, when a user requests a channel change in Step 10, the client module 6 sends a command to the RRLA 2 in step 12, so that in step 14 the client module 6 receives and plays a UDP stream from the RRLA module 2 on a loopback interface or local network interface.

[0048] In Fig. 3 the method steps as performed by the Local Retransmission Module 2 are described. In step 16 the Local Retransmission Module 2 establishes a connection with the RTP/UDP Retransmission Server 8 (if applicable). In step 20 the Local Retransmission Module 2 listen for the commands issued by the Client module 6. In step 22, when a tune command is received from the client module, the media stream data prefetch/multicast receiving/lost packet recovery (in conjunction with the RTP/UDP Retransmission Server 8) is performed. In step 26 the processed/corrected stream is send to the loopback interface or local network interface of the client module 6, thus making it available for the client module 6.

Claims

1. System for packet loss recovery in a streaming media connection between a sender and receiver, including a Retransmission Server, wherein a Local Retransmission Module, being adapted to handle packet loss recovery and data prefetch for fast channel change, is provided at the receiver side, communicating with the Retransmission Server, to which a client application, running on the receiver side, is connectable to receive a corrected stream.

2. System according to claim 1, wherein the Local Retransmission Module is a software package.

3. System according to claim 1, wherein the Local Retransmission Module is a hardwired device.

4. System according to any of claims 1 to 3, wherein the Local Retransmission Module is an autonomous module.

5. System according to claim 4, wherein the Local Retransmission Module is implemented and embedded into the client device.

6. System according to claim 5, wherein the Local Retransmission Module is implemented as a software or hardware.

7. System according to any of the preceding claims, wherein the communication between the client and the Local Retransmission Module is accomplished by a connection oriented protocol.

8. System according to any of the preceding claims, wherein the Local Retransmission Module is adapted to send a stream to a local network/loopback interface of the client application.

9. System according to any of the preceding claims, wherein the client application runs on a Set Top Box.

10. System according to claim 8, wherein the local network/loopback interface is a local network interface, residing on a Set Top Box, being accessible by the Client Application.