Multicast with UDP using packet identifier in MPEG payload

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority to European Patent Application EP 08021780.5, filed in the European Patent Office on Dec. 15, 2008, the entire contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

The invention relates to a method of multicasting content information via a data network to a plurality of receivers using data packets of a transport stream. The invention further relates to data processing equipment comprising an interface to a data network and configured for processing content information received via the data network, and to control software for use on such equipment.

BACKGROUND

Internet Protocol TV (IPTV) is a system that delivers content information (e.g., video and/or audio) via a data network, such as the Internet, to a network-enabled data processing device, e.g., a set-top box (STB) or a personal computer (PC). IPTV typically uses a multicast technology if the content information is a live broadcast, and a unicast technology for, e.g., a video-on-demand or for implementing a pause functionality in a live broadcast. Multicast is an addressing method for the simultaneous transmission of data to multiple destinations. Multicast is an efficient approach in that the data is delivered over each link of the network only once and in that copies of the data are created only where links to destinations split. Unicast, on the other hand is the addressing method for delivery of data from a single source to a single destination. Using unicast per individual one of a group of receivers typically requires more bandwidth than multicast to the same group.

The content information is typically transported via a data network using the MPEG-2 Transport Stream format, (MPEG-data), although other container formats are feasible, e.g., Advanced Systems Format (ASF), Audio Video Interleave (AVI), etc. As is known, the expression “container format” refers to a multiplexing format that can contain various types of data, compressed by means of audio/video codecs. Currently, there are two main approaches being used to transport MPEG-2 data using the Internet Protocol (IP).

In a first approach, the MPEG-data form the payload of UDP datagrams. The acronym “UDP” stands for User Datagram Protocol (or: Universal Datagram Protocol). UDP is not a reliable protocol in the sense that datagrams may be received out of order, may be duplicated, or may have disappeared without notice. On the other hand, UDP avoids the overhead of checking whether every datagram has actually arrived, thus making it a fast and efficient protocol for applications that do not need guaranteed delivery. Time-sensitive applications often use UDP because dropped packets are preferred to delayed packets.

In a second approach, the MPEG-data are encapsulated in UDP datagrams that themselves form the payload of Real-time Transport Protocol (RTP) packets. RTP defines a standardized packet format for delivery of real-time data, such as audio and/or video, over the Internet using the IP. RTP provides suitable functionality for carrying real-time information content, e.g., a timestamp and control mechanisms for synchronizing different streams with timing properties. An RTP packet has a header comprised of a plurality of fields, among which is the field “sequence number.” This field carries a numerical value that increments by one for each next RTP data packet transmitted. This field may be used by the receiver to detect packet loss and to restore packet sequence. Accordingly, RTP requires more overhead than UDP alone.

Now consider the scenario of a network operator multicasting content information such as a TV program from a source, e.g., a server, to a group of receivers, typically STBs or PCs, via a data network. If RTP is being used, packet loss can be easily detected at the receiver and the missing packets can be easily identified, based on the packet sequence numbers. The network operator may have reserved a buffer server that buffers at least part of the content information. When a receiver detects packet loss and identifies the missing packet, the receiver can contact the buffer server with a request to send the missing packets. The buffer server then responds by sending the missing packets to the requesting receiver. If the operations of detecting packet loss, identifying the missing packets, sending the request to the buffer server and receiving the missing packets, can be carried out in a small enough time window, the receiver can restore the integrity of the content information in time for rendering without user-perceptible artifacts.

SUMMARY

The above scenario is readily implemented if the multicasting is implemented using RTP. If, however, the multicasting is implemented using less reliable transmission protocols, such as UDP without RTP, packet loss detection may not be possible, and it may be impossible to identify which packets or datagrams may have gone missing.

The inventors now propose an elegant manner to use the less reliable transmission, thereby saving overhead and bandwidth, and nevertheless able to detect packet loss and identify lost packets at the receiver. As a consequence, the receiver can request and receive the lost packets from the buffer server in a timely manner in order to restore content information integrity.

