WO2008134897A1

WO2008134897A1 - Method and system for quality service enhancement in networks for media streaming

Info

Publication number: WO2008134897A1
Application number: PCT/CA2008/000898
Authority: WO
Inventors: Mathieu Giguere; Marc-André FORGET; Ronald Brisebois
Original assignee: Technologies Ezoom Exponentiel Inc.
Priority date: 2007-05-08
Filing date: 2008-05-08
Publication date: 2008-11-13

Abstract

A method and system for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network, comprise a detector for detecting errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; a producer of error-free data packets corresponding to the error-detected data packets; a processor for changing the TCP sequence number used for transmitting each error-free data packet through TCP; and a channel for transmitting the error-free data packets with their changed TCP sequence number to the end users.

Description

TITLE

METHOD AND SYSTEM FOR QUALITY SERVICE ENHANCEMENT IN NETWORKS FOR MEDIA STREAMING

FIELD

[0001] The present invention generally relates to media streaming networks. More specifically, the present invention is concerned with a method and system for quality service enhancement in networks for media streaming.

BACKGROUND

[0002] Over the past few decades, Internet has experienced an incredible growth and expansion. Technologies have changed from centralized computing to personalized computing, to mobile computing and now to intelligent services with a convergence of networks, devices and services.

[0003] Indeed, with the introduction of broadband Internet and highspeed Internet access, many new services have been offered to the consumers, such as Internet Protocol TV (IPTV), using video streaming over IP. In addition, more and more users are always connected to Internet.

[0004] Also, major worldwide television broadcasters are now transmitting their broadcast signals over the Internet. The streaming applications can be also deployed over some private networks, such as cable TV networks, or cellular networks, for example.

[0005] Streaming applications generally consist of streaming medias that are consumed, i.e., heard or viewed while they are being delivered to a consumer. Each media stream, either audio or video, is delivered to the consumer using the Internet Protocol (IP). Furthermore, two IP based protocols can be used when broadcasting to a large audience over a network: Unicast or Multicast.

[0006] Unicast protocols send a distinct copy of the media stream from the server to each client. This is simple, but can lead to a massive duplication of data or media streams in the network, which implies the use of many servers, in the network, for providing a distinct copy of the media stream to each client.

[0007] Multicast protocols send only one copy of the media stream over any given network connection, i.e., along the path between any two network routers. This is a more efficient use of the network capacity and it keeps the number of servers to a minimum, but it is much more complex to implement. Furthermore, multicast protocols must be implemented in the network routers, as well as in the servers. Forwarding multicast traffic also requires a great deal of protocol complexity, particularly when knowing and satisfying in real-time the profile of each client of the audience, such as personalized content, interactions, billing, Quality-of-Service (QoS), etc. Thus, the multicast protocol suffers from deployment problems and complexity. Also, there is no efficient software to support such deployment and implementation. Usually, the few networks that use multicast protocols are complex and expensive, and they are also difficult to install and maintain.

[0008] IPTV has become more and more attractive to consumers and has grown rapidly; it evolved from broadcast TV to Video on Demand, then to Interactive TV and finally to personal communications with personal TV channels, using unicast contents. With opportunities of offering interactive and personalized services, this field constitutes a huge market for generating large potential revenues for the telecommunication companies. However, as the number of users and offered services increases, the management of the bandwidth becomes a critical issue for providing a good quality of service (QoS). Indeed, the bandwidth is a limited resource.

[0009] Furthermore, it is important to provide a good quality of service so as to offer an optimized users' experience, by using intelligently the network resources. Most of the current networks offer slow delivery of media streams. Also, media streaming is generally unreliable because of congestion in the networks and/or packet loss. Furthermore, media streaming may not be scalable, since the bandwidth usage is limited at a master site. Congestion, packet loss and limited bandwidth usage degrade the quality of the media stream, and, therefore yield an inferior QoS, and limit user uploads/downloads.

[0010] Therefore, there is a need for overcoming the above discussed problems, related to deploying broadcasting networks and providing high quality media streams, using the unicast protocol but offering the multicast capabilities. Accordingly, a method and system for quality service enhancement in networks for media streaming are sought.

OBJECTS

[0011] An object of the present invention is therefore to provide a method and system for quality service enhancement in networks for media streaming.

SUMMARY

[0012] More specifically, in accordance with a first aspect of the present invention, there is provided a system for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network. The system comprises a means for detecting errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; a means for providing error-free data packets corresponding to the error-detected data packets; a means for changing the TCP sequence number, used for transmitting each error-free data packet through TCP; and a means for transmitting the error-free data packets with their changed TCP sequence number to the end users.

[0013] According to a second aspect of the present invention, there is also provided a system for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network. The system comprises a detector of errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; a producer of error-free data packets corresponding to the error-detected data packets; a processor that changes the TCP sequence number, used for transmitting each error-free data packet through TCP; and a channel for transmitting the error-free data packets with their changed TCP sequence number to the end users.

