Classifications

• • H—ELECTRICITY
  • H03—ELECTRONIC CIRCUITRY
  • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
  • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
  • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
  • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
  • H03M13/11—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits using multiple parity bits
  • H03M13/1102—Codes on graphs and decoding on graphs, e.g. low-density parity check [LDPC] codes
• • H—ELECTRICITY
  • H03—ELECTRONIC CIRCUITRY
  • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
  • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
  • H03M13/35—Unequal or adaptive error protection, e.g. by providing a different level of protection according to significance of source information or by adapting the coding according to the change of transmission channel characteristics
  • H03M13/356—Unequal error protection [UEP]
• • H—ELECTRICITY
  • H03—ELECTRONIC CIRCUITRY
  • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
  • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
  • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
  • H03M13/3761—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35 using code combining, i.e. using combining of codeword portions which may have been transmitted separately, e.g. Digital Fountain codes, Raptor codes or Luby Transform [LT] codes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/40—Support for services or applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

• Provisional Patent Application No. 61/645,562 filed May 10, 2012 entitled “Content Delivery System with Allocation of Source Data and Repair Data Among HTTP Servers” (Docket Ref. No. 121519P4), and U.S. Provisional Patent Application No. 61/647,414, filed May 15, 2012 entitled “Content Delivery System with Allocation of Source Data and Repair Data Among HTTP Servers” (Docket Ref. No. 121519P5), the entire disclosure of which is incorporated by reference herein for all purposes.
• ALC Luby, M., Watson, M., Vicisano, L., "Asynchronous Layered Coding (ALC) Protocol Instantiation", IETF RFC 5775 (April 2010);
• DOCOMO, Inc. 3-6, Hikari-No-Oka, Yokosuka, Kanagawa, 239-8536, Japan;
• 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 in an efficient manner and that handle different file delivery methods.
• a recipient desires to receive an exact copy of data transmitted over a channel by a sender with some level of certainty.
• 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
• errors are often easier to deal with than corrupted data (errors) because the recipient cannot always tell when corrupted data is data received in error.
• Many error-correcting codes have been developed to correct for erasures and/or for errors.
• 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.
• source data refers to data that is available at one or more senders and that a receiver is used to obtain, by recovery from a transmitted sequence with or without errors and/or erasures, etc.
• encoded data refers to data that is conveyed and can be used to recover or obtain the source data.
• the encoded data is a copy of the source data, but if the received encoded data differs (due to errors and/or erasures) from the transmitted encoded data, in this simple case the source data might not be entirely recoverable absent additional data about the source data. Transmission can be through space or time.
• the encoded data is generated based on source data in a transformation and is transmitted from one or more senders to receivers. The encoding is said to be "systematic" if the source data is found to be part of the encoded data. In a simple example of systematic encoding, redundant information about the source data is appended to the end of the source data to form the encoded data.
• input data refers to data that is present at an input of an FEC (forward-error correcting) encoder apparatus or an FEC encoder module, component, step, etc.
• FEC encoder forward-error correcting
• output data refers to data that is present at an output of an FEC encoder.
• output data would be expected to be present at an input of an FEC decoder and the FEC decoder would be expected to output the input data, or a correspondence thereof, based on the output data it processed.
• the input data is, or includes, the source data
• the output data is, or includes, the encoded data.
• the input data would be the source data if there is no processing before the input of an FEC encoder.
• the source data is processed into a different form (e.g., a static encoder, an inverse encoder or another process) to generate intermediate data that is presented to the FEC encoder instead of the source data.
• a sender device or sender program code may comprise more than one FEC encoder, i.e., source data is transformed into encoded data in a series of a plurality of FEC encoders.
• FEC decoder applied to generate source data from received encoded data.
• Data can be thought of as partitioned into symbols.
• An encoder is a computer system, device, electronic circuit, or the like, that generates encoded symbols or output symbols from a sequence of source symbols or input symbols and a decoder is the counterpart that recovers a sequence of source symbols or input symbols from received or recovered encoded symbols or output symbols.
• the encoder and decoder are separated in time and/or space by the channel and any received encoded symbols might not be exactly the same as corresponding transmitted encoded symbols and they might not be received in exactly the same sequence as they were transmitted.
• the "size" of a symbol can be measured in bits, whether or not the symbol is actually broken into a bit stream, where a symbol has a size of M bits when the symbol is selected from an alphabet of 2 M symbols.
• symbols are measured in octets and codes might be over a field of 256 possibilities (there are 256 possible 8-bit patterns within each octet), but it should be understood that different units of data measurement can be used and it is well-known to measure data in various ways.
• octet and "byte” are used interchangeably. Unless otherwise indicated, the examples herein are not limited to a particular integer or noninteger number of bits per symbol.
• Luby I describes the use of codes, such as chain reaction codes, to address error correction in a compute-efficient, memory-efficient and bandwidth-efficient manner.
• codes such as chain reaction codes
• One property of the encoded symbols produced by a chain reaction encoder is that a receiver is able to recover the original file as soon as enough encoded symbols have been received. Specifically, to recover the original K source symbols with a high probability, the receiver needs approximately K+A encoded symbols.
• the "absolute reception overhead" for a given situation is represented by the value A, while a “relative reception overhead” can be calculated as the ratio A/K.
• the absolute reception overhead is a measure of how much extra data needs to be received beyond the information theoretic minimal amount of data, and it may depend on the reliability of the decoder and may vary as a function of the number, K, of source symbols.
• the relative reception overhead, A/K is a measure of how much extra data needs to be received beyond the information theoretic minimal amount of data relative to the size of the source data being recovered, and also may depend on the reliability of the decoder and may vary as a function of the number K of source symbols.
• Chain reaction codes are extremely useful for communication over a packet based network. However, they can be fairly computationally intensive at times.
• a decoder might be able to decode more often, or more easily, if the source symbols are encoded using a static encoder prior to a dynamic encoder that encodes using a chain reaction or another rateless code.
• Such decoders are shown in Shokrollahi I, for example.
• source symbols are input symbols to a static encoder that produces output symbols that are input symbols to a dynamic encoder that produces output symbols that are the encoded symbols, wherein the dynamic encoder is a rateless encoder that that can generate a number of output symbols in a quantity that is not a fixed rate relative to the number of input symbols.
• the static encoder might include more than one fixed rate encoder.
• a static encoder might include a Hamming encoder, a low-density parity -check (“LDPC”) encoder, a high-density parity-check (“HDPC”) encoder, and/or the like.
• LDPC low-density parity -check
• HDPC high-density parity-check
• Chain reaction codes have a property that as some symbols are recovered at the decoder from the received symbols, those symbols might be able to be used to recover additional symbols, which in turn might be used to recover yet more symbols.
• the chain reaction of symbol solving at the decoder can continue such that all of the desired symbols are recovered before the pool of received symbols is used up.
• the computational complexity of performing chain reaction encoding and decoding processes is low.
• the desired symbols might be all of the symbols needed to fully recover all of the original source symbols, or some desired level of completeness that is less than all of the original source symbols.
• a recovery process at the decoder might involve determining which symbols were received, creating a matrix that would map the original input symbols to those encoded symbols that were received, then inverting the matrix and performing a matrix multiplication of the inverted matrix and a vector of the received encoded symbols.
• FEC Forward Error Correction
• ⁇ Object Transmission Information
• FEC OTI Field Error Correction
• a receiver Based on the FEC OTI a receiver receives (or is able to infer), the receiver can determine the source block and sub-block structure of the file transfer. In
• the FEC Payload ID is (SBN, ESI), where in [Raptor-RFC-5053] the source block number (SBN) is 16 bits and the encoding symbol ID (ESI) is 16 bits, whereas in [RaptorQ-RFC-6330] the SBN is 8 bits and the ESI is 24 bits, as illustrated in Fig. 1 herein.
• SBN source block number
• ESI encoding symbol ID
• SBN 8 bits
• the ESI 24 bits, as illustrated in Fig. 1 herein.
• One disadvantage of this FEC Payload ID format is that one has to pre-determine the number of bits of the FEC Payload ID to allocate to the SBN and to the ESI, and it is sometimes difficult to determine a proper mix that will be adequate for all file delivery parameters.
• Another desirable property is to provide capabilities for prioritized encoding transmission, sometimes also called unequal error protection ("UEP"), between different parts of the file. For example, it might be desirable to protect the first 10% of the file more strongly against packet loss than the remaining 90%.
• UEP unequal error protection
• [LDPC-Extensions] describes how [LDPC-RFC-5170] can be extended to provide support for UEP. In this case, the actual FEC code itself is modified to provide different levels of parity protection on different parts of a file.
• drawbacks to this approach For example, it is not desirable to have to modify the FEC code itself to provide UEP, as this complicates implementing and testing the FEC code itself.
• content is provided to a file delivery system so that source blocks and symbols representing the content are available in a unicast fashion and repair blocks and symbols are provided in a broadcast or multicast fashion.
• Other avenues and redundancies might be provided.
• the unicast provision of source blocks and symbols might be done by one entity and the broadcast or multicast portion provided by another entity, with or without specific handling done by the first entity.
• a set of content (data, images, audio, video, etc.) is to be made available to a large number of end-user devices ("UEs") operated by or for a large number of users in order to present the content to those users, typically beginning a presentation to a given user very shortly after that user asynchronously makes a request for the content and preferably continuing the presentation to its end (unless the user terminates it).
• the content is stored in source form at one or more unicast servers and repair symbols for the content are generated and stored at a broadcast server and broadcast or multicast from there to multiple UEs. Alternatively, there is no storage and the content is broadcast as soon as the repair symbols are generated.
• a UE would then receive some number of repair symbols from the broadcast server, determine whether repair symbols were lost in the process, determine (at least approximately) the number of additional symbols needed to fully recover the content from the additional symbols and the received repair symbols, then request that number of symbols from the unicast server.
• at least some source symbols are broadcast or multicast from the broadcast server, determine (at least approximately) the number of additional symbols needed to fully recover portions of the content that the UE is going to play back, and then request that number of symbols or sub-symbols from the unicast server, which may be repair sub-symbols or repair symbols.
• the request to the unicast server is in the form of an HTTP byte-range request.
• an HTTP byte-range request specifies a URL of a file, a starting position in the file and a length of the request (such as the number of symbols requested), or the number of sub-symbols requested, or a byte range request
• the requests might be such that all or many of the requests use the initial position of the file as the starting position. This would allow for downstream caches to more frequently fulfill requests, as it would have all the necessary data to provide, once it has cached the largest request with respect to a given file, since all smaller requests would be a subset of that cached byte range.
• the unicast servers are simple, conventional HTTP web servers capable of fielding byte-range requests. As such, those unicast servers can be designed unaware of any particular broadcasting being performed. [0050] The following detailed description together with the accompanying drawings will provide a better understanding of the nature and advantages of the present invention.
• Fig. 1 is a diagram illustrating conventional FEC Payload IDs; Fig. 1A illustrates an FEC Payload ID for Raptor-RFC 5053, while Fig. IB illustrates an FEC Payload ID for RaptorQ-RFC-6330.
• Fig. 2 is a diagram illustrating the FEC Payload ID for a basic universal file delivery (“UFD”) method.
• Fig. 3 is a flow chart that illustrates a sender basic UFD method.
• Fig. 4 is a flow chart that illustrates a receiver basic UFD method.
• Figs. 5A-5B are examples illustrating the (SBN, ESI) identification of symbols of a file and the mapping to and from the corresponding universal file symbol identifiers ("UFSIs") of symbols of a file.
• Fig. 6 is a flow chart that illustrates a sender universal file delivery, unequal error protection ("UFD-UEP”) method.
• Fig. 7 is a flow chart that illustrates a receiver UFD-UEP method.
• Figs. 8A-8B illustrate an example of an (SBN, ESI) identification of a file that comprises two parts, each having a different priority.
• Fig. 9 illustrates an example, corresponding to Figs. 8A and 8B, of the mapping between the (SBN, ESI) identifiers of encoded symbols from the two parts of the file and the packets containing encoded symbols for the parts together with the UFSI included in each packet.
• Fig. 10 illustrates the performance of a simple UEP file delivery method using [RaptorQ-RFC-6330].
• Fig. 11 illustrates an example performance comparison between a simple UEP file delivery method and a UFD-UEP file delivery method, both using [RaptorQ-RFC- 6330].
• Fig. 12 illustrates an example performance comparison between file delivery of one file, file delivery of multiple files, and a UFD-bundled file delivery method, all using [RaptorQ-RFC-6330].
• Fig. 13 is a block diagram of a communications system that might be used for generating, sending and receiving Raptor, RaptorQ or other packets as part of a file delivery.
• Fig. 14 is an illustration of a communication system where file delivery might be done wherein one receiver receives output symbols from multiple, usually independent, senders.
• FIG. 15 is an illustration of a communication system where file delivery might be done where multiple, possibly independent, receivers receive output symbols from multiple, usually independent, senders to receive an input file in less time than if only one receiver and/or only one sender is used.
• Fig. 16 depicts elements of a block-request streaming system that might be used to provide for file delivery using HTTP streaming servers.
• FIG. 17 illustrates elements of the block-request streaming system of Fig. 16, showing greater detail in the elements of a client system that is coupled to a block serving infrastructure ("BSI") to receive data that is processed by a content ingestion system, as might be used for file delivery.
• BSI block serving infrastructure
• Fig. 18 illustrates a hardware/software implementation of an ingestion system that might be used to prepare files for file delivery.
• Fig. 19 illustrates a hardware/software implementation of a client system that might be used to receive files delivered to the client system.
• Fig . 20 illustrates an example of a common FEC OTI element format.
• Fig . 21 illustrates an example of a scheme-specific FEC OTI element format.
• Fig . 22 illustrates basic FLUTE file delivery.
• Fig . 23 illustrates basic FLUTE packet format.
• Fig . 24 illustrates sub-block encoding that occurs at a sender that uses sub- blocks.
• Fig. 25 illustrates sub-block decoding that occurs at a receiver that uses sub- blocks.
• Fig. 26 illustrates file delivery using sub-blocking.
• Fig. 27 illustrates the handling of multiple source blocks.
• Fig. 28 illustrates a workflow using FEC and FLUTE.
• Fig. 29 illustrates a broadcast/repair, unicast/source configuration.
• Fig. 30 illustrates how a system would broadcast only repair symbols over the MBMS bearer.
• Fig. 31 illustrates using unicast repair via HTTP byte range requests.
• Fig. 32 illustrates an example of sub-block range request calculations for a first source block.
• Fig. 33 illustrates an example of sub-block range request calculations for a second source block.
• Fig. 34 illustrates an example of an Original-order HTTP file format and partition structure.
• Fig. 35 illustrates an example of source symbols in UOSI order.
• Fig. 36 illustrates an example of repair symbols in UOSI order.
• Fig. 37 illustrates an example of an Extended-original-order HTTP file format.
• Fig. 38 illustrates another example of Extended-original-order HTTP file format.
• Fig. 39 illustrates an example of byte range calculations for an Original-order HTTP file format with no sub-blocking.
• Fig. 40 illustrates an example of byte range calculations for an Extended- original-order HTTP file format with no sub-blocking.
• Fig. 41 illustrates an example of byte range calculations for an Extended- original-order HTTP file format with sub-blocking. DETAILED DESCRIPTION OF THE INVENTION
• file delivery is performed by an encoder/transmitter system that sends a file and a receiver/decoder system that receives a file.
• the format of the transmissions is coordinated so that the decoder understands what the encoder encoded.
• file delivery is an example of general object delivery and unless otherwise indicated, it should be apparent from these examples that objects can be treated as files and possibly vice versa.
• the data is organized into packets and transmitted as packets.
• Each packet has elements that allow a receiver to determine what is in the packet and how it is laid out.
• FEC forward error correction
• a preferred file delivery system or method should allow any flexible combination of the number of source blocks and the number of encoding symbols per source block that is used as the file delivery structure for a file.
• a typical file delivery system or method should allow any flexible combination of the number of source blocks and the number of encoding symbols per source block that is used as the file delivery structure for a file.
• a source block is a scope of an FEC operation, such as generating repair symbols.
• a repair symbol might be generated as a function of one or more source symbols all from one source block.
• each source block might be independently decodable. This is useful at a decoder if it needs to decode and process some data being delivered before all of the data is received.
• a received repair symbol would be usable for recovery of a smaller number of source symbols, however, it source blocks are very large, it might take more time for a receiver to decode and/or process and/or use any of the source symbols in the source block as it might take longer to decode a larger source block.
• File delivery methods should provide efficient protection against packet loss, and support delivery of the file with different parts of the file protected at different priorities, wherein each part of the file may have a different source block structure and sub-block structure than other parts of the file.
• files are in some cases considered specific examples of objects, but herein it should be understood that the examples used herein to describe transport and handling of files can also be used for data objects that are perhaps not referred to as files, such as large chunks of data from a database, a portion of a video sequence, etc.
• the file/object delivery system or method should provide for the delivery of many smaller files/objects with the protection efficiency of a large file/object, simple signaling of the smaller file/object structures, and the capabilities for the receiver to independently recover only a subset of the smaller files/objects without recovering all of the smaller files/objects.
• a file delivery system might comprise a broadcast portion and a unicast portion.
• “broadcast” might be read to mean “broadcast, multicast, and/or other mechanisms for serving common data to a plurality of users.”
• "Unicast” refers to movement of data from one source to one destination, although one logical source might comprise multiple components and one logical destination might comprise multiple components.
• a source server and a destination client typically there is a source server and a destination client, with the source server waiting for requests from clients and responding to received request by sending the requested data (if otherwise permitted) to the requesting client specifically.
• unicast delivery to a large number of destinations can create more scalability challenges than broadcast deliver to those same large number of destinations.
• HTTP delivery many caching servers are deployed throughout the network to increase sever delivery scalability. However, such an approach doesn't necessarily increase network capacity, which is a common bottleneck for delivery of content to mobile devices.
• UFD universal file delivery
• FEC Forward Error Correction
• UFSI universal file symbol identifier
• UOSI universal object symbol identifier
• Fig. 1 is a diagram illustrating conventional FEC Payload IDs; Fig. 1A illustrates an FEC Payload ID for Raptor-RFC 5053, while Fig. IB illustrates an FEC Payload ID for RaptorQ-RFC-6330.
• Fig. 2 is a diagram illustrating the FEC Payload ID for a basic universal file delivery (“UFD”) method. The latter approach can be more flexible.
• Fig. 3 illustrates a sender basic UFD method.
• the sender can use existing methods to generate the FEC Object Transmission Information ("OTI"), for example as described in the [Raptor-RFC-5053] or [RaptorQ-RFC-6330] (see, for example, Section 4.3 of [RaptorQ-RFC-6330]), and use the FEC OTI to determine the source block and sub-block structure to be used to transmit the file, and to determine the relationship between (SBN, ESI) pairs and the encoded symbols of the file (see, for example, Section 4.4 of [RaptorQ-RFC-6330]).
• OTI FEC Object Transmission Information
• the generated FEC OTI can be (F, Al, T, Z, N , where F is the size of the file to be transmitted, Al is an alignment factor that is used to make sure that sub-symbols are aligned on memory boundaries that are multiples of Al, T is the size of the symbols to be generated and sent in the transmission, Z is the number of source blocks into which the file is to be partitioned for transmission, and N is the number of sub-blocks into which each source block is to partitioned for transmission. This is as shown in Step 300 of Fig. 3.
• the sender can form encoded symbols to be sent in packets and generate the SBNs and ESIs for these encoded symbols using existing methods based on the source block, and if sub-blocking is used, then also the sub-block structure, e.g., as described in [RaptorQ-RFC-6330].
• the sender can send the encoded symbol in a packet with the FEC Payload ID of the packet set to the UFSI C of the encoded symbol, as shown in Step 340 of Fig. 3.
• the sender can then determine if more encoded symbols are to be sent, as shown in Step 350 of Fig. 3, and if so then the sender can generate additional encoded symbols to send, as shown by the "Yes" branch to Step 310 of Fig. 3 and, and if not then the sender can finish, as shown by the "No" branch to Step 360 of Fig. 3.
• the sender may predetermine how many encoded symbols to generate and determine the (SBN, ESI) values for all the encoded symbols to be generated before generating any of the encoded symbols.
• the UFSI values may be generated directly without an intermediate step of generating the (SBN, ESI) values.
• a base UFSI BU may be included in the FEC OTI for the file, that can be used as follows: the UFSI to be used by the FEC sender and receiver for an encoded symbol contained in a packet is U + BU, where U is the UFSI carried in the packet carrying the encoded symbol.
• U the UFSI carried in the packet carrying the encoded symbol.
• a Transmission Object Identifier also called a TOI
• the receiver basic UFD method is described with reference to Fig. 4.
• the receiver can use existing techniques to determine the FEC OTI (F, Al, T, Z, N) in the same format as described above as for the sender, as shown in Step 400 of Fig. 4.
• the FEC OTI may be embedded in a FLUTE session description, or the FEC OTI may be encoded into a URL, or the FEC OTI may be obtained via an SDP message.
• Step 410 the receiver sees if more encoded symbols are received, and it may stay at this step until it either receives another encoded symbol, in which case the receiver proceeds to Step 430, or the receiver determines that more encoded symbols are not going to be received, in which case the receiver proceeds to Step 420 and either tries to recover the file using other means, for example using HTTP requests to a file repair server, or the receiver may wait for another session to receiver more encoded symbols at a later time, or the receiver may decide that the file cannot be recovered.
• other means for example using HTTP requests to a file repair server, or the receiver may wait for another session to receiver more encoded symbols at a later time, or the receiver may decide that the file cannot be recovered.
• Step 430 the receiver determines the UFSI C of the encoded symbol and receives the value of the encoded symbol.
• Step 470 the receiver determines if there are enough encoded symbols received to recover the file, and if so proceeds to recover the file in Step 480, and if not proceeds to receive more encoded symbols in Step 410.
• the receiver may do some processing that is specific to the FEC code used to determine if enough encoded symbols have been received to recover the file.
• the UFSI values may be used directly without an intermediate step of generating the (SBN, ESI) values in the recovery process.
• recovery of the file may happen concurrently with reception of encoded symbols.
• other forms of FEC OTI information may be used.
• the (SBN, ESI) labeling of the symbols of the file is shown at the top and/or side, where each row corresponds to a source block and each column corresponds to symbols with the same ESI value.
• the corresponding UFSI labeling of the symbols is shown at the bottom.
• Another advantage of the basic UFD method is that if the encoded symbols are sent in the order defined by their UFSI, i.e., in the UFSI order 0, 1, 2, 3, 4, ..., then the encoded symbols for the Z source blocks are sent in interleaved order, i.e., the Z encoded symbols with ESI 0 from each of the Z source blocks are sent first, followed by the Z encoded symbols with ESI 1 from each of the Z source blocks, etc. For most transmissions, this simple sending order is sufficient and preferred.
• a potentially better sending order is to randomly permute each set of Z UFSI-consecutive encoded symbols before sending them, i.e., the first Z encoded symbols with UFSIs 0, ..., Z-l are sent in random permuted order, and then the next Z encoded symbols with UFSIs Z, ..., 2*Z-1 are sent in random permuted order, etc.
• random can include pseudorandom, unless otherwise indicated.
• Using the basic UFD method provides many additional advantages over previous known methods. For example, there is a separate predetermined number of possible source blocks or number of possible encoded symbols per source block when using an FEC Payload ID comprising an SBN and ESI fields of predetermined sizes. For example, an 8-bit SBN and a 24-bit ESI resulting in a 32-bit FEC Payload ID limits the number of possible source blocks to 256 and the number of possible encoded symbols per source block to 16,777,216. Instead, the FEC Payload ID comprising the UFSI field only limits the total number of possible encoded symbols for a file, independent of the source block structure of the file.
• the total number of encoded symbols that can be generated for a file is 4,294,967,296, independent of how many source blocks into which the file is partitioned, and independent of the sub-block structure of the file if sub-blocking is used.
• symbol is 1,024 octets in size
• the file size could be up to 4 GB and the number of encoded symbols could be 1,024 times the file size, independent of whether the file is partitioned into one source block, 16,384 source blocks, or 4, 194,304 source blocks.
• the file size could be 2 TB and the number of encoded symbols could be twice the file size. In all cases, the number of encoded symbols that could be generated for the file is independent of the sub-blocking structure of the file, if a sub-blocking structure is used.
• the FEC code that is used often requires significant reception overhead to recover source block, i.e., more packets are required to be received to recover a file than there are source packets in the file.
• the second issue is that method essentially sends and protects the first part of the file using a separate set of packets than are used to send and protect the second part of the file.
• the variance in receiving 30 packets out of the 130 sent for the first part of the file can be large, because the first part of the file is sent over such a small number of packets.
• [LDPC-Extensions] by an extension herein called the "simple UEP" file delivery method.
• the simple UEP file delivery method delivers the parts of a file as separate file deliveries, using existing techniques for file delivery and using different amounts of protection for each part of the file based on its priority, and then the logical connection between the parts of the file can be signaled so that the receiver would know that the delivered files are parts of the same file.
• the simple UEP file delivery method could use the [RaptorQ-RFC-6330] in the example above to deliver the first 30 KB part of the file by sending a total of 130 packets, each containing an encoded symbol of size 1,024 octets generated from the first part, and then the second 970 KB part of the file could be could delivered as a separate file by sending a total of 1870 packets, each containing an encoded symbol of size 1,024 octets generated from the second part.
• a total of 2,000 packets are sent for the two parts of the file sent as separate files.
• the simple UEP file delivery method is an improvement over the method described in [LDPC-Extensions], because the FEC code itself is not modified, and because, as shown in Fig. 10 herein, the performance of the delivery of the two parts of the file under different packet loss conditions is superior to that shown in Fig. 6 of [LDPC-Extensions].
• [PET] and [PET -Patent] provide potentially improved methods for providing a UEP file delivery service, wherein each packet contains a specified amount of encoding data from each part of the file based on its priority.
• a straightforward incorporation of [PET] would be to include an encoded symbol of the appropriate size for each part of the file in each packet, and then to include a separate FEC Payload ID comprising an (SBN, ESI) pair for each part of the file.
• this method is not advantageous for a few reasons.
• an FEC Payload ID comprising an SBN and ESI fields of predetermined sizes for each part.
• an 8-bit SBN and a 24-bit ESI for each of d parts results in a (32* ⁇ f)-bit FEC Payload ID that limits the number of possible source blocks per part to 256 and the number of possible encoded symbols per source block to 16,777,216.
• UFD-UEP unequal error protection
• the sender partitions a file of size F into d > 1 parts of sizes FQ, F ⁇ , . . ., Fd-i, and thus F is equal to the sum over i of F t .
• the sender partitions the packet size T into d parts of sizes To, T ⁇ , T A, and thus T is equal to the sum over i of T.
• This partitioning of T is based on F 0 , F Fd- ⁇ and the priorities of the corresponding file parts.
• the ratio Fj/ determines how many packets need to be received to recover part i of the file assuming an ideal FEC code is used to protect part i of the file as one source block, and thus the smaller the ratio FJTj the higher the priority of part i of the file.
• slightly more than Fj/ packets may be needed to recover part i of the file, for example because the FEC code is not perfect and exhibits some reception overhead, or because that part of the file is partitioned into multiple source blocks and the encoded symbols for some source blocks are lost at a higher rate than for other source blocks, or because Fj/ is not an integer.
• the sender UFD-UEP method for generation of the FEC OTI is now described, with reference to Fig. 6.
• the sender can generate the FEC OTI for file part i that determines how it is to be partitioned into source blocks and sub-blocks using for example the methods described in [RaptorQ- RFC-6330] in Section 4.3, treating F t as the file size and T as the symbol size to be used to carry information for part i in each packet.
• the sender thus generates the FEC OTI for part i of the file independent of the other parts of the file. This process is shown in Step 600 of Fig. 6 herein.
• the sender can also generate the partitioning of part i of the file into source blocks and sub-blocks and the mapping between the (SBN, ESI) of an encoded symbol for part i of the file and how the encoded symbol is generated from part i of the file using existing methods, for example methods described [RaptorQ-RFC-6330] in Section 4.4 and Section 5 therein.
• These UFD-UEP methods are applied to part i of the file independent of the other parts of the file, and thus different parts of the file may have different source block and sub-block structures, and in particular there may be different numbers of source symbols per source block and different numbers of source blocks between different parts of the file, since the methods are applied independently to each part of the file.
• the alignment factor Al is preferably the same for all of the parts of the file, and in particular it is preferable if for each part i the value of T is a multiple of Al. Furthermore, if for example, the methods described in Section 4.5 of [RaptorQ-RFC- 6330] are used to derive the FEC OTI, it is preferable if the same value of Al and of WS is used when deriving the source block and sub-block structure for each of the parts of the file.
• the usage of the same value for Al ensures that decoding can occur on memory aligned on multiples of Al octets at the receiver, and the usage of the same value for WS ensures that the maximum block size that needs to be decoded in Random Access Memory (RAM) at the receiver is the same for all parts of the file.
• RAM Random Access Memory
• There are some applications where using a different value of WS for the different parts of the file are preferred to derive the FEC OTI, for example if it desirable to use less memory to recover the higher priority parts of the file.
• the high priority parts may be decoded by both low-end receivers that have 4-octet aligned memory and high-end receivers that have 8-octet aligned memory, whereas the low priority parts may be decode by only high-end receivers.
• the corresponding FEC OTI generated by the sender UFD-UEP method specific to file part i comprises F T, Z N, where Z ; is the number of source blocks into which part i of the file is partitioned and N is the number of sub-blocks into which each source block of part i of the file is partitioned.
• the FEC OTI that the sender UFD-UEP method generates for the file can comprise: (d, Al, F 0 , To, Z 0 , No, F ⁇ , Z ⁇ , Ni, . . ., Fd-i, Td- h Zd-i, Nd- ).
• Other versions of the FEC OTI are also available, e.g., when d is fixed and thus does not need to be explicitly listed in the FEC OTI, or when other methods are used for indicating the source block structure, and the sub-block structure if used.
• the sender using the UFD-UEP method, assembles one encoded symbol for each part of the file to be sent in a packet, and the FEC Payload ID for the packet comprises an UFSI value C.
• the sender determines an UFSI value C to be used as the FEC Payload ID for the packet, as shown in Step 610 of Fig. 6.
• the UFSI values to be used for example can be consecutive, for example UFSI values 0, 1, 2, 3, ..., etc.
• Step 620 of Fig. 6 a given UFSI value C
• these d encoded symbols are generated for each of the d parts of the packet, and then the UFSI C together with these d encoded symbols of aggregate size T are sent together in the packet, as shown in Steps 630, 640 and 650 of Fig. 6.
• the sender UFD-UEP method continues to generate and send encoded packets, as shown in the decision made in Step 660 of Fig. 6.
• the receiver UFD-UEP method is described with reference to Fig. 7.
• the receiver can use existing techniques to determine the FEC OTI (d, Al, F 0 , To, Zo, No, F ⁇ , Z ⁇ , Ni, ..., Fd-i, Td- h Zd-i, N/ i) in the same format as described above as for the sender, as shown in Step 700 of Fig. 7.
• the FEC OTI may be embedded in a FLUTE session description, or the FEC OTI may be encoded into a URL, or the FEC OTI may be obtained via an SDP message.
• Step 710 the receiver sees if more packets are received, and it may stay at this step until it either receives another packet, in which case the receiver proceeds to Step 730, or the receiver determines that more packets are not going to be received, in which case the receiver proceeds to Step 720 and either determines that enough parts of the file have been recovered and stops, or else tries to recover additional parts of the file using other means, for example using HTTP requests to a file repair server, or the receiver may wait for another session to receiver more packets at a later time.
• the receiver may predetermine how many encoded symbols to receive before attempting recovery, or may calculate packet loss statistics during the session and decide based on this which parts of the file to attempt to recover.
• the receiver may do some processing that is specific to the FEC code used to determine if enough encoded symbols have been received to recover each part of the file.
• the UFSI values may be used directly without an intermediate step of generating the (SBN, ESI) values in the recovery process for each file part.
• recovery of parts of the file may happen concurrently with reception of encoded symbols.
• a base UFSI BUi may be specified in the FEC OTI for the part i independently of the other parts, that can be used as follows: the UFSI to be used by the FEC sender and receiver for an encoded symbol for part i contained in a packet is U + BUi, where U is the UFSI carried in the packet carrying the encoded symbol.
• U the UFSI carried in the packet carrying the encoded symbol.
• BUi 2,000,000, then the encoded symbol UFSI is 2,001 ,045.
• a different base UFSI for each part can be associated with each TOI for which encoded symbols are to be sent for the file without sending duplicate encoded symbols for the different TOIs.
• the source block structure and sub-blocking structure is determined for each part of the file as for example described in [RaptorQ-RFC-6330], and the UFD-UEP method described above is used to convert the identification of a symbol for a part of the file from (SBN, ESI) format to and from UFSI format
• the range of UFSIs for the file symbols are 0, 1, 2, ..., KT r l
• any repair symbols generated from the file will have UFSIs in the range KTj, KTj+l, KTj+2, etc.
• This property allows the determination of whether a symbol is part of the original part i of the file or is a repair symbol generated from part i of the file by simply comparing its UFSI to the value of ;.
• Figs. 8A and 8B illustrate an example, where in this case the file comprises two parts.
• Fig. 9 shows a possible packetization for the file structure illustrated in Figs. 8A and 8B.
• the unshaded portions of the packets carry source symbols of the corresponding part of the file, whereas shaded portions carry repair symbols generated from the corresponding part of the file.
• the minimal number of packets needed to recover the first part of the file is 28, whereas the minimal number of packets needed to recover the second part of the file is 15.
• Fig. 9 depicts 28 packets with UFSIs 0, ..., 21 , and thus all of the encoded symbols for the first part of the file carried in these packets are source symbols. Any additional packets generated with UFSI values at least 28 will carry repair symbols for the first part of the file.
• Another advantage of the UFD-UEP method is that if the encoded symbols are sent in the order defined by their UFSI, i.e., in the UFSI order 0, 1, 2, 3, 4, ..., then the encoded symbols for the Z ; source blocks of part i of the file are sent in interleaved order, i.e., the encoded symbols with ESI 0 from each of the Z source blocks are sent first, followed by the Z encoded symbols with ESI 1 from each of the Z source blocks, etc.
• This property is true for all the parts of the file, even though each part has an independent source block structure. For most transmissions, this simple sending order is sufficient and preferred.
• Another potential sending order is to randomly permute all of the encoded symbols to be sent before sending them.
• the total number of possible encoded symbols for each part of the file is only limited by the size of the UFSI field, and is independent of the source block structure of each part of the file. Furthermore, the usage of the UFSI field provides a universal and succinct FEC Payload ID that allows the concurrent identification of symbols of generated from completely different source block structures for each part of the file.
• the total number of encoded symbols that can be generated for a file is 4,294,967,296, independent of how many source blocks into which the file is partitioned, and independent of the sub-block structure of the file if sub-blocking is used, for each part of the file.
• the number of encoded symbols could be 1,024 times the number of source symbols for each file part, independent of whether each file part is partitioned into one source block, 16,384 source blocks, or 4,194,304 source blocks.
• Fig. 10 illustrates the performance of a simple UEP file delivery method using [RaptorQ-RFC-6330].
• the UEP file delivery is for 30 source packets, protected with 100 repair packets and 970 source packets protected with 900 repair packets.
• Fig. 11 illustrates an example of improvements that a UFD-UEP file delivery method provides over the simple UEP file delivery method of Fig. 10.
• a file of 1 MB is partitioned into a first part of 32 KB and a second part of 992 KB.
• the FEC codes specified in [RaptorQ-RFC-6330] are used, the size within each packet to carry encoded symbols is 1,024 octets, and a total of 2,048 packets are transmitted.
• the first part of the file and the second part of the file are processed and delivered independently, where in both cases exactly one encoded symbol of size 1,024 octets is carried in each packet.
• the source for the first part of the file is carried in 32 packets, and a total of 128 packets are sent containing encoded symbols.
• the source for the second part of the file is carried in 992 packets, and a total of 1,920 packets are sent containing encoded symbols.
• each packet sent contains an encoded symbol for each of the two parts, where for the first part the size of the encoded symbol is 64 octets and for the second part the size of the encoded symbol is 960 octets.
• the source for the first part of the file is carried in 512 packets, and all 2,048 packets contain an encoded symbol for the first part.
• the source for the second part of the file is carried in 1059 packets (the encoded symbol in the last packet of the source an encoded symbol for the second part that is padded out with zeroes to the full symbol size of 992 octets), and all 2,048 packets contain an encoded symbol for the second part.
• the recovery performance of the simple UEP file delivery method and the UFD-UEP file delivery method are practically identical for the second part of the file as a function of the packet loss rate, i.e., in both cases the second part of the file is recovered fairly consistently up to a packet loss rate that is approaching 48%.
• the recovery performance of the UFD-UEP file delivery method is significantly better than that of the simple UEP file delivery method for the first part of the file: the simple UEP file delivery method can consistently recover the first part of the file for packet loss rates less than 65%, whereas the UFD-UEP file delivery method can consistently recover the first part of the file for packet loss rates approaching 75%.
• the protection provided is far from ideal if the files are small, because there can be large variance in packet loss statistics if the number of packets containing encoded symbols for each file is small.
• Fig. 12 illustrates this issue.
• the reliability of the file delivery of a 32 KB file is shown as a function of the percent of packet loss in the network during the delivery.
• symbols are of size 1,024, and the 32 source symbols of the file are encoded into 64 encoded symbols using the FEC codes specified in [RaptorQ-RFC-6330], and each encoded symbol is sent in a separate packet.
• the percent of loss under which reliable delivery of the file can be achieved is far less than 50% due to this variance.
• Fig. 12 shows this behavior for the delivery of 32 files, each of size 32 KB, where the encoding and transmission of each file is performed independently of the other files using the same parameters as described in the previous paragraph. As can be seen, the delivery of all 32 files can only be reliably achieved when the packet loss is below around 25%, which is far less than 50%.
• the UFD-UEP file delivery method can be extended as follows to provide a UFD-bundled file delivery method.
• the UFD-bundled file delivery method can use the same methods as the UFD-UEP file delivery method, but instead of signaling the delivery of d parts of the same file, instead signal that each part is a separate file and that d files are being delivered as a bundle.
• the sender wants to provide the bundled delivery of d files of sizes F 0 , F ⁇ , . . . , F A, respectively.
• UFD-bundled method partitions the packet size T into d parts of sizes To, T T A, and thus T is equal to the sum over i of T. This partitioning of T is based on F 0 , F ⁇ , FdA and the priorities of the corresponding files.
• the ratio Fj/ determines how many packets need to be received to recover file i assuming an ideal FEC code is used to protect part i of the file as one source block, and thus the smaller the ratio Fj/ the higher the priority of part i of the file.
• slightly more than Fj/ packets may be needed to recover part i of the file, for example because the FEC code is not perfect and exhibits some reception overhead, or because that part of the file is partitioned into multiple source blocks and the encoded symbols for some source blocks are lost at a higher rate than for other source blocks, or because FilTi is not an integer.
• the priority of all the files to be delivered is desired to be the same, then is set so that Fj/ ⁇ FIT.
• the UFD-bundled file delivery method can be extended to simultaneously provide both bundled file delivery and UEP file delivery, i.e., the priority of each file in the bundle may be set differently. Furthermore, the UFD-bundled file delivery method can support both delivery of prioritized delivery of multiple files and prioritized delivery of parts of a file, with the proper signaling. For example, if three objects are to be encoded and sent using UFD-bundled file delivery methods, then the first two objects might be different parts of the same file with different priorities, and the third object may be a different file with yet a different priority.
• the receiver can decide, based on many factors, which of the bundled files and or file parts it is interested in recovering, and recover only those files or parts of files independently of the other files or parts of files. As one skilled in the art will recognize, upon reading this disclosure, there are many possible alternative versions of the UFD-bundled file delivery methods.
• Fig. 12 illustrates the recovery properties of this UFD-bundled file delivery example as a function of packet loss.
• all 32 files can be reliably recovered using the UFD-bundled file delivery method for packet loss rates approaching 50%, which is a substantial improvement over the approximately 25% packet loss rate that allows reliably delivery of all 32 files using separate encoding and sending of each file.
• UFD and UEP file delivery methods may have many other applications.
• the segments of DASH formatted content may be delivered over a multicast or broadcast network, such as networks according to the 3 GPP eMBMS standard.
• the DASH formatted content might be delivered to end user mobile devices to be played back later, and each segment of the DASH formatted content might comprise 8 seconds of video content encoded at 1 Mbps, i.e., each segment is 1 MB in size.
• each DASH segment be delivered as a separate file.
• each DASH segment be FEC protected and delivered fully-interleaved with the other segments, wherein preferably the interleaving provided by UFD and UEP delivery methods within packets can be utilized.
• each DASH segment can be recovered upon the arrival to a mobile receiving device of approximately 131,072 packets, i.e., upon the arrival of 1 MB of data for each of the 150 segments.
• each of the 150 DASH segments can be decoded and optionally played back at the receiving mobile device without having to decode the other DASH segments.
• each video segment comprises 8 seconds of video content encoded at 1 Mbps, i.e., each video segment is 1 MB in size
• each audio segment comprises 8 seconds of corresponding audio content encoded at 32 Kbps, i.e., each audio segment is 32 KB in size
• the video segment and the corresponding audio segment contain content for largely the same interval of 8 seconds of presentation time.
• the DASH content is to be streamed, i.e., each video segment and corresponding audio segment is to be delivered in sequence in order of their presentation times.
• the content is to be delivered in packets with payloads of 1200 bytes each.
• 1 160 bytes of each packet might be allocated to a video segment and the remaining 40 bytes of each packet might be allocated to the corresponding audio segment, i.e., each packet carries a 1 160-byte symbol for the video segment and a 40-byte symbol for the corresponding audio segment.
• a video segment can be recovered from reception of approximately 905 packets containing symbols for that segment, and the corresponding audio segment can be recovered from approximately 820 packets containing symbols for that segment.
• reception of any 820 packets corresponding to an 8 second interval of presentation time for which there is a corresponding video and audio segment allows the mobile receiving device to recover the audio segment
• reception of an additional 85 packets, or 905 packets in total also allows recovery of the corresponding video segment.
• audio is more protected than video, which is in many cases preferable, for example because the timing of the video play back is dictated by the timing of the audio play back, and in many cases is it preferable to at least play back the audio if not enough data is received to play back both audio and video.
• a file or file part may be organized into and made available as an "HTTP file” with an associated URL that can be used by standard HTTP web cache servers to store and provide access to the file or file parts by receivers.
• the file or file part in its original order made available as an HTTP file is herein called an "Original-order HTTP file".
• a method for native HTTP support of unicast repair requests can translate repair requests for symbols and sub-symbols of source blocks of the HTTP file, based on SBNs and ESIs, into standard HTTP (e.g., native HTTP/1.1) octet range requests within the HTTP file (often called HTTP partial GET requests with a specified byte range).
• This allows standard HTTP web cache servers to be able to service these repair requests, avoiding the need to massively deploy specialized HTTP web cache servers that understand how an HTTP file is partitioned into source blocks and source symbols within a source block.
• a source block of a part comprises 1,000 source symbols
• 700 repair symbols are received for the source block (even though some of the repair symbols may be lost in transmission, and thus the pattern of ESIs of received repair symbols may be far from consecutive).
• the receiver can request the first 300 consecutive source symbols for the source block in the unicast repair requests, and combine these source symbols with the 700 repair symbols to recover the source block. If the source symbols are consecutive in the HTTP file, then a single HTTP octet range request can be used to request and receive all 300 consecutive source symbols.
• the receiver doesn't necessarily need to make a prefix request (i.e., a request for a set number of bytes of a file that starts with the first byte), but requiring that all UEs make prefix requests significantly improves the caching efficiency in the HTTP servers as the resulting requests from the UEs will greatly overlap, even when there are many receiving devices and there are arbitrarily differing loss patterns experienced by different receiving devices when receiving packets from a broadcast or multicast session.
• a prefix request i.e., a request for a set number of bytes of a file that starts with the first byte
• the above-described techniques can be advantageous for the network or a network device to signal to the receivers that only repair symbols are being broadcast.
• the receivers do not have to keep track of what source symbols they receive and may only have to track the number of symbols they receive. For example, based on the total symbols received, the receivers can then determine how many more source symbols to request from the repair server.
• the receivers can be configured to make prefix requests for the missing number of source symbols based on their knowledge of the indication that only repair symbols are broadcast.
• receivers can be configured so that they always select the missing source symbols with the lowest symbol index values (i.e., those closest to the beginning of a source block or sub-block) whenever the receivers have the flexibility to choose between different subsets of missing source blocks. This can be the case when both source and repair symbols are sent over the broadcast channel.
• receiving devices keep track of received symbol identifiers, ESIs, and determine if they receive ESIs corresponding to only repair symbols, based on for example the FEC OTI or based on the FEC Payload ID carried in receive packets. If this is the case, then such receivers can make prefix requests.
• receives will send requests for prefixes of the source blocks and sub-blocks in the repair requests if they only receive repair symbols. Even in the case where receiving devices receive repair symbols from a broadcast channel, the repair requests can still be largely or fully prefix requests, depending on the pattern of received symbols and the trade-offs between making simple requests and potentially receiving redundant data already received via the broadcast channel.
• the signaling to indicate that only repair symbols are broadcast can be sent out-of-band (via unicast) or in-band (via broadcast).
• the indication can be applicable to the service level, session level, media level, or even file level, depending on the desired level of granularity.
• the signaling can be added in the User Service Description ("USD").
• USD might indicate that only repair symbols are broadcast for the delivery of all of the identified services.
• the signaling could also be added in the Media Presentation Description (“MPD”), where the MPD indicates which media are broadcast using only repair symbols.
• MPD Media Presentation Description
• the signaling could be added in the Session Description Protocol (“SDP”) to indicate whether it applies to the delivery of the entire session or media components in the session.
• SDP Session Description Protocol
• the signaling could also be added in the File Description Table (“FDT”) to indicate that the broadcast of repair symbols only applies on a file level.
• the signaling to require receivers to make prefix requests for repair data can also be delivered via in-band and out-of-band transports.
• the indication can also be made to apply to the service level, session level, media level, or even file level, depending on the desired level of granularity.
• the request can be for a specific number of bytes or symbols.
• the receiver will determine the number of source symbols to request based on the number of repair symbols received and the number of source symbols anticipated to be contained in the files or objects to be received.
• the receiver might perform a scheduling operation, wherein the receiver determines how to decode using only the repair symbols it has already received, and thus can note a more specific number of source symbols needed. For example, it might be that some of the repair symbols are redundant of other repair symbols, in which case more source symbols might be required. In other instances, it might turn out that fewer source symbols are needed.
• a single HTTP octet range request may be made if multiple consecutive source symbols are requested from the Original-order HTTP file if sub-blocking is not used.
• the HTTP web cache servers may have files containing repair symbols, in addition to or instead of the Original-order HTTP file, or the Original-order HTTP file may already have been extended to contain repair symbols, and the receiver can use similar methods to those described herein to make HTTP octet range requests for repair symbols.
• these methods can be extended to handle the case when sub-blocking is used, using similar methods as will be recognized by those skilled in the art.
• the receiver can use the methods described in Section 4.4 of [RaptorQ-RFC-6330] to determine (TL, TS, NL, NS), where the first NL sub-blocks of a source block are of size TL*Al and the remaining NS sub-blocks of a source block are of size TS*Al. Then, based on A, B, and the symbol size T, the receiver can determine that the start and end octet index of the N sub-symbols within the file that correspond to a source symbol, and make the requests for these octets using standard HTTP octet range requests.
• the receiver can translate requests for source symbols of a file or file part corresponding to particular UFSIs into HTTP octet range requests based on the FEC OTI.
• the following methods can greatly enhance the efficiency of using standard HTTP byte range requests by the receiver to recover symbols of an HTTP file, while at the same time using standard HTTP web caching servers to deliver the requested octet range requests to receivers.
• a straightforward method to support the HTTP octet range requests as described is to use the Original-order HTTP file.
• This method has the advantage that no transformation of the original file or file part is needed to generate the Original-order HTTP file for the HTTP web cache servers, but many different HTTP octet range requests might be needed to request source symbols, even when only consecutive source symbols are requested for each source block.
• UFSI- order HTTP file a new format, herein called the "UFSI- order HTTP file", based on the FEC OTI for the original file or file part. This method is useful when there are multiple source blocks and/or multiple sub-blocks per source block.
• the order of the data in the UFSI-order HTTP file is in order of the file symbol with UFSI 0, the file symbol with UFSI 1, the file symbol with UFSI 2, etc., i.e., the order of the data in the UFSI-order HTTP file is organized into file symbols ordered according to increasing consecutive UFSIs, as determined by the FEC OTI.
• a URL can be associated with the UFSI-order HTTP file, and the URL can be provided to the HTTP web caching system.
• the receiver can then use HTTP octet range requests to request portions of the UFSI-order HTTP file as needed.
• One advantage of the UFSI- order HTTP file is that, if the receiver receives approximately the same number of repair symbols from each of the source blocks then the number of HTTP octet range requests needed to obtain enough source symbols to recover the original file or file part can be minimal, e.g., one HTTP octet range request may be sufficient if exactly the same number of repair symbols is received for each source block.
• a request for the first L*T*Z consecutive octets of the UFSI-order HTTP file is sufficient to receive the first L source symbols of size T from each of the Z source blocks of the original file or file part. If K-L repair symbols are received in one or more sessions for each of the Z source symbols and if the FEC code has ideal recovery properties then the L*T*Z octets received from the HTTP octet range request is sufficient to FEC decode the HTTP file, where in this example it is presumed that K is the number of source symbols in each of the Z source blocks.
• Another advantageous method to support the HTTP octet range requests described above first reorganizes the file or file part into a different new format, herein called the "SS-order HTTP file", based on the FEC OTI for the original file or file part.
• This method is useful when there are multiple sub-blocks per source block, as in this case each source symbol may not be a consecutive portion of the original file or file part, i.e., the sub-symbols of a source symbol can be scattered throughout the source block in the original file ordering.
• the order of the data in the SS-order HTTP file is in order of all the source symbols of the first source block, followed by all the source symbols of the second source block, followed by all the source symbols of the third source block, etc., i.e., the order the data in the SS-order HTTP file is organized into source symbols ordered according to increasing consecutive ESI order within a source block, and is the concatenation of the source blocks in increasing consecutive SBN order, as determined by the FEC OTI.
• a URL can be associated with the SS-order HTTP file, and the URL can be provided to the HTTP web caching system. The receiver can then use HTTP octet range requests to request portions of the SS-order HTTP file as needed.
• the SS-order HTTP file is especially advantageous if the receiver receives different numbers of repair symbols from each of the source blocks. For example, if there are two source blocks of 1,000 source symbols each, and if the receiver receives 900 repair symbols for the first source block and 100 repair symbols for the second source block from one or more sessions, then the receiver can make one request for the first T * 100 octets of the SS-order HTTP file and receive 100 source symbols for the first source block, and the receiver can make another request for octets T * 1,000 through T * 1,900 - 1 of the SS-order HTTP file and receive 900 source symbols for the second source block, wherein in this example T is the symbol size in octets for both source blocks.
• a combination of both of the methods just described might also be used, i.e., both the UFSI-order HTTP file and the SS-order HTTP file might be made available through different URLs to receivers, and then a receiver might use a combination of HTTP octet requests to the two differently formatted HTTP files.
• the receiver might make an HTTP octet range requests to the UFSI- order HTTP file to receive 200 source symbols for each of the 10 source blocks, and an additional HTTP octet range request to the SS-order HTTP file to receive an additional 300 source symbols for the 10 th source block.
• the receiver may receive an unneeded 20 source symbols for the 9 th source block (assuming an FEC code with ideal recovery properties), but in some cases requesting more than the minimum needed octets for some source blocks using a smaller number of HTTP octet range requests may be more efficient than requesting exactly the needed number of source symbols for each source block, which may require a much larger number of different HTTP octet range requests.
• conventional HTTP -based file repair servers can start deploying receivers capable of making HTTP byte-range requests before the feature is fully supported over the entire their network or in roaming partner networks. Then, as the number of deployed HTTP- capable receivers increases, the operator can begin deploying the HTTP servers to match the estimated request load from these terminals. Signaling can be used in a particular network to indicate to the receivers that they can use the HTTP byte-range requests in that network.
• Another approach for signaling the network support of HTTP byte-range requests is to provide a descriptor alongside the repair server URI that indicates that the server supports HTTP byte-range requests only (e.g., tag the server URI as a
• byteRangeServiceURI type object
• This method is useful in networks that have already deployed repair servers only accepting symbol-based requests, typically identified by a "serviceURI” descriptor.
• Definition of the new "byteRangeServiceURI” allows new receivers to use byte range requests with these servers while preventing legacy receivers that do not recognize this descriptor from erroneously making symbol- based requests from these HTTP servers.
• Another embodiment for signaling the network support of HTTP byte-range request is to provide a descriptor alongside the repair server URI that indicates whether the server supports HTTP byte-range requests only, or supports HTTP-byte range requests and other request formats, such as symbol-based requests.
• the descriptor indicates one of three possibilities: (1) whether the repair server supports HTTP byte-range requests only, (2) whether the repair server supports another type of request format only (e.g., symbol-based), or (3) whether the repair server supports HTTP -byte range requests and other request formats.
• the descriptor can also indicate which of the request formats are preferred or required to be used if supported by the receiver. This descriptor of the request formats supported by the servers can be sent along with the list of repair server URIs.
• Another descriptor (e.g., "useFileURI” element) can also be sent to receivers indicating that they can use HTTP byte-range requests to retrieve portions of a file or all of a file directly from the content server where the file is stored, e.g., a location on the Internet.
• This enables an architecture where the network operator (such as a mobile network operator) does not have to deploy dedicated file repair servers and instead can rely on the content servers of the files to provide source data for the repair procedures.
• files are downloaded via a broadcast channel, they might be sent with a File Descriptor Table that includes the URI of the file, e.g., www. ⁇ news
• the content delivery system might include mechanisms for signaling to a receiver that, in addition to the broadcasted content, some or all of a file's content is available by unicast.
• This signaling might be data provided as part of the broadcast, wherein the data points to a unicast location.
• the broadcast data might include an indication of file availability and a URL for the file.
• Different embodiments might use these available files differently.
• the file indicated by the URL that is broadcast can be a file used for repair processing, used to speed up downloading, and/or to support faster initial playout.
• the file exists is more than one network or physical location.
• signaling on the broadcast channel may include a list of URLs indicating a plurality of locations where the file is accessible.
• the resource(s) indicated by the URL(s) can be restricted, for example by being available for only a limited amount of time. It can be beneficial to enable a mapping of an object (specified through an identifier in the broadcast distribution) to possibly multiple URLs. For each of the URLs, additional information may be provided, such as an indication that a file is physically accessible at one location using the HTTP protocol and available at other locations or the same location using other protocols.
• additional information include a time when the resource is accessible at the specific URL, and/or rules on the priority of the selection of a URL among a plurality of URLs to access the resource, for example priority lists, or priority lists depending on the access network available, etc.
• Another descriptor can also be sent with the server URI list to provide a prioritization of which servers or domains the receiver should try first when requesting repair data.
• a "priorityURI” element can be associated with certain URIs to indicate that they should be prioritized by the receiver in selecting a server. This enables two levels of prioritization whereby the receiver tries servers with the "priorityURI” first and only sends requests to the other servers if the prioritized servers are unresponsive.
• groups of server URIs can be structured into "priortyGroups" with the groups listed in order of decreasing priority. This indicates to the receiver that it should choose from the highest priority group first. If requests to all of these servers fail, then the receiver proceeds to selecting a server from the next group of servers, etc., thereby enabling multiple levels of prioritization.
• the signaling is over the broadcast channel for all the receivers (in-band) and in the other, the signaling is through a unicast channel to each receiver (out-of-band).
• the information can be added to a variety of existing message types used in the file-repair feature such as the
• the server When the server is configured to signal FDTs and USDs for distributing such information, and receivers are configured to read and understand those FDTs and USDs, this provides a facility for sending various useful information.
• the information might include an "Alternative-Content-Location" element in the File element in FLUTE, which can include multiple alternative URLs for the same file.
• This element may be extended to also add other parameters (such as indicators of resource availability, formats in which it is available, time that it is available, priority, etc.).
• a "BaseURL" element can be included in the FDT element (and thus not needed in the File element) to indicate to the receiver that each of the files in the FDT can be resolved against any of the BaseURL elements. Flags as above and timing may be present as well. This can cover many deployment options.
• the BaseURL element is presented on the USD level instead of on FLUTE. Thus, the USD can be provided as a way to do a BaseURL resolution for MBMS, while being compatible with FLUTE.
• some optional elements can be introduced into the File element of the File Delivery Table (FDT), such as an "Alternate-Content-Location- 1" element and an “Alternate-Content-Location-2" element.
• FDT File Delivery Table
• Each of these elements can be used to provide the URL of the file on a content server or on a common dedicated server.
• these URLs are prioritized by the terminal before making a request from symbol-based file repair servers when either of these elements is present. It is also possible to require that when both elements are present, the "Alternate- Content-Location- 1" element is selected before the "Alternate-Content-Location-2" element.
• the URLs can be absolute URLs or relative references as described in RFC 3986.
• an optional "Availability-Time” element is associated with each of the above “Alternate-Content-Location-x" attributes, to indicate the availability time, if known.
• Base-URL- 1 and “Base-URL-2” might be used in the File Delivery Table.
• “Base-URL- 1” provides a base URL against which to resolve a relative reference included in any "Alternate-Content- Location-1" element of the FDT File elements.
• “Base-URL-2” provides a base URL against which to resolve a relative reference included in any "Alternate- Content-Location-2" element of the FDT File elements.
• Other options may be considered and combinations of the above options may be considered as well. For example, embedding the file format type into other URLs grouped according to the file format available.
• the operator can shift more of the file repair capacity to conventional HTTP servers and indicate their capabilities via this signaling method.
• a terminal supporting the HTTP byte-range requests Upon receiving an indication that certain repair servers support HTTP byte-range requests, a terminal supporting the HTTP byte-range requests might use the byte- range message to request data from one of the supporting servers.
• the receiver follows the preferences or requirements indicated.
• Another approach is to signal to receivers that HTTP-byte range requests are supported by the repair servers without identifying which particular servers have this capability.
• the signaling would indicate that all the repair servers are capable of HTTP byte-range requests only, or all are capable of HTTP byte-range requests and other request message formats, e.g., symbol-based requests.
• the signal indicates one of three possibilities as listed above, namely: (1) whether all repair servers support HTTP byte-range requests only, (2) whether the repair servers support another type of request format only (e.g., symbol- based), or (3) whether the repair servers support HTTP-byte range requests and other request formats.
• the operator might upgrade all of the file repair servers to support the indicated request format(s) before signaling this to the receivers.
• the file format type might also be signaled, e.g., Original-order, UFSI- order, SS-order, Extended-original-order or other types of HTTP file formats. There might be a default file format type if no file format type is explicitly signaled, e.g., the Original-order HTTP file format might be the default in case no file format type is signaled.
• this signaling can also be signaled to the receiver using two general methods. In one, the signaling is over the broadcast channel for all the receivers (in-band) and in the other, the signaling is through a unicast channel to each receiver (out-of-band).
• the indication can be added to a variety of existing message types used in the file-repair feature such as the
• an Original-order HTTP file could all be made available for requests.
• a SS- order HTTP file may be split up and made available as a multitude of HTTP files, one such HTTP file for each source block.
• methods and protocols other than those based on HTTP might be used, such as methods based on PvTP/UDP, or proprietary protocols built on top of UDP, might be used.
• Fig. 13 is a block diagram of a communications system 1300 that uses multi-stage coding as might be used to send packets as part of a file delivery system as described herein. Of course, other codes and/or hardware might be used instead.
• an input file 1301, or an input stream 1305, is provided to an input symbol generator 1310.
• Input symbol generator 1310 generates a sequence of one or more input symbols (IS(0), IS(1), IS(2), ...) from the input file or stream, with each input symbol having a value and a position (denoted in Fig. 13 as a parenthesized integer).
• the possible values for input symbols i.e., its alphabet
• the value of M is generally determined by the use of communication system 1300, but a general purpose system might include a symbol size input for input symbol generator 1310 so that M can be varied from use to use.
• the output of input symbol generator 1310 is provided to an encoder 1315.
• Static key generator 1330 produces a stream of static keys So, Si, ....
• the number of the static keys generated is generally limited and depends on the specific embodiment of encoder 1315. The generation of static keys will be subsequently described in more detail.
• Dynamic key generator 1320 generates a dynamic key for each output symbol to be generated by the encoder 1315. Each dynamic key is generated so that a large fraction of the dynamic keys for the same input file are unique.
• a random number generator 1335 might provide an input to generator 1320 and/or generator 1330. For example, Luby I describes embodiments of key generators that can be used.
• the outputs of dynamic key generator 1320 and the static key generator 1330 are provided to encoder 1315.
• encoder 1315 From each key I provided by dynamic key generator 1320, encoder 1315 generates an output symbol, with a value B(I), from the input symbols provided by the input symbol generator. The operation of encoder 1315 will be described in more detail below.
• the value of each output symbol is generated based on its key, on some function of one or more of the input symbols, and possibly one or more redundant symbols that had been computed from the input symbols.
• the collection of input symbols and redundant symbols that give rise to a specific output symbol is referred to herein as the output symbol's "associated 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.
• M is the same for input symbols and output symbols, i.e., they both code for the same number of bits.
• the number K of input symbols is used by the encoder 1315 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 1315 to allocate storage for input symbols and any intermediate symbols generated by encoder 1315.
• Encoder 1315 provides output symbols to a transmit module 1340.
• Transmit module 1340 is also provided the key of each such output symbol from the dynamic key generator 1320.
• Transmit module 1340 transmits the output symbols, and depending on the keying method used, transmit module 1340 might also transmit some data about the keys of the transmitted output symbols, over a channel 1345 to a receive module 1350.
• Channel 1345 is assumed to be an erasure channel, but that is not a requirement for proper operation of communication system 1300.
• Modules 1340, 1345 and 1350 can be any suitable hardware components, software components, physical media, or any combination thereof, so long as transmit module 1340 is adapted to transmit output symbols and any needed data about their keys to channel 1345 and receive module 1350 is adapted to receive symbols and potentially some data about their keys from channel 1345.
• the value of K if used to determine the associates, can be sent over channel 1345, or it may be set ahead of time by agreement of encoder 1315 and decoder 1355.
• Other elements shown in Fig. 13 (and elsewhere herein, whether described as a module, a step, a process, etc., can also be implemented using hardware, software, and/or program code stored on
• channel 1345 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 1345 can be a storage channel, such as a CD-ROM, disk drive, Web site, or the like.
• Channel 1345 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.
• ISP Internet Service Provider
• channel 1345 is assumed to be an erasure channel, communications system 1300 does not assume a one-to-one correspondence between the output symbols that exit receive module 1350 and the output symbols that go into transmit module 1340. In fact, where channel 1345 comprises a packet network, communications system 1300 might not even be able to assume that the relative order of any two or more packets is preserved in transit through channel 1345. 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 1350.
• Receive module 1350 provides the output symbols to a decoder 1355, and any data receive module 1350 receives about the keys of these output symbols is provided to a dynamic key regenerator 1360.
• Dynamic key regenerator 1360 regenerates the dynamic keys for the received output symbols and provides these dynamic keys to decoder 1355.
• Static key generator 1363 regenerates the static keys So, Si, ... and provides them to decoder 1355.
• the static key generator has access to random number generator 1335 used both during the encoding and the decoding process. This can be in the form of access to the same physical device if the random numbers are generated on such device, or in the form of access to the same algorithm for the generation of random numbers to achieve identical behavior.
• Decoder 1355 uses the keys provided by dynamic key regenerator 1360 and static key generator 1363 together with the corresponding output symbols, to recover the input symbols (again IS(0), IS(1), IS(2), ). Decoder 1355 provides the recovered input symbols to an input file reassembler 1365, which generates a copy 1370 of input file 1301 or input stream 1305.
• File delivery can be done with multiple receivers and/or multiple senders. These concepts are illustrated in Figs. 14-15.
• Fig. 14 illustrates an arrangement wherein one receiver 2402 receives data from three transmitters 2404 (individually denoted "A”, "B” and “C”) over three channels 2406. This arrangement can be used to triple the bandwidth available to the receiver or to deal with transmitters not being available long enough to obtain an entire file from any one transmitter.
• each transmitter 2404 sends a stream of values, S().
• Each S() value represents an output symbol B(I) and a key I, the use of which is explained above.
• the value S(A, n A ) is the "n A "-th output symbol and "nA"-th key in a sequence of output symbols generated at transmitter 2402(A).
• the sequence of keys from one transmitter is preferably distinct from the sequence of keys from the other transmitters, so that the transmitters are not duplicating efforts. This is illustrated in Fig. 14 by the fact that the sequence S() is a function of the transmitter.
• 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., n A ⁇ n B ⁇ n c ).
• Fig. 15 copies of one input file 2502 are provided to a plurality of transmitters 2504 (two of which are shown in the figure). Transmitters 2504 independently transmit output symbols generated from the contents of input file 2502 over channels 2506 to receivers 2508. Each transmitter of the two shown might need to only transmit (K + A)/2 output symbols before the receiver's decoder is able to recover the entire input file.
• 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.
• receiver unit 2510 performs the functions similar to the functions of receive module 1350, decoder 1355, dynamic key regenerator 1360 and input file reassembler 1365 shown in Fig. 13.
• 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.
• 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.
• 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.
• 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.
• 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.
• a block-request streaming system using an HTTP streaming server might deliver files as described above. Below, an example implementation of such a system is described.
• the sources might be standard web servers and content delivery networks (CDNs) and might use standard HTTP.
• CDNs content delivery networks
• requests may be made, using HTTP, for individual segments that are seamlessly spliced together by the client.
• Advantages of HTTP streaming include the use of standardized and existing infrastructure.
• Fig. 16 which shows a simplified diagram of a block-request streaming system that might deliver files.
• a block-streaming system 1600 is illustrated, comprising block serving infrastructure ("BSI") 1601 in turn comprising an ingestion system 1603 for ingesting content 1602, preparing that content and packaging it for service by an HTTP streaming server 1604 by storing it into a content store 1610 that is accessible to both ingestion system 1603 and HTTP streaming server 1604.
• system 1600 might also include an HTTP cache 1606.
• a client 1608, such as an HTTP streaming client sends requests 1612 to HTTP streaming server 1604 and receives responses 1614 from HTTP streaming server 1604 or HTTP cache 1606.
• elements shown in Fig. 16 might be implemented, at least in part, in software, therein comprising program code that is executed on a processor or other electronics.
• media blocks may be stored within a block serving infrastructure 1601(1), which could be, for example, an HTTP server, a Content Delivery Network device, an HTTP proxy, FTP proxy or server, or some other media server or system.
• Block serving infrastructure 1601(1) is connected to a network 1722, which could be, for example, an Internet Protocol (“IP”) network such as the Internet.
• IP Internet Protocol
• a block-request streaming system client is shown having six functional components, namely a block selector 1723, provided with the metadata described above and performing a function of selecting blocks or partial blocks to be requested from among the plurality of available blocks indicated by the metadata, a block requestor 1724, that receives request instructions from block selector 1723 and performs the operations necessary to send a request for the specified block, portions of a block, or multiple blocks, to block serving infrastructure 1601(1) over network 1722 and to receive the data comprising the block in return, as well as a block buffer 1725, a buffer monitor 1726, a media decoder 1727 and one or more media transducers 1728 that faciliate media consumption.
• a block selector 1723 provided with the metadata described above and performing a function of selecting blocks or partial blocks to be requested from among the plurality of available blocks indicated by the metadata
• a block requestor 1724 that receives request instructions from block selector 1723 and performs the operations necessary to send a request for the specified block, portions of a block, or multiple
• Block data received by block requestor 1724 is passed for temporary storage to block buffer 1725, which stores the media data.
• the received block data can be stored directly into block buffer 1725.
• Media decoder 1727 is provided with media data by block buffer 1725 and performs such transformations on this data as are necessary to provide suitable input to media transducers 1728, which render the media in a form suitable for user or other consumption. Examples of media transducers include visual display devices such as those found in mobile phones, computer systems or televisions, and might also include audio rendering devices, such as speakers or headphones.
• Buffer monitor 1726 receives information concerning the contents of block buffer 1725 and, based on this information and possibly other information, provides input to block selector 1723, which is used to determine the selection of blocks to request, as is described herein.
• a block-request streaming system comprises one or more clients that make requests to one or more content servers (for example, HTTP servers, FTP servers, etc.).
• An ingestion system comprises one or more ingestion processors, wherein an ingestion processor receives content (in real-time or not), processes the content for use by the BRSS and stores it into storage accessible to the content servers, possibly also along with metadata generated by the ingestion processor.
• the BRSS also might contain content caches that coordinate with the content servers.
• the content servers and content caches might be conventional HTTP servers and HTTP caches that receive requests for files or segments in the form of HTTP requests that include a URL, and may also include an octet range, in order to request less than all of the file or segment indicated by the URL.
• the clients might include a conventional HTTP client that makes requests of HTTP servers and handles the responses to those requests, where the HTTP client is driven by a novel client system that formulates requests, passes them to the HTTP client, gets responses from the HTTP client and processes those (or storing, transforming, etc.) in order to provide them to a presentation player for playout by a client device.
• the client system does not know in advance what media is going to be needed (as the needs might depend on user input, changes in user input, etc.), so it is said to be a "streaming" system in that the media is “consumed” as soon as it is received, or shortly thereafter.
• response delays and bandwidth constraints can cause delays in a presentation, such as causing a pause in a presentation as the stream catches up to where the user is in consuming the presentation.
• a number of details can be implemented in the BRSS, either at the client end, at the ingestion end, or both. In some cases, the details that are implemented are done in consideration of, and to deal with, the client-server interface at the network. In some embodiments, both the client system and the ingestion system are aware of the enhancement, whereas in other embodiments, only one side is aware of the
• the entire system benefits from the enhancement even though one side is not aware of it, while in others, the benefit only accrues if both sides are aware of it but when one side is not aware, it still operates without failing.
• the ingestion system may be implemented as a combination of hardware and software components, according to various embodiments.
• the ingestion system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methodologies discussed herein.
• the system may be realized as a specific machine in the form of a computer.
• the system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system.
• PC personal computer
• system shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
• the ingestion system may include the ingestion processor 1802 (e.g., a central processing unit (CPU)), a memory 1804 which may store program code during execution, and disk storage 1806, all of which communicate with each other via a bus 1800.
• the system may further include a video display unit 1808 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)).
• the system also may include an alphanumeric input device 1810 (e.g., a keyboard), and a network interface device 1812 for receiving content source and delivering content store.
• the disk storage unit 1806 may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein.
• the instructions may also reside, completely or at least partially, within the memory 1804 and/or within the ingestion processor 1802 during execution thereof by the system, with the memory 1804 and the ingestion processor 1802 also constituting machine-readable media.
• the client system may be implemented as a combination of hardware and software components, according to various embodiments.
• the client system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methodologies discussed herein.
• the system may be realized as a specific machine in the form of a computer.
• the system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system.
• PC personal computer
• system shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
• the client system may include the client processor 1902 (e.g., a central processing unit (CPU)), a memory 1904 which may store program code during execution, and disk storage 1906, all of which communicate with each other via a bus 1900.
• the system may further include a video display unit 1908 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)).
• the system also may include an alphanumeric input device 1910 (e.g., a keyboard), and a network interface device 1912 for sending requests and receiving responses.
• the disk storage unit 1906 may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein.
• the instructions may also reside, completely or at least partially, within the memory 1904 and/or within the client processor 1902 during execution thereof by the system, with the memory 1904 and the client processor 1902 also constituting machine-readable media.
• the UOSI FEC payload ID can be used together with RaptorQ FEC Scheme in [RaptorQ-RFC-6330] (herein referred to as the "UOD-RaptorQ FEC Scheme") to provide simplified and enhanced object delivery capabilities.
• RaptorQ FEC Scheme in [RaptorQ-RFC-6330] (herein referred to as the "UOD-RaptorQ FEC Scheme")
• UOD-RaptorQ FEC Scheme RaptorQ FEC Scheme
• more flexible and simpler support is provided for basic object delivery, and support is also provided for unequal error protection (UEP) object delivery, for bundled object delivery, and for combinations of UEP and bundled object delivery.
• UEP unequal error protection
• suitable hardware and/or software can be used to implement the "UOD-RaptorQ FEC Scheme" between communicating devices.
• the FEC Payload ID format is a 4-octet field as illustrated in Fig. 2, where in this specific implementation, the Universal File Symbol Identifier (UFSI), a 32-bit, unsigned integer, is generalized by a Universal Object Symbol Identifier (UOSI), also a 32-bit, unsigned integer.
• UFSI Universal File Symbol Identifier
• UOSI Universal Object Symbol Identifier
• the UOSI is a non-negative integer that, in conjunction with the FEC OTI, is used to identify the encoding symbols contained within a packet carrying that payload ID.
• the FEC OTI is as described below. It should be noted that for each object delivered, the FEC OTI can be the same as specified by the RaptorQ FEC Scheme. A delivery might comprise d objects, for some positive integer d. Each object may comprise different parts of the same file, or different files, or combinations thereof.
• the relationship between the size, F ⁇ , of an object, i, and the size, Tj, of the encoding symbol to be used for object i can be used to determine the priority of object i in the transmission.
• the Common FEC OTI elements specific to object i include a 16-bit unsigned integer for the symbol size, Tj, a positive integer that is less than 2 , indicating the size of a symbol for object i in units of octets, a 40-bit unsigned integer for the transfer length, F of object i, which is a non-negative integer that is at most 2 40 , indicating the transfer length of object i in units of octets. Suitable padding is provided.
• Scheme-Specific FEC OTI element includes a symbol alignment parameter (Al) (8 bits, unsigned integer), Scheme-Specific FEC OTI elements for each object, comprising the number, 3 ⁇ 4, of source blocks for object i (12 bits, unsigned integer), and the number, N, of sub-blocks for object i.
• Al symbol alignment parameter
• Scheme-Specific FEC OTI elements for each object comprising the number, 3 ⁇ 4, of source blocks for object i (12 bits, unsigned integer), and the number, N, of sub-blocks for object i.
• the encoded FEC OTI can then be a (2+10* ⁇ f)-octet field comprising a concatenation of the encoded Common FEC OTI and the encoded Scheme-specific FEC OTI elements.
• Content delivery using the encoded FEC OTI can involve an information exchange between devices, computers, programs of systems using the UOD-RaptorQ FEC Scheme and a content delivery protocol ("CDP") that makes use of the
• the CDP should provide an encoder device and decoder device with d, Al, and for each object, F t , Tj (a multiple of At), Zi and Ni.
• the encoder is provided with each object, indexed by i.
• the encoder device that uses the UOD-RaptorQ encoder scheme would supply the CDP, for each packet to be sent, the packet's UOSI and the encoding symbol(s) for the d object(s).
• the example parameter derivation described in Section 4.3 of [RaptorQ-RFC-6330] might be used, applied independently to each of the d objects.
• Al 4 octets
• Tj for object i is preferably at least SS*A1 octets, with Tj being a multiple of Al
• each encoding packet would contain a UOSI and the encoding symbol(s) for the d object(s).
• the (SBN, ESI) format of the FEC Payload ID used by the RaptorQ FEC Scheme of [RaptorQ- RFC-6330] and the UOSI format used by the UOD-RaptorQ FEC Scheme might be a specific format.
• the mapping from a UOSI value, C, to the corresponding (SBN, ESI) values (A, B) for an object i might be where
• UOSI values from KTj onwards identify repair symbols generated from the source symbols of object i using the RaptorQ encoder.
• Encoding packets may contain source symbols, repair symbols, or
• a packet may contain any number of symbols from the same source block of object i. Where the last source symbol in a source packet for object i includes padding octets added for FEC encoding purposes, these octets should be included in the packet, so that only whole symbols are included in each packet.
• the Universal Object Symbol Identifier, C, carried in each encoding packet is the UOSI of the first encoding symbol for each object carried in that packet.
• the subsequent encoding symbols in the packet for each object have the UOSIs numbered from C+l to C+G-l, in sequential order, where G is the number of encoding symbols for each object in the packet.
• G is the number of encoding symbols for each object in the packet.
• the repair symbols are sent in a broadcast fashion and source symbols are sent in a unicast fashion in response to UE requests for some sets of the source symbols.
• the repair symbols are sent in a broadcast fashion and source symbols are sent in a unicast fashion in response to UE requests for some sets of the source symbols.
• An example broadcast file delivery system is an eMBMS file delivery system.
• An example unicast file delivery system is an HTTP byte-range request capable system. However, a unicast system wherein only whole files can be requested and provided could possibly be used, but many benefits would be lost. Earlier sections herein show some example systems.
• repair data is sent in the broadcast session, and only source data is sent in the unicast repair session.
• the unicast repair requests are standard HTTP 1.1 byte range requests for parts of the original file. Since the broadcast session only had repair symbols, there will not be overlapping data between the two sessions. It should be noted that in some implementations, both the earlier-described system and the system of this section could co-exist and/or be combined.
• UEs e.g., end-user devices; such as a mobile user device
• UEs can be configured to determine what source symbols the UE is missing and convert from source block number, encoding symbol id of the missing source symbols to standard HTTP 1.1 byte range requests and make those requests.
• the unicast repair server By sending repair symbols in the broadcast session, the unicast repair server only needs an original copy of the file, and the requests will be simple requests for a consecutive range of source symbols or for a consecutive large range of consecutive bytes rather than requests for individual symbols or requests for many small ranges of bytes.
• the UE might determine how many symbols to request based on simply counting how many are received and how many are needed, or based on running a decoding schedule to determine for example the prefix number of source symbols that will allow decoding of a source block, or prefix number of source sub-symbols that will allow decoding of a source sub-block, or prefix byte range size that will allow decoding of a sub-block or source block.
• prefix is meant to designate the "prefix of a portion of a file corresponding to a sub- block” or "prefix of a portion of a file corresponding to a source block", i.e., "prefix” may not refer to prefix of the entire file, but instead prefix of a relevant portion of the file, where the relevant portion can be inferred from the context in which "prefix” is used.
• a request for consecutive source symbols of a source block can be translated into a request for a consecutive sequence of bytes.
• a request for a consecutive number of source sub-symbols of a sub-block can be translated into a request for a consecutive sequence of bytes of the file.
• the UE can derive the byte range request in the file from a request for a consecutive number of source sub-symbols of a sub-block.
• different broadcast servers have different sets of repair symbols, perhaps based on different geographies. This is beneficial for UEs that move from one geography to another during the broadcast transmission in order to ensure that there is not duplicate reception for the same device.
• the UEs request a byte range prefix of a sub-block (or block, in the case where sub-blocks are not used) in HTTP requests, largely independent of which repair sub- symbols (symbols, in the case where sub-blocks are not used; this parenthetical applies below as well) they receive in the broadcast session and only depending on how many repair symbols they received in the broadcast session.
• the byte range prefix requested can be completely independent of which repair symbols are received in the broadcast session.
• the size of the byte range prefix may depend weakly on which repair symbols are received in the broadcast session. For example, if there are K source sub-symbols in a source sub-block, and K-L repair sub-symbols are received for that sub-block, the requesting a byte range prefix that corresponds to the first L source sub-symbols will allow decoding with probability at least 99%, and requesting L+1 sub-symbols will allow decoding with probability at least 99.99%, and requesting L+2 sub-symbols will allow decoding with probability at least 99.9999%.
• Whether or not decoding is possible depends on the pattern of sub-symbols that are used for decoding, and the receiving device and determine before making the request whether a particular sequence of received sub- symbols will allow decoding and thus determine which requests to make to guarantee decoding.
• the size of the prefix requested for repair can depend weakly on the pattern of received sub-symbols in the broadcast session.
• the receiving device might simply make a request for L+2 sub-symbols, in which case the request size is independent of which sub-symbols are received in the broadcast session, at the expense of an overhead of receiving potentially 2 redundant sub-symbols, i.e., K - L sub-symbols from the broadcast session and L+2 from the repair request for a total of K+2 sub-symbols received to recover the K source sub-symbols, and at the expense of a very small probability of failing to decode.
• Some reasons for making the size and pattern of the request independent of which data is received, and only depend on how much data is received in the broadcast session include:
• the UE requests can be simple, and always request from the beginning of the source sub-block (block), one byte range request per source sub-block (block) at most (in some cases if enough repair sub-symbols (symbols) are received in the broadcast session then no additional HTTP requests are needed).
• a UE can start playing out the content of the sub-block (block) while it is downloading over HTTP from the repair server, then once it has downloaded enough, it can use the already received over broadcast repair sub-symbols to recover the remaining portion of the sub-block (size of remaining sub-block (block) is essentially the size of the repair sub-symbols (symbols) for the sub-block (block) received in the broadcast session).
• the UEs that receive the least amount of repair sub- symbols will generally make the largest prefix byte range request for the source sub- block, and all requests from other UEs will be a subset of this request.
• an HTTP server has already fetched and served the byte range request for one UE for a sub-block (block)
• the HTTP server can cache this response and have it available for the next UE that makes a repair request for the same sub-block (block).
• An HTTP caching server may proactively request from an upstream server a larger byte range than is requested by the UE, thus reducing the time till data beyond the size of the request is available if there are further requests from the same or other UEs for portions of the data beyond the current request.
• one UE makes a request for a prefix of data from a relevant portion of a file
• the HTTP caching server may already have that cached and be able to respond to the request with the corresponding prefix of data immediately.
• an HTTP repair server receives multiple requests, e.g., beyond some threshold, for overlapping byte-ranges, the server can also be configured to decide to forward a request to the BMSC requesting broadcast of this byte range of data to avoid redundantly loading the unicast channels to these receivers.
• the repair server would only have to unicast to each receiver the source data that was not going to be broadcast by the BMSC.
• the BMSC can convert the byte-range request into the necessary source symbols required and can then broadcast these source symbols, or better, broadcast these many new repair symbols. This allows the terminals to receive enough non- redundant symbols to repair their files with less loading to the unicast channels.
• the UE In some cases, it is an advantage for the UE to only make unicast requests for source symbols (sub-symbols) for a source block (sub-block) when the UE is ready to play back the content associated with that source block (sub-block), i.e., to use a "streaming mode" for making requests.
• One reason is that the UE only requests repair data for content it is actually going to play back, and if for some reason it never plays back some of the content, then it never wastes the unicast network resources requesting data for that block (sub-block).
• the UE may start playing back a content (file) from the middle, and only play back one quarter of the content.
• only making the requests when the play back is imminent reduces the unicast network resources to around one-fourth of what would be needed if the unicast repair requests are made to recover the entire content file before play back.
• source symbols sub-symbols
• a system operator can benefit from these approaches. For example, the deployment of unicast repair servers can be simplified and can be much less expensive. It also eliminates the need to purchase, deploy and operate specialized repair servers instead of relying upon much cheaper and easier to deploy and manage HTTP web servers.
• the operator may deploy a service whereby Internet content files are transparently captured, FEC repair data for them are broadcast to UEs, and then the UEs include methods to use the received FEC repair data broadcast to them, determine what HTTP 1.1 byte range requests to make that combined with FEC repair data received over broadcast allow them to recover the portions of the file they are going to play back, make the appropriate HTTP 1.1 byte range requests over the Internet for portions of the Internet-available content file that may already be cached in existing CDNs (not necessarily operated by the operator, nor is the content necessarily sourced by the operator).
• the operator may provide a valuable service of providing better user experience (since files are available much more reliably and much faster) while at the same time reducing the amount of overall network traffic on their network needed to deliver the files (since the broadcast data is useful to all UEs and takes less network resource to send than sending the data over many individual unicast connections to each individual UE), and at the same time the operator can avoid the cost of deploying any unicast repair servers to support their service, since the content is already available from standard HTTP web servers provided by others and this is what is used to support the unicast repair.
• the system operator can also repurpose existing HTTP web servers and create new service opportunities, such as intercepting and broadcasting repair symbols for files that are delivered from other content providers via HTTP web servers to UEs.
• this approach can save operator network bandwidth capacity.
• the cost is the amount of broadcast data sent over a network, while the benefit is the sum over all UEs that play back content of amount of broadcast data received by that UE. This can provide better user experience on the operator network as well as faster and more reliable delivery of content.
• the session description and the MBMS download delivery protocol, FLUTE provide the client (i.e., a UE) with sufficient information to determine the source block and encoding symbol structure of each file. From this, a client is able to determine which source symbols can be requested and used to recover the file. Thus, an MBMS client is able to identify the number of required source symbols that would complete the reconstruction of a source block (of a file).
• the MBMS client can consider already received repair symbols when making the determination of the further source symbols required. In this case, the client should identify for each source block (of the file) a number, r, and make a repair request for the first r source symbols of the source block that will allow the MBMS FEC decoder to recover the file.
• the MBMS client sends one or more messages to a file repair server requesting transmission of data that allows recovery of missing file data. All file repair requests and repair responses for a particular MBMS transmission can take place in a single TCP session using the HTTP protocol.
• the byte range request may be partitioned into multiple requests over different potentially overlapping HTTP/TCP connections, or FTP connections, or RTP connections or the like.
• Responses to repair requests may be delivered at a very slow or high bit-rate, depending on network availability and how busy the receiving device is and its capabilities.
• the repair request can be routed to the file repair server IP address resolved from the selected "serviceURI.”
• the timing of the opening of the TCP connection to the server, and the first repair request, of a particular MBMS client can be randomized over a time window, so that not all UEs make their unicast requests at the same time.
• a MBMS UE When a MBMS UE identifies symbols to be requested in repair requests, the reply will be the corresponding symbols so identified, and should include all the symbols from the relevant source block identified in the request.
• the MBMS UE may instead make requests for sub-symbols of source sub-blocks when sub-blocking is used.
• byte range requests may be made to request symbols or sub-symbols.
• the MBMS UE may combine this with other methods. For example, the MBMS UE may receive data in the broadcast session and store it in long term storage without de-interleaving or decoding the original source file, as described in Luby VI. The MBMS UE may trigger de-interleaving and decoding portions of the original source file in response to an end user making requests to play back those portions of the source file, for example when the source file is a video file. If the MBMS UE doesn't receive enough data from the broadcast session to recover the portions of the original source file that are being requested for play back, then the MBMS UE may make repair requests as described herein for the relevant portions of the source file that the end user is requesting to play back.
• the MBMS UE may only make requests to receive additional data for certain sub-blocks or source blocks only if not enough data is received in the broadcast session to recover them, and the requests are only made at or near the time when the end user desire to play back portions of the source file that intersect those sub-blocks or source blocks.
• This embodiment minimizes network resources, as repair data for portions of the source file is only requested when the end user requests play back of those portions, and thus if portions of the file are never played back then repair requests for those portions are never made.
• this embodiment minimizes device resources required to read in from long term storage and de-interleave and decode the data for recovering sub-blocks or source blocks, since these operations are only performed if the end user requests play back of these portions of the source file.
• the MBMS UE may make repair requests for sub-blocks or source blocks for which not enough data has been received to recover from the broadcast session when the MBMS UE has appropriate network connection and idle capacity to make such repair requests, and then store the response data to long term storage for later recovery of the sub-blocks or source blocks, in addition to the data received from the broadcast session for these sub-blocks or source blocks.
• the MBMS UE can read back from long storage the combination of the interleaved and encoded data received from the broadcast session and from the repair requests for the sub-blocks or source blocks intersecting the user requested portions of the file and recover those sub-blocks or source blocks and provide them directly for play back to the video player.
• This alternative has the advantage that the repair data can be requested when the MBMS UE is connected to the appropriate network to make repair requests and receive responses, whereas when the user requests play back the MBMS UE may not be connected to the appropriate network. Furthermore, the play back response time to user requests for play back may be smaller, since all the data needed for play back is stored locally at the time of the user request on the device instead of requiring delivery over a network.
• the MBMS UE can request repair data for all of the sub-blocks or source blocks for which additional data is required to recover, and recover all of the file and store it in long term storage for later play back or usage.
• the MBMS UE may perform these operations at any point in time in any order, i.e., the repair data in some case may be requested before receiving data from the broadcast session, for example if it is known that not enough data will be sent over the broadcast session to fully recover the sub-blocks or source blocks of the file, or if for example the end user desires to start playing back the content before the broadcast session has ended (and potentially before it has begun).
• the repair broadcast sessions use partial reordering of broadcast data as illustrated in Luby VI at the UE.
• the combination of the unicast repair service using HTTP as described above can be combined with the methods described in Luby VI.
• the symbols/sub-symbols received in the broadcast transmission could be stored into flash or other memory as described in Luby VI.
• Luby VI The methods described in Luby VI can be used to write the symbols or sub-symbols received from a broadcast session into flash memory, and then when a source block or sub-block is to be recovered the methods described in Luby VI can be used to read into RAM the symbols or sub-symbols for the source block or sub-block stored in flash memory from the broadcast session. These can then be combined with the symbols or sub-symbols received via HTTP and stored directly into RAM, and the source block or sub-block is decoded in RAM using the combination of these symbols or sub-symbols and then the recovered source block or sub-block can be provided directly for play back.
• Luby VI Some methods described in Luby VI can be used to write the symbols or sub-symbols received via HTTP into flash memory, and the same for symbols or sub- symbols received via a broadcast session, and then at any point in time a source block or sub-block can be recovered on the fly by reading into RAM from flash memory the combination of the symbols or sub-symbols for the source block or sub-block stored in flash memory based on the HTTP request and the symbols or sub-symbols for the source block or sub-block stored in flash memory from the broadcast session.
• the symbols or sub-symbols received via the broadcast session and the symbol or sub-symbols received in the repair session are largely different sets of symbols or sub-symbols.
• Fig. 22 illustrates basic FLUTE file delivery. Note that the FEC Payload ID could instead comprise the UOSI or UOFI described herein.
• Fig. 23 illustrates some portions of a basic FLUTE packet format.
• Fig. 24 illustrates sub-block encoding that occurs at a sender that uses sub- blocks. As illustrated there, a file can be organized as one or more source block (one in this example) and divided into sub-blocks, which are arranged to form symbols from sub-symbols.
• Fig. 25 illustrates sub-block decoding that occurs at a receiver that uses sub- blocks. In some cases, there is partial reordering before storing at the receiver. This might be useful, for example, where there is asymmetry in a storage element between reading and writing.
• Fig. 26 illustrates file delivery using sub-blocking.
• the receiver sees the same loss pattern within each sub-block.
• a file might be one source block and each packet might contain one symbol.
• a schedule of decoding operations can be the same for all sub- blocks, with the same loss or reception pattern of sub-symbols for each sub-block, and the receiver computes the schedule once for all sub-blocks.
• the schedule of decoding operations is then applied to each sub-block separately, operating on sub-symbols and applying the same schedule to all sub-blocks.
• the decoder's CPU can perform well even operating on large source blocks, using only a small amount of scratch RAM memory and allowing for access and decoding of sub-blocks of media when they are played back.
• Fig. 27 illustrates an example of the handling of multiple source blocks.
• the symbols are sent in a round-robin fashion, with one symbol from each source block sent each round.
• the symbols are sent in a sequential fashion, i.e., for each source block all symbols are sent in a consecutive sequence without interspersing symbols from other source blocks. Sub-blocking can be used in all cases.
• Fig. 28 illustrates a workflow using FEC and FLUTE.
• a file is defined to be carried in a FLUTE session.
• the file may be segmented into blocks. The need for segmentation is driven by the max size the FEC scheme can handle.
• step 3 FEC is applied to a block, each block is divided into K equal sized systematic symbols, and R 1 +R 2 repair FEC symbols are generated.
• K+Ri symbols are sent via FLUTE over a broadcast transmission, or alternatively via unicast using UDP, or via unicast using HTTP.
• Each IP/UDP/LCT packet carries one or more symbols depending on symbol size.
• step 5 the receiver collects enough packets such that ⁇ + ⁇ symbols are available for FEC decoding.
• 5 2.
• the additional R 2 symbols generated in step 3 might be provided to HTTP servers to provide an HTTP-based repair service for receivers that don't receive K+5 symbols from the transmission in step 4.
• Fig. 29 illustrates the above-described broadcast/repair, unicast/source configuration.
• a large number of repair symbols can be generated.
• a UE needs any K+5 of those symbols for successful FEC decoding.
• each broadcast BM-SC sends N different Raptor repair symbols of a file and each BM-SC sends only repair symbols, i.e., those with ESI in the range ⁇ K, K+l, ... ⁇ .
• One advantage of the above embodiments is that when a UE is roaming between the coverage areas of different BM-SCs, a UE can use symbols from different BM-SCs and not worry about duplicate reception of symbols, allowing for more efficient FEC decoding.
• the UE can make simple repair requests for source symbols (although this may require specialized repair request servers), but could also make HTTP byte range requests, using conventional HTTP web servers that have only the original source file as described in more detail elsewhere herein. This allows for more cost effective and converged Internet/MBMS solutions.
• Fig. 30 illustrates how a system would broadcast only repair symbols over the MBMS bearer and the UE would request only a contiguous set of source symbols.
• the UE typically needs ⁇ + ⁇ symbols to successfully decode the source block, but has only received ⁇ + ⁇ -R repair symbols over the MBMS bearer.
• the UE requests the first R (or K, when R>K) source symbols of the source block. It could request some other R source symbols, but if all UEs are requesting overlapping sets of source symbols, downstream caches are more likely to be able to deliver the requested source symbols to most receivers from their local cache.
• the UE can request a contiguous set of source symbols from the repair server using the Initial ESI + (the value of R). This keeps the requests very simple and short. This can also simplify the server construction of the response as the server does not have to retrieve and append disjoint sets of source symbols. This can be especially advantageous in deployments that do not use "no-code" FEC schemes as the server only has to handle contiguous source symbol requests.
• Fig. 31 illustrates using unicast repair via HTTP byte range requests when sub- blocking is used.
• the UE can request the same number of bytes for each sub-block for the same source block.
• One request of a byte-range for each sub-block can be used in most circumstances when no source symbols are sent in the broadcast session.
• HTTP requests can be made on an "as needed" basis.
• the UE can make a request for each sub-block when it is time to play back content within that sub-block.
• the UE can request and play back content for sub-block over HTTP until it has enough sub-symbols in combination with the sub-symbols receiver over other transports such as a broadcast session to decode and recover the sub-block. Once enough sub-symbols are received and decoded, the UE can seamlessly continue play back from locally recovered sub-blocks.
• the UE does not need to make HTTP requests for sub-blocks that are never played back.
• a reciever might perform calculations explained in this section, in order to determine which byte ranges to request. The calculations might rely on the FEC structure. The receiver can then send a request to the server to obtain the symbols the receiver needs based on byte range requests.
• the receiver uses the FEC Object Transmission Information (“FEC OTI") to recognize what symbols it has not received.
• the FEC OTI determines the source block, sub-block, symbol, and sub-symbol structure of the file, and is comprises the object transport size, F, the alignment factor, Al, the symbol size, T, the number of source blocks, Z, and the number of sub-blocks per source block, N.
• the receiver uses all of this information together with the properties of the FEC code itself to determine exactly how many and what symbols it needs, with each symbol or sub-symbol identified by the SBN, ESI and SuBN (source block number, encoding symbol identifier, sub-block number, respectively).
• source symbols or source sub-symbols are requested.
• the receiver uses the FEC OTI information to calculate the byte-ranges in the file that correspond to these symbols or sub-symbols as described in the following:
• the receiver can compute the starting byte number and ending byte number in the file of the corresponding source symbol identified by the (SBN, ESI) pair.
• the start byte associated with the symbol identified by SBN and ESI can be calculated as in Equation 2.
• the end byte position of this sub-symbol can be calculated by adding T-l to the start byte position.
• NL TIAl - TS*N
• NS N - NL
• TL* Al is the size of the sub-symbols in the first NL sub-blocks
• TS*Al is the size of the sub-blocks in the remaining NS sub-blocks.
• the start byte associated with the symbol identified by SBN, ESI, and SuBN can be calculated as in Equation 3.
• the end byte position of this sub-symbol can be calculated by adding r Su BN-l to the start byte position.
• the receiver can determine the byte-range requests it needs to send to the server. In cases where there are contiguous missing symbols or sub- symbols, the receiver can start the byte range request from the start byte position of the first missing symbol or sub-symbol and end the range at the end byte position of the last missing symbol or sub-symbol.
• each source block is further partitioned into 12 sub-blocks each, each with 7,576 source sub-symbols, wherein the first 6 sub-blocks have sub-symbols of size 112 bytes and the remaining 6 sub-blocks have sub-symbols of size 108 bytes.
• the HTTP GET request might be as follows:
• statistics are gathered as they relate to the various requests being made for content. These statistics might be useful, for example, for a system operator to be able to tell how many files are not entirely sourced from broadcasts of content. This could be done by just looking at the HTTP logs for the repair servers that provide repair data in a unicast fashion. However, if the repair server is also serving as a direct source for the content (such as from requests from a device that does not attempt receipt of broadcast symbols or simply looks to a repair server as a primary HTTP source for the content), then statistics would overcount the requests. The system operator could have the devices themselves report broadcast/unicast statistics (and not report unicast-only requesting), but this relies on the devices and that can be cumbersome. In one solution, the HTTP repair servers collect the statistics and are able to distinguish between requests that are for repair data due to broadcast losses and requests that are direct unicast requests for content.
• a repair server determines the type of request (repair request vs. direct request) and which terminal is making the request. The first part distinguishes between HTTP requests it is receiving that are for repairing a file received over the broadcast channel and requests from terminals that are merely requesting or repairing a file they received over unicast.
• the terminal identification allows the server to map requests from the same terminal and also provide detailed reception statistics for each terminal. This might be useful to reduce double-counting and also to better map repair patterns.
• the server URL or the URL of the file might be specific to repair-type requests to distinguish from direct unicast-type requests. For example, these URLs might be only provided in the Associated Delivery Procedures of the broadcast service, or File Delivery Table of the file being broadcast. These URLs would not be provided for terminals to directly download a file that was not broadcast.
• the server can determine that requests to the particular URLs are for repairing broadcasted files and collect repair statistics based on these requests. For identifying requests from the same terminal, the server can use the source IP address of the HTTP GET request.
• the server can use the IP address of the terminal to identify which terminal is making the request.
• the server can also use the IP address to determine whether the request is coming from a broadcast terminal if the HTTP server knows which IP addresses belong to broadcast terminals. Note that this approach is not as reliable for collecting broadcast statistics if a terminal is allowed to request data for files it did not receive via broadcast. So some restrictions could be placed on broadcast terminals directly requesting a file from these servers.
• an extension can be added to the HTTP GET request used by the terminal to request data from the HTTP server.
• the extension will identify that the request is for repairing a broadcasted file.
• the extension can also identify a unique ID of the terminal such as the Mobile Directory Number or the International Mobile Subscriber Identity (IMSI).
• IMSI International Mobile Subscriber Identity
• Another example of an extension header is to use the "X- 3GPP-Intended-Identity extension-header" as defined in 3 GPP TS 24.109.
• a hash or encryption can be applied to these IDs if the operator does not want to send these in the clear for privacy or security purposes.
• a content delivery system might comprise clients such as UEs and servers such as an MBMS broadcast server and/or HTTP servers, preferably those that support byte-range requests in addition to URL file requests.
• clients such as UEs and servers such as an MBMS broadcast server and/or HTTP servers, preferably those that support byte-range requests in addition to URL file requests.
• servers such as an MBMS broadcast server and/or HTTP servers, preferably those that support byte-range requests in addition to URL file requests.
• repair symbols might be broadcast and only source symbols are available via requests to an HTTP server.
• repair and/or source symbols might be broadcast and repair and/or source symbols might be available from HTTP servers.
• the nature of what is available from the HTTP server is expressed and/or signaled as a range of UOSI values (alternatively, called UOFI values).
• UOSI values alternatively, called UOFI values.
• the range of UOSI values is the same as the UOSI values corresponding to the original file, i.e., UOSI values 0 through ceil(7v )-l, where F is the file size in octets and T is the symbol size in octets
• it is the original file in the original format that is available from the HTTP repair server, i.e., the Original-order HTTP file format.
• the HTTP server could treat repair files having only source symbols identically to repair files having repair symbols only or repair files having repair symbols and source symbols (mixed format), just by signaling the UOSI range or some other signaling. Note that this scheme will work even when sub-blocking is used and when block size is variable between different source blocks of a file.
• the UOSI range could be signaled as [20,000, 40,063], i.e., signaling that there are 1056 repair symbols in the repair file for each of the 19 source blocks.
• the sub-symbols of each sub-block are in order within each source block, i.e., there will be 1056 sub-symbols for the first sub-block, followed by 1056 sub-symbols for the second sub-block, etc., within the repair data for a source block, i.e., it need not be the case that repair symbols are consecutive within the repair data for the source block and can thus have the same organization as that of source data in the original source file, i.e., the Extended-original- order HTTP file format is a natural extension of the Original-order HTTP file format.
• the file will comprise 1056 sub-symbols for sub-block (0,0), each sub-symbol of size 336 bytes, followed by 1056 sub-symbols for sub-block (0, 1), each sub-symbol of size 332 bytes, followed by 1056 sub-symbols for sub-block (0,2), each sub-symbol of size 332 bytes, followed by 1056 sub-symbols for sub-block (1,0), each sub-symbol of size 336 bytes, followed by 1056 sub-symbols for sub-block (1, 1), each sub-symbol of size 332 bytes, followed by 1056 sub-symbols for sub-block (1,2), each sub-symbol of size 332 bytes, and so on.
• the repair file containing repair data can be much smaller, e.g., corresponding to a UOSI range of [20,000, 24,027], i.e., there 212 repair symbols available for each of the 19 source blocks in the repair file.
• the ESI-range of sub-symbols for sub-blocks within the first 1 1 source blocks is 1053 through 1264
• the ESI-range of sub-symbols for sub-blocks within the remaining 8 source blocks is 1052 through 1263.
• an original source file format is sequential, e.g., data is in the order in which the bytes of the file would be consumed for playback of the content from the beginning to the end, i.e., it is the Original-order HTTP file format.
• This is a convenient format for many reasons, including the natural format for hosting on HTTP web servers for delivery, for storage in file systems, etc. This might be the format for source files whether delivered by eMBMS or by unicast.
• the file may be made available on conventional HTTP web servers and be used to provide a converged service wherein repair requests may be made to conventional HTTP web servers using byte range requests combined with delivering over eMBMS both source and repair symbols, such that caching efficiency is high, HTTP byte range requests are minimized and are requests for consecutive portions of data starting at the same point in the file independent of loss patterns experience by different receivers in the eMBMS session.
• a file X may have associated FEC OTI parameters (F, Al, T, Z, N).
• F, Al, T, Z, N the range of data in the file may be expressed in terms of the universal object symbol identifier ("UOSI"), alternatively called the UOFI.
• UOSI universal object symbol identifier
• SBN source block number
• ESI encoding symbol identifier
• the range might be expressed in the form [SU, EU] where SU is a start UOSI value for the file and EU is an end UOSI value for the file. Note that SU is less than or equal to EU.
• the range of symbols that are included in the file are those symbols with UOSIs ranging from SU to EU, and thus the total number of symbols in the file is EU-SU+1.
• Such a file may be identified by a URL, including the FEC OTI parameters, and by the start and end UOSIs of the symbols in the file.
• the organization is in order of sub-blocks, i.e., all the sub-symbols associated with the first sub-block of the source block are in order of increasing ESI, followed by all sub- symbols associated with the second sub-block of the source block, etc., up through all sub-symbols associated with the last (N-l) sub-block of the source block.
• EESI(J) can be calculated as follows:
• EESI(J) EESI(J) - 1.
• NK(J) EESI(J) - SESI(J) + 1. Note that the number of symbols for different source blocks of the file are all within one of one another independent of the range of values (SU, EU).
• TS( ) The size of the sub-symbols in sub-block L, TS( ) can be calculated as shown herein. In the formula below, TS( ') is the size of the sub-symbols in sub-block L'. [0345]
• the end byte position of the sub-symbol indexed by (J, L, I) within the file is the start byte position plus TS( ) - 1.
• UOSI range (X, ⁇ )
• X > Xand (Y - X)IZ is an upper bound on the number of symbols or sub- symbols any client would need to request to recover a source block or source sub-block.
• each source sub-symbol is labeled with a triple (J, L, I), where J is the SBN, L is the SuBN and I is the ESI of the sub-symbol.
• Fig. 35 shows the source symbols for the file corresponding to Fig. 34, where the source symbols are listed in UOSI order.
• Fig. 37 shows the Extended-original-order HTTP file format corresponding to the UOSI range 1 1 through 19 for the file shown in Fig. 34.
• sub- symbols comprising symbols in the specified UOSI range are first ordered by SBN, within that by SuBN, and within that by ESI.
• all the sub-symbols for a given sub- block are consecutive within the Extended-original-order HTTP file format.
• the Extended-original-order HTTP file format supports using a single byte range to request any number of sub-symbols from a single sub-block up to the number of sub-symbols in the file for that sub-block.
• the Extended-original-order HTTP file format can also be used to generate a file that comprises a mix of source and repair symbols.
• Fig. 38 shows the Extended-original-order HTTP file format for the UOSI range 8 through 12 for the file shown in Fig. 34.
• UOSIs 8, 9 and 10 correspond to source symbols
• UOSIs 11 and 12 correspond to repair symbols.
• different files might be available off of different CDNs, or in different regions.
• UOSI range [0, 19,999] corresponding to the original source file
• 3 other files with UOSI ranges [20,000, 22,000], [22,001, 26,354] and [45,651, 64,356], respectively.
• there might be multiple files corresponding to the original source file e.g., 3 files with UOSI ranges [0, 7,000], [7,001, 14,000], [14,000, 19,999], respectively for a source file with 20,000 source symbols.
• the symbols in the Extended-original-order HTTP file might be a mix of source and repair symbols, e.g., the UOSI range is [10,000, 30,000] whereas the number of source symbols in the source file is 20,000.
• An MBMS UE might use conventional HTTP/1.1 GET or partial GET requests as defined in RFC 2616 to request all or a subset of source symbols or sub- symbols of the referenced resource, respectively. These message formats are used if the MBMS UE is requesting symbols from a file repair server that supports byte range requests, i.e., its URI is listed as a "byteRangeServiceURI" or
• MBMS UE uses the HTTP GET request when it requires all the source symbols of the resource to be transmitted. If the MBMS UE only requests transmission of a subset of the source symbols or sub-symbols, the UE might use the HTTP partial GET request with the Range request header as defined in 14.35.2 of RFC 2626. The MBMS UE indicates the specific source symbols or sub- symbols as a byte-range-spec as defined in 14.35.1 of RFC 2616.
• the HTTP GET method allows the UE to include multiple byte range requests within a single partial GET request. If the UE includes multiple byte ranges in a single request, the HTTP GET request should not exceed 2048 bytes in length to avoid truncation by the HTTP server.
• the MBMS UE determines that it can select among multiple subsets of the source symbols or sub-symbols, the MBMS UE should request the subset with the lowest ESI values available, i.e., choose the missing source symbols or sub-symbols from the beginning of the source block or source sub-block, respectively. This improves the caching efficiency of the HTTP file repair servers. Other strategies are also possible, for example the MBMS UE requests subsets with the highest ESI values available.
• the selected repair server accepts byte range requests (e.g., the server URI is identified with the "byteRangeServiceURI" element in the associated delivery procedure meta data fragment) and its server URI is http://httprepairl .example.com, then the HTTP GET request to the repair server is as follows:
• the UOSI range of the file can be signaled via the Session Description Protocol (SDP), Media Presentation Description (MPD), or User Service Description (USD) associated with the delivery session for file, e.g., by adding new attributes for "Start-UOSI” and "End-UOSI” into one of these descriptions.
• SDP Session Description Protocol
• MPD Media Presentation Description
• USD User Service Description
• auxiliary file format parameters that are needed for the UE to properly decode the file format can be signaled, in addition to the UOSI range. Examples of such additional parameters include some FEC Object Transmission Information. These auxiliary file format parameters can also be sent in the File Description Table (FDT) of the FLUTE instance by defining attributes for these parameters.
• FDT File Description Table
• the auxiliary file format parameters can be directly encoded in the URL of the file.
• the auxiliary file format parameters can be signaled via the Session Description Protocol (SDP), Media Presentation Description (MPD), or User Service Description (USD) associated with the delivery session for file, e.g., by adding new attributes for the parameters into one of these descriptions.
• SDP Session Description Protocol
• MPD Media Presentation Description
• USD User Service Description
• the FEC OTI information, UOSI range, or any general auxiliary file format information can be signaled as a MIME type.
• a new file format is defined and adds the parameter as "fec-oti" to the MIME type registration.
• the auxiliary file format parameters for files stored on an HTTP server are the same as the auxiliary file format parameters for the file that is sent over the broadcast.
• some of the auxiliary file format parameters can be different for the file that was broadcast and for the file that is stored on the HTTP server for enabling repair.
• the FEC OTI for the file format stored on the HTTP server can be different from the FEC OTI that was used to format the broadcast.
• a practical example is when the broadcast data is encoded using different FEC OTI parameters in different areas; a device moving between different coverage areas may have its unicast repair requests routed to different servers serving differently encoded files depending on the current location of the device.
• the parameter values can be encoded directly into the file name or URI stored on the repair server as described above.
• their attributes can be defined with different names, e.g., "FEC_OTI_bcast” and "FEC_OTI_file", when signaled to the terminal as part of the FDT, SDP, MPD, or USD.
• the terminal e.g., a UE terminal
• the terminal can then determine the appropriate procedures for decoding the file retrieved from the broadcast or an HTTP server.
• the terminal may use the auxiliary file parameters to decide which files on the HTTP servers to retrieve data from when presented with multiple files using different file format configurations.
• the HTTP request for the file may contain pragma directives indicating the OTI parameters required; the HTTP server would then use the embedded directives to either serve the request from the correctly encoded file, or to reject the request if no such encoded file is available.
• auxiliary file format parameters e.g., the source files are located on servers with Internet URLs.
• Another approach is to have the ability to signal optional parameters in the URL, and assume default parameter values if they are not explicitly signaled in the URL. For example, suppose the potential parameters to be signaled were the Format Type (e.g., SS-order HTTP file format, or Extended-original-order HTTP file format), the FEC OTI parameters, and the UOSI range.
• Format Type e.g., SS-order HTTP file format, or Extended-original-order HTTP file format
• MBMS UE uses the HTTP GET request when it requires all the symbols of the resource to be transmitted. If the MBMS UE only requests transmission of a subset of the symbols or sub-symbols, the UE might use the HTTP partial GET request with the Range request header as defined in 14.35.2 of RFC 2626. The MBMS UE indicates the specific symbols or sub-symbols as a byte- range-spec as defined in 14.35.1 of RFC 2616.
• the repair file comprises the first 100 repair symbols for each of the 20 source blocks in Extended-original-order HTTP file format.
• the selected repair server accepts byte range requests (e.g., the server URI is identified with the "byteRangeServiceURI" element in the associated delivery procedure meta data fragment) and its server URI is http://httprepairl .example.com, then the HTTP GET request to the repair server is as follows:
• Range : bytes 5002800-5026559,19001400-19014599
• each source block is further partitioned into 12 sub-blocks each, each with 7,576 source sub- symbols, wherein the first 6 sub-blocks have sub-symbols of size 112 bytes and the remaining 6 sub-blocks have sub-symbols of size 108 bytes.
• the source symbols are transmitted in the MBMS download session, and that UOSI range associated with the repair file available over HTTP is [15, 152, 17,151], i.e., the repair file comprises the first 1000 repair symbols for each of the 2 source blocks in Extended-original-order HTTP file format.
• the Original-order HTTP format of this file can be expressed as (0, 0, 0), (0, 0, 1), (0, 0, 2), (0, 1, 0), (0, 1, 1), (0, 1, 2), (1, 0, 0), (1, 0, 1), (1, 0, 2), (1, 1, 0), (1, 1, 1), (1, 1, 2), where each triple indicates the SBN, SuBN, and ESI of each sub-symbol.
• This file in reverse order can be expressed as (0, 0, 2), (0, 0, 1), (0, 0, 0), (0, 1, 2), (0, 1, 1), (0, 1, 0), (1, 0, 2), (1, 0, 1), (1, 0, 0), (1, 1, 2), (1, 1, 1), (1, 1, 0).
• Similar reverse variants hold for all the other file formats described herein.
• a reverse variant of the file can be useful for example if a client is downloading data that can be used to reconstruct content from two different servers, wherein the client is downloading or receiving data that can be used to reconstruct the content from the first server stored in one file format and the client is downloading or receiving the file that can be used to reconstruct the content from the second server stored in the reverse format.
• the client can simply wait till enough data in combination from the two servers arrive to reconstruct the content and then the client can terminate the connection, or simply stop receiving additional data, from the two servers. Because the one format is the reverse of the other, the client largely receives non-redundant data that allows the client to reconstruct the content, independent of how much of the data the client receives from each server.
• a byte-range can be used to specify the data an Extended-original-order HTTP format file instead of a UOSI range. For example, if the UOSI range is (X, Y) and the symbol size is T, then the byte range specifying the same format could be the byte range starting at byte X*T and ending at byte (Y+1)*T-1.
• Other variants of specifying the format include specifying an explicit list of ESI ranges for each source block of the file.
• the ESI ranges could be replaced with byte ranges, where in this case each byte range would be relative to a source block. For example, in the above if the symbol size is 1,000 bytes, then byte range 30,000 - 40,999 would be equivalent to ESI range 30-40.

Landscapes

• Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• Probability & Statistics with Applications (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Multimedia (AREA)
• Detection And Prevention Of Errors In Transmission (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Error Detection And Correction (AREA)

Applications Claiming Priority (7)

Publications (1)

Family

ID=51266046

Family Applications (1)

Country Status (6)

Families Citing this family (14)

Family Cites Families (15)

• 2012
  • 2012-11-01 CN CN201280062414.6A patent/CN104067594A/zh active Pending
  • 2012-11-01 EP EP12798475.5A patent/EP2774347A2/de not_active Withdrawn
  • 2012-11-01 IN IN2992CHN2014 patent/IN2014CN02992A/en unknown
  • 2012-11-01 JP JP2014540098A patent/JP5795446B2/ja not_active Expired - Fee Related
  • 2012-11-01 KR KR1020147014698A patent/KR101591238B1/ko not_active IP Right Cessation
  • 2012-11-01 WO PCT/US2012/063115 patent/WO2013067219A2/en active Application Filing

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events