More specifically, the inventors propose a method of multicasting content information to a plurality of receivers, via a data network, using data packets in a transport stream. The content information is encapsulated according to a container format standard that allows an optional field in a packet header. Each respective one of the data packets forms a payload of a respective datagram in a connectionless communication protocol. The method comprises using the optional field in each respective one of the data packets to carry a respective one of multiple identifiers for identifying the respective data packet in a pre-determined sequence of data packets.

In the invention, the packet header may carry the information which enables the receiver to determine whether packet loss has occurred and, if so, which packet is missing. The packet loss is tackled at a higher layer in the OSI stack than the transport layer. An advantage of the invention over the above scenario using RTP is that less overhead is required in the communication between the source of the content information and the receivers.

Connectionless telecommunication protocols are protocols used to communicate from a transmitter via a network to a receiver without prior knowledge at the transmitter that the receiver is indeed available and/or ready for receiving. The transmitter just sends the data packet to the address of the receiver. In contrast, connection-oriented protocols allow establishing a network connection between transmitter and receiver before the actual sending of the data. Connectionless protocols are therefore more susceptible to transmission problems, which often require that a message be sent several times. Connectionless protocols are also referred to as “stateless protocols” as the communicating nodes on the network are not keeping track of the communication while it is going on. Connection-oriented protocols are referred to as “stateful” protocols because they do keep track of the ongoing communication. Examples of connectionless protocols are the Internet Protocol (IP), the User Datagram Protocol (UDP), and the Transparent Inter-process Communication (TIPC). An example of a connection-oriented protocol is the Transmission Control Protocol used over IP (TCP/IP).

In one embodiment of the invention, at least part of the content information is buffered during the multicasting. Upon receipt of a specific one of the identifiers from a particular one of the receivers, a specific one of the data packets associated with the specific identifier, is sent via a unicast to the particular receiver. Preferably, a history per particular receiver is maintained of the specific data packets sent to the particular receiver via previous unicasts. Based on the history, it is then determined to send in the current unicast one or more further data packets having further ones of the identifiers belonging to a particular range of the identifiers. As data packets typically go missing in a specific temporal pattern, e.g., in bursts, this pattern can be used to forecast the number of data packets to be sent upon receipt from a specific receiver of an identifier of a next missing data packet. For example, consider a history log of a particular receiver that is submitting individual requests for individual packets. Analysis of the history log may show that the requested packets typically turn out to be clustered in batches of three packets with numerically successive identifiers. It may then be determined at the buffer that, upon receipt of the next request from this particular receiver for a specific packet, the two succeeding packets are sent together with the one just requested. In turn, the receiver may be configured to halt sending requests for succeeding packets once it receives multiple packets per unicast event. That is, a single request from a receiver for a specific packet eventually results in receiving the specific packet as well as its successors at the receiver. Thus, the network traffic generated by the requesting receivers and by the unicasts of missing packets may be optimized.

Above embodiments relate to a method and are commercially relevant to, e.g., network operators and service providers.

The invention can also be embodied by data processing equipment, e.g., a set-top box, a personal computer, a smart phone, etc. Such embodiment is relevant to the commercial exploitation of the invention by, e.g., hardware manufacturers, set makers, distributors, etc. The equipment comprises an interface to a data network configured for processing content information received via the data network as data packets in a transport stream. The content information is encapsulated according to a container format standard that allows an optional field in a packet header. Each respective one of the data packets forms a respective payload of a respective datagram in a connectionless communication protocol. The optional field in each respective one of the data packets carries a respective identifier for identifying the respective data packet in a pre-determined sequence of the data packets. The equipment is configured for determining loss of a specific one or more of the data packets on the basis of the identifiers in the data packets received and for requesting via the data network the specific one or more of the data packets.

The invention can also be embodied by control software, e.g., provided on a computer-readable medium or via a download from a server on the Internet, for control of data processing equipment, the data processing equipment comprising an interface to a data network and being configured for processing content information received as data packets in a transport stream via the interface.

It should be understood that any of the methods described herein could be implemented within hardware, software, or any combination thereof. For example, when a method is implemented in software, it should be noted that the method can be stored on any computer-readable medium for use by, or in connection with, any computer-related system or method. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by, or in connection with, a computer related system or method. The methods can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