[0014] According to a third aspect of the present invention, there is provided a method for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network. The method comprises: detecting errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; upon detection of the errors, providing error-free data packets corresponding to the error-detected data packets; changing the TCP sequence number used for transmitting each error-free data packet through TCP; and transmitting the error-free data packets with their changed TCP sequence number to the end users. [0015] The foregoing and other objects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of illustrative embodiments thereof, given by way of example only with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In the appended drawings:

[0017] Figure 1 is a schematic view of a broadcasting network according to a non-restrictive illustrative embodiment of the present invention;

[0018] Figure 2 is a schematic view of a cooperative streaming accelerator (CSA) used in the network of Figure 1 ;

[0019] Figure 3 is a flow chart illustrating a method of optimizing the transmission bandwidth in the network of Figure 1 ;

[0020] Figure 4 is a flow chart illustrating a method for recovering and correcting the lost data packets using the Transmission Control Protocol (TCP) stack in the network of Figure 1 ; and

[0021] Figure 5 is a flow chart illustrating a method for transmitting media stream data packets using the TCP stack in the network of Figure 1.

DETAILED DESCRIPTION

[0022] In the following description, an illustrative embodiment of the present invention will be described in the context of IPTV. However embodiments of the present invention are not restricted to IPTV applications only and may be applied to other types of broadcasting networks.

[0023] Furthermore, in IPTV applications, the Real-Time Protocol

(RTP) is generally used. In this case, the data packets in the media streams are referred to as the RTP data packets. However, many other protocols, such as some proprietary protocols, can be used and are within the scope of the present invention.

[0024] Generally stated, a streaming accelerator (SA)₁ according to a non-restrictive illustrative embodiment of the present invention, is an element of the broadcasting network, which rationalizes and accelerates non-intrusively the delivery of streaming media to remote users, while lowering deployment costs and operating expenses. The SA also allows for improving streaming Quality-of-Service (QoS), as will be explained hereinbelow, and for opening the feasibility of new TV and Audio related applications over an IP network. The SA uses standard networking equipments and is compatible with the Internet Protocol (IP). The SA can duplicate, control and deliver media streams to an unlimited number of destinations, using the unicast protocol but offering the capabilities of the multicast protocol. It also uses standard Internet Engineering Task Force (IETF) protocols and it is not bound to any streaming audio or video CODEC. Furthermore, it can also use proprietary protocols, specific to different elements in the network.

[0025] The SA can be, for example, in the context of a broadcasting network, an embedded piece of software implemented directly in a Network Processor Unit (NPU) or can use a specially designed chip or a Field Programmable Gate Array (FPGA) or a network processor unit inside a switch. However, the SA can take the form of a mini SA, such as a Personal Computer (PC) card, which can be inserted in any computers, for small companies to broadcast over the Internet.

[0026] In addition, a plurality of SAs can be implemented for handling a large network, for duplicating and delivering media streams through the large network, and for enhancing the media streaming QoS. Such infrastructure, comprising the plurality of SAs, can be used to deploy a distributed media stream delivery network using the unicast protocol, for example, such as for an IPTV private network that offers TV channels over Digital Subscriber Line (DSL) access.

[0027] Generally stated, the plurality of SAs works together to better distribute and thus accelerate media streams delivery over a large network. When only one SA is used for duplicating media streams, all the duplicated media streams travel through a same path in the network until they reach the last segment of the network where they are delivered to the respective end users. Using a plurality of SAs, with one main SA working in cooperation with some regional SAs connected thereto, only the duplicated media streams requested by a whole region travel through a main path between the main SA and one regional SA, corresponding to said region. When those media streams reach the regional SA, they are then duplicated and sent to all the end users of tha region that requested the media streams. Therefore, the efficiency of media stream delivery is improved. In such a configuration, the SAs working with one another are each referred to as a Cooperative Streaming Accelerator (CSA).

[0028] Now turning to Figure 1 , an example of broadcasting network

20, according to a non-restrictive, illustrative embodiment of the present invention, will be described. The broadcasting network 20 includes a headend section 22, a main office 24, a regional office 26 and end user sections 28 (only two end user sections 28 being shown for the purpose of simplifying the drawings).

[0029] The headend section 22 comprises one or a plurality of receivers, which can be analog or digital systems, for receiving broadcast signals. More specifically, the receivers may include a satellite receiver system 30, an analog receiver system 32, such as an antenna, an interactive content authority system 34, etc. Those receivers are connected to the main office 24.

[0030] The main office 24 includes a main CSA 36, for performing media stream duplication. Thus, the main CSA 36 can be viewed as a main generator of a set of first media streams. The main CSA 36 is connected to a streaming server 38, from which the main CSA 36 receives media streams and then duplicates them. The streaming server 38, in turn, is connected to the interactive content authority system 34 for receiving digital broadcasting signals. The main CSA 36 is also connected to an encoder 40, for receiving media streams and then duplicating them. The encoder 40 encodes signals received from a decoder 42, such as an integrated receive decoder, and a demodulator 44. The decoder 42 receives, as input, broadcasting signals coming from the satellite receiver system 30 and decodes the received broadcasting signals which have been encoded previously. The demodulator 44 receives, as input, modulated broadcasting signals coming from the analog receiver system 30 and demodulates those signals.

