Patent Grant
9246633
The present invention relates to encoding and decoding data in communications systems and more specifically to communication systems that encode and decode data to account for errors and gaps in communicated data, and to efficiently utilize communicated data emanating from more than one source.
Transmission of files between a sender and a recipient over a communications channel has been the subject of much literature. Preferably, a recipient desires to receive an exact copy of data transmitted over a channel by a sender with some level of certainty. Where the channel does not have perfect fidelity (which covers most all physically realizable systems), one concern is how to deal with data lost or garbled in transmission. Lost data (erasures) are often easier to deal with than garbled data (errors) because the recipient cannot always tell when garbled data is data received in error. Many error correcting codes have been developed to correct for erasures (so called “erasure codes”) and/or for errors (“error-correcting codes”, or “ECC's”). Typically, the particular code used is chosen based on some information about the infidelities of the channel through which the data is being transmitted and the nature of the data being transmitted. For example, where the channel is known to have long periods of infidelity, a burst error code might be best suited for that application. Where only short, infrequent errors are expected a simple parity code might be best.
File transmission between multiple senders and/or multiple receivers over a communications channel has also been the subject of much literature. Typically, file transmission from multiple senders requires coordination among the multiple senders to allow the senders to minimize duplication of efforts. In a typical multiple sender system sending one file to a receiver, if the senders do not coordinate which data they will transmit and when, but instead just send segments of the file, it is likely that a receiver will receive many useless duplicate segments. Similarly, where different receivers join a transmission from a sender at different points in time, a concern is how to ensure that all data the receivers receive from the sender is useful. For example, suppose the sender is continuously transmitting data about the same file. If the sender just sends segments of the original file and some segments are lost, it is likely that a receiver will receive many useless duplicate segments before receiving one copy of each segment in the file.
Another consideration in selecting a code is the protocol used for transmission. In the case of the global internetwork of networks known as the “Internet” (with a capital “I”), a packet protocol is used for data transport. That protocol is called the Internet Protocol or “IP” for short. When a file or other block of data is to be transmitted over an IP network, it is partitioned into equal size input symbols and input symbols are placed into consecutive packets. Being packet-based, a packet oriented coding scheme might be suitable. The “size” of an input symbol can be measured in bits, whether or not the input symbol is actually broken into a bit stream, where an input symbol has a size of M bits when the input symbol is selected from an alphabet of 2M symbols.
The Transport Control Protocol (“TCP”) is a point-to-point packet control scheme in common use that has an acknowledgment mechanism. TCP is good for one-to-one communications, where the sender and recipient both agree on when the transmission will take place and be received and both agree on which transmitters and receivers will be used. However, TCP is often not suitable for one-to-many or many-to-many communications or where the sender and the recipient independently determine when and where they will transmit or receive data.
Using TCP, a sender transmits ordered packets and the recipient acknowledges receipt of each packet. If a packet is lost, no acknowledgment will be sent to the sender and the sender will resend the packet. Packet loss has a number of causes. On the Internet, packet loss often occurs because sporadic congestion causes the buffering mechanism in a router to reach its capacity, forcing it to drop incoming packets. With protocols such as TCP/IP, the acknowledgment paradigm allows packets to be lost without total failure, since lost packets can just be retransmitted, either in response to a lack of acknowledgment or in response to an explicit request from the recipient. Either way, an acknowledgment protocol requires a back channel from the recipient to the sender.
Although acknowledgment-based protocols are generally suitable for many applications and are in fact widely used over the current Internet, they are inefficient, and sometimes completely infeasible, for certain applications. In particular, acknowledgment-based protocols perform poorly in networks with high latencies, high packet loss rates, uncoordinated recipient joins and leaves, and/or highly asymmetric bandwidth. High latency is where acknowledgments take a long time to travel from the recipient back to the sender. High latency may result in the overall time before a retransmission being prohibitively long. High packet loss rates also cause problems where several retransmissions of the same packet may fail to arrive, leading to a long delay to obtain the last one or last few unlucky packets.
“Uncoordinated recipient joins and leaves” refers to the situation where each recipient can join and leave an ongoing transmission session at their own discretion. This situation is typical on the Internet, next-generation services such as “video on demand” and other services to be offered by network providers in the future. In the typical system, if a recipient joins and leaves an ongoing transmission without coordination of the senders, the recipient will likely perceive a loss of large numbers of packets, with widely disparate loss patterns perceived by different recipients.
Asymmetric bandwidth refers to the situation is where a reverse data path from recipient to sender (the back channel) is less available or more costly than the forward path. Asymmetric bandwidth may make it prohibitively slow and/or expensive for the recipient to acknowledge packets frequently and infrequent acknowledgments may again introduce delays.
Furthermore, acknowledgment-based protocols do not scale well to broadcasting, where one sender is sending a file simultaneously to multiple users. For example, suppose a sender is broadcasting a file to multiple recipients over a satellite channel. Each recipient may experience a different pattern of packet loss. Protocols that rely on acknowledgment data (either positive or negative) for reliable delivery of the file require a back channel from each recipient to the sender, and this can be prohibitively expensive to provide. Furthermore, this requires a complex and powerful sender to be able to properly handle all of the acknowledgment data sent from the recipients. Another drawback is that if different recipients lose different sets of packets, rebroadcast of packets missed only by a few of the recipients causes reception of useless duplicate packets by other recipients. Another situation that is not handled well in an acknowledgment-based communication system is where recipients can begin a receiving session asynchronously, i.e., the recipient could begin receiving data in the middle of a transmission session.
Several complex schemes have been suggested to improve the performance of acknowledgment-based schemes, such as TCP/IP for multicast and broadcast. However none has been clearly adopted at this time, for various reasons. For one, acknowledgment-based protocols also do not scale well where one recipient is obtaining information from multiple senders, such as in a low earth orbit (“LEO”) satellite broadcast network. In an LEO network, the LEO satellites pass overhead quickly because of their orbit, so the recipient is only in view of any particular satellite for a short time. To make up for this, the LEO network comprises many satellites and recipients are handed off between satellites as one satellite goes below the horizon and another rises. If an acknowledgment-based protocol were used to ensure reliability, a complex hand-off protocol would probably be required to coordinate acknowledgments returning to the appropriate satellite, as a recipient would often be receiving a packet from one satellite yet be acknowledging that packet to another satellite.
An alternative to an acknowledgment-based protocol that is sometimes used in practice is a carousel-based protocol. A carousel protocol partitions an input file into equal length input symbols, places each input symbol into a packet, and then continually cycles through and transmits all the packets. A major drawback with a carousel-based protocol is that if a recipient misses even one packet, then the recipient has to wait another entire cycle before having a chance at receiving the missed packet. Another way to view this is that a carousel-based protocol can cause a large amount of useless duplicate data reception. For example, if a recipient receives packets from the beginning of the carousel, stops reception for a while, and then starts receiving again at the beginning of the carousel, a large number of useless duplicate packets are received.
One solution that has been proposed to solve the above problems is to avoid the use of an acknowledgment-based protocol, and instead use erasure codes such as Reed-Solomon Codes to increase reliability. One feature of several erasure codes is that, when a file is segmented into input symbols that are sent in packets to the recipient, the recipient can decode the packets to reconstruct the entire file once sufficiently many packets are received, generally regardless of which packets arrive. This property removes the need for acknowledgments at the packet level, since the file can be recovered even if packets are lost. However, many erasure code solutions either fail to solve the problems of acknowledgment-based protocol or raise new problems.
One problem with many erasure codes is that they require excessive computing power or memory to operate. One coding scheme that has been recently developed for communications applications that is somewhat efficient in its use of computing power and memory is the Tornado coding scheme. Tornado codes are similar to Reed-Solomon codes in that an input file is represented by K input symbols and is used to determine N output symbols, where N is fixed before the encoding process begins. Encoding with Tornado codes is generally much faster than encoding with Reed-Solomon codes, as the average number of arithmetic operations required to create the N Tornado output symbols is proportional to N (on the order of tens of assembly code operations times N) and the total number of arithmetic operations required to decode the entire file is also proportional to N.
Tornado codes have speed advantages over Reed-Solomon codes, but with several disadvantages. First, the number of output symbols, N, must be determined in advance of the coding process. This leads to inefficiencies if the loss rate of packets is overestimated, and can lead to failure if the loss rate of packets is underestimated. This is because a Tornado decoder requires a certain number of output symbols (specifically, K+A packets, where A is small compared to K) to decode and restore the original file and if the number of lost packets is greater than N−(K+A), then the original file cannot be restored. This limitation is generally acceptable for many communications problems, so long as N is selected to be greater than K+A by at least the actual packet loss, but this requires an advance guess at the packet loss.
Another disadvantage of Tornado codes is that they require the encoder and decoder to agree in some manner on a graph structure. Tornado codes require a pre-processing stage at the decoder where this graph is constructed, a process that slows the decoding substantially. Furthermore, a graph is specific to a file size, so a new graph needs to be generated for each file size used. Furthermore, the graphs needed by the Tornado codes are complicated to construct, and require different custom settings of parameters for different sized files to obtain the best performance. These graphs are of significant size and require a significant amount of memory for their storage at both the sender and the recipient.
In addition, Tornado codes generate exactly the same output symbol values with respect to a fixed graph and input file. These output symbols consist of the K original input symbols and N−K redundant symbols. Furthermore, N can practically only be a small multiple of K, such as 1.5 or 2 times K. Thus, it is very likely that a recipient obtaining output symbols generated from the same input file using the same graph from more than one sender will receive a large number of useless duplicate output symbols. That is because the N output symbols are fixed ahead of time and are the same N output symbols that are transmitted from each transmitter each time the symbols are sent and are the same N symbols received by a receiver. For example, suppose N=1500, K=1000 and a receiver receives 900 symbols from one satellite before that satellite dips over the horizon. Unless the satellites are coordinated and in sync, the Tornado code symbols received by the receiver from the next satellite might not be additive because that next satellite is transmitting the same N symbols, which is likely to result in the receiver receiving copies of many of the already received 900 symbols before receiving 100 new symbols needed to recover the input file.
Therefore, what is needed is a simple erasure code that does not require excessive computing power or memory at a sender or recipient to implement, and that can be used to efficiently distribute a file in a system with one or more senders and/or one or more recipients without necessarily needing coordination between senders and recipients.
In one embodiment of a communications system according to the present invention, an encoder uses an input file of data and a key to produce an output symbol, wherein the input file is an ordered plurality of input symbols each selected from an input alphabet, the key is selected from a key alphabet, and the output symbol is selected from an output alphabet. An output symbol with key I is generated by determining a weight, W(I), for the output symbol to be generated, wherein the weights W are positive integers that vary between at least two values over the plurality of keys, selecting W(I) of the input symbols associated with the output symbol according to a function of I, and generating the output symbol's value B(I) from a predetermined value function F(I) of the selected W(I) input symbols. The encoder may be called one or more times, each time with another key, and each such time it produces an output symbol. The output symbols are generally independent of each other, and an unbounded number (subject to the resolution of I) can be generated, if needed.
In a decoder according to the present invention, output symbols received by a recipient are output symbols transmitted from a sender, which generated those output symbols based on an encoding of an input file. Because output symbols can be lost in transit, the decoder operates properly even when it only receives an arbitrary portion of the transmitted output symbols. The number of output symbols needed to decode the input file is equal to, or slightly greater than, the number of input symbols comprising the file, assuming that input symbols and output symbols represent the same number of bits of data.
In one decoding process according to the present invention, the following steps are performed for each received output symbol: 1) identify the key I of the received output symbol; 2) identify the received output symbol value B(I) for output symbol; 3) determine the weight, W(I), of the output symbol, 4) determine positions for the W(I) associated input symbols associated with the output symbol, and 5) store B(I) in an output symbol table along with the weight W(I) and the positions of the associated input symbols. The following process is then applied repeatedly until there are no more unused output symbols of weight one: 1) for each stored output symbol that has a weight of one and is not denoted as a “used up” output symbol, calculate the position J of the unique remaining unrecovered input symbol associated with the output symbol based on its key I; 2) calculate the value for input symbol J from the output symbol; 3) identify the output symbols in the output symbol table that have input symbol J as an associate; 4) recalculate the values B for the identified output symbols so that they are independent of input symbol J; 5) decrement by one the weights of these identified output symbols; and 6) denote input symbol J as recovered and the output symbol with key I as used up. This process is repeated until the ordered set of input symbols is recovered, i.e., until the entire input file is completely recovered.
One advantage of the present invention is that it does not require that the recipient begin receiving at any given point in the transmission and it does not require that the sender stop after a set number of output symbols are generated, since the sender can send an effectively unbounded set of output symbols for any given input file. Instead, a recipient can begin reception when it is ready, and from wherever it can, and can lose packets in a random pattern, and still have a good chance that the great majority of the data received is “information additive” data, i.e., data that helps in the recovery process rather than being duplicative of information already available. The fact that independently generated (often randomly unrelated) data streams are coded in an information additive way leads to many advantages in that it allows for multiple source generation and reception, erasure robustness and uncoordinated joins and leaves.
A further understanding of the nature and the advantages of the inventions disclosed herein may be realized by reference to the remaining portions of the specification and the attached drawings.
a) is a flowchart of process that might be used by a recovery processor, such as the recovery processor shown in
b)-(c) form a flowchart of portions of a variation of the process of
Appendix A is a source code listing of a program for implementing a weight distribution.
In the examples described herein, a coding scheme denoted as “chain reaction coding” is described, preceded by an explanation of the meaning and scope of various terms used in this description.
With chain reaction coding, output symbols are generated by the sender from the input file as needed. Each output symbol can be generated without regard to how other output symbols are generated. At any point in time, the sender can stop generating output symbols and there need not be any constraint as to when the sender stops or resumes generating output symbols. Once generated, these symbols can then be placed into packets and transmitted to their destination, with each packet containing one or more output symbols.
As used herein, the term “file” refers to any data that is stored at one or more sources and is to be delivered as a unit to one or more destinations. Thus, a document, an image, and a file from a file server or computer storage device, are all examples of “files” that can be delivered. Files can be of known size (such as a one megabyte image stored on a hard disk) or can be of unknown size (such as a file taken from the output of a streaming source). Either way, the file is a sequence of input symbols, where each input symbol has a position in the file and a value.
Transmission is the process of transmitting data from one or more senders to one or more recipients through a channel in order to deliver a file. If one sender is connected to any number of recipients by a perfect channel, the received data can be an exact copy of the input file, as all the data will be received correctly. Here, we assume that the channel is not perfect, which is the case for most real-world channels, or we assume that the data emanates from more than one sender, which is the case for some systems. Of the many channel imperfections, two imperfections of interest are data erasure and data incompleteness (which can be treated as a special case of data erasure). Data erasure occurs when the channel loses or drops data. Data incompleteness occurs when a recipient doesn't start receiving data until some of the data has already passed it by, the recipient stops receiving data before transmission ends, or the recipient intermittently stops and starts again receiving data. As an example of data incompleteness, a moving satellite sender might be transmitting data representing an input file and start the transmission before a recipient is in range. Once the recipient is in range, data can be received until the satellite moves out of range, at which point the recipient can redirect its satellite dish (during which time it is not receiving data) to start receiving the data about the same input file being transmitted by another satellite that has moved into range. As should be apparent from reading this description, data incompleteness is a special case of data erasure, since the recipient can treat the data incompleteness (and the recipient has the same problems) as if the recipient was in range the entire time, but the channel lost all the data up to the point where the recipient started receiving data. Also, as is well known in the communication systems design, detectable errors can be the equivalent of erasures by simply dropping all data blocks or symbols that have detectable errors.
In some communication systems, a recipient receives data generated by multiple senders, or by one sender using multiple connections. For example, to speed up a download, a recipient might simultaneously connect to more than one sender to transmit data concerning the same file. As another example, in a multicast transmission, multiple multicast data streams might be transmitted to allow recipients to connect to one or more of these streams to match the aggregate transmission rate with the bandwidth of the channel connecting them to the sender. In all such cases, a concern is to ensure that all transmitted data is of independent use to a recipient, i.e., that the multiple source data is not redundant among the streams, even when the transmission rates are vastly different for the different streams, and when there are arbitrary patterns of loss.
In general, transmission is the act of moving data from a sender to a recipient over a channel connecting the sender and recipient. The channel could be a real-time channel, where the channel moves data from the sender to the recipient as the channel gets the data, or the channel might be a storage channel that stores some or all of the data in its transit from the sender to the recipient. An example of the latter is disk storage or other storage device. In that example, a program or device that generates data can be thought of as the sender, transmitting the data to a storage device. The recipient is the program or device that reads the data from the storage device. The mechanisms that the sender uses to get the data onto the storage device, the storage device itself and the mechanisms that the recipient uses to get the data from the storage device collectively form the channel. If there is a chance that those mechanisms or the storage device can lose data, then that would be treated as data erasure in the channel.
When the sender and recipient are separated by a data erasure channel, it is preferable not to transmit an exact copy of an input file, but instead to transmit data generated from the input file that assists with recovery of erasures. An encoder is a circuit, device, module or code segment that handles that task. One way of viewing the operation of the encoder is that the encoder generates output symbols from input symbols, where a sequence of input symbol values represent the input file. Each input symbol would thus have a position, in the input file, and a value. A decoder is a circuit, device, module or code segment that reconstructs the input symbols from the output symbols received by the recipient.
Chain reaction coding is not limited to any particular type of input symbol, but the type of input symbol is often dictated by the application. Typically, the values for the input symbols are selected from an alphabet of 2M symbols for some positive integer M. In such cases, an input symbol can be represented by a sequence of M bits of data from the input file. The value of M is often determined based on the uses of the application and on the channel. For example, for a packet-based Internet channel, a packet with a payload of size of 1024 bytes might be appropriate (a byte is 8 bits). In this example, assuming each packet contains one output symbol and 8 bytes of auxiliary information, an input symbol size of M=(1024−8)·8, or 8128 bits would be appropriate. As another example, some satellite systems use the MPEG packet standard, where the payload of each packet comprises 188 bytes. In that example, assuming each packet contains one output symbol and 4 bytes of auxiliary information, a symbol size of M=(188−4)·8, or 1472 bits would be appropriate. In a general-purpose communication system using chain reaction coding, the application-specific parameters, such as the input symbol size (i.e., M, the number of bits encoded by an input symbol), might be variables set by the application.
Each output symbol has a value. In one preferred embodiment, which we consider below, each output symbol has an identifier called its “key.” Preferably, the key of each output symbol can be easily determined by the recipient to allow the recipient to distinguish one output symbol from other output symbols. Preferably, the key of an output symbol is distinct from the keys of all other output symbols. Also preferably, as little data as possible is included in the transmission in order for a recipient to determine the key of a received output symbol.
In a simple form of keying, the sequence of keys for consecutive output symbols generated by an encoder is a sequence of consecutive integers. In this case, each key is called a “sequence number”. In the case where there is one output symbol value in each transmitted packet, the sequence number can be included in the packet. Since sequence numbers can typically fit into a small number of bytes, e.g., 4 bytes, including the sequence number along with the output symbol value in some systems is economical. For example, using UDP Internet packets of 1024 bytes each, allocating 4 bytes in each packet for the sequence number incurs only a small overhead of 0.4%.
In other systems, it is preferable to form a key from more than one piece of data. For example, consider a system that includes a recipient receiving more than one data stream generated from the same input file from one or more senders, where the transmitted data is a stream of packets, each containing one output symbol. If all such streams use the same set of sequence numbers as keys, then it is likely that the recipient will receive output symbols with the same sequence numbers. Since output symbols with the same key, or in this case with the same sequence number, contain identical information about the input file, this causes useless reception of duplicate data by the recipient. Thus, in such a situation it is preferred that the key comprise a unique stream identifier paired with a sequence number.
For example, for a stream of UDP Internet packets, the unique identifier of a data stream could include the IP address of the sender and the port number that the sender is using to transmit the packets. Since the IP address of the sender and the port number of the stream are parts of the header of each UDP packet, there is no additional space required in each packet to ensure that these parts of the key are available to a recipient. The sender need only insert a sequence number into each packet together with the corresponding output symbol, and the recipient can recreate the entire key of a received output symbol from the sequence number and from the packet header. As another example, for a stream of IP multicast packets the unique identifier of a data stream could include the IP multicast address. Since the IP multicast address is part of the header of each IP multicast packet, the remarks made above about UDP packets apply to this situation as well.
Keying by the position of the output symbol is preferred when it is possible. Position keying might work well for reading output symbols from a storage device, such as a CD-ROM (Compact Disk Read-Only-Memory), where the key of an output symbol is its position on the CD-ROM (i.e., track, plus sector, plus location within the sector, etc.). Position keying might also work well for a circuit based transmission system, such as an ATM (Asynchronous Transfer Mode) system, where ordered cells of data are transmitted under tight timing constraints. With this form of keying, the recipient can recreate the key of an output symbol with no space required for explicitly transmitting the key. Position keying, of course, requires that such position information be available and reliable.
Keying by position might also be combined with other keying methods. For example, consider a packet transmission system where each packet contains more than one output symbol. In this case, the key of the output symbol might be constructed from a unique stream identifier, a sequence number, and the position of the output symbol within the packet. Since data erasures generally result in the loss of entire packets, the recipient generally receives a full packet. In this case, the recipient can recreate the key of an output symbol from the header of the packet (which contains a unique stream identifier), the sequence number in the packet, and the position of the output symbol within the packet.
Another form of keying that is preferred in some systems is random keying. In these systems, a random (or pseudo-random) number is generated, used as the key for each output symbol and explicitly transmitted with the output symbol. One property of random keying is that the fraction of keys that have the same value is likely to be small, even for keys generated by different senders at different physical locations (assuming the range of possible keys is large enough). This form of keying may have the advantage over other forms in some systems because of the simplicity of its implementation.
As explained above, chain reaction coding is useful where there is an expectation of data erasure or where the recipient does not begin and end reception exactly when a transmission begins and ends. The latter condition is referred to herein as “data incompleteness”. These conditions do not adversely affect the communication process when chain reaction coding is used, because the chain reaction coding data that is received is highly independent so that it is information additive. If most random collections of output symbols are independent enough to be largely information additive, which is the case for the chain reaction coding systems described herein, then any suitable number of packets can be used to recover an input file. If a hundred packets are lost due to a burst of noise causing data erasure, an extra hundred packets can be picked up after the burst to replace the loss of the erased packets. If thousands of packets are lost because a receiver did not tune into a transmitter when it began transmitting, the receiver could just pickup those thousands of packets from any other period of transmission, or even from another transmitter. With chain reaction coding, a receiver is not constrained to pickup any particular set of packets, so it can receive some packets from one transmitter, switch to another transmitter, lose some packets, miss the beginning or end of a given transmission and still recover an input file. The ability to join and leave a transmission without receiver-transmitter coordination greatly simplifies the communication process.
A Basic Implementation
Transmitting a file using chain reaction coding involves generating, forming or extracting input symbols from an input file, encoding those input symbols into one or more output symbols, where each output symbol is generated based on its key independently of all other output symbols, and transmitting the output symbols to one or more recipients over a channel. Receiving (and reconstructing) a copy of the input file using chain reaction coding involves receiving some set or subset of output symbols from one of more data streams, and decoding the input symbols from the values and keys of the received output symbols.
As will be explained, the decoder can recover an input symbol from the values of one or more output symbols and possibly from information about the values of other input symbols that have already been recovered. Thus, the decoder can recover some input symbols from some output symbols, which in turn allows the decoder to decode other input symbols from those decoded input symbols and previously received output symbols, and so on, thus causing a “chain reaction” of recovery of input symbols of a file being reconstructed at the recipient.
Aspects of the invention will now be described with reference to the figures.
Key generator 120 generates a key for each output symbol to be generated by the encoder 115. Each key is generated according to one of the methods described previously, or any comparable method that insures that a large fraction of the keys generated for the same input file are unique, whether they are generated by this or another key generator. For example, key generator 120 may use a combination of the output of a counter 125, a unique stream identifier 130, and/or the output of a random generator 135 to produce each key. The output of key generator 120 is provided to encoder 115.
From each key I provided by key generator 120, encoder 115 generates an output symbol, with a value B(I), from the input symbols provided by the input symbol generator. The value of each output symbol is generated based on its key and on some function of one or more of the input symbols, referred to herein as the output symbol's “associated input symbols” or just its “associates”. The selection of the function (the “value function”) and the associates is done according to a process described in more detail below. Typically, but not always, M is the same for input symbols and output symbols, i.e., they both code for the same number of bits.
In some embodiments, the number K of input symbols is used by the encoder to select the associates. If K is not known in advance, such as where the input is a streaming file, K can be just an estimate. The value K might also be used by encoder 115 to allocate storage for input symbols.
Encoder 115 provides output symbols to a transmit module 140. Transmit module 140 is also provided the key of each such output symbol from the key generator 120. Transmit module 140 transmits the output symbols, and depending on the keying method used, transmit module 140 might also transmit some data about the keys of the transmitted output symbols, over a channel 145 to a receive module 150. Channel 145 is assumed to be an erasure channel, but that is not a requirement for proper operation of communication system 100. Modules 140, 145 and 150 can be any suitable hardware components, software components, physical media, or any combination thereof, so long as transmit module 140 is adapted to transmit output symbols and any needed data about their keys to channel 145 and receive module 150 is adapted to receive symbols and potentially some data about their keys from channel 145. The value of K, if used to determine the associates, can be sent over channel 145, or it may be set ahead of time by agreement of encoder 115 and decoder 155.
As explained above, channel 145 can be a real-time channel, such as a path through the Internet or a broadcast link from a television transmitter to a television recipient or a telephone connection from one point to another, or channel 145 can be a storage channel, such as a CD-ROM, disk drive, Web site, or the like. Channel 145 might even be a combination of a real-time channel and a storage channel, such as a channel formed when one person transmits an input file from a personal computer to an Internet Service Provider (ISP) over a telephone line, the input file is stored on a Web server and is subsequently transmitted to a recipient over the Internet.
Because channel 145 is assumed to be an erasure channel, communications system 100 does not assume a one-to-one correspondence between the output symbols that exit receive module 150 and the output symbols that go into transmit module 140. In fact, where channel 145 comprises a packet network, communications system 100 might not even be able to assume that the relative order of any two or more packets is preserved in transit through channel 145. Therefore, the key of the output symbols is determined using one or more of the keying schemes described above, and not necessarily determined by the order in which the output symbols exit receive module 150.
Receive module 150 provides the output symbols to a decoder 155, and any data receive module 150 receives about the keys of these output symbols is provided to a key regenerator 160. Key regenerator 160 regenerates the keys for the received output symbols and provides these keys to decoder 155. Decoder 155 uses the keys provided by key regenerator 160 together with the corresponding output symbols, to recover the input symbols (again IS(0), IS(1), IS(2), . . . ). Decoder 155 provides the recovered input symbols to an input file reassembler 165, which generates a copy 170 of input file 101 or input stream 105.
A Basic Encoder
Encoder 115 is provided with input symbols and a key for each output symbol it is to generate. As shown, the K input symbols are stored in an input symbol buffer 205. Key I (provided by the key generator 120 shown in
In operation, the K input symbols are received and stored in input symbol buffer 205. As explained above, each input symbol has a position (i.e., its original position in the input file) and a value. The input symbols need not be stored in input symbol buffer 205 in their respective order, so long as the position of stored input symbols can be determined.
Using key I and the number of input symbols K, weight selector 215 determines the number W(I) of input symbols that are to be “associates” of the output symbol having key I. Using key I, weight W(I) and the number of input symbols K, associator 220 determines the list AL(I) of positions of input symbols associated with the output symbol. It should be understood that W(I) need not be separately or explicitly calculated if associator 220 can generate AL(I) without knowing W(I) ahead of time. Once AL(I) is generated, W(I) can be easily determined because it is the number of associates in AL(I).
Once I, W(I) and AL(I) are known, the value B(I) of the output symbol is calculated by calculator 225 based on a value function F(I). One property of a suitable value function is that it would allow the value for an associate in AL(I) to be determined from output symbol value B(I) and from the values for the other W(I)−1 associates in AL(I). One preferred value function used in this step is the XOR value function, since it satisfies this property, is easily computed and easily inverted. However, other suitable value functions might be used instead.
If used, value function selector 210 determines a value function F(I) from key I and from K. In one variation, the value function F(I) is the same value function F for all I. In that variation, value function selector 210 is not needed and calculator 225 can be configured with the value function F. For example, the value function might be XOR for all I, i.e., the output symbol value is an XOR (exclusive OR) of the values of all of its associates.
For each key I, weight selector 215 determines a weight W(I) from I and K. In one variation, weight selector 215 selects W(I) by using the key I to first generate a random looking number and then uses this number to look up the value of W(I) in a distribution table that is stored within weight selector 215. A more detailed description of how such a distribution table might be formed and accessed is given below. Once weight selector 215 determines W(I), this value is provided to associator 220 and to calculator 225.
Associator 220 determines a list AL(I) of the positions of the W(I) input symbols associated with the current output symbol. The association is based on the value of I, on the value of W(I) and on K (if available). Once associator 220 determines AL(I), AL(I) is provided to calculator 225. Using list AL(I), weight W(I) and either the value function F(I) provided by value function selector 210 or a preselected value function F, calculator 225 accesses the W(I) input symbols referenced by AL(I) in input symbol buffer 205 to calculate the value, B(I), for the current output symbol. An example of a procedure for calculating AL(I) is given below, but another suitable procedure might be used instead. Preferably, the procedure gives each input symbol a roughly even chance of being selected as an associate for a given output symbol and does the selection in a way that the decoder can replicate if the decoder does not already have AL(I) available to it.
Encoder 115 then outputs B(I). In effect, encoder 115 performs the action illustrated in
B(I)=IS(0) XOR IS(2) XOR IS(3)
for that value of I.
The generated output symbols are then transmitted and received as described above. Herein, it is assumed that some of the output symbols might have been lost or gotten out of order, or were generated by one or more encoders. It is assumed, however, that the output symbols that are received have been received with an indication of their key and some assurance their values B(I) are accurate. As shown in
The number of bits, M, encoded in an input symbol (i.e., its size) is dependent on the application. The size of an output symbol is also dependent on the application, but might also be dependent on the channel. For example, if the typical input file is a multiple megabyte file, the input file might be broken into thousands, tens of thousands, or hundreds of thousands of input symbols with each input symbol encoding a few, tens, hundreds or thousands of bytes.
In some cases, the coding process might be simplified if the output symbol values and the input symbol values were the same size (i.e., representable by the same number of bits or selected from the same alphabet). If that is the case, then the input symbol value size is limited when the output symbol value size is limited, such as when it is desired to put output symbols in packets and each output symbol must fit into a packet of limited size. If some data about the key were to be transmitted in order to recover the key at the receiver, the output symbol would preferably be small enough to accommodate the value and the data about the key in one packet.
As described above, although the positions of the input symbols are typically consecutive, in many implementations, the keys are far from consecutive. For example, if an input file were divided up into 60,000 input symbols, the positions for the input symbols would range from 0 to 59,999, while in one of the implementations mentioned previously, each key might be independently chosen as a random 32-bit number and the output symbols might be generated continuously and transmitted until the sender is stopped. As shown herein, chain reaction coding allows the 60,000 symbol input file to be reconstructed from any sufficiently large collection (60,000+some increment A) of output symbols regardless of where in the output sequence those output symbols where taken.
A Basic Decoder
In operation, for each received output symbol with key I and value B(I), decoder 155 does the following. Key I is provided to value function selector 210, weight selector 215 and associator 220. Using K and key I, weight selector 215 determines weight W(I). Using K, key I and W(I), associator 220 produces the list AL(I) of W(I) positions of input symbols associated with the output symbol. Optionally, using K and I, value function selector 210 selects value function F(I). Then, I, B(I), W(I) and AL(I), and optionally F(I), are stored in a row of output symbol buffer 405. Value function selector 210, weight selector 215 and associator 220 perform the same operation for decoder 155 as described for encoder 115. In particular, the value function F(I), the weight W(I) and the list AL(I) produced by value function selector 210, by weight selector 215 and by associator 220 in
Reconstructor 420 scans output symbol buffer 405 looking for output symbols stored there that have weight one, i.e., W(I)=1 and AL(I) lists the position of just one associate. Those symbols are referred to herein as members of a “decodable set.” For value functions with the properties described above, output symbols of weight one are in the decodable set because a value of an input symbol can be determined from that output symbol. Of course, if a value function were used that would allow input symbols to be decoded under a condition other than having a weight of one, that condition would be used to determine whether an output symbol is in the decodable set. For clarity, the examples described here assume that the decodable set is those output symbols with weight one, and extensions of these examples to other value function decodable conditions should be apparent from this description.
When reconstructor 420 finds an output symbol that is in the decodable set, the output symbol's value B(I) and optionally the value function F(I) is used to reconstruct the input symbol listed in AL(I) and the reconstructed input symbol is placed into reconstruction buffer 425 at the appropriate position for that input symbol. If the indicated input symbol had already been reconstructed, the reconstructor 420 could drop the newly reconstructed input symbol, overwrite the existing reconstructed input symbol, or compare the two and issue an error if they differ. Where the value function is an XOR of all the associates, the input symbol value is simply the output symbol's value. Reconstructor 420 thus reconstructs input symbols, but only from output symbols in the decodable set. Once an output symbol from the decodable set is used to reconstruct an input symbol it can be deleted to save space in output symbol buffer 405. Deleting the “used up” output symbol also ensures that reconstructor 420 does not continually revisit that output symbol.
Initially, reconstructor 420 waits until at least one output symbol is received that is a member of the decodable set. Once that one output symbol is used, the decodable set would be empty again, except for the fact that some other output symbol might be a function of only that one reconstructed input symbol and one other input symbol. Thus, reconstructing one input symbol from a member of the decodable set might cause other output symbols to be added to the decodable set. The process of reduction of output symbols to add them to the decodable set is performed by reducer 415.
Reducer 415 scans output symbol buffer 405 and reconstruction buffer 425 to find output symbols that have lists AL(I) that list positions of input symbols that have been recovered. When reducer 415 finds such a “reducible” output symbol with key I, reducer 415 obtains the value IS(R) of a recovered input symbol at position R and modifies B(I), W(I) and AL(I) as follows:
B(I) is reset to B(I) XOR IS(R)
W(I) is reset to W(I)−1
AL(I) is reset to AL(I) excluding R
In the equations above, it is assumed that the value function was an XOR of all the associates' values. Note that XOR is its own inverse—if that were not the case and another value function was used originally to compute the output symbol, then the inverse of that value function would be used here by reducer 415. As should be apparent, if the values for more than one associate are known, the equivalent of the above equations can be calculated to make B(I) dependent only on any unknown associate values (and adjust W(I) and L(I) accordingly).
The action of reducer 415 reduces the weights of output symbols in output symbol buffer 405. When an output symbol's weight is reduced to one (or other decodable condition occurs for other value functions), then that output symbol becomes a member of the decodable set, which can then be acted upon by reconstructor 420. In practice, once a sufficient number of output symbols are received, reducer 415 and reconstructor 420 create a chain reaction decoding, with reconstructor 420 decoding the decodable set to recover more input symbols, reducer 415 using those freshly recovered input symbols to reduce more output symbols so they are added to the decodable set, and so on, until all input symbols from the input file are recovered.
The decoder shown in
A More Efficient Decoder
OSDS 505 is a table that stores information about output symbols, where row R of OSDS 505 stores information about the R-th output symbol that is received. A variable R keeps track of the number of output symbols that have been received, and it is initialized to zero. OSDS 505 stores the fields KEY, VALUE, WEIGHT and XOR_POS for each row, with the fields shown organized in columns. The KEY field stores the key of the output symbol. The VALUE field stores the output symbol value, which is updated during processing. All output symbols that are eventually used to recover an input symbol eventually have their VALUE modified to the recovered input symbol value. The WEIGHT field stores the initial weight of the output symbol. The WEIGHT of an output symbol is reduced over time until it becomes one and then can be used to recover an input symbol. The XOR_POS field initially stores the XOR of all the positions of the associates of the output symbol. When the WEIGHT of an output symbol becomes one, the XOR_POS of the output symbol becomes the position of the one remaining associate.
ISDS 510 is a table that stores information about input symbols, where row P stores information about the input symbol at position P. For each row ISDS 510 includes storage for a REC_ROW field, which eventually becomes the row number in OSDS 505 of the output symbol that is used to recover the input symbol, a REC_IND field, which is initialized to all values “no” and indicates whether or not input symbols have been recovered, and an RL field. When an input symbol is recovered, the REC_IND of the input symbol is changed to “yes”. The RL column is initialized to all “empty list” values. As output symbols are received that have an input symbol as an associate, the row number in OSDS 505 of the output symbol is added to the RL list for the input symbol.
DSS 515 is a stack that stores information about the decodable set. A variable S keeps track of the size of the decodable set, and it is initialized to zero. In DSS 515, column OUT_ROW stores row numbers in OSDS 505 of output symbols, and column IN_POS stores the positions in ISDS 510 of the input symbols that can be recovered.
In one embodiment, decoder 500 operates as follows and as shown in the flowchart of
A flowchart that describes the operation of receive organizer 520 is shown in
Referring again to
A flowchart that describes one operation of recovery processor 525 is shown in
Referring still to
A variation of the process shown in
In either variation, i.e., in either
An Associator Implementation
The mapping from an output symbol key to associated input symbols (i.e., the determination of the weight W(I) and the list AL(I) of positions of associates for a key I) can take a variety of forms. W(I) should be chosen to be the same value by both the encoder and decoder for the same key I (in the sender and the recipient, respectively). Similarly, AL(I) should be chosen to contain the same list of positions by both encoder and decoder for the same key I. The associator is the object that calculates or generates AL(I) from I and usually W(I) and K.
In one embodiment, W(I) and AL(I) are determined in a manner designed to mimic a random process. To satisfy the requirement that the encoder and decoder produce the same result with respect to the same key, a pseudorandom sequence could be generated by both encoder and decoder seeded with the key. Instead of a pseudorandom sequence, a truly random sequence might be used for the generation of W(I) and/or AL(I), but for that to be useful, the random sequence used for generating W(I) and AL(I) would need to be communicated to the recipient.
In the decoder shown in
A preferred embodiment of associator 220 is shown in
The input to associator 220 is a key I, the number of input symbols K, and a weight W(I). The output is a list AL(I) of the W(I) positions of associates of the output symbol with key I. As shown in
In this embodiment, ASSOC_CALC 910 operates as described below and as shown in the flowchart of
One advantage of the above approach to calculating AL(I) is that it produces enough variety in the distribution on the positions of the associates to ensure that the decoding algorithm works with high probability with minimal reception overhead (i.e., the input file is recovered after receiving only slightly more than K output symbols, assuming input symbols and output symbols are the same length) when coupled with a good procedure for selecting W(I).
A Weight Selector Implementation
The performance and efficiency of the encoder/decoder is dependent on the distribution of weights and some distributions are better than others. The operational aspects of weight selection are discussed below, followed by a description of some important weight distributions. The block diagram of
As shown in
As shown in
Other variations of implementing a weight selector and associator include generating I pseudorandomly and generating W(I) and AL(I) directly from I. As should be apparent, W(I) can be determined by examining AL(I), since W(I) is the equal to the number of associates in AL(I). It should be apparent from this description that many other methods of generating W(I) values are equivalent to the just-described system to generate a set of W(I) values with the distribution defined by WT_DISTRIB.
An Alternative Decoder
Upon reading this disclosure, it should be clear to those of skill in the art that a receiver can work more efficiently than the implementations described above. For example, the receiver might be more efficient if it buffered packets and only applied the recovery rule once a group of packets arrived. This modification reduces computational time spent in doing subsequently unnecessary operations and reduces overhead due to context switching. In particular, since the decoder cannot hope to recover the original file of K input symbols before at least K output symbols (assume same size input and output symbols) arrive in K packets (assume one symbol per packet), it is beneficial to wait until at least K packets arrive before beginning the decoding process.
It is advantageous to minimize the storage required for the decoder's auxiliary data structures as much as possible. As already described, storage for the associates list for each output symbol is not needed, since associator 220 can be used to quickly calculate those lists as needed. Another storage need is for storing, for each as yet unrecovered input symbol, the row number in OSDS 505 of the output symbols that have the input symbol as an associate, i.e., the space for the lists shown in the RL column in table ISDS 510 of
A Presorting Decoder
A more preferred embodiment of the decoder is now described, referring to
Processing output symbols in batches of appropriate sizes in order of increasing weight lowers the memory requirements as well as the processing requirements.
As shown in
The row numbers in OSDS 505 of received output symbols are stored in table WEIGHT SORT 1405 of
Normally, K+A output symbols will suffice to recover all input symbols. However, some sets of K+A packets might not suffice to recover all input symbols. In such cases, batches of G additional packets are received and then processed until all input symbols are recovered. A good setting for G is √K.
At this point in the process, the first five output symbols in order of increasing weight have been processed, the sixth output symbol in row 2 of OSDS 505 has been processed by receive organizer 520 and this sixth output symbol is just about to be processed by recovery processor 525. Output symbols in rows 0, 1, 3 and 5 have already been added to the schedule to eventually recover input symbols in positions 0, 3, 2 and 1, respectively. The output symbol in row 4 of OSDS 505 has two associates at positions 4 and 5 that have not as yet been recovered, and thus there are links from positions 4 and 5 in ISDS 510 back to row 4 in OSDS 505. The output symbol in row 2 of OSDS 505 has four associates in positions 0, 1, 3, and 5. The three associates in positions 0, 1 and 3 have already been marked as recovered, and thus there is no link from them back to row 2 (they caused the weight of this output symbol to be reduced from 4 to 1, which will trigger the recovery of the remaining input symbols in positions 4 and 5 once recovery processor 525 is executed). The associate in position 5 has not been recovered, and thus the receive organizer 520 added a link from position 5 in ISDS 510 to row 2 in OSDS 505. This is all shown in
In general, the savings in storage space for links is dramatically reduced when using the process described in
Selecting a Weight Distribution
An important optimization is to design the coding process so that an input file can be fully reconstructed with as few output symbols as possible. This optimization is helpful where the transmission time and bandwidth is costly or limited, or where an input file must be decoded quickly, without waiting for additional output symbols. Typically, the sufficient number of output symbols needed to reconstruct an input file is slightly larger than the number of input symbols in the original input file (assuming the same size input and output symbols). It can be shown that an arbitrary input file cannot be recovered when fewer bits have been received than are in the input file. Therefore, a perfect coding scheme will allow recovery of an input file from any set of output symbols encoding the same number of bits as the input file, and one measure of coding efficiency is how few extra bits are needed under expected conditions.
In the decoder shown in
This point is illustrated in
Efficiency is improved by limiting the number of times a decodable set member, which has but one associated input symbol in the case of an XOR value function, has an already reconstructed input symbol as its associate. This can be accomplished by suitable selection of the function for generating W(I).
Thus, while it is possible to completely recover an input file with any desired degree of certainty, by receiving enough output symbols, it is preferable to design a chain reaction coding communications system such that there is a high probability of recovering the K input symbols comprising a complete input file with as few as K+A output symbols (assume the same size for input symbols and output symbols) for some small value of A. The minimum value for A is zero, and can be achieved in some coding schemes, such as Reed-Solomon coding, but in accepting some small nonzero value for A, an improved communications system can be obtained.
Small values of A can be achieved in chain reaction coding by using the appropriate distributions determine the weight distribution for output symbols, i.e., the distribution of W(I) over all I, and the distribution of associates over the output symbols, i.e., the memberships of AL(I) over all I. It should be emphasized that while the decoding process can be applied regardless of the weight distribution and the distribution on the choice of the associates, the preferred embodiments will use weight distributions and distributions on the choice of associates specifically chosen for near optimal performance. In fact, many distributions will perform well, as small variations in the chosen distribution may lead to only small changes in performance.
The methodology for determining the distributions in one preferred embodiment will now be described. The actual weight distributions used are based on an ideal mathematical distribution. In the ideal weight distribution, the weights W(I) are chosen according to an “ideal” probability distribution. The smallest weight is one and the largest weight is K, where K is the number of input symbols. In the ideal distribution, a weight equal to a value of i is chosen with the following probability p:
for i=1: p=1/K; and
for i=2, . . . , K: p=1/(i(i−1)).
Once a weight W(I) chosen, a list AL(I) of W(I) associated input symbols are chosen independently and uniformly at random (or pseudorandomly, if needed), making sure that all chosen associates are distinct. Thus, the first associate is randomly selected among the K input symbols, each having a probability of 1/K of being selected. The second associate (if W>1) is then randomly selected among the remaining K−1 symbols. The weight probability distribution shown above has the property that if the system behaved exactly as expected, exactly K output symbols would be sufficient to decode and recover all input symbols. This expected behavior for the ideal distribution is shown in
Generally, the best parameters for a given setting can be found by computer simulation. However, a simple variation on the ideal weight distribution is an effective option. In this simple variation, the ideal weight distribution is modified slightly by increasing the probability of output symbols of weight one and of high weight output symbols, to reduce the chance of the decodable set emptying before the K+A output symbols are processed. The extra supply of weight one output symbols decreases the chance that the process will run out of weight one output symbols (i.e., empty the decodable set) until the recovery process is near the end of the recovery of the input symbols. The extra supply of high weight output symbols increases the chance that, near the end of the recovery process, for each yet unrecovered input symbol there will be at least one output symbol that will have that input symbol as its unique remaining associate.
More specifically, the modified weight distribution is as follows:
for i=1: p=n·R1/K;
for i=2, . . . , (K/R2−1): p=n/(i(i−1)(1−iR2/K));
and
for i=K/R2, . . . , K: p=n·HW(i)
where K is the number of input symbols, R1 and R2 are tunable parameters and n is a normalization factor used so that the p values all sum to one.
The calculation of HW(i) and sample values for R1 and R2 are shown in detail in Appendix A. There, the C++ symbols nStartRippleSize, nRippleTargetSize and nSegments correspond with R1, R2 and K, respectively, in the above equations.
This modified distribution is similar to the ideal mathematical weight distribution, with more output symbols of weight 1 and of higher weight and the distribution rescaled accordingly. As shown in the modified distribution, R1 determines the initial fraction of weight one output symbols as well as determining the multiple of the increased probability of weight one symbols and R2 determines the boundary between the “higher” weights and the “not so high” weights.
Good choices for R1 and R2 generally depend on K and can be determined empirically. For example, having R1 equal to 1.4 times the square root of K and R2 equal to two plus twice the fourth root of K works well in practice. Thus, for K=4000, setting R1=89 and R2=18 works well; when K is 64000, setting R1=354 and R2=34 works well. More detailed calculations of R1 and R2 are shown in Appendix A.
Although the reconstruction processes described above is similar to the one used for Tornado codes, the different process used to build the code leads to extremely different effects. In particular, as described earlier, the memory required for chain reaction encoding is significantly less than for Tornado codes, and the ease of use of chain reaction codes in diverse situations far exceeds that of Tornado codes, at possibly the expense of some speed. The mathematical details underlying the processes are described in more detail below.
Properties of Some Chain Reaction Codes
The number of output symbols generated and sent through the channel is not limited with chain reaction coding as with other coding schemes, since keys need not have a one-to-one correspondence with input symbols and the number of different values of I is not limited to some ratio of input symbols. Therefore, it is likely that even if the decodable set goes empty before the input file is reconstructed, the decoding process will not fail, since the decoder can gather as many more output symbols as needed to get at least one more output symbol of weight one. When that output symbol of weight one is received, it populates the decodable set and, by the chain reaction effect, might cause reduction of previously received output symbols down to weight one so that they can, in turn, be used to reconstruct input symbols.
In most of the examples described above, the input and output symbols encode for the same number of bits and each output symbol is placed in one packet (a packet being a unit of transport that is either received in its entirety or lost in its entirety). In some embodiments, the communications system is modified so that each packet contains several output symbols. The size of an output symbol value is then set to a size determined by the size of the input symbol values in the initial splitting of the file into input symbols, based on a number of factors. The decoding process would remain essentially unchanged, except that output symbols would arrive in bunches as each packet was received.
The setting of input symbol and output symbol sizes is usually dictated by the size of the file and the communication system over which the output symbols are to be transmitted. For example, if a communication system groups bits of data into packets of a defined size or groups bits in other ways, the design of symbol sizes begins with the packet or grouping size. From there, a designer would determine how many output symbols will be carried in one packet or group and that determines the output symbol size. For simplicity, the designer would likely set the input symbol size equal to the output symbol size, but if the input data makes a different input symbol size more convenient, it can be used.
Another factor in determining the input symbol size is to choose the input symbol size so that the number of input symbols, K, is large enough to keep the reception overhead minimal. For example, K=10,000 leads to an average reception overhead of 5% to 10% with moderate fluctuations, whereas K=80,000 leads to an average reception overhead of 1% to 2% with very little fluctuation. As an example, in one test comprising 1,000,000 trials with K=80,000, the reception overhead never exceeded 4%.
The above-described encoding process produces a stream of packets containing output symbols based on the original file. The output symbols hold an encoded form of the file, or more succinctly the encoded file. Each output symbol in the stream is generated independently of all other output symbols, and there is no lower or upper bound on the number of output symbols that can be created. A key is associated with each output symbol. That key, and some contents of the input file, determines the value of the output symbol. Consecutively generated output symbols need not have consecutive keys, and in some applications it would be preferable to randomly generate the sequence of keys, or pseudorandomly generate the sequence.
Chain reaction decoding has a property that if the original file can be split into K equal-sized input symbols and each output symbol value is the same length as an input symbol value, then the file can be recovered from K+A output symbols on average, where A is small compared to K. For example, A might be 500 for K=10,000. Since the particular output symbols are generated in a random or pseudorandom order, and the loss of particular output symbols in transit is arbitrary, some small variance exists in the actual number of output symbols needed to recover the input file. In some cases, where a particular collection of K+A packets are not enough to decode the entire input file, the input file is still recoverable if the receiver can gather more packets from one or more sources of output packets.
Because the number of output symbols is only limited by the resolution of I, well more than K+A output symbols should be able to be generated. For example, if I is a 32-bit number, 4 billion different output symbols could be generated, whereas the file could consist of K=50,000 input symbols. In practice, only a small number of those 4 billion output symbols would be generated and transmitted and it is a near certainty that an input file can be recovered with a very small fraction of the possible output symbols and an excellent probability that the input file can be recovered with slightly more than K output symbols (assuming that the input symbol size is the same as the output symbol size).
The average number of arithmetic operations required to produce each output symbol is proportional to log K and so the total number of arithmetic operations required to decode and recover the input file is proportional to K log K. As shown above, an efficient decoding process exists that uses only slightly more memory than the memory required to store the input file (typically around 15% more). The above numbers show significant reductions in operations and storage compared with previously known coding techniques.
For example, Reed-Solomon codes are a standard code for communications applications. With Reed-Solomon codes, the input file is split into K input symbols, as with chain reaction coding, but the K input symbols in Reed-Solomon codes are encoded into N output symbols, where N is typically fixed before the encoding process begins. This contrasts with the present invention, which allows for an indeterminate number of output symbols.
One advantage of having an indeterminate number of output symbols is that if a recipient misses more output symbols than expected, either due to a poor channel or due to the recipient beginning after some output symbols have already passed it by, the recipient can just listen for a little longer and pick up more output symbols. Another advantage is that since the recipient may be gathering output symbols produced from multiple encoders, each encoder may have to provide only a small fraction of K output symbols and the number of symbols from one encoder may depend on how many encoders are supplying the recipient with output symbols.
Reed-Solomon codes also require substantially more time than chain reaction codes, for both encoding and decoding. For example, the number of arithmetic operations required to produce each output symbol with Reed-Solomon is proportional to K. The number of arithmetic operations required for decoding Reed-Solomon codes depends on which output symbols arrive at the recipient, but generally the number of such operations is proportional to K2. Hence, in practice, acceptable values of K and N are very small, on the order of tens and possibly up to small hundreds. For example, Cross-Interleaved Reed-Solomon codes are used on compact disks (CDs) and CD-ROMs. For CDs, one standard code uses K=24 and N=28 and another standard code uses K=28 and N=32. For CD-ROMs, one standard code uses K=24 and N=26 and another standard code uses K=43 and N=45. Standard Reed-Solomon codes used for satellite transmission of MPEG files (MPEG is a file format for video and audio streams) use K=188 and N=204; generally these large values require specialized hardware.
Faster implementations of Reed-Solomon codes are known to exist which allow encoding in time cK log K and decoding in time c′ K (log K)2, but c and c′ are prohibitively large constants that make these implementations slower than other implementations of Reed-Solomon codes for all but very large values of K, i.e., the efficiency crossover point is for values of K in the thousands or tens of thousands. Thus, for values of K below the crossover point, the other implementations of Reed-Solomon codes are faster. Although the faster implementations are faster than the other implementations at values of K above the crossover point, the faster implementations are slower at those values of K than chain reaction codes, by orders of magnitude.
Because of the speed limitations, only small values of K and N are generally feasible for Reed-Solomon codes. Consequently, their use on large files requires that the files be split into many subfiles and each subfile separately coded. Such splitting decreases the effectiveness of the codes to protect against packet loss in transmission.
One feature of Reed-Solomon codes is that any K distinct output symbols can be used by the recipient to decode the input file. It is provable that at least K output symbols are required to decode an arbitrary input file, and hence Reed-Solomon codes are optimal in this regard since K is also the maximum number of output symbols needed to decode the input file. Chain reaction coding, in contrast, generally requires K+A packets, where A is small compared to a suitably chosen K. In the network applications described previously, this disadvantage of possibly needing A additional symbols is greatly overshadowed by the speed advantage and the ability to seamlessly handle larger files.
Variations of the Basic Communication System
Embodiments of communication systems according to the present invention for a single channel have been described above in detail. The elements of those embodiments can be extended to advantageously use more than one channel.
As should be apparent upon reading the above description, the chain reaction coding scheme described above can be used to send a file over a lossy transmission medium, such as a computer network, the Internet, a mobile wireless network or a satellite network, as a stream of packetized data with desirable properties. One such desirable property is that, once a decoding agent receives any set of sufficiently many packets from the stream, it can reconstruct the original file extremely quickly. Chain reaction coding is also useful in situations where many agents are involved, such as when one transmitting agent is sending the file to multiple receiving agents in a multicast or broadcast setting.
The chain reaction coding scheme is also useful in situations where multiple transmitting agents are sending the same file to multiple receiving agents. This allows for improved robustness against localized failure of the network infrastructure, allows receiving agents to seamlessly change from receiving packets from one transmitting agent to another, and allows receiving agents to speed up their download by receiving from more than one transmitting agent at the same time.
In one aspect, the chain reaction coding process described above performs the digital equivalent of a holographic image, where each part of a transmission contains an image of the transmitted file. If the file is a megabyte file, a user can just tap into a transmitted stream to obtain any arbitrary megabyte's worth of data (plus some extra overhead) and decode the original megabyte file from that megabyte.
Because chain reaction coding works with a random selection of data from the transmitted stream, downloads do not need to be scheduled or coherent. Consider the advantages of video-on-demand with chain reaction coding. A particular video could be broadcast as a continuous stream on a particular channel without coordination between the receiver and the transmitter. The receiver simply tunes into a broadcast channel for a video of interest and captures enough data to reconstruct the original video, without having to figure out when the transmission started or how to get copies of lost portions of the broadcast.
These concepts are illustrated in
Note that transmitters 2402 do not need to be synchronized or coordinated in order not to duplicate efforts. In fact, without coordination, each transmitter is likely to be in a different location in its sequence (i.e., nA≠nB≠nC). Since a random selection of K+A output symbols, maybe with a few bunches of G extra output symbols, can be used to recover an input file, the uncoordinated transmissions are additive instead of duplicative.
This “information additivity” is illustrated again in
Using two receivers and two transmitters, the total amount of information received by a receiver unit 2510 can be as much as four times the information available over one channel 2506. The amount of information might be less than four times the single channel information if, for example, the transmitters broadcast the same data to both receivers. In that case, the amount of information at receiver unit 2510 is at least double and often more, if data is lost in any channel. Note that, even if the transmitters broadcast only one signal, but the receivers are in view at different times, there is an advantage to having more than one receiver listening to each transmitter. In
In some embodiments, input file 2502 is encoded in one computing device having two encoders so that the computing device can provide one output for one transmitter and another output for the other transmitter. Other variations of these examples should be apparent upon review of this disclosure.
It is to be understood that the coding apparatus and methods described herein may also be used in other communication situations and are not limited to communications networks such as the Internet. For example, compact disk technology also uses erasure and error-correcting codes to handle the problem of scratched disks and would benefit from the use of chain reaction codes in storing information thereon. As another example, satellite systems may use erasure codes in order to trade off power requirements for transmission, purposefully allowing for more errors by reducing power and chain reaction coding would be useful in that application. Also, erasure codes have been used to develop RAID (redundant arrays of independent disks) systems for reliability of information storage. The current invention may therefore prove useful in other applications such as the above examples, where codes are used to handle the problems of potentially lossy or erroneous data.
In some preferred embodiments, sets of instructions (or software) to perform the communication processes described above are provided to two or more multi-purpose computing machines that communicate over a possibly lossy communications medium. The number of machines may range from one sender and one recipient to any number of machines sending and/or receiving. The communications medium connecting the machines may be wired, optical, wireless, or the like. The above-described communications systems have many uses, which should be apparent from this description.
The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.
This application is a continuation U.S. patent application Ser. No. 11/226,919, filed Sep. 13, 2005, which is a continuation of U.S. patent application Ser. No. 10/600,484, filed Jun. 19, 2003, issued as U.S. Pat. No. 7,057,534, which is a continuation of U.S. patent application Ser. No. 10/076,623, filed Feb. 14, 2002, issued as U.S. Pat. No. 6,614,366, which is a continuation of U.S. patent application Ser. No. 09/757,078, filed Jan. 8, 2001, issued as U.S. Pat. No. 6,373,406, which is a continuation of U.S. patent application Ser. No. 09/246,015, filed Feb. 5, 1999, issued as U.S. Pat. No. 6,307,487, which claims priority to U.S. Provisional Patent Application No. 60/101,473, filed Sep. 23, 1998, the disclosures of which are incorporated herein by reference for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3909721 | Bussgang et al. | Sep 1975 | A |
| 4365338 | McRae et al. | Dec 1982 | A |
| 4589112 | Karim | May 1986 | A |
| 4901319 | Ross | Feb 1990 | A |
| 5136592 | Weng | Aug 1992 | A |
| 5153591 | Clark | Oct 1992 | A |
| 5329369 | Willis et al. | Jul 1994 | A |
| 5331320 | Cideciyan et al. | Jul 1994 | A |
| 5371532 | Gelman et al. | Dec 1994 | A |
| 5372532 | Robertson, Jr. | Dec 1994 | A |
| 5379297 | Glover et al. | Jan 1995 | A |
| 5421031 | De Bey | May 1995 | A |
| 5425050 | Schreiber et al. | Jun 1995 | A |
| 5432787 | Chethik | Jul 1995 | A |
| 5455823 | Noreen et al. | Oct 1995 | A |
| 5465318 | Sejnoha | Nov 1995 | A |
| 5517508 | Scott | May 1996 | A |
| 5524025 | Lawrence et al. | Jun 1996 | A |
| 5566208 | Balakrishnan | Oct 1996 | A |
| 5568614 | Mendelson et al. | Oct 1996 | A |
| 5583784 | Kapust et al. | Dec 1996 | A |
| 5608738 | Matsushita | Mar 1997 | A |
| 5617541 | Albanese et al. | Apr 1997 | A |
| 5642365 | Murakami et al. | Jun 1997 | A |
| 5659614 | Bailey, III | Aug 1997 | A |
| 5699473 | Kim | Dec 1997 | A |
| 5701582 | DeBey | Dec 1997 | A |
| 5751336 | Aggarwal et al. | May 1998 | A |
| 5754563 | White | May 1998 | A |
| 5757415 | Asamizuya et al. | May 1998 | A |
| 5802394 | Baird et al. | Sep 1998 | A |
| 5805825 | Danneels et al. | Sep 1998 | A |
| 5835165 | Keate et al. | Nov 1998 | A |
| 5844636 | Joseph et al. | Dec 1998 | A |
| 5852565 | Demos | Dec 1998 | A |
| 5870412 | Schuster et al. | Feb 1999 | A |
| 5903775 | Murray | May 1999 | A |
| 5917852 | Butterfield et al. | Jun 1999 | A |
| 5926205 | Krause et al. | Jul 1999 | A |
| 5933056 | Rothenbergg et al. | Aug 1999 | A |
| 5936659 | Viswanathan et al. | Aug 1999 | A |
| 5936949 | Pasternak et al. | Aug 1999 | A |
| 5953537 | Balicki et al. | Sep 1999 | A |
| 5970098 | Herzberg | Oct 1999 | A |
| 5983383 | Wolf | Nov 1999 | A |
| 5993056 | Vaman et al. | Nov 1999 | A |
| 6005477 | Deck et al. | Dec 1999 | A |
| 6011590 | Saukkonen | Jan 2000 | A |
| 6012159 | Fischer et al. | Jan 2000 | A |
| 6014706 | Cannon et al. | Jan 2000 | A |
| 6018359 | Kermode et al. | Jan 2000 | A |
| 6041001 | Estakhri | Mar 2000 | A |
| 6044485 | Dent et al. | Mar 2000 | A |
| 6061820 | Nakakita et al. | May 2000 | A |
| 6073250 | Luby et al. | Jun 2000 | A |
| 6079041 | Kunisa et al. | Jun 2000 | A |
| 6079042 | Vaman et al. | Jun 2000 | A |
| 6081907 | Witty et al. | Jun 2000 | A |
| 6081909 | Luby et al. | Jun 2000 | A |
| 6081918 | Spielman | Jun 2000 | A |
| 6088330 | Bruck et al. | Jul 2000 | A |
| 6097320 | Kuki et al. | Aug 2000 | A |
| 6134596 | Bolosky et al. | Oct 2000 | A |
| 6141053 | Saukkonen | Oct 2000 | A |
| 6141787 | Kunisa et al. | Oct 2000 | A |
| 6141788 | Rosenberg et al. | Oct 2000 | A |
| 6154452 | Marko et al. | Nov 2000 | A |
| 6163870 | Luby et al. | Dec 2000 | A |
| 6166544 | Debbins et al. | Dec 2000 | A |
| 6175944 | Urbanke et al. | Jan 2001 | B1 |
| 6178536 | Sorkin | Jan 2001 | B1 |
| 6185265 | Campanella | Feb 2001 | B1 |
| 6195777 | Luby et al. | Feb 2001 | B1 |
| 6223324 | Sinha et al. | Apr 2001 | B1 |
| 6226259 | Piret | May 2001 | B1 |
| 6226301 | Cheng et al. | May 2001 | B1 |
| 6229824 | Marko | May 2001 | B1 |
| 6243846 | Schuster et al. | Jun 2001 | B1 |
| 6272658 | Steele et al. | Aug 2001 | B1 |
| 6278716 | Rubenstein et al. | Aug 2001 | B1 |
| 6298462 | Yi | Oct 2001 | B1 |
| 6307487 | Luby | Oct 2001 | B1 |
| 6314289 | Eberlein et al. | Nov 2001 | B1 |
| 6320520 | Luby | Nov 2001 | B1 |
| 6332163 | Bowman-Amuah | Dec 2001 | B1 |
| 6333926 | Van Heeswyk et al. | Dec 2001 | B1 |
| 6373406 | Luby et al. | Apr 2002 | B2 |
| 6393065 | Piret et al. | May 2002 | B1 |
| 6411223 | Haken et al. | Jun 2002 | B1 |
| 6415326 | Gupta et al. | Jul 2002 | B1 |
| 6420982 | Brown | Jul 2002 | B1 |
| 6421387 | Rhee | Jul 2002 | B1 |
| 6430233 | Dillon et al. | Aug 2002 | B1 |
| 6445717 | Gibson et al. | Sep 2002 | B1 |
| 6459811 | Hurst, Jr. | Oct 2002 | B1 |
| 6466698 | Creusere | Oct 2002 | B1 |
| 6473010 | Vityaev | Oct 2002 | B1 |
| 6486803 | Luby et al. | Nov 2002 | B1 |
| 6487692 | Morelos-Zaragoza | Nov 2002 | B1 |
| 6496980 | Tillman et al. | Dec 2002 | B1 |
| 6497479 | Stoffel et al. | Dec 2002 | B1 |
| 6510177 | De Bonet et al. | Jan 2003 | B1 |
| 6523147 | Kroeger et al. | Feb 2003 | B1 |
| 6535920 | Parry et al. | Mar 2003 | B1 |
| 6577599 | Gupta et al. | Jun 2003 | B1 |
| 6584543 | Williams et al. | Jun 2003 | B2 |
| 6609223 | Wolfgang | Aug 2003 | B1 |
| 6614366 | Luby | Sep 2003 | B2 |
| 6618451 | Gonikberg | Sep 2003 | B1 |
| 6631172 | Shokrollahi et al. | Oct 2003 | B1 |
| 6633856 | Richardson et al. | Oct 2003 | B2 |
| 6641366 | Nordhoff | Nov 2003 | B2 |
| 6643332 | Morelos-Zaragoza et al. | Nov 2003 | B1 |
| 6677864 | Khayrallah | Jan 2004 | B2 |
| 6678855 | Gemmell | Jan 2004 | B1 |
| 6694476 | Sridharan et al. | Feb 2004 | B1 |
| 6704370 | Chheda et al. | Mar 2004 | B1 |
| 6732325 | Tash et al. | May 2004 | B1 |
| 6742154 | Barnard | May 2004 | B1 |
| 6748441 | Gemmell | Jun 2004 | B1 |
| 6751772 | Kim et al. | Jun 2004 | B1 |
| 6765866 | Wyatt | Jul 2004 | B1 |
| 6804202 | Hwang | Oct 2004 | B1 |
| 6810499 | Sridharan et al. | Oct 2004 | B2 |
| 6820221 | Fleming | Nov 2004 | B2 |
| 6831172 | Barbucci et al. | Dec 2004 | B1 |
| 6849803 | Gretz | Feb 2005 | B1 |
| 6850736 | McCune, Jr. | Feb 2005 | B2 |
| 6856263 | Shokrollahi et al. | Feb 2005 | B2 |
| 6868083 | Apostolopoulos et al. | Mar 2005 | B2 |
| 6876623 | Lou et al. | Apr 2005 | B1 |
| 6882618 | Sakoda et al. | Apr 2005 | B1 |
| 6895547 | Eleftheriou et al. | May 2005 | B2 |
| 6909383 | Shokrollahi et al. | Jun 2005 | B2 |
| 6928603 | Castagna et al. | Aug 2005 | B1 |
| 6937618 | Noda et al. | Aug 2005 | B1 |
| 6956875 | Kapadia et al. | Oct 2005 | B2 |
| 6965636 | DesJardins et al. | Nov 2005 | B1 |
| 6985459 | Dickson | Jan 2006 | B2 |
| 6995692 | Yokota et al. | Feb 2006 | B2 |
| 7010052 | Dill et al. | Mar 2006 | B2 |
| 7030785 | Shokrollahi | Apr 2006 | B2 |
| 7031257 | Lu et al. | Apr 2006 | B1 |
| 7057534 | Luby | Jun 2006 | B2 |
| 7068681 | Chang et al. | Jun 2006 | B2 |
| 7068729 | Shokrollahi | Jun 2006 | B2 |
| 7072971 | Lassen et al. | Jul 2006 | B2 |
| 7073191 | Srikantan et al. | Jul 2006 | B2 |
| 7100188 | Hejna et al. | Aug 2006 | B2 |
| 7110412 | Costa et al. | Sep 2006 | B2 |
| 7139660 | Sarkar et al. | Nov 2006 | B2 |
| 7139960 | Shokrollahi | Nov 2006 | B2 |
| 7143433 | Duan et al. | Nov 2006 | B1 |
| 7151754 | Boyce et al. | Dec 2006 | B1 |
| 7154951 | Wang | Dec 2006 | B2 |
| 7164370 | Mishra | Jan 2007 | B1 |
| 7164882 | Poltorak | Jan 2007 | B2 |
| 7168030 | Ariyoshi et al. | Jan 2007 | B2 |
| 7219289 | Dickson | May 2007 | B2 |
| 7231404 | Paila et al. | Jun 2007 | B2 |
| 7233264 | Luby | Jun 2007 | B2 |
| 7240236 | Cutts et al. | Jul 2007 | B2 |
| 7240358 | Horn et al. | Jul 2007 | B2 |
| 7243285 | Foisy et al. | Jul 2007 | B2 |
| 7249291 | Rasmussen et al. | Jul 2007 | B2 |
| 7254754 | Hetzler et al. | Aug 2007 | B2 |
| 7257764 | Suzuki et al. | Aug 2007 | B2 |
| 7265688 | Shokrollahi et al. | Sep 2007 | B2 |
| 7293222 | Shokrollahi et al. | Nov 2007 | B2 |
| 7295573 | Yi et al. | Nov 2007 | B2 |
| 7304990 | Rajwan | Dec 2007 | B2 |
| 7318180 | Starr | Jan 2008 | B2 |
| 7320099 | Miura et al. | Jan 2008 | B2 |
| 7363048 | Cheng et al. | Apr 2008 | B2 |
| 7391717 | Klemets et al. | Jun 2008 | B2 |
| 7394407 | Shokrollahi et al. | Jul 2008 | B2 |
| 7398454 | Cai et al. | Jul 2008 | B2 |
| 7409626 | Schelstraete | Aug 2008 | B1 |
| 7412641 | Shokrollahi | Aug 2008 | B2 |
| 7418651 | Luby et al. | Aug 2008 | B2 |
| 7451377 | Shokrollahi | Nov 2008 | B2 |
| 7483447 | Chang et al. | Jan 2009 | B2 |
| 7483489 | Gentric et al. | Jan 2009 | B2 |
| 7512697 | Lassen et al. | Mar 2009 | B2 |
| 7525994 | Scholte | Apr 2009 | B2 |
| 7529806 | Shteyn | May 2009 | B1 |
| 7532132 | Shokrollahi et al. | May 2009 | B2 |
| 7555006 | Wolfe et al. | Jun 2009 | B2 |
| 7559004 | Chang et al. | Jul 2009 | B1 |
| 7570665 | Ertel et al. | Aug 2009 | B2 |
| 7574706 | Meulemans et al. | Aug 2009 | B2 |
| 7590118 | Giesberts et al. | Sep 2009 | B2 |
| 7597423 | Silverbrook | Oct 2009 | B2 |
| 7613183 | Brewer et al. | Nov 2009 | B1 |
| 7633413 | Shokrollahi et al. | Dec 2009 | B2 |
| 7633970 | van Kampen et al. | Dec 2009 | B2 |
| 7644335 | Luby et al. | Jan 2010 | B2 |
| 7650036 | Lei et al. | Jan 2010 | B2 |
| 7668198 | Yi et al. | Feb 2010 | B2 |
| 7720096 | Klemets | May 2010 | B2 |
| 7720174 | Shokrollahi et al. | May 2010 | B2 |
| 7721184 | Luby et al. | May 2010 | B2 |
| 7812743 | Luby | Oct 2010 | B2 |
| 7831896 | Amram et al. | Nov 2010 | B2 |
| 7924913 | Sullivan et al. | Apr 2011 | B2 |
| 7956772 | Shokrollahi et al. | Jun 2011 | B2 |
| 7961700 | Malladi et al. | Jun 2011 | B2 |
| 7979769 | Lee et al. | Jul 2011 | B2 |
| 8027328 | Yang et al. | Sep 2011 | B2 |
| 8028322 | Riedl et al. | Sep 2011 | B2 |
| 8081716 | Kang et al. | Dec 2011 | B2 |
| 8135073 | Shen | Mar 2012 | B2 |
| 8185794 | Lohmar et al. | May 2012 | B2 |
| 8185809 | Luby et al. | May 2012 | B2 |
| RE43741 | Shokrollahi et al. | Oct 2012 | E |
| 8301725 | Biderman et al. | Oct 2012 | B2 |
| 8327403 | Chilvers et al. | Dec 2012 | B1 |
| 8340133 | Kim et al. | Dec 2012 | B2 |
| 8422474 | Park et al. | Apr 2013 | B2 |
| 8462643 | Walton et al. | Jun 2013 | B2 |
| 8544043 | Parekh et al. | Sep 2013 | B2 |
| 8572646 | Haberman et al. | Oct 2013 | B2 |
| 8615023 | Oh et al. | Dec 2013 | B2 |
| 8638796 | Dan et al. | Jan 2014 | B2 |
| 8713624 | Harvey et al. | Apr 2014 | B1 |
| 8737421 | Zhang et al. | May 2014 | B2 |
| 8806050 | Chen et al. | Aug 2014 | B2 |
| 8812735 | Igarashi | Aug 2014 | B2 |
| 20010015944 | Takahashi et al. | Aug 2001 | A1 |
| 20010033586 | Takashimizu et al. | Oct 2001 | A1 |
| 20020009137 | Nelson et al. | Jan 2002 | A1 |
| 20020053062 | Szymanski | May 2002 | A1 |
| 20020081977 | McCune, Jr. et al. | Jun 2002 | A1 |
| 20020083345 | Halliday et al. | Jun 2002 | A1 |
| 20020085013 | Lippincott | Jul 2002 | A1 |
| 20020133247 | Smith et al. | Sep 2002 | A1 |
| 20020141433 | Kwon et al. | Oct 2002 | A1 |
| 20020143953 | Aiken | Oct 2002 | A1 |
| 20020191116 | Kessler et al. | Dec 2002 | A1 |
| 20030005386 | Bhatt et al. | Jan 2003 | A1 |
| 20030037299 | Smith | Feb 2003 | A1 |
| 20030058958 | Shokrollahi et al. | Mar 2003 | A1 |
| 20030086515 | Trans et al. | May 2003 | A1 |
| 20030101408 | Martinian et al. | May 2003 | A1 |
| 20030106014 | Dohmen et al. | Jun 2003 | A1 |
| 20030138043 | Hannuksela | Jul 2003 | A1 |
| 20030194211 | Abecassis | Oct 2003 | A1 |
| 20030207696 | Willenegger et al. | Nov 2003 | A1 |
| 20030224773 | Deeds | Dec 2003 | A1 |
| 20040015768 | Bordes et al. | Jan 2004 | A1 |
| 20040031054 | Dankworth et al. | Feb 2004 | A1 |
| 20040049793 | Chou | Mar 2004 | A1 |
| 20040066854 | Hannuksela | Apr 2004 | A1 |
| 20040081106 | Bruhn | Apr 2004 | A1 |
| 20040096110 | Yogeshwar et al. | May 2004 | A1 |
| 20040117716 | Shen | Jun 2004 | A1 |
| 20040151109 | Batra et al. | Aug 2004 | A1 |
| 20040162071 | Grilli et al. | Aug 2004 | A1 |
| 20040207548 | Kilbank | Oct 2004 | A1 |
| 20040231004 | Seo | Nov 2004 | A1 |
| 20040240382 | Ido et al. | Dec 2004 | A1 |
| 20040255328 | Baldwin et al. | Dec 2004 | A1 |
| 20050018635 | Proctor | Jan 2005 | A1 |
| 20050028067 | Weirauch | Feb 2005 | A1 |
| 20050041736 | Butler-Smith et al. | Feb 2005 | A1 |
| 20050071491 | Seo | Mar 2005 | A1 |
| 20050084006 | Lei et al. | Apr 2005 | A1 |
| 20050091697 | Tanaka et al. | Apr 2005 | A1 |
| 20050097213 | Barrett et al. | May 2005 | A1 |
| 20050102371 | Aksu | May 2005 | A1 |
| 20050105371 | Johnson et al. | May 2005 | A1 |
| 20050123058 | Greenbaum et al. | Jun 2005 | A1 |
| 20050138286 | Franklin et al. | Jun 2005 | A1 |
| 20050160272 | Teppler | Jul 2005 | A1 |
| 20050163468 | Takahashi et al. | Jul 2005 | A1 |
| 20050169379 | Shin et al. | Aug 2005 | A1 |
| 20050180415 | Cheung et al. | Aug 2005 | A1 |
| 20050193309 | Grilli et al. | Sep 2005 | A1 |
| 20050195752 | Amin et al. | Sep 2005 | A1 |
| 20050195899 | Han | Sep 2005 | A1 |
| 20050195900 | Han | Sep 2005 | A1 |
| 20050207392 | Sivalingham et al. | Sep 2005 | A1 |
| 20050216472 | Leon et al. | Sep 2005 | A1 |
| 20050216951 | MacInnis | Sep 2005 | A1 |
| 20050254575 | Hannuksela et al. | Nov 2005 | A1 |
| 20060015568 | Walsh et al. | Jan 2006 | A1 |
| 20060020796 | Aura et al. | Jan 2006 | A1 |
| 20060031738 | Fay et al. | Feb 2006 | A1 |
| 20060037057 | Xu | Feb 2006 | A1 |
| 20060093634 | Lutz et al. | May 2006 | A1 |
| 20060107174 | Heise | May 2006 | A1 |
| 20060109805 | Malamal Vadakital et al. | May 2006 | A1 |
| 20060120464 | Hannuksela | Jun 2006 | A1 |
| 20060193524 | Tarumoto et al. | Aug 2006 | A1 |
| 20060212444 | Handman et al. | Sep 2006 | A1 |
| 20060212782 | Li | Sep 2006 | A1 |
| 20060229075 | Kim et al. | Oct 2006 | A1 |
| 20060244824 | Debey | Nov 2006 | A1 |
| 20060244865 | Simon | Nov 2006 | A1 |
| 20060248195 | Toumura et al. | Nov 2006 | A1 |
| 20060256851 | Wang et al. | Nov 2006 | A1 |
| 20060262856 | Wu et al. | Nov 2006 | A1 |
| 20060279437 | Luby et al. | Dec 2006 | A1 |
| 20070002953 | Kusunoki | Jan 2007 | A1 |
| 20070006274 | Paila et al. | Jan 2007 | A1 |
| 20070016594 | Visharam et al. | Jan 2007 | A1 |
| 20070022215 | Singer et al. | Jan 2007 | A1 |
| 20070028099 | Entin et al. | Feb 2007 | A1 |
| 20070078876 | Hayashi et al. | Apr 2007 | A1 |
| 20070081562 | Ma | Apr 2007 | A1 |
| 20070081586 | Raveendran et al. | Apr 2007 | A1 |
| 20070110074 | Bradley et al. | May 2007 | A1 |
| 20070127576 | Henocq et al. | Jun 2007 | A1 |
| 20070134005 | Myong et al. | Jun 2007 | A1 |
| 20070140369 | Limberg et al. | Jun 2007 | A1 |
| 20070157267 | Lopez-Estrada | Jul 2007 | A1 |
| 20070162568 | Gupta et al. | Jul 2007 | A1 |
| 20070162611 | Yu et al. | Jul 2007 | A1 |
| 20070176800 | Rijavec | Aug 2007 | A1 |
| 20070177811 | Yang et al. | Aug 2007 | A1 |
| 20070185973 | Wayda et al. | Aug 2007 | A1 |
| 20070195894 | Shokrollahi et al. | Aug 2007 | A1 |
| 20070200949 | Walker et al. | Aug 2007 | A1 |
| 20070201549 | Hannuksela et al. | Aug 2007 | A1 |
| 20070204196 | Watson et al. | Aug 2007 | A1 |
| 20070230568 | Eleftheriadis et al. | Oct 2007 | A1 |
| 20070233784 | O'Rourke et al. | Oct 2007 | A1 |
| 20070255844 | Shen et al. | Nov 2007 | A1 |
| 20070277209 | Yousef | Nov 2007 | A1 |
| 20070300127 | Watson et al. | Dec 2007 | A1 |
| 20080010153 | Pugh-O'Connor et al. | Jan 2008 | A1 |
| 20080052753 | Huang et al. | Feb 2008 | A1 |
| 20080058958 | Cheng | Mar 2008 | A1 |
| 20080059532 | Kazmi et al. | Mar 2008 | A1 |
| 20080066136 | Dorai et al. | Mar 2008 | A1 |
| 20080075172 | Koto | Mar 2008 | A1 |
| 20080086751 | Horn et al. | Apr 2008 | A1 |
| 20080101478 | Kusunoki | May 2008 | A1 |
| 20080134005 | Izzat et al. | Jun 2008 | A1 |
| 20080152241 | Itoi et al. | Jun 2008 | A1 |
| 20080168133 | Osborne | Jul 2008 | A1 |
| 20080168516 | Flick et al. | Jul 2008 | A1 |
| 20080170564 | Shi et al. | Jul 2008 | A1 |
| 20080170806 | Kim | Jul 2008 | A1 |
| 20080172430 | Thorstensen | Jul 2008 | A1 |
| 20080172712 | Munetsugu | Jul 2008 | A1 |
| 20080181296 | Tian et al. | Jul 2008 | A1 |
| 20080189419 | Girle et al. | Aug 2008 | A1 |
| 20080192818 | DiPietro et al. | Aug 2008 | A1 |
| 20080215317 | Fejzo | Sep 2008 | A1 |
| 20080232357 | Chen | Sep 2008 | A1 |
| 20080243918 | Holtman | Oct 2008 | A1 |
| 20080256418 | Luby et al. | Oct 2008 | A1 |
| 20080281943 | Shapiro | Nov 2008 | A1 |
| 20080285556 | Park et al. | Nov 2008 | A1 |
| 20080303893 | Kim et al. | Dec 2008 | A1 |
| 20080303896 | Lipton et al. | Dec 2008 | A1 |
| 20080309525 | Shokrollahi et al. | Dec 2008 | A1 |
| 20080313191 | Bouazizi | Dec 2008 | A1 |
| 20090003439 | Wang et al. | Jan 2009 | A1 |
| 20090019229 | Morrow et al. | Jan 2009 | A1 |
| 20090031199 | Luby et al. | Jan 2009 | A1 |
| 20090043906 | Hurst et al. | Feb 2009 | A1 |
| 20090055705 | Gao | Feb 2009 | A1 |
| 20090067551 | Chen et al. | Mar 2009 | A1 |
| 20090083806 | Barrett et al. | Mar 2009 | A1 |
| 20090089445 | Deshpande | Apr 2009 | A1 |
| 20090092138 | Joo et al. | Apr 2009 | A1 |
| 20090100496 | Bechtolsheim et al. | Apr 2009 | A1 |
| 20090103523 | Katis et al. | Apr 2009 | A1 |
| 20090106356 | Brase et al. | Apr 2009 | A1 |
| 20090125636 | Li et al. | May 2009 | A1 |
| 20090150557 | Wormley et al. | Jun 2009 | A1 |
| 20090158114 | Shokrollahi | Jun 2009 | A1 |
| 20090164653 | Mandyam et al. | Jun 2009 | A1 |
| 20090189792 | Shokrollahi et al. | Jul 2009 | A1 |
| 20090195640 | Kim et al. | Aug 2009 | A1 |
| 20090201990 | Leprovost et al. | Aug 2009 | A1 |
| 20090204877 | Betts | Aug 2009 | A1 |
| 20090210547 | Lassen et al. | Aug 2009 | A1 |
| 20090222873 | Einarsson | Sep 2009 | A1 |
| 20090248697 | Richardson et al. | Oct 2009 | A1 |
| 20090257508 | Aggarwal et al. | Oct 2009 | A1 |
| 20090287841 | Chapweske et al. | Nov 2009 | A1 |
| 20090297123 | Virdi et al. | Dec 2009 | A1 |
| 20090300203 | Virdi et al. | Dec 2009 | A1 |
| 20090300204 | Zhang et al. | Dec 2009 | A1 |
| 20090307565 | Luby et al. | Dec 2009 | A1 |
| 20090319563 | Schnell | Dec 2009 | A1 |
| 20090328228 | Schnell | Dec 2009 | A1 |
| 20100011061 | Hudson et al. | Jan 2010 | A1 |
| 20100011117 | Hristodorescu et al. | Jan 2010 | A1 |
| 20100011274 | Stockhammer et al. | Jan 2010 | A1 |
| 20100020871 | Hannuksela et al. | Jan 2010 | A1 |
| 20100023525 | Westerlund et al. | Jan 2010 | A1 |
| 20100046906 | Kanamori et al. | Feb 2010 | A1 |
| 20100049865 | Hannuksela et al. | Feb 2010 | A1 |
| 20100061444 | Wilkins et al. | Mar 2010 | A1 |
| 20100067495 | Lee et al. | Mar 2010 | A1 |
| 20100131671 | Kohli et al. | May 2010 | A1 |
| 20100153578 | Van Gassel et al. | Jun 2010 | A1 |
| 20100165077 | Yin et al. | Jul 2010 | A1 |
| 20100174823 | Huang | Jul 2010 | A1 |
| 20100189131 | Branam et al. | Jul 2010 | A1 |
| 20100198982 | Fernandez | Aug 2010 | A1 |
| 20100211690 | Pakzad et al. | Aug 2010 | A1 |
| 20100223533 | Stockhammer et al. | Sep 2010 | A1 |
| 20100235472 | Sood et al. | Sep 2010 | A1 |
| 20100235528 | Bocharov et al. | Sep 2010 | A1 |
| 20100257051 | Fernandez | Oct 2010 | A1 |
| 20100318632 | Yoo et al. | Dec 2010 | A1 |
| 20110019769 | Shokrollahi et al. | Jan 2011 | A1 |
| 20110055881 | Yu et al. | Mar 2011 | A1 |
| 20110083144 | Bocharov et al. | Apr 2011 | A1 |
| 20110096828 | Chen et al. | Apr 2011 | A1 |
| 20110103519 | Shokrollahi et al. | May 2011 | A1 |
| 20110119394 | Wang et al. | May 2011 | A1 |
| 20110119396 | Kwon et al. | May 2011 | A1 |
| 20110216541 | Inoue et al. | Sep 2011 | A1 |
| 20110231519 | Luby et al. | Sep 2011 | A1 |
| 20110231569 | Luby et al. | Sep 2011 | A1 |
| 20110238789 | Luby et al. | Sep 2011 | A1 |
| 20110239078 | Luby et al. | Sep 2011 | A1 |
| 20110258510 | Watson et al. | Oct 2011 | A1 |
| 20110268178 | Park et al. | Nov 2011 | A1 |
| 20110280311 | Chen et al. | Nov 2011 | A1 |
| 20110280316 | Chen et al. | Nov 2011 | A1 |
| 20110299629 | Luby et al. | Dec 2011 | A1 |
| 20110307545 | Bouazizi | Dec 2011 | A1 |
| 20110307581 | Furbeck et al. | Dec 2011 | A1 |
| 20120013746 | Chen et al. | Jan 2012 | A1 |
| 20120016965 | Chen et al. | Jan 2012 | A1 |
| 20120020413 | Chen et al. | Jan 2012 | A1 |
| 20120023249 | Chen et al. | Jan 2012 | A1 |
| 20120023254 | Park et al. | Jan 2012 | A1 |
| 20120033730 | Lee | Feb 2012 | A1 |
| 20120042050 | Chen et al. | Feb 2012 | A1 |
| 20120042089 | Chen et al. | Feb 2012 | A1 |
| 20120042090 | Chen et al. | Feb 2012 | A1 |
| 20120047280 | Park et al. | Feb 2012 | A1 |
| 20120099593 | Luby | Apr 2012 | A1 |
| 20120151302 | Luby et al. | Jun 2012 | A1 |
| 20120185530 | Reza | Jul 2012 | A1 |
| 20120202535 | Chaddha et al. | Aug 2012 | A1 |
| 20120207068 | Watson et al. | Aug 2012 | A1 |
| 20120208580 | Luby et al. | Aug 2012 | A1 |
| 20120210190 | Luby et al. | Aug 2012 | A1 |
| 20120317305 | Einarsson et al. | Dec 2012 | A1 |
| 20130002483 | Rowitch et al. | Jan 2013 | A1 |
| 20130007223 | Luby et al. | Jan 2013 | A1 |
| 20130067295 | Luby et al. | Mar 2013 | A1 |
| 20130091251 | Walker et al. | Apr 2013 | A1 |
| 20130246643 | Luby et al. | Sep 2013 | A1 |
| 20130254634 | Luby | Sep 2013 | A1 |
| 20130287023 | Bims | Oct 2013 | A1 |
| 20140009578 | Chen et al. | Jan 2014 | A1 |
| 20140380113 | Luby | Dec 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 1338839 | Mar 2002 | CN |
| 1425228 | Jun 2003 | CN |
| 1481643 | Mar 2004 | CN |
| 1708934 | Dec 2005 | CN |
| 1714577 | Dec 2005 | CN |
| 1792056 | Jun 2006 | CN |
| 1806392 | Jul 2006 | CN |
| 1819661 | Aug 2006 | CN |
| 1868157 | Nov 2006 | CN |
| 101390399 | Mar 2009 | CN |
| 101729857 | Jun 2010 | CN |
| 0669587 | Aug 1995 | EP |
| 0701371 | Mar 1996 | EP |
| 0784401 | Jul 1997 | EP |
| 0 854 650 | Jul 1998 | EP |
| 0853433 | Jul 1998 | EP |
| 0903955 | Mar 1999 | EP |
| 0986908 | Mar 2000 | EP |
| 1024672 | Aug 2000 | EP |
| 1051027 | Nov 2000 | EP |
| 1124344 | Aug 2001 | EP |
| 1241795 | Sep 2002 | EP |
| 1298931 | Apr 2003 | EP |
| 1406452 | Apr 2004 | EP |
| 1455504 | Sep 2004 | EP |
| 1468497 | Oct 2004 | EP |
| 1501318 | Jan 2005 | EP |
| 1670256 | Jun 2006 | EP |
| 1755248 | Feb 2007 | EP |
| 2046044 | Apr 2009 | EP |
| 2071827 | Jun 2009 | EP |
| 2096870 | Sep 2009 | EP |
| 1700410 | Apr 2010 | EP |
| 2323390 | May 2011 | EP |
| H07183873 | Jul 1995 | JP |
| 08186570 | Jul 1996 | JP |
| 8289255 | Nov 1996 | JP |
| 9252253 | Sep 1997 | JP |
| 11041211 | Feb 1999 | JP |
| 11112479 | Apr 1999 | JP |
| 11164270 | Jun 1999 | JP |
| 2000151426 | May 2000 | JP |
| 2000216835 | Aug 2000 | JP |
| 2000513164 | Oct 2000 | JP |
| 2000307435 | Nov 2000 | JP |
| 2000353969 | Dec 2000 | JP |
| 2001036417 | Feb 2001 | JP |
| 2001094625 | Apr 2001 | JP |
| 2001189665 | Jul 2001 | JP |
| 2001223655 | Aug 2001 | JP |
| 2001251287 | Sep 2001 | JP |
| 2001274776 | Oct 2001 | JP |
| 2001274855 | Oct 2001 | JP |
| 2002073625 | Mar 2002 | JP |
| 2002204219 | Jul 2002 | JP |
| 2002543705 | Dec 2002 | JP |
| 2003018568 | Jan 2003 | JP |
| 2003507985 | Feb 2003 | JP |
| 2003092564 | Mar 2003 | JP |
| 2003510734 | Mar 2003 | JP |
| 2003174489 | Jun 2003 | JP |
| 2003256321 | Sep 2003 | JP |
| 2003318975 | Nov 2003 | JP |
| 2003319012 | Nov 2003 | JP |
| 2003333577 | Nov 2003 | JP |
| 2004048704 | Feb 2004 | JP |
| 2004070712 | Mar 2004 | JP |
| 2004135013 | Apr 2004 | JP |
| 2004165922 | Jun 2004 | JP |
| 2004516717 | Jun 2004 | JP |
| 2004192140 | Jul 2004 | JP |
| 2004193992 | Jul 2004 | JP |
| 2004529533 | Sep 2004 | JP |
| 2004289621 | Oct 2004 | JP |
| 2004343701 | Dec 2004 | JP |
| 2004348824 | Dec 2004 | JP |
| 2004362099 | Dec 2004 | JP |
| 2005094140 | Apr 2005 | JP |
| 2005136546 | May 2005 | JP |
| 2005514828 | May 2005 | JP |
| 2005204170 | Jul 2005 | JP |
| 2005223433 | Aug 2005 | JP |
| 2005277950 | Oct 2005 | JP |
| 2006503463 | Jan 2006 | JP |
| 2006505177 | Feb 2006 | JP |
| 2006506926 | Feb 2006 | JP |
| 2006074335 | Mar 2006 | JP |
| 2006074421 | Mar 2006 | JP |
| 2006115104 | Apr 2006 | JP |
| 3809957 | Jun 2006 | JP |
| 2006174032 | Jun 2006 | JP |
| 2006174045 | Jun 2006 | JP |
| 2006186419 | Jul 2006 | JP |
| 2006519517 | Aug 2006 | JP |
| 2006287422 | Oct 2006 | JP |
| 2006319743 | Nov 2006 | JP |
| 2007013675 | Jan 2007 | JP |
| 3976163 | Jun 2007 | JP |
| 2007158592 | Jun 2007 | JP |
| 2007174170 | Jul 2007 | JP |
| 2007520961 | Jul 2007 | JP |
| 2007228205 | Sep 2007 | JP |
| 2008011404 | Jan 2008 | JP |
| 2008016907 | Jan 2008 | JP |
| 2008502212 | Jan 2008 | JP |
| 2008508761 | Mar 2008 | JP |
| 2008508762 | Mar 2008 | JP |
| 2008283232 | Nov 2008 | JP |
| 2008283571 | Nov 2008 | JP |
| 2008543142 | Nov 2008 | JP |
| 2008546361 | Dec 2008 | JP |
| 2009027598 | Feb 2009 | JP |
| 2009522921 | Jun 2009 | JP |
| 2009522922 | Jun 2009 | JP |
| 2009171558 | Jul 2009 | JP |
| 2009527949 | Jul 2009 | JP |
| 2009277182 | Nov 2009 | JP |
| 2009544991 | Dec 2009 | JP |
| 2010539832 | Dec 2010 | JP |
| 2011087103 | Apr 2011 | JP |
| 1020030071815 | Sep 2003 | KR |
| 1020030074386 | Sep 2003 | KR |
| 20040107152 | Dec 2004 | KR |
| 20040107401 | Dec 2004 | KR |
| 20050009376 | Jan 2005 | KR |
| 100809086 | Mar 2008 | KR |
| 20080083299 | Sep 2008 | KR |
| 20090098919 | Sep 2009 | KR |
| 20100028156 | Mar 2010 | KR |
| 99117925 | Jul 2001 | RU |
| 2189629 | Sep 2002 | RU |
| 2265960 | Dec 2005 | RU |
| 2290768 | Dec 2006 | RU |
| 2297663 | Apr 2007 | RU |
| 2312390 | Dec 2007 | RU |
| 2357279 | May 2009 | RU |
| I246841 | Jan 2006 | TW |
| 1354908 | Dec 2011 | TW |
| 1355168 | Dec 2011 | TW |
| WO 9634463 | Oct 1996 | WO |
| WO-9750183 | Dec 1997 | WO |
| WO9804973 | Feb 1998 | WO |
| 9832231 | Jul 1998 | WO |
| WO-9832256 | Jul 1998 | WO |
| WO0014921 | Mar 2000 | WO |
| WO0018017 | Mar 2000 | WO |
| WO0052600 | Sep 2000 | WO |
| WO0120786 | Mar 2001 | WO |
| WO0157667 | Aug 2001 | WO |
| WO0158130 | Aug 2001 | WO |
| WO0158131 | Aug 2001 | WO |
| WO0227988 | Apr 2002 | WO |
| WO0247391 | Jun 2002 | WO |
| 02063461 | Aug 2002 | WO |
| WO-03046742 | Jun 2003 | WO |
| WO03056703 | Jul 2003 | WO |
| WO03105350 | Dec 2003 | WO |
| WO-03105484 | Dec 2003 | WO |
| WO2004008735 | Jan 2004 | WO |
| WO2004015948 | Feb 2004 | WO |
| WO2004019521 | Mar 2004 | WO |
| WO2004030273 | Apr 2004 | WO |
| WO2004034589 | Apr 2004 | WO |
| WO-2004036824 | Apr 2004 | WO |
| WO2004040831 | May 2004 | WO |
| WO-2004047019 | Jun 2004 | WO |
| WO2004047455 | Jun 2004 | WO |
| WO-2004088988 | Oct 2004 | WO |
| WO-2004109538 | Dec 2004 | WO |
| WO2005036753 | Apr 2005 | WO |
| WO2005041421 | May 2005 | WO |
| WO2005078982 | Aug 2005 | WO |
| WO-2005107123 | Nov 2005 | WO |
| WO2005112250 | Nov 2005 | WO |
| WO-2006013459 | Feb 2006 | WO |
| WO2006020826 | Feb 2006 | WO |
| WO-2006036276 | Apr 2006 | WO |
| 2006060036 | Jun 2006 | WO |
| WO-2006057938 | Jun 2006 | WO |
| WO2006084503 | Aug 2006 | WO |
| WO-2006116102 | Nov 2006 | WO |
| WO-2006135878 | Dec 2006 | WO |
| WO2007042916 | Apr 2007 | WO |
| 2007078253 | Jul 2007 | WO |
| WO2007090834 | Aug 2007 | WO |
| WO-2007098397 | Aug 2007 | WO |
| WO-2007098480 | Aug 2007 | WO |
| 2008011549 | Jan 2008 | WO |
| WO-2008023328 | Apr 2008 | WO |
| WO2008054100 | May 2008 | WO |
| 2008086313 | Jul 2008 | WO |
| WO2008085013 | Jul 2008 | WO |
| WO-2008131023 | Oct 2008 | WO |
| 2008144004 | Nov 2008 | WO |
| WO2008148708 | Dec 2008 | WO |
| WO2008156390 | Dec 2008 | WO |
| WO-2009065526 | May 2009 | WO |
| WO-2009137705 | Nov 2009 | WO |
| 2009143741 | Dec 2009 | WO |
| WO2010085361 | Jul 2010 | WO |
| WO2010088420 | Aug 2010 | WO |
| WO2010120804 | Oct 2010 | WO |
| WO-2011038013 | Mar 2011 | WO |
| WO-2011038034 | Mar 2011 | WO |
| 2011059286 | May 2011 | WO |
| 2011070552 | Jun 2011 | WO |
| 2011102792 | Aug 2011 | WO |
| WO-2012021540 | Feb 2012 | WO |
| WO-2012109614 | Aug 2012 | WO |
| Entry |
|---|
| International Search Report—PCT/US99/021574—ISA/EPO—Jan. 28, 2000. |
| International Search Report—PCT/US00/025405—ISA/EPO—Mar. 1, 2001. |
| International Preliminary Examination Report—PCT/US00/025405—Oct. 29, 2001. |
| European Search Report—EP02007488—Search Authority—Munich Patent Office—Mar. 24, 2003. |
| Gemmell, et al . “A Scalable Multicast Architecture for One-to-Many Telepresentations”, Multimedia Computing and Systems. 1998/ Proceedings. IEEE International Conference on Austin. TX. USA Jun. 28-Jul. 1, 1998. Los Alamitos. CA USA. IEEE Comput. Soc. US. |
| Hershey, et al., “Random Parity Coding (RPC)”, 1996 IEEE International Conference on Comminications (ICC) Converging Technologies for Tomorrows Applications. Dallas, Jun. 23-27, 1996. IEEE International Conference on Communications (ICC). New York, IEEE. |
| Kallel. “Complementary Punctured Convolutional (CPC) Codes and Their Applications”, IEEE Transactions on Communications. IEEE Inc. New York. US vol. 43. No. 6. Jun. 1, 1995. pp. 2005-2009. |
| Narayanan, et al., “Physical Layer Design for Packet Data Over IS-136”, Vehicular Technology Conference. 1997. IEEE 47th Phoenix, AZ. USA May 4-7, 1997. New York, NY, USA, IEEE, US May 4, 1997, pp. 1029-1033. |
| Nonnenmacher, et al. “Parity-Based Loss Recovery for Reliable Multicast Transmission”, IEEE / ACM Transactions on Networking. IEEE Inc. New York, US, vol. 6. No. 4, Aug. 1, 1998. |
| European Search Report—EP09007850, Search Authority—Munich Patent Office, Jun. 17, 2010. |
| Bitner, J.R., et al.: “Efficient generation of the binary reflected Gray code and its Applications,” Communications of the ACM (1976). |
| Clark, G.C. et al.: “Error Correction Coding for Digital Communications, System Applications,” 1981, Plenum Press New York, pp. 339-341. |
| Digital Fountain: “Raptor code specification for MBMS file download,” 3GPP SA4 PSM AD-HOC #31 (May 21, 2004) XP002355055 pp. 1-6. |
| Digital Fountain: “Specification Text for Raptor Forward Error Correction,” TDOC S4-050249 of 3GPP TSG SA WG 4 Meeting #34 [Online] (Feb. 25, 2005) pp. 1-23, XP002425167, Retrieved from the Internet: URL:http://www.3gpp.org/ftp/tsg—sa/WG4—CODEC/TSGS4—34/Docs. |
| Luby, M et al.: “Efficient Erasure Correction Codes,” 2001, IEEE Transactions on Information Theory, vol. 47, No, 2, pp. 569-584. |
| Pursley, M. et al.: A Correction and an Addendum for “Variable-Rate Coding for Meteor-Burst Communications;” IEEE Transactions on Communications, vol. 43, No. 12 pp. 2866-2867 (Dec. 1995). |
| Rizzo, L.: “Effective Erasure Codes for Reliable Computer Communication Protocols,” Computer Communication Review. Association for Computing Machinery, vol, 27, No. 2, pp. 24-36. |
| Shokrollahi, A.: “Raptor Cordes,” Internet Citation [Online] (Jan. 13, 2004 XP002367883, Retrieved from the Internet: URL:htttp://www.cs.huji.ac.il/labs/danss/p2p/resources/raptor.pdf. |
| Lin, S. et al.: “Error Control Coding-Fundamentals and Applications,” 1983 Englewood Cliffs, pp. 288. |
| Luby, et al., “Analysis of Low Density Codes and Improved Designs Using Irregular Graphs”, 1998, Proceedings of the 30th Annual ACM Symposium on Theory of Computing, 1998, pp. 249-258. |
| Shu, et al., “Error Control Coding-Fundamentals and Applications”, 1983, Englewood Cliffs, pp. 288. |
| Byers, et al., “A Digital Fountain Approach to Reliable Distribution of Bulk Data”, ICSI Technical Report No. TR-98-005 and Proceedings of the ACM SIGCOMM '98 Conference, Computer Communications Review, 1998, vol. 28, No. 4, pp. 56-67. |
| Alon et al., “Linear Time Erasure Codes With Nearly Optimal Recovery,” Proceedings of the Annual Symposium on Foundations of Computer Science, US, Los Alamitos, IEEE Comp. Soc. Press, Vol. Symp. 36, pp. 512-516, (Oct. 23, 1995), XP 000557871. |
| Bigloo et al., “A Robust Rate-Adaptive Hybrid ARQ Scheme for Frequency-Flopped Spread-Spectrum Multiple-Access Communication Systems,” IEEE Journal on Selected Areas in Communications, US, IEEE Inc, New York, (Jun. 1, 1994), pp. 917-924, XP0000464977. |
| Blömer et al., “An XOR-Based Erasure-Resilient Coding Scheme,” ICSI Technical Report No. TR-95-048, (1995), [avail. at ftp://ftp.icsi.berkeley.edu/pub/techreports/1995/tr-95-048.pdf]. |
| Byers et al., “A Digital Fountain Approach to Reliable Distribution of Bulk Data,” International Computer Science Institute Technical Report TR-98-013 (May 1998), [available at ftp://ftp.icsi.berkeley.edu/pub/techreports/1998/tr-98-013.pdf]. |
| Byers et al., “Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads,” International Computer Science Institute Technical Report TR-98-021 (1998) [available at http://www.icsi.berkeley.edu/˜luby/PAPERS/mindown.ps]. |
| Byers et al., “Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads,” Proceeding IEEE Infocom. The Conference on Computer Communications, New York, (Mar. 21, 1999), pp. 275-283, XP000868811. |
| Esaki et al., “Reliable IP Multicast Communication Over ATM Networks Using Forward Error Correction Policy,” IEICE Transactions on Communications, JP, Institute of Electronics Information and Comm. ENG. Tokyo, vol. E78-V, No. 12, (Dec. 1995), pp. 1622-1637, XP000556183. |
| Luby et al., “Analysis of Low Density Codes and Improved Designs Using Irregular Graphs,” International Computer Science Institute Technical Report TR-97-045, (Nov. 1997), [available at ftp://ftp.icsi.berkeley.edu/pub/techreports/1997/tr-97-045.pdf]. |
| Luby et al., “Analysis of Random Processes via And-Or Tree Evaluation,” ICSI Technical Report No. TR-97-042 (1997) and Proceedings of the 9th Annual ACM Symposium on Discrete Algorithms, (1998), available at ftp://ftp.icsi.berkeley.edu/pub/techreports/1997/tr-97-042.pdf. |
| Luby et al., “Improved Low-density Parity-Check Codes Using Irregular Graphs and Belief Propagation,” International Computer Science Institute Technical Report TR-97-044, (Nov. 1997), [available at ftp://ftp.icsi.berkeley.edu/pub/techreports/1997/tr-97-044.pdf]. |
| Luby et al., “Tornado Codes,”Practical Loss-Resilient Codes, 29th Annual ACM Symposium on Theory of Computing, (1997). |
| Pursley et al., “Variable-Rate Coding for Meteor-Burst Communications,” IEEE Transactions on Communications, US, IEEE Inc. New York (1989) vol. 37, No. 11, pp. 1105-1112, XP000074533. |
| Seshan et al., “Handoffs in Cellular Wireless Networks: The Daedalus Implementation and Experience,” Wireless Personal Communications, NL, Kluwer Academic Publishers, vol. 4, No. 2, (Mar. 1, 1997), pp. 141-162, XP000728589. |
| Shacham, N., “Packet Recovery and Error Correction in High-Speed Wide-Area Networks,” Proceedings of the Military Communications Conference. (Milcom), US, New York, IEEE, vol. 1, pp. 551-557, (1989), XP 000131876. |
| 3GPP TS 26.234 V9.1.0 ,“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (Release 9)”, Dec. 2009, 179 pages. |
| 3GPP TS 26.244 V9.1.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP), (Release 9), Mar. 2010, 55 pp. |
| 3GPP TS 26.247, v1.5.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (Release 10), 2010. |
| 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects Transparent end-to-end packet switched streaming service (PSS), 3GPP file format (3GP) (Release 8), 3GPP Standard, 3GPP TS 26.244, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre, 650, Route Des Lucioles, F-06921 Sophia-Antipolis Cedex, France, No. V8.1.0, Jun. 1, 2009, pp. 1-52, XP050370199. |
| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (Release 9), 3GPP Standard; 3GPP TS 26.244, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, No. V9.2.0, Jun. 9, 2010, pp. 1-55, XP050441544, [retrieved on Jun. 9, 2010]. |
| Afzal, et al., “Video Streaming over MBMS: A System Design Approach”, Journal of Multimedia, vol. 1, No. 5, Aug. 2006, pp. 25-35. |
| Aggarwal, C. et al.: “A Permutation-Based Pyramid Broadcasting Scheme for Video-on-Demand Systems,” Proc. IEEE Int'l Conf. on Multimedia Systems, Hiroshima, Japan (Jun. 1996). |
| Aggarwal, C. et al.: “On Optimal Batching Policies for Video-on-Demand Storage Servers,” Multimedia Systems, vol. 4, No. 4, pp. 253-258 (1996). |
| Albanese, A., et al., “Priority Encoding Transmission”, IEEE Transactions on Information Theory, vol. 42, No. 6, pp. 1-22, (Nov. 1996). |
| Alex Zambelli, “IIS Smooth Streaming Technical Overview”, Microsoft Mar. 25, 2009, XP002620446, Retrieved from the Internet: URL:http://www.microsoft.com/downloads/en/ details.aspx?FamilyID=03d22583-3ed6-44da-8464-blb4b5ca7520, [retrieved on Jan. 21, 2011]. |
| Aljoscha Smolic et al., “Development of a New MPEG Standard for Advanced 3D Video Applications”, IEEE International Symposium on Image and Signal Processing and Analysis, Sep. 16, 2009, pp. 400-407, XP031552049, ISBN: 978-953-184-135-1. |
| Almeroth, et al., “The use of multicast delivery to provide a scalable and interactive video-on-demand service”, IEEE Journal on Selected Areas in Communication, 14(6): 1110-1122, (1996). |
| Amin Shokrollahi: “LDPC Codes: An Introduction” Internet Citation 2 Apr. 1, 2003 (Apr. 2, 2003), XP002360065 Retrieved from the Internet: URL: http ://www . ipm. ac. ir/IPM/homepage/Amin 2. pdf [retrieved on Dec. 19, 2005]. |
| Amon P. et al., “File Format for Scalable Video Coding”, IEEE Transactions on Circuits and Systems for Video Technology, IEEE Service Center, Piscataway, NJ, US, vol. 17, No. 9, Sep. 1, 2007, pp. 1174-1185, XP011193013, ISSN: 1051-8215, DOI:10.1109/TCSVT.2007.905521. |
| Anonymous: [Gruneberg, K., Narasimhan, S. and Chen, Y., editors] “Text of ISO/IEC 13818-1:2007/PDAM 6 MVC operation point descriptor”, 90 MPEG Meeting; Oct. 26-30, 2009; Xian; (Motion Picture Expertgroup or ISO/IEC JTC1/SC29/WG11|), No. N10942, Nov. 19, 2009, XP030017441. |
| Anonymous: “Text of ISO/IEC 14496-12 3rd Edition”, 83 MPEG Meeting; Jan. 14-18, 2008; Antalya; (Motion Pictureexpert Group or ISO/IEC JTC1/SC29/WG11), No. N9678, Apr. 22, 2008, XP030016172. |
| Anonymous: “Text of ISO/IEC 14496-12:2008/PDAM 2 Sub-track selection & switching”, 91. Mpeg Meeting; Jan. 18-22, 2010; Kyoto; (Motion Picture Expertgroup or ISO/IEC JTC1/SC29/WG11), No. N11137, Jan. 22, 2010, XP030017634, ISSN: 0000-0030. |
| Anonymous: “Text of ISO/IEC 14496-15 2nd edition”, 91 MPEG Meeting; Jan. 18-22, 2010; Kyoto; (Motion Picture Expertgroup or ISO/IEC JTC1/SC29/WG11) No. N11139, Jan. 22, 2010, XP030017636. |
| Apple Inc., “On the time-stamps in the segment-inbox for httpstreaming (26.244, R9)”, TSG-SA4#58 meeting, Vancouver, Canada, Apr. 2010, p. 5. |
| Bar-Noy, et al., “Competitive on-line stream merging algorithms for media-on-demand”, Draft (Jul. 2000), pp. 1-34. |
| Bar-Noy et al. “Efficient algorithms for optimal stream merging for media-on-demand,” Draft (Aug. 2000), pp. 1-43. |
| Charles Lee L.H, “Error-Control Block Codes for Communications Engineers”, 2000, Artech House, XP002642221 pp. 39-45. |
| Chen, et al., U.S. Patent Application titled “Frame Packing for Asymmetric Stereo Video”, filed Feb. 25, 2011. |
| Chen, et al., U.S. Patent Application titled “One-Stream Coding for Asymmetric Stereo Video”, filed Feb. 25, 2011. |
| Chen Ying et al., “Coding techniques in Multiview Video Coding and Joint Multiview Video Model”, Picture Coding Symposium, 2009, PCS 2009, IEEE, Piscataway, NJ, USA, May 6, 2009, pp. 1-4, XP031491747, ISBN: 978-1-4244-4593-6. |
| Choi S: “Temporally enhanced erasure codes for reliable communication protocols” Computer Networks, Elsevier Science Publishers B.V., Amsterdam, NL, vol. 38, No. 6, Apr. 22, 2002, pp. 713-730, XP004345778, ISSN: 1389-1286, DOI:10.1016/S1389-1286(01)00280-8. |
| D. Gozalvez et,al. “AL-FEC for Improved Mobile Reception of MPEG-2 DVB-Transport Streams” Hindawi Publishing Corporation, International Journal of Digital Multimedia Broadcasting vol. 2009, Dec. 31, 2009, pp. 1-10, XP002582035 Retrieved from the Internet: URL:http://www.hindawi.com/journals/ijdmb/2009/614178.html> [retrieved on May 12, 2010] . |
| Dan, A. et al.: “Scheduling Policies for an On-Demand Video Server with Batching,” Proc. ACM Multimedia, pp. 391-398 (Oct. 1998). |
| Davey, M.C. et al.: “Low Density Parity Check Codes over GF(q)” IEEE Communications Letters, vol. 2, No. 6 pp. 165-167 (1998). |
| David Singer, et al., “ISO/IEC 14496-15/FDIS, International Organization for Standardization Organization Internationale De Normalization ISO/IEC JTC1/SC29/WG11 Coding of Moving Pictures and Audio”, ISO/IEC 2003, Aug. 11, 2003, pp. 1-34. |
| “Digital Video Broadcasting (DVB); Guidelines for the implementation of DVB-IP Phase 1 specifications; ETSI TS 102 542” ETSI Standards, LIS, Sophia Antiopoliscedex France, vol. BC, No. V1.2.1, Apr. 1, 2008, XP014041619 ISSN: 0000-0001 p. 43 p. 66 pp. 70, 71. |
| DVB-IPI Standard: DVB BlueBook A086r4 (Mar. 2007) Transport of MPEG 2 Transport Streatm (TS) Based DVB Services over IP Based Networks, ETSI Technical Specification 102 034 v1.3.1. |
| Eager, et al. “Minimizing bandwidth requirements for on-demand data delivery,” Proceedings of the International Workshop on Advances in Multimedia Information Systems, pg. 80-87 (Indian Wells, CA Oct. 1999). |
| Eager, et al., “Optimal and efficient merging schedules for video-on-demand servers”, Proc. ACM Multimedia, vol. 7, pp. 199-203 (1999). |
| European Search Report—EP09007850, Search Authority—Munich Patent Office, Aug. 9, 2010. |
| European Search Report—EP10011741—Search Authority—Munich—Feb. 28, 2011. |
| Feng, G., Error Correcting Codes over Z2m for Algorithm-Based Fault-Tolerance, IEEE Transactions on Computers, vol. 43, No. 3, Mar. 1994, pp. 370-374. |
| Fernando, et al., “httpstreaming of MPEG Media—Response to CfP”, 93 MPEG Meeting; Jul. 26, 2010-Jul. 30, 2010; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SCE29/VVG11), No. M17756, Jul. 22, 2010, XP030046346. |
| Fielding et al., “RFC 2616: Hypertext Transfer Protocol HTTP/1.1”, Internet Citation, Jun. 1999, pp. 165, XP002196143, Retrieved from the Internet: URL:http://www.rfc-editor-org/ [retrieved on Apr. 15, 2002]. |
| Frojdh, et al., “File format sub-track selection and switching,” ISO/IEC JTC1/SC29/WG11 MPEG2009 M16665, London UK., Jul. 2009, 14 pp. |
| Gao, L. et al.: “Efficient Schemes for Broadcasting Popular Videos,” Proc. Inter. Workshop on Network and Operating System Support for Digital Audio and Video, pp. 1-13 (1998). |
| Gasiba, Tiago et al., “System Design and Advanced Receiver Techniques for MBMS Broadcast Services” Proc. 2006 International Conference on Communications (ICC 2006), Jun. 1, 2006, pp. 5444-5450, XP031025781 Isbn: 978-1-4244-0354-7. |
| Goyal: “Multiple Description Coding: Compression Meets the Network,” in Signal Processing Magazine, IEEE, vol. 18., Issue 5 (Sep. 2001) pp. 74-93 URL:http://www.rle.mit.edu/stir/documents/Goyal13 SigProcMag200113 Md.pdf [Apr. 7, 2011]. |
| Gozalvez D et, al: “Mobile reception of DVB-T services by means of AL-FEC protection” Proc. IEEE Intern. Symposium on Broadband Multimedia Systems and Broadcasting (BMSB '09), IEEE, Piscataway, NJ, USA, May 13, 2009, pp. 1-5, XP031480155 ISBN: 978-1-4244-2590-7. |
| Grineberg, et al., “Deliverable D3.2 MVC/SVC storage format” Jan. 29, 2009, XP002599508 Retrieved from the Internet: URL:http://www.ist-sea.eu/Public/SEA—D3.2—HHI FF—20090129.pdf [retrieved on Sep. 1, 2010] paragraph [02.3]. |
| Hagenauer, J. : “Soft is better than hard” Communications, Coding and Cryptology, Kluwer Publication May 1994, XP002606615 Retrieved from the Internet: URL: http://www. Int . ei .turn. de/veroeffentlic hungen/l994/ccc94h. pdf [retrieved on Oct. 25, 2010]. |
| He Wenge et al., “Asymmetric Stereoscopic Video Encoding Algorithm Based on Joint Compensation Prediction”, IEEE International Conference on Communications and Mobile Computing, Jan. 6, 2009, pp. 191-194, XP031434775, ISBN: 978-0/7695-3501-2. |
| Hitachi Ltd. et al., “High-Definition Multimedia Interface,” Specification Version 1.4, Jun. 5, 2009, 425 pp. |
| Hua, et al., “Skyscraper broadcasting: A new broadcsting system for metropolitan video- on-demand systems”, Proc. ACM SIGCOMM, pp. 89-100 (Cannes, France, 1997). |
| Ian Trow, “Is 3D Event Coverage Using Existing Broadcast Infrastructure Technically Possible?”, International Broadcasting Conference, Sep. 9, 2009-Sep. 13, 2009, XP030081671, pp. 4-5, “3D transmission over broadcast infrastructure” pp. 7-8, “Screen signaling” —Conclusions on 3D systems. |
| IETF RFC 2733: Rosenberg, J. et al. “An RTP Payload Format for Generic Forward Error Correction,” Network Working Group, RFC 2733 (Dec. 1999). |
| Information Technology—Generic Coding of Moving Pictures and Audio: Systems, Amendment 4: Transport of Multiview Video over ITU-T Rec H.222.01 ISO/IEC 13818-1 “Text of ISO/IEC 13818-1:2007/FPDAM 4—Transport of Multiview Video over ITU-T Rec H.222.01 ISO/IEC 13818-1,” Lausanne, Switzerland, 2009, 21 pp. |
| International Search Report and Written Opinion—PCT/US2011/044745—ISA/EPO—Dec. 21, 2011. |
| International Standard ISO/IEC 13818-1:2000(E), “Information Technology—Generic Coding of Moving Pictures and Associated Audio Information: Systems,” Second edition, Dec. 1, 2000, pp. 1-174. |
| International Standard ISO/IEC 14496-12, Information Technology—Coding of audio-visual objects—Part 12: ISO base media file format, Third Edition, Oct. 15, 2008, 120 pp. |
| International Telecommunication Union, “ITU-T H.264, Series H: Audiovisual and Multimedia Systems, Infrastructure of audiovisual services—Coding of moving video, Advanced video coding for generic audiovisual services,” Mar. 2010, 669 pp. |
| ISO/IEC JTC 1/SC 29, ISO/IEC FCD 23001-6, Information technology—MPEG systems technologies—Part 6: Dynamic adaptive streaming over HTTP (DASH), Jan. 28, 2011. |
| ISO/IEC JTC1/SC29/WG11: “Requirements on HTTP Streaming of MPEG Media”, 92. MPEG Meeting; Apr. 19, 2010-Apr. 23, 2010; Dresden; No. N11340, May 14, 2010, XP030017837, ISSN: 0000-0029. |
| Jin Li, “The Efficient Implementation of Reed-Solomon High Rate Erasure Resilient Codes” Proc. 2005 IEEE International Conference on Acoustics, Speech, and Signal Processing, Philadelphia, PA, USA, IEEE, Piscataway, NJ, vol . 3, Mar. 18, 2005, pp. 1097-1100, XP010792442, DOI: 10.1109/ICASSP.2005.1415905 ISBN: 978-0-7803-8874-1. |
| “Joint Draft 8.0 on Multiview Video Coding”, 28th JVT meeting, Hannover, Germany, Document: JVT-AB204 (rev.1), Jul. 2008. available from http://wftp3.itu.int/av-arch/jvt- site/200813 0713 Hannover/JVT-AB204. |
| Juhn, L. et al.: “Adaptive Fast Data Broadcasting Scheme for Video-on-Demand Service,” IEEE Transactions on Broadcasting, vol. 44, No. 2, pp. 182-185 (Jun. 1998). |
| Juhn, L. et al.: “Harmonic Broadcasting for Video-on-Demand Service,” IEEE Transactions on Broadcasting, vol. 43, No. 3, pp. 268-271 (Sep. 1997). |
| Kimata H et al., “Inter-View Prediction With Downsampled Reference Pictures”, ITU Study Group 16—Video Coding Experts Group—ISO/IEC MPEG & ITU-T VCEG(ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q6), No. JVT-W079, Apr. 19, 2007, XP030007039. |
| Kozamernik F: “Media streaming over the Internet”, Internet Citation, Oct. 2002, XP002266291, Retrieved from the Internet: URL:http://www.ebu.ch/trev—292-kozamerni k. pdf [retrieved on Jan. 8, 2004] section “Video codecs for scalable streaming”. |
| Lee L., et al.,“VLSI implementation for low density parity check decoder”, Proceedings of the 8th IEEE International Conference on Elecctronics, Circuits and Systems, 2001. ICECS 2001, Sep. 2, 2001, vol. 3, pp. 1223-1226. |
| Luby Digital Fountain a Shokrollahi EPFL M Watson Digital Fountain T Stockhammer Nomor Research M: “Raptor Forward Error Correction Scheme for Object Delivery; rfc5053.txt”, IETF Standard, Internet Engineering Task Force, IETF, CH, Oct. 1, 2007, XP015055125, ISSN: 0000-0003. |
| Luby, et al., “Flute-File Delivery over Unidirectional Transport”, IETF RFC 3926, pp. 1-35, (Oct. 2004). |
| Luby et, al. “Layered Coding Transport (LCT) Building Block”, IETF RFC 5651, pp. 1-42, (Oct. 2009). |
| Luby, M., et, al. “Forward Error Correction (FEC) Building Block”, IETF RFC 5052, pp. 1-31, (Aug. 2007). |
| Luby, M., et al., “Raptor Forward Error Correction Scheme for Object Delivery”, IETF RFC5053, pp. 1-46 (Sep. 2007). |
| Luby, M., et al., “RaptorQ Forward Error Correction Scheme for Object Delivery”, IETF draft ietf-rmt-bb-fec-raptorq-04, Reliable Multicast Transport, pp. 1-68, (Aug. 24, 2010). |
| Luby, M., et al., “Request for Comments: 3453: The Use of Forward Error Correction (FEC) in Reliable Multicast,” Internet Article, [Online] Dec. 2002, pp. 1-19. |
| Luby M et al: “IPTV Systems, Standards and Architectures: Part II—Application Layer FEC in IPTV Services” IEEE Communications Magazine, IEEE Service Center, Piscataway, US LNKDDOI: 10.1109/MCOM.2008.4511656, vol. 46, No. 5, May 1, 2008, pp. 94-101, XP011226858 ISSN: 0163-6804. |
| Luby, M. et al.: “Pairwise Independence and Derandomization,” Foundations and Trends in Theoretical Computer Science, vol. 1, Issue 4, 2005, Print ISSN 1551-305X, Online ISSN 1551-3068. |
| Mandelbaum D.M., “An Adaptive-Feedback Coding Scheme Using Incremental Redundancy”, IEEE Trans on Information Theory, vol. May 1974, May 1974, pp. 388-389, XP002628271, the whole document. |
| Marpe, et al., “The H.264/MPEG4 Advanced Video Coding Standard and its Applications,” Standards Report, IEEE Communications Magazine, Aug. 2006, pp. 134-143. |
| Matsuoka H., et al., “Low-Density Parity-Check Code Extensions Applied for Broadcast-Communication Integrated Content Delivery”, Research Laboratories, NTT DOCOMO, Inc., 3-6, Hikari-No-Oka, Yokosuka, Kanagawa, 239-8536, Japan, ITC-SS21, 2010 IEICE, pp. 59-63. |
| McCanne, et al., “Low-Complexity Video Coding for Receiver-Driven Layered Multicast”, IEEE Journal on Selected Areas in Communication IEEE Service Center, Aug. 1, 1997, vol. 15, No. 6, pp. 983-1001, Piscataway, US, XP011054678, ISSN: 0733-8716. |
| Mimnaugh, A et, al. “Enabling Mobile Coverage for DVB-T” Digital Fountain Whitepaper Jan. 29, 2008, pp. 1-9, XP002581808 Retrieved from the Internet: URL:http://www.digitalfountain.com/ufiles/ library/DVB-T-whitepaper.pdf> [retrieved on May 10, 2010]. |
| Min-Goo Kim: “On systematic punctured convolutional codes”, IEEE Trans on Communications, vol. 45, No. 2, Feb. 1997, XP002628272, the whole document, pp. 133-139. |
| Muller, et al., “A test-bed for the dynamic adaptive streaming over HTTP featuring session mobility” MMSys '11 Proceedings of the second annual ACM conference on Multimedia systems, Feb. 23-25, 2011, San Jose, CA, pp. 271-276. |
| Naguib, Ayman, et al., “Applications of Space-Time Block Codes and Interference Suppression for High Capacity and High Data Rate Wireless Systems,” IEEE, 1998, pp. 1803-1810. |
| Nokia: “Reed-Solomon Code Specification for. MBMS Download and Streaming Services”, 3GPP Draft; S4-050265 RS—Spec, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre ; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. SA WG4, No. San Diego, USA; 20050415, Apr. 15, 2005, XP050287675, [retrieved on Apr. 15, 2005]. |
| Nokia Corp., “Usage of ‘mfra’ box for Random Access and Seeking,” S4-AHI127, 3GPP TSG-SA4 Ad-Hoc Meeting, Dec. 14-16, 2009, Paris, FR, 2 pp. |
| Ozden, B. et al.: “A Low-Cost Storage Service for Movie on Demand Databases,” Proceedings of the 20th Very Large DataBases (VLDB) Conference, Santiago, Chile (1994). |
| Pa. Chou, A. Mohr, A. Wang, S. Mehrotra, “FEC and Pseudo-ARQ for Receiver-Driven Layered Multicast of Audio and Video,” pp. 440-449, IEEE Computer Society, Data Compression Conference (2000). |
| Pantos R et al., “HTTP Live Streaming; draft-pantos-http-1ive-streaming-OT.txt ”, HTTP Live Streaming; Draft-Pant0s-HTTP-Live-Streaming-01.Txt, Internet Engineering Task Force, IETF; Standardworkingdraft, Internet Society (ISOC) 4, Rue Des Falaises CH—1205 Geneva, Switzerland, No. 1, Jun. 8, 2009, XP015062692. |
| Paris, et al., “A low bandwidth broadcasting protocol for video on demand”, Proc. International Conference on Computer Communications and Networks, vol. 7, pp. 690-697 (Oct. 1998). |
| Paris, et al., “Efficient broadcasting protocols for video on demand”, International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication systems (MASCOTS), vol. 6, pp. 127-132 (Jul. 1998). |
| Perkins, et al.: “Survey of Packet Loss Recovery Techniques for Streaming Audio,” IEEE Network; Sep./Oct. 1998, pp. 40-48. |
| Petition decision for Petition Under 37 C.F.R. § 1.78 to Accept an Unintentionally Delayed Priority Claim under 35 U.S.C. § 120 in U.S. Pat. No. 7,532,132, dated Jul. 21, 2011, 2 pages. |
| Petition under 37 C.F.R. § 1.78 to Accept an Unintentionally Delayed Priority Claim under 35 U.S.C. § 120 in U.S. Pat. No. 7,532,132, dated May 27, 2011, 2 pages. |
| Plank J. S., “A Tutorial on Reed-Solomon Coding for Fault-Tolerance I N Raid-Like Systems”, Software Practice & Experience, Wiley & Sons, Bognor Regis, GB, vol. 27, No. 9, Sep. 1, 1997, pp. 995-1012, XP00069594. |
| Pless and WC Huffman EDS V S: Algebraic geometry codes, Handbook of Coding Theory, 1998, pp. 871-961, XP002300927. |
| Pyle, et al., “Microsoft http smooth Streaming: Microsoft response to the Call for Proposal on httpstreaming”, 93 MPEG Meeting; Jul. 26, 2010-Jul. 30, 2010; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SCE29/WG11), No. M17902, Jul. 22, 2010, XP030046492. |
| Qualcomm Europe S A R L: “Baseline Architecture and Definitions for HTTP Streaming”, 3GPP Draft; S4-090603 Http Streaming Architecture, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, No. Kista; 20090812, Aug. 12, 2009, XP050356889. |
| Qualcomm Incorporated: “Use Cases and Examples for Adaptive httpstreaming”, 3GPP Draft; 54-100408-Usecases-HSD, 3rd Generation Partnership Project (JGPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. SA WG4, No. Prague, Czech Republic; 20100621, Jun. 17, 2010, XP050438085, [retrieved on Jun. 17, 2010]. |
| Rangan, et al., “Designing an On-Demand Multimedia Service,” IEEE Communication Magazine, vol. 30, pp. 56-64, (Jul. 1992). |
| Realnetworks Inc, et al., “Format for httpstreaming Media Presentation Description”, 3GPP Draft; S4-100020, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. SA WG4, No. S t Julians, Malta; 20100125, Jan. 20, 2010, XP050437753, [retrieved on Jan. 20, 2010]. |
| Research in Motion Uk Limited: “An MPD delta file for httpstreaming”, 3GPP Draft; S4-100453, 3rd Generation Partnership Project (SGPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. SA WG4, No. Prague, Czech Republic; 20100621, Jun. 16, 2010, XP050438066, [retrieved on Jun. 16, 2010]. |
| Rhyu, et al., “Response to Call for Proposals on httpstreaming of MPEG Media”, 93 MPEG Meeting; Jul. 26, 2010-Jul. 30, 2010; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SCE29/WG11) No. M17779, Jul. 26, 2010, XP030046369. |
| Roca, V., et, al. “Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes”, IETF RFC 5170 (Jun. 2008), pp. 1-34. |
| Roca, V. et al.: “Design, Evaluation and Comparison of Four Large Block FEC Codecs, LDPC, LDGM, LDGM Staircase and LDGM Triangle, plus a Reed-Solomon Small Block FEC Codec,” INRIA Research Report RR-5225 (2004). |
| Rost, S. et al.: “The Cyclone Server Architecture: streamlining delivery of popular content,” 2002, Computer Communications, vol. 25, No. 4, pp. 403-412. |
| Roth, R., et al., “A Construction of Non-Reed-Solomon Type MDS Codes”, IEEE Transactions of Information Theory, vol. 35, No. 3, May 1989, pp. 655-657. |
| Roth, R., “On MDS Codes via Cauchy Matrices”, IEEE Transactions on Information Theory, vol. 35, No. 6, Nov. 1989, pp. 1314-1319. |
| Schwarz, Heiko et al., “Overview of the Scalable Video Coding Extension of the H.264/AVC Standard”, IEEE Transactions on Circuits and Systems for Video Technology, vol. 17, No. 9, September 2007, pp. 1103-1120. |
| Shierl T; Gruneberg K; Narasimhan S; Vetro A: “ISO/IEC 13818-1:2007/FPDAM 4—Information Technology Generic Coding of Moving Pictures and Audio Systems amendment 4: Transport of Multiview Video over ITU-T Rec H.222.0 ISO/IEC 13818-1” ITU-T REC. H.222.0(May 2006)FPDAM 4, vol. MPEG2009, No. 10572, May 11, 2009, pp. 1-20, XP002605067 p. 11, last two paragraphs sections 2.6.78 and 2.6.79 table T-1. |
| Shokrollahi, Amin. “Raptor Codes,” IEEE Transactions on Information Theory, Jun. 2006, vol. 52, No. 6, pp. 2551-2567, (search date: Feb. 1, 2010) URL: <http://portal.acm.org/citation.cfm?id=1148681> . |
| Shokrollahi et al., “Design of Efficient Easure Codes with Differential Evolution”, IEEE International Symposium on Information Theory, Jun. 25, 2000, pp. 5-5. |
| Sincoskie, W. D., “System Architecture for Large Scale Video on Demand Service,” Computer Network and ISDN Systems, pp. 155-162, (1991). |
| Stockhammer, “WD 0.1 of 23001-6 Dynamic Adaptive Streaming over HTTP (DASH)”, MPEG-4 Systems, International Organisation for Standardisation, ISO/IEC JTC1/SC29/WG11, Coding of Moving Pictures and Audio, MPEG 2010 Geneva/m11398, Jan. 6, 2011, 16 pp. |
| Sullivan et al., Document: JVT-AA007, “Editors' Draft Revision to ITU-T Rec. H.264|ISO/IEC 14496-10 Advanced Video Coding—In Preparation for ITU-T SG 16 AAP Consent (in integrated form), ” Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q.6), 30th Meeting: Geneva, CH, Jan. 29-Feb. 3, 2009, pp. 1-683, http://wftp3.itu.int/av-arch/jvt-site/2009—01—Geneva/JVT-AD007.zip. |
| Sun, et al., “Seamless Switching of Scalable Video Bitstreams for Efficient Streaming,” IEEE Transactions on Multimedia, vol. 6, No. 2, Apr. 2004, pp. 291-303. |
| Telefon AB LM Ericsson, et al., “Media Presentation Description in httpstreaming”, 3GPP Draft; 54-100080-MPD, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. SA WG4, No. St Julians, Malta; 20100125, Jan. 20, 2010, XP050437773, [retrieved on Jan. 20, 2010]. |
| Thomas Wiegand, et al., “Joint Draft ITU-T Rec. H.2641 ISO/IEC 1 4496-10 / Amd.3 Scalable video coding”, Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/VVG11 and ITU-T SG16 Q.6) 24th Meeting: Geneva, Switzerland, Jun. 29, -Jul. 5, 2007, pp. 1-559. |
| Tsunoda T., et al., “Reliable Streaming Contents Delivery by Using Multiple Paths,” Technical Report of the Institute of Electronics, Information and Communication Engineers, Japan, Mar. 2004, vol. 103, No. 692, pp. 187-190, NS2003-331, IN2003-286. |
| U.S. Appl. No. 12/840,146, by Ying Chen et al., filed Jul. 20, 2010. |
| U.S. Appl. No. 12/908,537, by Ying Chen et al., filed Oct. 20, 2010. |
| U.S. Appl. No. 12/908,593, by Ying Chen et al., filed Oct. 20, 2010. |
| U.S. Appl. No. 13/082,051, by Ying Chen et al., filed Apr. 7, 2011. |
| U.S. Appl. No. 13/205,559, by Ying Chen et al., filed Aug. 8 2011. |
| U.S. Appl. No. 13/205,565, by Ying Chen et al., filed Aug. 8, 2011. |
| U.S. Appl. No. 13/205,574, by Ying Chen et al., filed Aug. 8, 2011. |
| Universal Mobile Telecommunications System (UMTS); LTE; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (3GPP TS 26.234 version 9.3.0 Release 9), Technical Specification, European Telecommunications Standards Institute (ETSI), 650, Route Des Lucioles; F-06921 Sophia-Antipolis; France, vol. 3GPP SA, No. V9.3.0, Jun. 1, 2010, XP014047290, paragraphs [5.5.4.2], [5.5.4.3], [5.5.4.4], [5.4.5], [5.5.4.6] paragraphs [10.2.3], [11.2.7], [12.2.3], [12.4.2], [12.6.2] paragraphs [12.6.3], [12.6.3.1], [12.6.4], [12.6.6]. |
| Viswanathan, et al., “Metropolitan area video-on-demand services using pyramid broadcasting”, Multimedia Systems, 4(4): 197-208 (1996). |
| Viswanathan, et al., “Pyramid Broadcasting for Video-on-Demand Service”, Proceedings of the SPIE Multimedia Computing and Networking Conference, vol. 2417, pp. 66-77 (San Jose, CA, Feb. 1995). |
| Viswanathan, Subramaniyam R., “Publishing in Wireless and Wireline Environments,” Ph.D Thesis, Rutgers, The State University of New Jersey (Nov. 1994), 180pages. |
| Wang,“On Random Access”, Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q.6), 4th Meeting: Klagenfurt, Austria, Jul. 22-26, 2002, p. 13. |
| Watson, M., et, al. “Asynchronous Layered Coding (ALC) Protocol Instantiation”, IETF RFC 5775, pp. 1-23, (Apr. 2010). |
| Wenger, et al., RFC 3984, “RTP Payload Format for H.264 Video,” Feb. 2005, 84 pp. |
| Wong, J.W., “Broadcast delivery”, Proceedings of the IEEE, 76(12): 1566-1577, (1988). |
| Yamauchi, Nagamasa. “Application of Lost Packet Recovery by Front Error Correction to Internet Multimedia Transfer” Proceedings of Workshop for Multimedia Communication and Distributed Processing, Japan, Information Processing Society of Japan (IPS), Dec. 6, 2000, vol. 2000, No. 15, pp. 145-150. |
| Yin et al., “Modified Belief-Propogation algorithm for Decoding of Irregular Low-Density Parity-Check Codes”, Electronics Letters, IEE Stevenage, GB, vol. 38, No. 24, Nov. 21, 2002, pp. 1551-1553. |
| Ying Chen et al: “Response to the CfP on HTTP Streaming: Adaptive Video Streaming based on AVC”, 93 MPEG Meeting; Jul. 26, 2010-Jul. 30, 2010; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. M17909, Jul. 26, 2010, XP030046499. |
| Zorzi, et al.: “On the Statistics of Block Errors in Bursty Channels,” IEEE Transactions on Communications, vol. 45, No. 6, Jun. 1997, pp. 660-667. |
| Cataldi et al., “ Sliding-Window Raptor Codes for Efficient Scalable Wireless Video Broadcasting With Unequal Loss Protection”, IEEE Transactions on Image Processing, Jun. 1, 2010, pp. 1491-1503, vol. 19, No. 6, IEEE Service Center, XP011328559, ISSN: 1057-7149, DOI: 10.1109/TIP.2010.2042985. |
| Gracie et al., “ Turbo and Turbo-Like Codes: Principles and Applications in Telecommunications”, Proceedings of the IEEE, Jun. 1, 2007, pp. 1228-1254, vol. 95, No. 6, IEEE, XP011189323, ISSN: 0018-9219, DOI: 10.1109/JPR0C.2007.895197. |
| Huawei et al., “Implict mapping between CCE and PUCCH for ACK/NACK TDD”, 3GPP Draft; R1-082359, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, vol. RAN WG1, No. Warsaw, Poland, Jun. 24, 2008, XP050110650, [retrieved on Jun. 24, 2008]. |
| International Search Report and Written Opinion—PCT/US2012/024737—ISA/EPO—May 11, 2012. |
| Kimura et al., “A Highly Mobile SDM-0FDM System Using Reduced-Complexity-and- Latency Processing”, IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Sep. 1, 2007, pp. 1-5, IEEE, XP031168836, ISBN: 978-1-4244-1143-6, DOI: 10.1109/PIMRC.2007.4394758. |
| Luby Qualcomm Incorporated, “Universal Object Delivery using RaptorQ; draft-luby-uod-raptorq-OO.txt”, Internet Engineering Task Force (IETF), Standardworkingdraft, Internet Society (ISOC), Mar. 7, 2011, pp. 1-10, XP015074424, [retrieved on Mar. 7, 2011]. |
| Mackay, “Fountain codes Capacity approaching codes design and implementation”, IEE Proceedings: Communications, Dec. 9, 2005, pp. 1062-1068, vol. 152, No. 6, Institution of Electrical Engineers, XP006025749, ISSN: 1350-2425, DOI: 10.1049/IPC0M:20050237. |
| Todd, “Error Correction Coding: Mathematical Methods and Algorithms”, Mathematical Methods and Algorithms, Jan. 1, 2005, pp. 451-534, Wiley, XP002618913. |
| Bross, et al., “High efficiency video coding (HEVC) text specification draft 6,” Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 JCTVC-H1003, 7th Meeting: Geneva, CH, Nov. 21-30, 2011, pp. 259. |
| Bross, et al., “High efficiency video coding (HEVC) text specification draft 7,” Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 9th Meeting: Geneva, CH, Apr. 27-May 7, 2012, JCTVC-11003—d21, pp. 290. |
| Bross, et al., “High efficiency video coding (HEVC) text specification draft 8,” Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 10th Meeting: Stockholm, SE, Jul. 11-20, 2012, JCTVC-J1003—d7, pp. 261. |
| Bross et al., “WD4: Working Draft 4 of High-Efficiency Video Coding,” JCTVC-F803—d2, (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 Joint Collaborative Team on Video Coding, 6th Meeting, Torino, IT, Jul. 14-22, 2011, 226 pages. |
| Bross et al., “WD5: Working Draft 5 of High-Efficiency Video Coding,” JCTVC-G1103—d2, (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11 Joint Collaborative Team on Video Coding, 7th Meeting, Geneva, Switzerland (Nov. 2011), 214 pages. |
| ITU-T H.264, Series H: Audiovisual and Multimedia Systems, Infrastructure of audiovisual services—Coding of moving video, Advanced video coding for generic audiovisual services, The International Telecommunication Union. Jun. 2011, 674 pages. |
| Jiang., File Format for Scalable Video Coding, PowerPoint Presentation for CMPT 820, Summer 2008. |
| Pantos, “HTTP Live Streaming draft-pantos-http-live-streaming-02”, Informational, Internet-Draft, Intended status: Informational, Expires: Apr. 8, 2010, http://tools.ietf.org/html/draft-pantos-http-live-streaming-02, pp. 1-20, Oct. 5, 2009. |
| Supplementry European Search Report—EP08746007—Search Authority—Munich—Sep. 27, 2012. |
| Thomas Wiegand et al.,“ WD1: Working Draft 1 of High-Efficiency Video Coding”, JCTVC-C403, Joint Collaborative Team on Video Coding (JCT-VC), of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 3rd Meeting: Guangzhou, CN, Oct. 7-15, 2010. |
| Wiegand et al., “WD3: Working Draft 3 of High-Efficiency Video Coding,” Document JCTVC-E603, 5th Meeting: Geneva, CH, Mar. 16-23, 2011, 193 pp. |
| Wiegand T. et al., “WD2: Working Draft 2 of High-Efficiency Video Coding”, 20110128, No. JCTVC-D503, Jan. 28, 2011, XP002679642, Retrieved from the Internet: URL: http://wftp3.itu.int/av-archictvc-site/2011—01—D—Daegu/ [retrieved on Jul. 11, 2012]. |
| Yamanouchi N., et al., “Internet Multimedia Transmission with Packet by Using Forward Error Correction,” Proceedings of DPS Workshop, The Information Processing Society of Japan, Dec. 6, 2000, vol. 2000, No. 15, pp. 145-150. |
| Anonymous: “Technologies under Consideration”, 100. MPEG Meeting; Apr. 30, 2012-Apr. 5, 2012; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. N12682, Jun. 7, 2012, XP030019156. |
| Gil A., et al., “Personalized Multimedia Touristic Services for Hybrid Broadcast/Broadband Mobile Receivers,” IEEE Transactions on Consumer Electronics, 2010, vol. 56 (1), pp. 211-219. |
| Hannuksela M.M., et al., “DASH: Indication of Subsegments Starting with SAP”, 97. MPEG Meeting; Jul. 18, 2011-Jul. 22, 2011; Torino; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. m21096, Jul. 21, 2011, XP030049659. |
| Hannuksela M.M., et al., “ISOBMFF: SAP definitions and ‘sidx’ box”, 97. MPEG Meeting; Jul. 18, 2011-Jul. 22, 2011; Torino; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11) No. m21435,Jul. 22, 2011, XP030049998. |
| Li, M., et al., “Playout Buffer and Rate Optimization for Streaming over IEEE 802.11 Wireless Networks”, Aug. 2009, Worcester Polytechnic Institute, USA. |
| Roumy A., et al., “Unequal Erasure Protection and Object Bundle Protection with the Generalized Object Encoding Approach”, Inria-00612583, Version 1, Jul. 29, 2011, 25 pages. |
| Stockhammer T., et al., “DASH: Improvements on Representation Access Points and related flags”, 97. MPEG Meeting; Jul. 18, 2011-Jul. 22, 2011; Torino; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11) No. m20339, Jul. 24, 2011, XP030048903. |
| Yamazaki M., et al., “Multilevel Block Modulation Codes Construction of Generalized DFT,” Technical Report of the Institute of Electronics, Information and Communication Engineers, Jan. 24, 1997, vol. 96, No. 494, pp. 19-24, IT96-50. |
| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (Release 10), 3GPP Standard; 3GPP TS 26.247, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre ; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. SA WG4, No. V10.0.0, 17 Jun. 2011 (2011-06-17), pp. 1-94, XP050553206, [retrieved on Jun. 17, 2011]. |
| Atis: “PTV Content on Demand Service”, IIF-WT-063R44, Nov. 11, 2010, pp. 1-124, XP055045168, Retrieved from the Internet: URL:ftp://vqeg.its.bldrdoc.gov/Documents/VQEG—Atlanta—Nov10/MeetingFiles/Liaison/IIF-WT-063R44—Content—on—Demand.pdf [retrieved on Nov. 22, 2012]. |
| Bouazizi I., et al., “Proposals for ALC/FLUTE server file format (14496-12Amd.2)”, 77. MPEG Meeting; Jul. 17, 2006-Jul. 21, 2006; Klagenfurt; (Motion PictureExpert Group or ISO/IEC JTC1/SC29/WG11), No. M13675, Jul. 12, 2006, XP030042344, ISSN: 0000-0236. |
| Frojdh P., et al., “Study on 14496-12:2005/PDAM2 ALU/FLUTE Server File Format”, 78.MPEG Meeting; Oct. 23, 2006-Oct. 27, 2006; Hangzhou: (Motion PicturExpert Group or ISO/IEC JTC1/SC29/WG11), No. M13855, Oct. 13, 2006, XP030042523, ISSN: 0000-0233. |
| International Search Report and Written Opinion—PCT/US2012/053394—ISA/EPO—Feb. 6, 2013. |
| Luby et al., RaptorQ Forward Error Correction Scheme for Object Delivery draft-ietf-rmt-bb-fec-raptorq-00, Qualcomm, Inc. Jan. 28, 2010. |
| Michael G et al., “Improved low-density parity-check codes using irregular graphs”, Information Theory, IEEE Transactions on Feb. 2001, vol. 47, No. 2, pp. 585-598. |
| Motorola et al: “An Analysis of DCD Channel Mapping to Bcast File Delivery Sessions; OMA-CD-DCD-2007-0112-INP—DCD—Channel—Mapping—to—BCAST—Fi1e—Delivery”, OMA-CD-DCD-2007-0112-INP—DCD—Channel—Mapping—To—Bcast—File—Delivery, Open Mobile Alliance (OMA), 4330 La Jolla Village Dr., Suite 110 San Diego, CA 92122; USA Oct. 2, 2007, pp. 1-13, XP064036903. |
| Ohashi A et al., “Low-Density Parity-Check (LDPC) Decoding of Quantized Data,” Technical Report of the Institute of Electronics, Information and Communication Engineers, Aug. 23, 2002, vol. 102, No. 282, pp. 47-52, RCS2002-154. |
| Schulzrinne, et al., “Real Time Streaming Protocol (RTSP)” Network Working Group, Request for Comments: 2326, Apr. 1998, pp. 1-92. |
| Wadayama T, “Introduction to Low Density Parity Check Codes and Sum-Product Algorithm,” Technical Report of the Institute of Electronics, Information and Communication Engineers, Dec. 6, 2001, vol. 101, No. 498, pp. 39-46, MR2001-83. |
| Bross, et al., “High efficiency video coding (HEVC) text specification draft 6,” JCTVC-H1003, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 8th Meeting: San José, CA, USA, Feb. 1-10, 2012, 259 pp. |
| Bitner, J. R., et al “Efficient generation of the binary reflected Gray code and its Applications,”Communications of the ACM (1976). |
| Clark, G.C. et at.: “Error Correction Coding for Digital Communications, System Applications,” 1981, Plenum Press New York, pp. 339-341. |
| Digital Fountain: “Raptor code specification for MBMS file download,”3GPP SA4 PSM AD-HOC #31 (May 21, 2004) XP002355055 pp. 1-6. |
| Digital Fountain: “Specification Text for Raptor Forward Error Correction,” TDOC S4-050249 of 3GPP TSG SA WG 4 Meeting #34 [Online] (Feb. 25, 2005) pp. 1-23, XP002425167, Retrieved from the Internet: URL:http//www.3gpp.org/ftp/tsg—sa/WG4—,CODEC/TSGS4—34/Docs. |
| Ludy. M et al.: “Efficient Erasure Correction Codes,” 2001, IEEE Transactions on information Theory, Vo. 47, No. 2, pp. 569-584. |
| Pursley, M. et al.: “A Correction and an Addendum for Variable-Rate Coding for Meteor-Burst Communications;” IEEE Transactions on Communications, vol. 43, No. 12 pp. 2866-2867 (Dec. 1995). |
| Rizzo, L.: “Effective Erasure Codes for Reliable Computer Communication Protocols,” Computer Communication Review. Association for Computing Machinery, vol. 27, No. 2, pp. 24-36, Apr. 1997. |
| Shokrollahi, A.: “Raptor Codes,” Internet Citation [Online] (Jan. 13, 2004) XP002367883, Retrieved from the Internet: URL:http://www.cs.huji.ac.il/labs/danss/p2p/resources/raptor.pdf. |
| Lin, S. et : “Error Control Coding-Fundamentals and Applications,” 1983 Englewood Cliffs. pp. 88. |
| 3GPP: “3rd Generation Partnership Project; Technical Specification Group Services and system Aspects; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6)”, Sophia Antipolis, France, Jun. 1, 2005, XP002695256, Retrieved from the Internet: URL:http://www.etsi.org/deliver/etsi—ts/126300—126399/126346/06.01.00—60/ts—126346v060100p.pdf. |
| Anonymous: “Technologies under Consideration”, 98. MPEG Meeting; Nov. 28, 2011-Feb. 12, 2011; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. N12330, Dec. 3, 2011, XP030018825. |
| Anonymous: “Text of ISO/IEC Is 23009-1 Media Presentation Description and Segment Formats”, 98. MPEG Meeting; Nov. 28, 2011-Feb. 12, 2012; Geneva; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/ WG11), No. N12329, Jan. 6, 2012, XP030018824. |
| “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television; ETSI EN 300 744” ETSI Standards, LIS, Sophia Antipolis Cedex, France, V1.6.1, pp. 9, Jan. 10, 2009. |
| Kim J., et al., “Enhanced Adaptive Modulation and Coding Schemes Based on Multiple Channel Reportings for Wireless Multicast Systems”, 62nd IEEE Vehicular Technology Conference, VTC-2005-Fall, Sep. 25-28, 2005, vol. 2, pp. 725-729, XP010878578, DOI: 1 0.11 09/VETECF.2005.1558019, ISBN: 978-0/7803-9152-9. |
| Moriyama, S., “5. Present Situation of Terrestrial Digital Broadcasting in Europe and USA”, Journal of the Institute of Image Information and Television Engineers, Nov. 20, 1999, vol. 53, No. 11, pp. 1476-1478. |
| Qualcomm Incorporated: “RaptorQ Technical Overview”, pp. 1-12, Oct. 1, 2010. |
| Makoto N., et al., “On Tuning of Blocking LU decomposition for VP2000 series” The 42th Information Processing Society of Japan Conference (1st term in 1991), Feb. 25, 1991, pp. 71-72, 4B-8. |
| Miller G., et al., “Bounds on the maximum likelihood decoding error probability of low density parity check codes”, Information Theory, 2000. Proceedings. IEEE International Symposium on, 2000, p. 290. |
| Muramatsu J., et al., “Low density parity check matrices for coding of multiple access networks”, Information Theory Workshop, 2003. Proceedings. 2003 IEEE , Apr. 4, 2003, pp. 304-307. |
| Samukawa, H. “Blocked Algorithm for LU Decomposition” Journal of the Information Processing Society of Japan, Mar. 15, 1993, vol. 34, No. 3, pp. 398-408. |
| 3GPP TSG-SA4 #57 S4-100015, IMS based PSS and MBMS User Service extensions, Jan. 19, 2010, URL: http://www..3gpp.org/ftp/tsg—sa/WG4—CODEC/TSGS4—57/docs/S4-100015.zip. |
| 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS);Protocols and codecs(Release 9) 3GPP TS 26.234 V9.3.0, Jun. 23, 2010 P.85-102,URL,http://www.3gpp.org/ftp/TSG—SA/WG4—CODEC/TSGS4—59/Docs/S4-100511.zip, 26234-930.zip. |
| International Preliminary Report on Patentability—PCT/US2012/053394, The International Bureau of WIPO—Geneva, Switzerland, Mar. 13, 2014. |
| Lee, J.Y., “Description of Evaluation Experiments on ISO/IEC 23001-6, Dynamic Adaptive Streaming over HTTP”, ISO/IEC JTC1/SC29/WG11MPEG2010/N11450, Jul. 31, 2010, 16 pp. |
| Luby M., “Simple Forward Error Correction (FEC) Schemes,” draft-luby-rmt-bb-fec-supp-simple-00.txt, pp. 1-14, Jun. 2004. |
| Luby M., “LT Codes”, Foundations of Computer Science, 2002, Proceedings, The 43rd Annual IEEE Symposium on, 2002. |
| Morioka S., “A Verification Methodology for Error Correction Circuits over Galois Fields”, Tokyo Research Laboratory, IBM Japan Ltd, pp. 275- 280, Apr. 22-23, 2002. |
| Qualcomm Incorporated: “Adaptive HTTP Streaming: Complete Proposal”, 3GPP TSG-SA4 AHI Meeting S4-AHI170, Mar. 2, 2010, URL, http://www.3gpp.org/FTP/tsg—sa/WG4—CODEC/Ad-hoc—MBS/Docs—AHI/S4-AHI170.zip, S4- AH170—CR—AdaptiveHTTPStreaming-Full.doc. |
| Qualcomm Incorporated: “Corrections to 3GPP Adaptive HTTP Streaming”, 3GPP TSG-SA4 #59 Change Request 26.234 CR0172 S4-100403, Jun. 16, 2010, URL, http://www.3gpp.org/FTP/tsg—sa/WG4—CODEC/TSGS4—59/Docs/54-100403.zip, S4-100403—CR—26234-0172-AdaptiveHTTPStreaming-Re1-9.doc. |
| Gerard F., et al., “HTTP Streaming MPEG media—Response to CFP”, 93. MPEG Meeting, Geneva Jul. 26, 2010 to Jul. 30, 2010. |
| Ch Ikara S., et al., “Add-on Download Scheme for Multicast Content Distribution Using LT Codes”, IEICE. B, Communications, Aug. 1, 2006, J89-B (8), pp. 1379-1389. |
| Hasan M A., et al., “Architecture for a Low Complexity Rate-Adaptive Reed-Solomon Encoder”, IEEE Transactions on Computers, IEEE Service Center, Los Alamitos, CA, US, vol. 44, No. 7, Jul. 1, 1995, pp. 938-942, XP000525729, ISSN: 0018-9340, DOI: 10.1109/12.392853. |
| Tetsuo M., et al., “Comparison of Loss Resilient Ability between Multi-Stage and Reed-Solomon Coding”, Technical report of IEICE. CQ, Communication Quality, vol. 103 (178), Jul. 4, 2003, pp. 19-24. |
| Watson M., et al., “Forward Error Correction (FEC) Famework draft-ietf-fecframe-framework-11,” 2011, pp. 1-38, URL, http://tools.ietf.org/pdf/draft-ietf-fecframe-framework-11.pdf. |
| Watson M., et al., “Raptor FEC Schemes for FECFRAME draft-ietf-fecframe-raptor-04,” 2010, pp. 1-21, URL, http://tools.ietf.org/pdf/draft-ietf-fecframe-raptor-04.pdf. |
| Qualcomm Incorporated: “RatorQ Forward Error Correction Scheme for Object Delivery draft-ietf-rmt-bb-fec-raptorq-04”, Internet Engineering Task Force, IETF, pp. 1-68, Aug. 24, 2010. |
| Ramsey B, “HTTP Status: 206 Partial Content and Range Requests,” May 5, 2008 obtained at http://benramsey.com/blog/2008/05/206-partial-content-and-range-requests/. |
| Number | Date | Country | |
|---|---|---|---|
| 20080034273 A1 | Feb 2008 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60101473 | Sep 1998 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11226919 | Sep 2005 | US |
| Child | 11738866 | US | |
| Parent | 10600484 | Jun 2003 | US |
| Child | 11226919 | US | |
| Parent | 10076623 | Feb 2002 | US |
| Child | 10600484 | US | |
| Parent | 09757078 | Jan 2001 | US |
| Child | 10076623 | US | |
| Parent | 09246015 | Feb 1999 | US |
| Child | 09757078 | US |