Any process descriptions or steps described herein should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the preferred embodiments of the methods in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art. Furthermore, steps may be omitted altogether or combined with steps from other processes.

The content information is encapsulated according to a container format standard that allows an optional field in a packet header. Each respective one of the data packets forms a respective payload of a respective datagram in a connectionless communication protocol. The optional field in each respective one of the data packets carries a respective identifier for identifying the respective data packet in a pre-determined sequence of data packets. The control software comprises first instructions for determining loss of a specific one or more of the data packets on the basis of the identifiers in the data packets received, and second instructions for requesting via the data network the specific one or more of the lost data packets.

This embodiment is relevant to, e.g., the software developer, a network operator or a content provider, who markets the software as an after-market add-on to data processing equipment so as to render the equipment suitable for receiving and processing the content information.

The invention can also be embodied as a data structure representative of content information encoded as data packets for a transport stream encapsulated according to a container format standard that allows an optional field in a packet header. Each respective one of the data packets forms a respective payload of a respective datagram in a connectionless communication protocol. The optional field in each respective one of the data packets carries a respective identifier for identifying the respective data packet in a pre-determined sequence of the data packets. This embodiment is relevant to, e.g., the content provider or service provider. As known, the expression “data structure”, as specified by IEEE, refers to a physical or logical relationship among data elements, designed to support specific data processing functions.

BRIEF DESCRIPTION OF THE DRAWING

The invention is explained in further detail, by way of example and with reference to the accompanying drawing, wherein:

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a system in the invention;

<figref idrefs="DRAWINGS">FIG. 2</figref> is a diagram of a datagram with payload in the invention;

<figref idrefs="DRAWINGS">FIG. 3</figref> is a diagram illustrating a sliding window FIFO configuration of a buffer in the system of the invention; and

<figref idrefs="DRAWINGS">FIG. 4</figref> is a diagram illustrating a manner of identifying packets in accordance with an embodiment.

Throughout the Figures, similar or corresponding features are indicated by same reference numerals.

DETAILED DESCRIPTION

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a system <b>100</b> in the invention. System <b>100</b> comprises a server <b>102</b> that provides a multicast service of content information to a plurality of receivers <b>104</b>, <b>106</b>, . . . , <b>108</b>, which may be, for example, STBs, via a data network <b>110</b>. If the transmission from server <b>102</b> to receivers <b>104</b>-<b>108</b> is not reliable, and data packets may be lost on their way to any of receivers <b>104</b>-<b>108</b>, the affected receiver, e.g., receiver <b>104</b>, is preferably configured to determine that packet loss has occurred and to determine which packets have gone missing. If so, affected receiver <b>104</b> can contact a buffer server <b>112</b> via network <b>110</b>. Buffer server <b>112</b> buffers the content information, or part thereof, during the multicast service. Receiver <b>104</b> requests buffer server <b>112</b> to supply the missing packet, and buffer server <b>112</b> sends the missing packet via a unicast transmission to the address of receiver <b>104</b>. If receiver <b>104</b> receives the packet from buffer server <b>112</b> in time, receiver <b>104</b> can process the missing packet to restore integrity of the data, thus avoiding artifacts when the content information is rendered via receiver <b>104</b>.

Server <b>102</b> transmits the content information, e.g., video and/or audio, as data packets in a transport stream. The audio and/or video information is encapsulated according to a container format that allows for an optional field in a packet header. Each packet of encapsulated content information forms a payload of an associated datagram in a connectionless protocol. Examples of suitable container format standards and connectionless protocols have been given above. For the purpose of illustrating the operation of the invention, it is assumed here that the content information is encapsulated in a MPEG-2 Transport Stream and that the connectionless protocol used in the multicast is UDP.