[0031] Furthermore, the main CSA 36 is connected to a router 46, for example as an Asynchronous Transport Mode (ATM) router, and a switch 48, for example an ATM switch, for forwarding the duplicated media streams to the regional office 26 through a network 50 which uses, for example, Synchronous Optical Networking (SONET). The router 46 can be further connected to a middleware server 52. [0032] The regional office 26 is generally implemented close to the end user sections 28. The regional office 26 includes a regional CSA 54, for performing a second duplication of the media streams received from the main office 24. Thus, the regional CSA 54 can be viewed as a regional generator of a set of second media streams. The regional CSA 54 is connected to a router 56, which is in turn connected to the output of a switch 58, for example an ATM switch. The switch 58 has an input connected to the network 50. In this manner, the regional CSA 54 receives media streams from the network 50 through the switch 58 and the router 56. The router 56, which can be an ATM router, has also outputs connected to a plurality of Digital Subscriber Line Access Multiplexers (DSLAM) 60, respectively, for distributing the duplicated media streams from the regional CSA 54 to the end user sections 28.

[0033] Each end user section 28 includes a Digital Subscriber Line

(DSL) modem 62, connected to one of the DSLAMs 60, for receiving media streams therefrom. The DSL modem 62 is also connected to a TV set 64 and/or a computer 66, which allow for playing and/or listening to the media streams requested by the users.

[0034] It should be noted that those skilled in the art would understand that other types of equipments and technologies can be used for networking.

[0035] It should be also noted that the main office 24 may be connected to a plurality of regional offices having similar functionalities as the regional office 26. Indeed, the main office 24 is not restricted to be connected to one regional office 26 only as described in the non-restrictive illustrative embodiment of Figure 1. [0036] Turning now to Figure 2, a SA, a main CSA 36 or a regional

CSA 54, which have substantially the same functionalities and therefore will be referred to simply as a CSA, will be described.

[0037] First, the CSA includes one or a plurality of processing elements 100i to 10O_n and one or a plurality of forwarding elements 102i to 102_m. The CSA is flexible and scalable, meaning that additional services and functionalities, such as transcoding and channel tracking, can be implemented in the plurality of processing elements 100i to 10O_n. Therefore, the plurality of processing elements 10O₁ to 10O_n allows for supporting new and/or additional functionalities.

[0038] More specifically, the processing element 10O₁ includes a

Real-Time Streaming Protocol (RTSP) proxy 104, for intercepting and processing the requests for media streams from the end users. It should be noted that media streams include frames and data packets.

[0039] The processing element 100i also includes a Multiple

Command Virtual Interface (MVIF) driver 106, for establishing a communication interface between the processing element 10O₁ and the forwarding element 102i over a private network 108, which can be a base channel for example.

[0040] The forwarding element 102i of the CSA, which allows for duplicating media streams and forwarding the duplicated media streams, includes a host 110, in which control commands are processed and postprocessing is performed, and a Network Processing Unit (NPU) 112, in which the process of duplication of the media streams takes place. One possible duplication process for a CSA is described in copending International Application PCT/CA2008/000183 entitled "Cooperative system and method for duplicating and delivering media streams in a distributed manner" filed on January 29, 2008.

[0041] For example, the host 110 can execute basic user commands, such as adding, removing or fetching a media stream requested by an end user by using binary formats with fast encoding/decoding mechanisms. The host 110 can also be used to send requests and receive responses. Generally, a network administrator or any person authorized to access the host 110 can perform those tasks. Furthermore, the host 110 can be used to perform post-processing of data, for example to generate statistical data collected throughout the network 20, or post-processing of non-identified data packets detected during the duplication process.

[0042] Before the duplication process in the NPU 112, incoming data packets are first identified and matched to a streaming flow. For that purpose, a flow matching based on a 5-tupple can be used. For example, the 5-tupple information concerning the data packet is given by: the source IP address, the destination IP address, the nature of the protocol used, the source port and the destination port. After the data packets have been identified, they can be duplicated as many times as required by the NPU 112.

[0043] Since the user experience is very important in the context of media streaming, the non-restrictive, illustrative embodiment according to the present invention is also concerned with providing a mechanism, implemented in the processing element 10O₂ and the forwarding element 102i, for controlling the quality of service in the network 20.

[0044] For that purpose, the NPU 112 of Figure 2 includes a Real-

Time Control Protocol (RTCP) handler 114, which generates feedback on the quality of the transmission links. Such feedback can be used to dynamically analyze quality of the user experience and to take action when required, as described hereinbelow.

[0045] More specifically, the RTCP handler 114 generates RTCP reports (not shown) to detect problems in the media streams or the network 20. The RTCP reports collect and gather cumulative packet drop or loss information, which gives an indication of the quality of a link. The values provided by those reports can further form statistics. Those statistics can be analyzed by the host 110 and compared to a packet drop threshold, for preventive purposes, so that proper actions and adjustments can be made within a certain time interval. For example, if the analyzed value is below a certain QoS threshold then adjustment of the QoS drop function is necessary in order to provide an acceptable quality of the link.

[0046] The time interval, mentioned in the preceding paragraph, can be random, but usually is around 10 seconds. Also, a function of Request for Comments (RFC) for unicast Real-Time Protocol (RTP) can be used to provide faster RTCP feedback when errors are detected at a client or user site. Thus, solutions for fixing the detected errors will be also provided faster.

[0047] In addition, abnormal data packets are flagged to the host

110 so that proper actions may be taken, for example a network dynamic down sampling adjustment. Indeed, upon detection of a sufficient number of packet drops, the media stream quality can be dynamically down scaled.

[0048] A further example of actions to take for obtaining a better user experience is to analyze the media stream in order to detect the key frames and data packets, which are marked as "important" or "high priority", from the rest of the frames and data packets contained in the media streams. In this manner, when the bandwidth has been reduced during the last time interval, for example, only the important and/or high priority key frames and data packets can be transmitted. This approach helps to maintain the image quality of the video stream and prevent peak congestion in the network 20 and random packet drop, since the important and/or high priority frames and data packets in the media streams are guaranteed to be transmitted in the reduced bandwidth.

[0049] The processing element 10O₂ includes a bandwidth manager

116 for taking care of bandwidth reservation and QoS (Quality of Service) in the network 20. Indeed, to deliver exceptional quality of media streams to an end user, bandwidth management between the main office 24 and the regional office 26 can be enforced. Plus, bandwidth management strategies should be offered and be easy to handle for an outside operator to manage properly the network 20.

[0050] For example, when the operator wants to minimize a reserved bandwidth to a minimum needed, dynamic bandwidth reservation should be used. In this case, the main CSA 36 includes a bandwidth manager 116 which can negotiate the required bandwidth when new media streams are sent to the regional office 26, so that a minimum and average bandwidth is guaranteed. However, in case the maximum bandwidth allowed is reached or exceeded, adaptive buffering in the regional office 26 should be provided, which will be described hereinbelow.

[0051] Furthermore, within the network 20, it is generally possible to analyze the codec (not shown) for media streaming and to prioritize the key frames. For example, if the network 20 is congested, the prioritized key frames will pass through the network 20. Therefore, as described in the following description, a strategy of marking frames is also provided. [0052] For that purpose, the processing element I OO2 further includes a packet marking element 118 to identify each data packet from the requested media streams and for specifying a certain level of QoS. The packet marking element 118 can use technologies, such as Terms of Service (ToS) from layer 3 of the Open System Interconnection (OSI) model and pBits (Priority bits) from layer 2 of the OSI model, to characterize real-time data packets. For example, the data packets identified as coming from the key frames are marked with a high level of QoS.

[0053] In general, in private networks, routers and switches decide to drop data packets according to the marking thereof, when there is congestion detected in the transmission links. Therefore, during congestion of the network 20, the data packets marked as having a high level of QoS will pass through the network 20 and the data packets having a lower priority will be dropped.

[0054] It should be noted that packet marking can be of different nature and technologies, for each media stream, for each regional office such as 26, and for a combination of media streams and regional offices. Indeed, each media stream can have a different pricing depending, for example, on the QoS guaranteed to the end user. Therefore, prioritization in terms of bandwidth will be performed accordingly. The marking of the data packets is modified depending on the used, for example, pBits or ToS in order to reflect different bandwidth negotiations. Furthermore, packet marking is generally not constant from one network to another. Therefore, the packet marking element 118 also offers a multitude of configuration and options to the operator.

[0055] It should be pointed out that the packet marking element 118 generally identifies each packet and decides which marking strategies or appropriate marking should be used for each packet. [0056] Generally stated, media streams and more specifically video streams include Intra frames (l-frames) and Predicted frames (P-frames). I- frames represent the pictures and the P-frames encode mainly the differences between consecutive pictures. Therefore, it is more critical to lose an l-frame than a P-frame during media streaming. Accordingly, l-frames are marked with a higher priority and QoS than P-frames by the marking element 118 of the processing element IOO₂.

[0057] Presently, using the Moving Picture Experts Group (MPEG) format, videos are sent using conventional pre-defined Group Of Pictures (GOP) sequence, comprising l-frames and P-frames. A GOP sequence can look like this: IPPPP, for example, which means that an l-frame is sent at each fifth frame, followed by four P-frames. In conventional systems, a media stream is generally encoded with an l-frame every 2 to 5 seconds.

[0058] Since l-frames stores a sufficient amount of information to describe an entire picture, the l-frames require a larger amount of data to store and therefore they need a larger portion of bandwidth. Thus, sending an I- frame on a regular basis is bandwidth consuming. In order to overcome this issue, dynamically transmitting l-frames, i.e., performing on-demand transmission of l-frames, is used. Instead of sending, at regular intervals, an I- frame, the l-frames are sent only when a problem is detected, at the user connection, for example. In this manner, most of the time, P-frames, corresponding to differences associated to an l-frame, are transmitted; this requires a smaller portion of bandwidth. Also, during congestion of the network 20, P-frames can be dropped since they are marked as having a lower priority than the l-frames.