In order to enable receiver <b>104</b> to determine that packets have gone missing, an optional field in the header of each encapsulated MPEG-2 packet is used to carry an identifier of the MPEG-2 packet. The identifiers are such that receiver <b>104</b>, upon extracting the identifiers from the packet headers of a group of encapsulated MPEG-2 packets, can determine the order of the received packets in a predetermined sequence of packets for rendering the content information, as well as their location in the sequence. Extraction of the packet headers can be done at the application level. Thus, receiver <b>104</b> can identify a specific one of the packets with respect to a successor and/or a predecessor in the pre-determined sequence of packets and therefore whether or not a specific one of the packets has not been received.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a diagram of an UDP datagram <b>200</b> to illustrate the formatting described above used by the content server <b>102</b> and STB's <b>104</b>-<b>108</b>. Datagram <b>200</b> encapsulates a data packet <b>202</b> of content information encapsulated in the MPEG Transport Stream container format. Packet <b>202</b> has a header <b>204</b> and a payload <b>206</b> of content data. Header <b>204</b> contains multiple fields of which only field <b>208</b> is shown to not obscure the drawing. Field <b>208</b> is an optional field in the MPEG Transport Stream format, and is used here to carry a packet identifier <b>210</b>. Another field (not shown) may be used to identify to buffer server <b>112</b> the content information being multicast. Upon extracting the header <b>204</b> from packet <b>202</b>, receiver <b>104</b> can determine a value of the packet identifier <b>208</b>. Receiver <b>104</b> may keep track of the identifiers of packets received from content server <b>102</b>. The identifiers are formatted such that their position can be identified in a pre-determined sequence. Receiver <b>104</b> may then determine a specific data packet that may have gone missing if the identifier associated with the specific data packet is missing from the pre-determined sequence. Receiver <b>104</b> may then send a request via network <b>110</b> to buffer server <b>112</b> to retrieve the missing packet. Buffer server <b>112</b> may respond by sending the missing packet via data network <b>110</b> to receiver <b>104</b> in a unicast transmission. Upon timely receipt of the missing packet at receiver <b>104</b>, the missing packet may be used to restore the integrity of the content information.

Now consider the scenario, wherein the receipt of the multicast content information at receiver <b>104</b> is interrupted by having it temporarily replaced by, e.g., a commercial from another source than content server <b>102</b>. The replacement may occur at a node in the signal path between content server <b>102</b> and receiver <b>104</b>, the node being upstream of receiver <b>104</b> and downstream of content server <b>102</b>. The identifier of the first data packet received after receipt of the content information has been resumed by receiver <b>104</b>, will not be the successor of the last data packet received before the commercial break. This then would cause receiver <b>104</b> to detect a discontinuity in the sequence of the identifiers, and to request the missing packets from buffer server <b>112</b> that correspond to the discontinuity as perceived by receiver <b>104</b>. In this scenario, receiver <b>104</b> should be prevented from submitting such requests. Receiver <b>104</b> may therefore be configured to set an internal flag upon detecting that data packets have started to be received from another source. For example, the detection mechanism may be based on determining whether or not the data packets as received do have an identifier in the format according to the invention. So long as the received data packets do have these specific identifiers, no flag is set. As soon as a data packet without such identifier has been received, receiver <b>104</b> sets the flag. When the flag is set, receiver <b>104</b> refrains from submitting requests to buffer server <b>112</b>. Then, after some time period, data packets start arriving at receiver <b>104</b> that do have these specific identifiers again. Upon receipt of the first one of such data packets having the specific identifiers, receiver <b>104</b> may reset the flag. Receiver <b>104</b> may then process all succeeding data packets as explained earlier and submit a request to buffer server <b>112</b> upon detection of a missing identifier.

More generically, the equipment according to the invention, e.g., receiver <b>104</b>, is configured to operate as follows. Receiver <b>104</b> detects whether a data packet is received not having the identifier, and determines based on the lack of identifier that the data packet is received from a source different from content server <b>102</b>. Upon detection of the data packet from a different source, receiver <b>104</b> disables the requesting of missing data packets from buffer server <b>112</b>, e.g., by setting a flag in a register (not shown) internal to receiver <b>104</b>. After detecting that receipt of data packets with identifiers has resumed, receiver <b>104</b> may enable the requesting of missing data packets, e.g., by means of resetting the internal flag.