[0059] At the NPU 112, both an internal l-frame and a P-frame are pre-generated so that, in case of errors, an l-frame without errors can be transmitted faster or even immediately. Also, the NPU can decide to send the pre-generated l-frame or corresponding P-frames based on the quality of the transmissions reported by the end user side.

[0060] Finally, the NPU 112 can be viewed as a producer of media streams and more specifically of data packets.

[0061] When an error occurs and data packets are lost, the TCP stack, corresponding to the set of protocol layers in TCP, asks for retransmission of the lost data packets. Then, it is possible to schedule the TCP session to receive a new l-frame, pre-generated by the NPU 112. Furthermore, in case User Datagram Protocol (UDP) players are used, the RTCP message needs to be sent even faster.

[0062] It should be noted that transmitting l-frames on demand allows to save bandwidth by up to 50%. In some cases where motions are few in the video streams, such as a professor teaching in front of a class, bandwidth can be saved by up to 80%.

[0063] Also, since l-frames are transmitted on demand, only after an error has occurred, the user experience is improved. Indeed, in the case of on- demand l-frame transmission, a glitch created by the retransmission of the I- frame lasts for about half a second. Therefore, the response time for recovering from the error and then displaying the video is faster, so that the user can hardly notice the glitch. On the contrary, in the case where l-frames are transmitted regularly, when errors occur, the decoding glitch can last for a few seconds. Therefore, the user has to wait for a few seconds in order for the video stream to resume. [0064] A second way of generating feedback about the quality of the transmission links comes from the Transmission Control Protocol (TCP) stack. However, it should be noted that streaming video content over a standard TCP stack is not normally performed, since the TCP stack is not well adapted for video streaming. Indeed, re-transmitting several times a same video packet, which was lost, is not only bandwidth consuming, but also requires a large amount of server buffering. Therefore, to overcome those drawbacks, a layer 5 of the OSI model or higher layer mechanism is implemented. For example, a codec for reading the video streams can recover from the lost video packets by performing a strategy using the TCP stack. This strategy will be described hereinbelow.

[0065] The strategy comprises a new way of transmitting data packets. This new way of transmitting data packets transmits any new data packet as a re-transmitted data packet. Therefore, a new data packet is transmitted, even when the TCP stack asks for a re-transmission of the lost data packet. To do so, a TCP sequence number contained in an acknowledgment data packet used by the end user side to confirm reception of the transmitted data packets is restarted from the previous TCP sequence number and in relation with the length of the previous TCP sequence number. This is done through a processor, for example. Then, every transmitted data packet forming a new data packet, for example, may be seen as a retransmitted data packet through the TCP sequence re-numbering, which follows the previously sent out TCP sequence number.

[0066] It should be noted that the "PUSH flag" in the TCP header of the data packets is important in order to transmit the data packets without any waiting time or delay to an end user's computer 66 or TV 64 (Figure 1), for example. In this manner, it is possible to transmit video packets using TCP. [0067] It should be also noted that each data packet has a RTP sequence number which is independent of the TCP sequence number. At the end user side, a media stream player connected to the computer 66, for example, can easily reconstruct the sequence of received data packets through the RTP sequence number.

[0068] In order to better understand the transmission strategy using

TCP, an example of media streaming of RTP data packets will be described.

[0069] For example, four (4) RTP data packets of one byte each and having a TCP sequence number of respectively 100, 101 , 102 and 103 in their TCP header are sent to the end user by the CSA. Upon reception, the TCP stack at the end user side transmits the TCP sequence number 104 in an acknowledgement data packet to the CSA, thus confirming reception of the four (4) data packets and waiting for the next data packet that will have a sequence number of 104. Next, the CSA sends the data packets corresponding to the TCP sequence number of respectively 104, 105, 106 and 107 to the end user. However, the end user receives only data packets 106 and 107, meaning that data packets 104 and 105 have been lost. In that case, the TCP sequence number from the end user side will be renumbered and restarted with the previously sent out TCP sequence number, i.e. 104, until it reaches 106. The TCP sequence number is usually incremented by the number of bytes of the received data packet. Therefore, after receiving two (2) good data packets of one (1) byte each, the TCP sequence number will reach 106. Then, the next TCP sequence number to be sent out will be automatically adjusted to 108, since data packets 106 and 107 have been received already.

[0070] In this example, two new RTP data packets have been transmitted through TCP. These two RTP data packets have their own RTP sequence number in their RTP header, independent from the TCP sequence number, so that they can be reconstructed at the end user side using the RTP sequence number.

[0071] It should be noted that it is within the scope of the present invention to use transmission protocols other than TCP.

[0072] According to another feature for optimizing the bandwidth in the network 20, an efficient error correction strategy can also be used, instead of re-transmitting lost data packets.