As to the condition of a timely receipt, this depends on the kind of processing of the content information at receiver <b>104</b>. Consider a first scenario wherein the multicast content information is being rendered at receiver <b>104</b> upon receipt. In this scenario, a missing packet can only be used to restore integrity within a relatively small time window. Receiver <b>104</b> may actively buffer a certain amount of packets before beginning rendering so as to increase this time window, thus allowing more time for determining what packets have been lost, for requesting buffer server <b>112</b> to send these lost packets via unicast transmissions, and for local processing of the packets received via unicast in order to restore integrity before rendering. For a live program being multicast, the delay introduced between receipt via multicast and receipt via unicast is preferably in the order of a fraction of a second.

Consider a second scenario wherein the multicast content information is being recorded locally at receiver <b>104</b> for rendering with a time shift of, say, hours or days. It may then be more efficient for receiver <b>104</b> to notify buffer server <b>112</b> with a single request of a batch of missing packets, after the multicast has completed, and for buffer server <b>112</b> to transmit the batch of missing packets all at once to receiver <b>104</b> in a single unicast or in a few unicast transmissions, thus reducing data traffic between receiver <b>104</b> and buffer server <b>112</b> with respect to the first scenario.

Consider a third scenario wherein the multicast content information is initially being rendered upon receipt at receiver <b>104</b> and wherein the user of receiver <b>104</b> decides during the multicast to time-shift the rendering using the “pause”-functionality as known from personal digital video recorders (PVRs), e.g., to make a phone call. In the pause mode, the packets received via multicast are buffered locally at receiver <b>104</b>. This third scenario is then a combination of the first and second scenarios mentioned earlier. During the time period of rendering upon receipt of the multicast packets, single requests per missing packet are made to buffer server <b>112</b>. After the user has invoked the pause-functionality at receiver <b>104</b>, receiver <b>104</b> may make a single request to buffer server <b>112</b> for missing packets and, after a predetermined time has elapsed in the pause mode, begin buffering identifiers of missing packets and submitting a batch request for missing packets to buffer server <b>112</b>, either periodically or when the pause functionality is turned off. During the pause, the time of receipt at receiver <b>104</b> of the missing packets, identified during recording, is less critical then in the first scenario.

The above scenarios of conditionally sending requests to buffer <b>114</b> may be taken care of by receiver <b>104</b> at the application level. That is, software running on receiver <b>104</b> may control when to submit requests to buffer server <b>112</b> and for how many missing packets.

The above scenarios may work satisfactorily if each identifier is unique within the multicast. However, a typical piece of content information, e.g., a movie, requires a very large number of data packets to be multicast. If each individual packet has a unique identifier within the set of all packets together representing the movie, a large number of bits need to be reserved in header field <b>208</b> for accommodating an individual identifier. An embodiment of the invention therefore uses identifiers that are recurrent, e.g., cyclically recurrent, during the multicast. This requires fewer bits in header field <b>208</b>. Now, an individual packet can be uniquely identified only within a particular subset of packets being multicast.

The use of recurrent identifiers during the multicast implies that buffer server <b>112</b> and content server <b>102</b> need to synchronize in some way or another so as for buffer server <b>112</b> to be able to uniquely identify the packet identified in the request from receiver <b>104</b>.

One way is to divide the content information in multiple contiguous ranges and use a further identifier per range of identifiers that themselves are being recurrently multicast. The further identifier itself may be recurrent as well upon a certain number of recurrent ranges of packet identifiers having been used.

<figref idrefs="DRAWINGS">FIG. 3</figref> is a diagram that illustrates another way for synchronizing buffer server <b>112</b> to content server <b>102</b>. This other way is particularly suitable for the above-noted first scenario and third scenario. Buffer server <b>112</b> now only buffers part of the multicast packets in a first-in-first-out (FIFO) memory. In this manner, buffer server <b>112</b> implements a window that slides along the packet stream as multicast by server <b>102</b>, the sliding being synchronized with the multicast. The number of packets contained in this window is determined by the number of bits in the optional field. Requests from receiver <b>104</b> cannot be honored for packets that have been overwritten in the FIFO of buffer server <b>112</b>. This then imposes a time restriction on the requests from receiver <b>104</b> in order for receiver <b>104</b> to restore integrity. The time restriction depends on the width of the time window of the FIFO, the total of the amount of time needed at receiver <b>104</b> to determine the missing packet, the amount of time needed to prepare the request and send it to buffer server <b>112</b>, the amount of delay in network <b>110</b>, the amount of time needed by buffer server <b>112</b> to process the request and send the packet per unicast, again the amount of network delay, and the amount of time needed at receiver <b>104</b> to process the request and restore data integrity of the content information. This total time can be estimated in advance if the configurations of receivers <b>104</b>-<b>108</b>, and of buffer server <b>112</b> are known in advance. These latter are assumed to be fixed entities in operational use, i.e., these do not change over time. Network delay can be estimated as well, dynamically if needed so as to be able to dynamically adjust the time window at buffer server <b>112</b> in response to changes in network delay.

In the diagram of <figref idrefs="DRAWINGS">FIG. 3</figref>, reference numeral <b>302</b> indicates at a time T=t the state of the stream of MPEG-packets, encapsulated in UDP datagrams, as sequentially multicast from server <b>102</b>. Reference numerals <b>304</b> indicate the encapsulated MPEG packets that are going to be multicast next, one after the other. Reference numeral <b>306</b> indicates a sequence of data packets ordered according to their identifiers (N−k), . . . , N−1 and N. Reference numeral <b>308</b> indicates the state of buffer server <b>112</b> at time T=(t−1). For convenience, the temporal units have been chosen such that an increment in time by one unit corresponds to the transmission of a next one of the data packets in a multicast. At time T=(t−1), the FIFO of buffer server <b>112</b> stores the most recent k packets that have identifiers (N−k), . . . , N−2 and N−1. Reference numeral <b>310</b> indicates the state of buffer server <b>112</b> at time T=t, when the FIFO of buffer server <b>112</b> has deleted the packet with identifier (N−k) and has buffered the packet with identifier N. In this manner, the FIFO of buffer server <b>112</b> maintains a sliding window along the data stream, and buffer server <b>112</b> can only comply with requests received from receiver <b>104</b> that refer to a packet buffered in the FIFO at the time of receiving the request.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a diagram for explaining the use of recurrent packet identifiers in a multicast. Reference numeral <b>402</b> indicates a first subset of the MPEG packets that together are representative of the content information to be multicast. Reference numeral <b>404</b> indicates a second subset of the MPEG packets that together are representative of the content information to be multicast. Each of subsets <b>402</b> and <b>404</b> uses the same identifiers: 1, 2, . . . , (N−1) and N, for uniquely identifying a particular packet only within the respective subset. If buffer server <b>112</b> now receives a request for a packet with a particular identifier, for example identifier ID=2, then buffer server <b>112</b> cannot uniquely identify the packet meant. This is so, because each of the subsets that, combined, make up the encoded content information, includes a packet with identifier ID=2.

One way of resolving this issue is to individually label the subsets in an additional optional field in header <b>204</b>. The packet, indicated with a subset label and a packet identifier can be identified. If buffer server <b>112</b> does not store the complete content but only a part thereof that, in addition, changes according to the sliding window process indicated above, the packet can still be uniquely identified, but the request cannot be honored if the sliding window has passed the desired packet. The probability that the request can be honored increases with an increased span of the window. Note that the subset labels can then also be made recurrent so as to reduce the bits to be spent on accommodating the label with the highest value. This approach is suitable for the first and third scenarios mentioned above, wherein in the first scenario the content is rendered synchronously with the multicast, and wherein in the third scenario the content is initially rendered synchronously with the multicast, but whose rendering gets time-shifted later on.

Another way is to not label the subsets at all, but to have the FIFO span a single subset, the size of which can be chosen based on practical criterions. The FIFO then always contains a single packet per particular identifier. The minimum size of the subset, and therefore the range of the identifiers, is then chosen such that it can be used in the first scenario mentioned above, wherein the content is being rendered practically synchronously with the multicast.