[0073] When an error occurs in the network 20, detected through a detector, for example, some data packets are lost or cut. Instead of requesting retransmission of the lost data packets, which requires occupying bandwidth resources, the efficient error correction strategy allows for recovering the lost data packets without asking for retransmission thereof. Therefore, by using such an error correction strategy, there is no need to re-transmit the lost data packets, and thus use of the bandwidth resources is optimized. Also, it is possible to control the recovery bandwidth that is necessary for transmitting the recovery or error-corrected data packets using the TCP stack, as described hereinabove. In this case, the error-corrected data packets represent the new RTP data packets which are sent out through TCP. However, the error- corrected data packet transmission is not limited to using TCP only, it can be transmitted using UDP as well.

[0074] For example, a FEC (Forward Error Correction) approach can be used to rebuild any lost data packets through generation of parity packets, corresponding to the error-corrected data packets. The parity packets can be generated according to the Reed-Solomon's codes using a Galois field, i.e. a finite field. The Reed-Solomon's codes are error-correcting codes that are generated by oversampling a polynomial constructed from the data packets over a given finite field.

[0075] A FEC encoder 130, located in the processing element 10O₂ of the main CSA 36, can be used to generate the FEC parity packets. For that purpose, a dynamic sequence of data packets is inputted into the FEC encoder 130. The length of the dynamic sequence of the data packets is variable. The length can be time limit or packet limit based; those limits are determined by an operator depending on the nature of the media streams, for example. Since the Reed-Solomon codes require that each data packet in the sequence should have the same length, then the longest data packet in the sequence is determined, which then sets the length for each of the remaining data packets. The shorter data packets in the sequence are padded with zeros so as to obtain the same length as the determined longest data packet.

[0076] Furthermore, the data packet sequences for different transmission links and channels are handled independently from each other so as to minimize zero padding.

[0077] The zeros in the data packets are used to generate the FEC parity packets according to the Reed-Solomon codes. The generated FEC parity packets are as close as possible to the original data packets of the media streams. For each sequence of data packets, corresponding FEC parity packets are generated. However, the generated FEC parity packets are only transmitted through a channel using the TCP stack or over UDP, to the end users who request them (FEC on-demand).

[0078] It should be noted that any generated FEC parity packet can replace an original data packet that has been lost. [0079] At the end user side, the sequence of data packets corresponding to the requested media streams is received. If an error occurs such that a certain number of data packets in the sequence is lost or cut, then a codec, at the end user side can dynamically request the same number of generated FEC parity packets to be transmitted to the end user for recovery and replacement of the lost data packets in the sequence. However, if the number of lost data packets in the sequence is larger than the number of FEC parity packets that has been generated, then the sequence of data packets cannot be recovered or replaced by a smaller quantity of FEC parity packets. In that case, when recovery is not possible, the end user will then request retransmissions of the original data packets; new and pre-generated l-frames can be transmitted to the end user through TCP, as described hereinabove.

[0080] By transmitting only the required number of FEC parity packets instead of the whole sequence, for example, the bandwidth for recovery of lost data packets in a media stream is optimized.

[0081] It should be understood that the processing element 10O₂ of the regional CSA 54 can also include a FEC encoder, such as the FEC encoder 130.

[0082] In summary, according to the non-restrictive illustrative embodiment of the present invention, a method 200, as illustrated in Figure 3, for bandwidth optimization is provided. The method 200 for bandwidth optimization in the network 20 is generally implemented in the processing element 10O₂.

[0083] In operation 202 of method 200, when at least one data packet from a transmitted frame is lost or cut, the error is detected at the end user side, for example. [0084] Upon the detection of the at least one lost data packet, two options are possible, depending on the ability of correcting the error (operation 203). If the error can be corrected, then the first option, as given in operation 204, provides for an error correction and recovery of the at least one lost or cut data packet. However, if error correction and recovery of the at least one lost data packet is not possible, then, in operation 206, the second option consists, for example, of providing an l-frame on demand transmission using TCP.

[0085] Now, turning to Figure 4, method 300 for recovery of the at least one lost data packet will be described, as provided in operation 204 of Figure 3.

[0086] Method 300 starts with operation 202 of method 200 where an error has been detected, because at least one data packet was lost or cut. For example, the error could have been detected by a media stream player connected to the computer 66 (Figure 1) of the end user.

[0087] In operation 302, a requesting element connected to the media stream player, for example, requests for a number of the FEC parity packets corresponding to the number of lost data packets. The request is sent to the main CSA 36, for example.

[0088] It should be noted that the FEC parity packets have been pre- generated by the FEC encoder 130 at the main CSA 36, which is connected to the streaming server 38 of Figure 1 , thus they are readily available. However, they are sent out only upon request.

[0089] Upon reception of the request, the main CSA 36 forwards the requested number of FEC parity packets to the end user, in operation 304. The FEC parity packets can be sent to the end user using the TCP stack or over UDP.

[0090] The above-mentioned operations loop back each time that a transmission error is detected and which can be corrected.

[0091] By using method 300, the bandwidth for error recovery is optimized. Indeed, only the requested number of FEC parity packets are transmitted.

[0092] Turning now to Figure 5, method 400 for bandwidth optimization using an "on-demand l-frame" strategy and the TCP stack will be described, provided for example in operation 206 of method 200 (Figure 3).

[0093] Method 400 starts with operation 202 of method 200 in Figure

3, where an error has been detected, because at least one data packet was lost or cut. For example, the error could have been detected by a detector in a media stream player connected to the computer 66 of the end user.

[0094] Upon detection of the at least one lost data packet, i.e. the error-detected data packet, which cannot be recovered and corrected, operation 402 requests retransmission of at least one, or for example a few last transmitted or lost data packets .

[0095] In operation 404, l-frames and/or P-frames which were pre- generated as described hereinabove by the NPU 112 (Figure 2), are provided.

[0096] In operation 406, the pre-generated l-frames and/or P-frames are marked with priority levels in their header with ToS or pBits. The l-frames have higher priority than the P-frames. Therefore, in case of congestion, P- frames are first dropped, for example.

[0097] In operation 408, the TCP sequence number to be used for the transmission of the pre-generated l-frames and/or P-frames is changed as described in the foregoing description. More specifically, it is restarted from the previous used TCP sequence number, so that the on-demand l-frames can be transmitted through the TCP stack.

[0098] Finally, in operation 410, the at least one new data packet, such as the l-frame and/or P-frame, is transmitted using TCP.

[0099] The above-mentioned operations loop back each time that a transmission error is detected and which cannot be recovered and corrected.

[00100] Furthermore, the processing element 10O_n allows for implementing additional functions, related to adaptive channel buffering, using a plurality of buffers 120. For example, in order to maximize channel zapping response time, prediction can be made on the next zapping channel. To do so, a function of pre-buffering is used.

[00101] The pre-buffering function simply buffers the next predicted channel for the user, meaning that, when zapping up/down, the next channel is simply buffered with one of the plurality of buffers 120. Therefore, when the user is zapping, the channel has already been received by the regional office CSA 26, which can then transmit immediately the channel to the user. In this manner, the response time to the user's requests is maximized. Furthermore, if after, for example, two minutes, no users are using the pre-buffered channel, then the main office 24 is notified to stop receiving and then transmitting the pre-buffered channel.

[00102] To further accelerate zapping time, no re-negotiation is made during a channel change. For example, when switching between channels, the set-top box (STB) of the TV 64 does not re-negotiate the session description protocol (SDP) file for new ports and media stream information. The CSA simply switches the new stream to the same user ports, by making sure that the user's codec is compatible. For that purpose, the proxy 104 determines that the same conditions, which existed for the previous channel, also exist for switching to the new channel, so that the same communication session is kept. Therefore, buffering time is maximized.

[00103] Furthermore, the function of post keeping is available, through a post keeper 122, for keeping a channel active for a certain period of time, for example during two minutes, in the case where the "last channel button" is activated or the zapping order has been changed. Therefore, the last channel viewed by the user is recorded in the processing element 10O_n.

[00104] Also, the history function, performed by a channel tracker

124, allows for keeping track of the favourite channels viewed or listened to by the users. To do so, pre-buffering of the favourite channels, that the users usually listen or view at certain hours, is performed.

[00105] The function of popular search, provided by a search engine

126, allows for setting aside a set of low resolution channels to perform popular searches and accelerate search results. By so doing, little bandwidth is consumed and the low bandwidth popular searches facilitate the display of the results. [00106] The processing element 10O_n further includes a server 128 for allowing time zone automatic adjustment or time slipping. Time slipping allows for receiving a live media stream, and then for sending it back after a certain period of time has passed by. More specifically, this function allows for re-broadcasting with awareness of time zone differences between different countries, for example.

[00107] The server 128 captures the live media stream and decides to display it live or to re-broadcast it corresponding to a different time zone. For example, the server 128 can capture TV news from France at 6 pm (France's time) and decide to re-broadcast it at 6 pm in Canada (Canada's time), which is about six/seven hours later. In that case, the live media stream is kept in a buffer (not shown) of the server 128 until the show or re-broadcasting time. It should be noted that the longest buffering time of internet quality video stream would be 23 hours.

[00108] The matching and identification process of the data packets is done in the same way as in the case of live broadcasting, in the NPU 112. A copy of the media stream is sent to the processing element 10O_n for storage. A buffer, such as a jitter buffer or one of the plurality of buffers 120, arranges the media stream in ordered frames for easier storage. The storage format keeps the original frame separations. At re-broadcasting time, the media stream is fetched and contains a new RTP header with the corresponding timestamp for time synchronization.

[00109] Also, it should be understood that the CSA, SA or mini SA may vary in terms of the number of functionalities implemented therein. Therefore, the number of processing elements, such as 100i and forwarding elements such as 102i may be different in a main CSA, regional CSA or a SA. [00110] Although the present invention has been described in the foregoing specification by means of a non-restrictive illustrative embodiment, this illustrative embodiment can be modified at will within the scope of the appended claims, without departing from the spirit and nature of the subject invention.

Claims

WHAT IS CLAIMED IS:

1. A system for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network, the system comprising: a means for detecting errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; a means for providing error-free data packets corresponding to the error-detected data packets; a means for changing the TCP sequence number used for transmitting each error-free data packet through TCP; and a means for transmitting the error-free data packets with their changed TCP sequence number to the end users.

2. A system for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network, the system comprising: a detector of errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; a producer of error-free data packets corresponding to the error- detected data packets; a processor that changes the TCP sequence number, used for transmitting each error-free data packet through TCP; and a channel for transmitting the error-free data packets with their changed TCP sequence number to the end users.

3. A system as defined in claim 2, wherein the media streams comprise video streams in IP TV networks.

4. A system as defined in claim 2, wherein the detector of errors comprises a detector of lost data packets.

5. A system as defined in claim 3, further comprising a requesting element for requesting retransmission of original data packets free from errors corresponding to the error-detected data packets.

6. A system as defined in claim 5, wherein the producer comprises a NPU for pre-generating l-frames and P-frames as the error-free data packets corresponding to the error-detected data packets.

7. A system as defined in claim 6, further comprising a packet marking element for prioritizing the pre-generated l-frames over the P-frames.

8. A system as defined in claim 6, wherein the l-frames are transmitted only on demand.

9. A system as defined in claim 2, further comprising a requesting element for requesting transmission of error-corrected data packets as the error-free data packets corresponding to the error-detected data packets.

10. A system as defined in claim 9, wherein the producer further comprises a Forward Error Correction (FEC) encoder for generating the error- corrected data packets based on Reed-Solomon's codes.

11. A system as defined in claim 9, wherein the channel for transmitting the error-free data packets to the end users comprises a channel for transmitting the error-corrected data packets using UDP.

12. A system as defined in claim 2, further comprising a bandwidth manager for reserving a required bandwidth.

13. A system as defined in claim 2, further comprising a Real-Time Control Protocol (RTCP) handler for generating feedback and statistics on a transmission quality in the distributed communication network.

14. A system as defined in claim 3, further comprising a plurality of buffers for buffering a plurality of predicted channels that will be zapped by the end users.

15. A system as defined in claim 3, further comprising a post keeper for keeping a channel active for a certain period of time.

16. A system as defined in claim 3, further comprising a channel tracker for keeping track of favourite channels of the end users.

17. A system as defined in claim 3, further comprising a time zone server for automatically adjusting the time zone of a live media stream.

18. A system as defined in claim 2, wherein the channel is also used for returning an acknowledgment data packet, containing the TCP sequence number associated to a next data packet to be received, by the end users upon reception of the transmitted media streams.

19. A method for transmitting media streams, generated by a media source, to end users through Transmission Control Protocol (TCP) and a distributed communication network, the method comprising: detecting errors in data packets of the transmitted media streams, each data packet being associated to a TCP sequence number; upon detection of the errors, providing error-free data packets corresponding to the error-detected data packets; changing the TCP sequence number used for transmitting each error- free data packet through TCP; and transmitting the error-free data packets with their changed TCP sequence number to the end users.

20. A method as defined in claim 19, wherein media streaming comprises video streaming in IP TV networks.

21. A method as defined in claim 19, wherein detecting errors comprising detecting lost data packets in the transmitted media streams.

22. A method as defined in claim 21 , wherein providing the error-free data packets corresponding to the error-detected data packets comprises requesting retransmission of original data packets free from errors.

23. A method as defined in claim 22, wherein providing the error-free data packets corresponding to the error-detected data packets further comprises pre-generating l-frames and P-frames as the error-free data packets.

24. A method as defined in claim 23, further comprising prioritizing the I-Frames over the P-Frames.

25. A method as defined in claim 23, further comprising transmitting the l-frames on demand only.

26. A method as defined in claim 19, wherein changing the TCP sequence number comprises restarting the TCP sequence number from a previously used TCP sequence number and in relation with a length of the previous TCP sequence number.

27. A method as defined in claim 19, wherein providing the error-free data packets corresponding to the error-detected data packets comprises requesting transmission of error-corrected data packets as the error-free data packets corresponding to the error-detected data packets.

28. A method as defined in claim 27, wherein providing the error-free data packets corresponding to the error-detected data packets further comprises generating the error-corrected data packets based on a FEC approach according to Reed-Solomon's codes.

29. A method as defined in claim 27, wherein transmitting the error- free data packets to the end users comprises transmitting the error-corrected data packets through UDP.

30. A method as defined in claim 19, further comprising managing a bandwidth of the distributed communication network through bandwidth reservation.

31. A method as defined in claim 19, further comprising generating feedback and statistics on a transmission quality of the distributed communication network.

32. A method as defined in claim 19, further comprising buffering a plurality of predicted channels that will be zapped by the end users.

33. A method as defined in claim 19, further comprising keeping a channel active for a certain period of time.

34. A method as defined in claim 19, further comprising keeping track of favourite channels of the end users.

35. A method as defined in claim 19, further comprising automatically adjusting the time zone of a live media stream.

36. A method as defined in claim 19, further comprising returning an acknowledgment data packet, containing the TCP sequence number associated to a next data packet to be received, upon reception of the transmitted media streams.