Classifications

• • 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/957—Browsing optimisation, e.g. caching or content distillation
• • 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]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
  • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

• FLUTE File Delivery Over Unidirectional Transport
• RRC Request for Comments
• a FLUTE receiver only passes up complete files (i.e., files that do not begin with missing/corrupted data portions or file that do not have intermediate missing/corrupted data portions).
• FLUTE receivers/handlers/interfaces are not capable of discerning whether a partially received file fragment may be useful to a specific application and/or a specific client implementing all or part of that application, such as a Dynamic Adaptive Streaming Over Hypertext Transfer Protocol (DASH) client that may access the DASH formatted files delivered via FLUTE to play back media in such FLUTE delivered files.
• DASH Dynamic Adaptive Streaming Over Hypertext Transfer Protocol
• a FLUTE receiver is not enabled to parse files; a FLUTE receiver merely delivers files to applications and/or clients.
• An application and/or a client providing inputs to a codec may be enabled under certain conditions to recover and provide some portion of a file to the codec even though the file may not have been received by the application and/or client in its entirety.
• a codec such as a DASH client
• an application and/or a client providing inputs to a codec may be enabled under certain conditions to recover and provide some portion of a file to the codec even though the file may not have been received by the application and/or client in its entirety.
• FLUTE receivers as currently defined cannot pass incomplete files up to an application, the functionality of applications and/or clients providing inputs to a codec which may be enabled to recover and playback partially received files may be reduced by the current limitations of a FLUTE interface serving those applications and/or clients.
• FLUTE receivers will simply discard incomplete and/or corrupted files received in broadcast and/or unicast communications, and the discarding of the incomplete and/or corrupted files may result in a DASH player receiving too few symbols for effective Forward Error Correction (FEC) to decode.
• FEC Forward Error Correction
• discarding of incomplete and/or corrupted files by current FLUTE interfaces may result in a DASH player failing to receive enough data from a Transmission Control Protocol
• TCPyinternet Protocol (IP) connection before playback time TCPyinternet Protocol (TCPyinternet Protocol (IP) connection before playback time.
• IP Transmission Control Protocol
• discarding of incomplete and/or corrupted files by current FLUTE interfaces may result in a DASH player having a long gap, or long stall, in presenting media content because of lost content.
• HTML Hypertext Transfer Protocol
• RRC Request for Comments
• HTTP servers such as HTTP servers associated with FLUTE receivers according to the various embodiments
• HTTP servers may be enabled to generate status codes identifying that an incomplete version of a file is being returned in response to a file request.
• an HTTP server may be enabled to determine the ability of a client to handle incomplete versions of files.
• an HTTP server may be enabled to generate headers identifying that an incomplete version of a file is being returned in response to a file request.
• FIG. 1 is a communication system block diagram of a network suitable for use with the various embodiments.
• FIG. 2 is a system block diagram illustrating the relationship between transport layers and application and/or client layers in a computing device utilizing the enhanced FLUTE protocol according to the various embodiments.
• FIG. 3 is a process flow diagram illustrating an embodiment method for assigning a URL URI to a file according to the enhanced FLUTE protocol.
• FIG. 4 is a process flow diagram illustrating another embodiment method for assigning a URL/URI to a file according to the enhanced FLUTE protocol.
• FIG. 5 is a process flow diagram illustrating an embodiment method for assigning a modified URL/URI to a partially received file according to the enhanced FLUTE protocol.
• FIG. 6 is a process flow diagram illustrating an embodiment method for sending a response including an incomplete version of a file.
• FIG. 7 is a process flow diagram illustrating another embodiment method for sending a response including an incomplete version of a file.
• FIG. 8 is a process flow diagram illustrating a third embodiment method for sending a response including an incomplete version of a file.
• FIG. 9 is a process flow diagram illustrating an embodiment method for delivering incomplete versions of files to a target application from an enhanced FLUTE client.
• FIG. 10 is a process flow diagram illustrating an embodiment method for utilizing a modified URL at a target application.
• FIG. 11 is a process flow diagram illustrating a prior art method for HTTP server handling of client requests for incomplete versions of files.
• FIG. 12 is a process flow diagram illustrating an embodiment method for enhanced HTTP server handling of client requests for incomplete versions of files.
• FIG. 13 is a process flow diagram illustrating another embodiment method for enhanced HTTP server handling of client requests for incomplete versions of files.
• FIG. 14 is a process flow diagram illustrating a third embodiment method for enhanced HTTP server handling of client requests for incomplete versions of files.
• FIG. 15 is a process flow diagram illustrating a fourth embodiment method for enhanced HTTP server handling of client requests for incomplete versions of files.
• FIG. 16 is a component diagram of an example mobile device suitable for use with the various embodiments.
• FIG. 17 is a component diagram of another example mobile device suitable for use with the various embodiments.
• FIG. 18 is a component diagram of an example server suitable for use with the various embodiments
• the terms “mobile device”, “receiver device”, and “computing device” are used interchangeably herein to refer to any one or all of cellular telephones, smart phones, personal or mobile multi-media players, personal data assistants (PDAs), laptop computers, personal computers, tablet computers, smart books, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, and similar personal electronic devices which include a programmable processor and memory and circuitry for receiving files.
• incomplete version of a file is used to refer to an incomplete version of a file that has missing and/or corrupted data portions. For example, if a file comprises 1,000 bytes indexed by 0-999 then bytes 0-888 of that file is an incomplete version of that file, and bytes 500-999 is another incomplete version of that file, and bytes 0-200 together with bytes 300-999 is another incomplete version of that file, whereas bytes 0-999 is not an incomplete version of that file.
• the term "incomplete version of a byte range” is used to refer to an incomplete version of byte range of a file that has missing and/or corrupted data portions. For example, if a file comprises 1,000 bytes indexed by 0-999 then bytes 0-88 of that file is an incomplete version of the byte range 0-99 of that file, and bytes 50-99 is another incomplete version of the byte range 0-99 of that file, and bytes 0-20 together with bytes 30-99 is another incomplete version of the byte range 0-99 of that file, whereas bytes 0-99 is not an incomplete version of the byte range 0-99 of that file.
• FLUTE receivers are not enabled to parse files; a FLUTE receiver merely delivers files to applications and/or clients by implementing the file transport mechanisms defined in Internet Engineering Task Force proposed standard RFC 3926 entitled "FLUTE - File Delivery over Unidirectional Transport,” published October 2004, available at
• FLUTE protocol video fragments or pieces are sent as individual files, called segments.
• segment if the segment includes errors, current FLUTE receivers may discard the file.
• FLUTE receivers may apply Forward Error Correction (FEC) to repair the segment, but if not enough repair symbols are present in the segment, a FLUTE receiver simply discards the file.
• FEC Forward Error Correction
• An application and/or a client providing inputs to a codec may be enabled under certain conditions to recover and provide some portion of a file to a codec even though the file may not have been received by the application and/or client in its entirety, i.e., the application and/or client may be able to recover and provide an incomplete version of the file.
• FLUTE receivers as currently defined cannot pass up incomplete files, i.e., incomplete versions of files, to an application or client, the functionality of applications and/or clients providing inputs to a codec which may be enabled to recover and playback incomplete versions of files may be reduced by the current limitations of a FLUTE interface serving those applications and/or clients.
• FLUTE receivers, handlers, and/or interfaces as currently defined cannot pass incomplete versions of files to a DASH client.
• the inability to pass incomplete versions of files may reduce the end user playback experience.
• FLUTE receivers, handlers, and/or interfaces were enabled to deliver to a DASH client at least a portion of a file that may still be useful to the DASH client.
• the delivery of at least a portion of the incomplete version of a file may enable the DASH client to playback at least a portion of the media in the incomplete version of a file that may improve the end user media playback experience.
• the various embodiments provide an enhanced FLUTE interface that may enable error recovery for applications and/or clients, such as a DASH client.
• a computing device may be enabled to receive files over the
• the computing device may receive files over the Internet utilizing an Internet Protocol (IP) User Datagram
• the enhanced FLUTE interface may place the files in a memory location visible to the target application(s) and/or client(s), such as a DASH client and/or DASH player.
• the target application may retrieve the file via a Uniform Resource Locator (URL) and/or Uniform Resource Identifier (URI) based on information in the Media Presentation Description (MPD), which is a piece of metadata that may be sent to a DASH client to notify the DASH client which media may be available for playback, and related information, such as different available rates at which the media may be presented, start and/or stop points of the media, information enabling the DASH client to switch from one media representation to another, memory locations where the media may be available, etc.
• URL Uniform Resource Locator
• URI Uniform Resource Identifier
• MPD Media Presentation Description
• a DASH client may retrieve the file via an HTTP "GET" operation (i.e., method).
• the URL/URI of the desired file may be known by the application and/or client, such as a DASH client, based on a prior agreed naming convention.
• enhanced FLUTE may assign a
• enhanced FLUTE may be enabled such that the incomplete versions of files with the modified URLs/URIs may remain stored in a memory of the computing device for a given but limited period of time, after which the incomplete versions of files may be deleted. In this manner, the computing device side server application/memory may not become cluttered with incomplete versions of files.
• applications/clients enabled to play and/or repair incomplete versions of files may be enabled to exchange messages directly with the enhanced FLUTE to request and receive incomplete versions of files.
• the applications/clients enabled to play and/or repair partially received files may indicate via explicit inline signaling to the FLUTE layer, such as via header- based signaling in a HTTP "GET" operation (i.e., method) or other direct HTTP message, that they are enabled to play and/or repair incomplete versions of files.
• the enhanced FLUTE layer may receive the indication that the
• applications/clients such as a DASH client, are enabled to utilize incomplete versions of files, and may provide incomplete versions of files to the
• enhanced FLUTE may also indicate in the response including the incomplete versions of files that the response includes the incomplete versions of files, such as via header-based signaling.
• applications and/or clients may provide information about their capability to handle incomplete versions of files to enhanced FLUTE in a file request sent from the application and/or client to enhanced FLUTE.
• an application and/or client such as a DASH client
• enabled to handle incomplete versions of files may indicate it may accept incomplete versions of files in a file request.
• an application and/or client such as a DASH client, may be enabled to distinguish between URLs/URIs for completely and partially received files and may be enabled to utilize both conventional and modified URLs URIs from enhanced FLUTE to retrieve complete and/or incomplete versions of files.
• enhanced FLUTE may supply incomplete versions of files to the application and/or client, such as a DASH client, according to a pre- agreed partial file naming convention.
• the incomplete versions of files may contain all the correct source symbols, and/or any correctly received repair symbols.
• enhanced FLUTE may provide two files, one which may include the correctly received symbols and one which may include a file of the repair symbols.
• enhanced FLUTE may provide two files, one which may include the correctly received symbols and one which may include a file of the repair symbols.
• FLUTE may provide an incomplete version of a file containing a correct subset of all the transmitted source and/or repair symbols.
• enhanced FLUTE may provide the incomplete version of a file with an incomplete version of a file indication in the response.
• enhanced FLUTE may respond that a file is unavailable, such as "File Not
• the locations of the missing source data may be denoted by substitution codes and/or lists of byte ranges.
• a list of byte ranges may be delivered as a portion of the source and/or repair files.
• a list of byte ranges may be delivered separately from the source and/or repair files.
• organization of the substitution codes and/or lists or byte ranges may be made according to a file naming convention, such that file naming may be utilize to signal which convention to follow for a given file.
• file naming may utilize pre-defined extensions of the URL URL
• the device side behaviors of applications and/or clients with an enhanced FLUTE interface may be categorized into three groups.
• a first group of applications and/or clients which may not be enabled to utilize incomplete versions of files and/or which may not be enabled with enhanced FLUTE may simply ignore the
• a second group of applications and/or clients may be enabled to recognize the added/modified URLs/URIs and manage the use of incomplete versions of files based on the added/modified URLs/URIs.
• the second group for example an application and/or client, such as a DASH client, may be restricted to operating on a file only at the level that may be nominally visible at the added/modified URL layer.
• a DASH client may be aware of the Stream Access Points (SAP) via metadata, but the DASH client may not parse the underlying codec syntax. In this manner, the DASH client may be functionally limited to service resumption of video frames that are marked as SAP, and no codec specific behavior may be required.
• SAP Stream Access Points
• a third group of applications and/or clients may be enabled to seek and/or correct the missing and/or corrupted data in the incomplete versions of files identified by enhanced FLUTE.
• the ability to seek and/or correct the missing and/or corrupted data may be application and/or client dependent.
• the ability to seek and/or correct the missing and/or corrupted data may be limited to predefined application methods, such as unicast repair.
• a DASH client may elect to attempt unicast file repair if the incomplete version of a file is of one type, such as On Demand type, but not attempt repair if the incomplete version of a file is of another type, such as Live type.
• the determination to seek and/or correct the missing and/or corrupted data may be based on time limitations, size/scope of the missing and/or corrupted data, user defined settings, and/or network settings.
• the third group of applications and/or clients may seek and/or correct the missing and/or corrupted data optionally based on unicast report back which may be accomplished by defined file report back methods and/or by the application and/or client.
• the third group of applications and/or clients may seek and/or correct the missing and/or corrupted data optionally in response to delivery failure reporting, existing 3GPP methods, and/or application reporting.
• the second or third group of applications and/or clients may also support rendering the content, such as a partial file playback, by various methods selected based on file type and/or temporal constraints.
• HTTP Hypertext Transfer Protocol
• RRC Request for Comments
• a client may generate a file request, such as a "GET" method, and send the file request to a server.
• File requests may be requests for a file associated with a URL/URI, and may be requests for the entire data contents of a file associated with a URL/URI (e.g., using a GET request that doesn't specify any byte range and thus requests the complete file) or may be requests for specific byte ranges of a file associated with a URL/URI (e.g., using a partial GET request that specifies a byte range within the complete file).
• a server can provide a "full response" or an error message, in response to a client's file request. The HTTP server will not provide incomplete versions of a file in response to HTTP client file requests.
• a full response from the HTTP server is the complete file, and an incomplete version of a file response is anything less than the complete file (e.g., an incomplete version of a file).
• a full response from the HTTP server is the intersection between the complete file and the requested byte range, and an incomplete version of a byte range response is anything less than the intersection between the complete file and the requested byte range (e.g., an incomplete version of a byte range).
• the server may determine whether the file corresponding to the file request is fully available. As an example, the server may determine whether the file corresponding to the file request is incomplete and/or corrupted, such as missing data portions and/or including an indication that the file is incomplete and/or corrupted. As an example, the server may determine whether the file
• the server may determine whether the file corresponding to the file request is incomplete and/or corrupted by detecting a difference in a value of a received checksum, such as the MD5 digest, and a checksum computed by the FLUTE receiver. Those files which are not incomplete and/or corrupted may be determined by the server to be fully available and may be sent to the client in a "full response" that includes the requested file.
• a received checksum such as the MD5 digest
• the server Upon identifying the requested file is not fully available (i.e., only an incomplete version of the file is available that has missing/corrupted data portions), the server merely returns a message with an error status code, such as a message with a 404 "Not Found" status code.
• an error status code such as a message with a 404 "Not Found” status code.
• the current HTTP also provides for partial GET requests, which specify a byte range for a requested file, and the full response to partial GET requests is the intersection between the complete file and the requested byte range.
• partial GET requests which specify a byte range for a requested file
• the full response to partial GET requests is the intersection between the complete file and the requested byte range.
• the full response that an HTTP server can provide is a sequential portion of bytes from the first byte in the requested byte range to the last byte of the complete file.
• the full response is less than the byte range requested (in particular, bytes 0-88), but it is considered a "full response" nonetheless and may be sent by the HTTP server.
• the HTTP server may not provide any portion of the requested bytes to the client and, instead, sends the client a message with an error status code.
• the current HTTP server will not send an incomplete version of the byte range response consisting of bytes 0-74 to the requesting client.
• the incomplete version of a byte range request is not sent to the requesting client; that is, an "incomplete response" to a request for a byte range of a file is not supported.
• HTTP does not pass incomplete responses to a client
• the functionality of clients and/or applications which may be enabled to recover and use incomplete responses may be reduced because the clients and/or applications may never receive incomplete responses.
• HTTP servers were enabled to deliver to clients at least a portion of incomplete versions of files or incomplete versions of byte ranges of files that are available at the server.
• the delivery of at least a portion of the incomplete version of a file or byte range may enable client devices running an application and/or a client, such as a smart phone running a DASH client, to render the content, such as playing back at least a portion of the media in the incomplete version of a file or byte range, which may improve the end user media playback experience.
• file requests e.g., a request for a complete file
• particular incomplete responses e.g., an incomplete version of a file
• other file requests e.g., requests for byte ranges of a file
• other incomplete responses e.g., an incomplete version of a byte range of a file that consists of less than the intersection between the complete file and the requested byte range.
• the various embodiments may be applied to a variety of file requests and incomplete responses.
• the various embodiments provide an enhanced HTTP server that may be configured to pass incomplete versions of files in response to file requests from client devices running an application and/or a client, such as a smart phone running a DASH client.
• HTTP servers may be configured to generate status codes identifying that an incomplete version of a file is being returned in response to a file request.
• an HTTP server may be configured to determine the ability of a client device to handle incomplete versions of files.
• a client device may indicate its ability to handle incomplete versions of files via an indication in the file request message sent to the HTTP server.
• the client device may indicate its ability to handle incomplete versions of files via information in the file request header.
• the client device may determine whether the clients and/or applications running on the client device are enabled to handle incomplete versions of files upon receiving an incomplete version of a file from an HTTP server.
• the HTTP server may send partial content in a response message along with an indication of partial delivery of the content.
• incomplete portions of a file may be provided to a requesting client.
• the non-sequential byte ranges i.e., incomplete portions of the file
• the client may be sent bytes 0-15 and 30-88.
• those available bytes may still be sent.
• FIG. 1 illustrates a network system 100 suitable for use with the various embodiments.
• the network system 100 may include a receiver device 102, such as a smart phone, and a server 112 connected to the Internet 110.
• the receiver device 102 may establish a wireless connection 114 with a wireless access point 104, such as a Wi-Fi access point.
• the wireless access point 104 may connect with the Internet 110.
• the receiver device 102 and a cellular tower or base station 106 may exchange data via a cellular connection 116, including a CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, or any other type connection.
• the cellular tower or base station 106 may be in communication with a router 108 which may connect to the Internet 110.
• the receiver device 102 may establish a wired connection 117 with a router 109 which may connect to the Internet 110. In this manner, via the connections to the wireless access point 104, cellular tower or base stations 106, router 109, and/or Internet 110, data may be exchanged between the receiver device 102 and the server 112.
• FIG. 2 illustrates an embodiment relationship between transport layers and application and/or client layers in a computing device utilizing the enhanced FLUTE protocol.
• files may be received at the computing device via the IP UDP transport layer 202.
• broadcast files sent from the server 112 to the wireless device 102 via the Internet 110 as discussed above with reference to FIG. 1, may be received at the wireless device 102 at the IP UDP transport layer 202.
• the files may be segments of a media file sent via the Internet.
• the IP UDP transport layer 202 may pass the received files to the FLUTE layer 204.
• the FLUTE layer 204 may be an application enabled to utilize the enhanced FLUTE protocol to pass files from the IP/UDP transport layer 202 to applications and/or clients, such as a DASH client 210, application 214, application 216, and/or application 218. While discussed in terms of one client (i.e., DASH client 210) and three applications (i.e., application 214, application 216, and application 218), the number of clients and/or applications that the FLUTE layer 204 may pass files to may be unlimited.
• the FLUTE layer 204 may apply error correction to the received files, such as FEC.
• the FLUTE layer 204 may received indications from the applications and/or clients, such as a DASH client 210, application 214, application 216, and/or application 218, which may indicate if the applications and/or clients may be enabled to utilize incomplete versions of files.
• a file request from the DASH client 210 may indicate the DASH client 210 is enabled to utilize incomplete versions of files.
• the FLUTE layer 204 may assign a conventional URL/URI to completely received files and may assign a modified URL/URI to partially received files.
• the modified URL/URI may include information based on the missing file portions, such as information indicating the location of the missing data from the file (e.g. byte ranges and/or substitution codes).
• the FLUTE layer 204 may discard files which may be of no use to applications and/or clients, such as the DASH client 210, application 214, application 216, and/or application 218, served by the FLUTE layer 204.
• the FLUTE layer 204 may include metadata with the incomplete versions of files, such as additional file(s) and/or file header(s) for the incomplete versions of files.
• incomplete versions of files may include a subset of the source symbols and the repair symbols originally transmitted.
• the source symbols may be stored in a separate file from the repair symbols.
• the source symbols and the repair symbols may be stored in the same file.
• the FLUTE layer 204 may be enabled to remove files from memory locations (i.e., a memory cache) of the computing device, such as the device side HTTP server 206 and/or the application device side memory space 208. In this manner, memory cache (e.g., a memory stack) overflow issues may be avoided as new files are passed by the FLUTE layer 204.
• memory cache e.g., a memory stack
• the FLUTE layer 204 may parse the received files and pass the files to the device side HTTP server 206 and/or the application device side memory space 208 (e.g., a memory cache) depending on the intended target application and/or client, such as the DASH client 210, application 214, application 216, and/or application 218.
• the device side HTTP server 206 may be an application resident on the computing device with its own assigned memory space (e.g., memory cache) on the computing device.
• the device side HTTP server 206 may utilize the same memory space (e.g., memory cache) as the application device side memory space 208 (e.g., memory cache).
• the DASH client 210 may request and/or receive files from the device side HTTP server 206 and may pass the files to a codec 212 for eventual rendering of the content (e.g., playing the content) by the computing device.
• a DASH client 210 may be enabled to utilize incomplete versions of files in rendering the content.
• a DASH client 210 may be enabled to repair incomplete versions of files before rendering the content.
• applications such as application 214, application 216, and/or application 218 may request and/or receive files from the application device side memory space 208 (e.g., memory cache).
• the application 214, application 216, and application 218 may be enabled to handle incomplete versions of files differently.
• application 214 may not be able to handle incomplete versions of files, application 216 may be able to play incomplete versions of files, and application 218 may be enabled to repair incomplete versions of files.
• application 214 may ignore modified URLs URIs, application 216 may attempt to play the incomplete versions of files corresponding to modified URLs/URIs, and application 218 may attempt to repair incomplete versions of files corresponding to modified URLs/URIs based on metadata included in/with the received incomplete versions of files by the FLUTE layer 204.
• applications/clients enabled to play and/or repair incomplete versions of files may be enabled to exchange messages directly with the enhanced FLUTE layer 204 to request and receive incomplete versions of files.
• the applications/clients enabled to play and/or repair incomplete versions of files may indicate via explicit inline signaling to the FLUTE layer 204 that they are enabled to play and/or repair incomplete versions of files to render the content.
• the FLUTE layer 204 may receive the indication that the applications/clients, such as DASH client 210, application 216, and/or application 218, are enabled to utilize incomplete versions of files, and may provide incomplete versions of files to the applications/clients, such as DASH client 210, application 216, and/or application 218.
• the FLUTE layer 204 may also indicate in the response including the incomplete versions of files that the response includes incomplete versions of files.
• FIG. 3 illustrates an embodiment method 300 for assigning a URL/URI to a file according to the enhanced FLUTE protocol.
• the computing device processor may receive the file.
• the file may be a segment of a media file transmitted to the computing device over the Internet.
• the computing device processor may determine whether the file may be an incomplete version of a file.
• incomplete versions of files may be those files received by the computing device that are missing data and/or that include corrupted data.
• the processor may employ error correction, such as FEC, to the file to reconstitute the file though a portion of the data in the file may be missing and/or corrupted.
• a successfully reconstituted file may be a complete file.
• a conventional URL/URI may be a URL/URI corresponding to the naming convention agreed upon between the enhanced FLUTE layer and the application and/or client, such as a DASH client, based on information in the MPD received from the application and/or client.
• the processor may put the file with its assigned URL/URI in the stack and the processor may return to block 302 and receive the next file.
• the processor may assign a modified URL/URI.
• the modified URL/URI may be different from the naming convention agreed upon between the enhanced FLUTE layer and the application and/or client based on information in the MPD.
• the modified URL/URI may be the same as the agreed naming convention, except with the addition of an additional identifier indicating the corresponding file is an incomplete version of a file.
• the modified URL/URI may include information based on the missing file portions, such as information indicating the location of the missing data from the incomplete version of a file (e.g. byte ranges and/or substitution codes).
• An example schema for enhanced FLUTE to provide byte ranges and substitution codes may be as follows:
• the incomplete version of a file may also be stored with additional data, such as source and repair symbols.
• the processor may put the file with its assigned URL/URI in the stack, and the processor may return to block 302 to receive the next file.
• the enhanced FLUTE protocol may continually receive files and assign conventional and/or modified URLs/URIs.
• FIG. 4 illustrates an embodiment method 400 for assigning a URL/URI to a file according to the enhanced FLUTE protocol similar to method 300 described above with reference to FIG. 3, except that a computing device processor implementing method 400 may determine whether the application and/or client is enabled to accept an incomplete version of a file. As discussed above, in block 302 the computing device may receive a file, and in
• the computing device may determine whether the application and/or client the file may be intended for (i.e., target application and/or client) is incomplete version of a file enabled (i.e., is capable of receiving/processing incomplete files).
• the enhanced FLUTE layer may receive an indication from an application and/or client that the application and/or client may utilize incomplete versions of files.
• a DASH client may send an indication as part of a file request that it can utilize incomplete versions of files.
• the FLUTE layer may discard the incomplete version of a file and the processor may return to block 302 to continue receiving files. In this manner, no data storage may be utilized for files which may not be utilized.
• FIG. 5 illustrates an embodiment method 500 for assigning a modified URL/URI to an incomplete version of a file.
• the method 500 may be performed by a computing device processor in conjunction with methods 300 and 400 discussed above.
• the computing device processor may determine the missing file portions and/or locations in the incomplete version of a file.
• the processor may generate a conventional URL/URI for the incomplete version of a file.
• a conventional URL/URI may be a URL/URI corresponding to the naming convention agreed upon between the enhanced FLUTE layer and the application and/or client, such as a DASH client, based on information in the MPD received from the application and/or client.
• the processor may modify the generated conventional URL/URI based on the missing file portions and/or locations.
• the conventional URL/URI may be modified to indicate it corresponds to an incomplete version of a file.
• the conventional URL/URI may be modified by appending additional URL/URI information including the byte ranges and/or substitution codes for the missing data as discussed above.
• the modifications to the URL/URI may be such that an application and/or client not enabled to recognize modified URLs/URIs may be unable to utilize the file corresponding to the modified URL/URI.
• the processor may store separate files for delivery of source and repair symbols with the incomplete version of a file.
• the processor may store a single file for delivery of the source and repair symbols.
• FIGs. 6-8 illustrate embodiment methods for enhanced HTTP handling of client requests for incomplete versions of files. While discussed in terms of client devices and enhanced HTTP servers the operations of the embodiment methods illustrated in FIGs. 6-8 may be performed by any two devices and/or applications operating in a client/server relationship according to an enhanced HTTP as discussed herein.
• FIG. 6 illustrates an embodiment method 600 for sending a response including an incomplete version of a file.
• the operations of method 600 may performed by a processor of an enhanced HTTP server.
• the enhanced HTTP server may receive a file request including a file header.
• the file header may indicate that the client originating the file request is capable of using an incomplete response, such as an incomplete version of a file (if a complete file is requested) or an incomplete version of a byte range (if a byte range is specified in the file request).
• a header field or tag in the file header may indicate the client is capable of using an incomplete version of a file or an incomplete version of a byte range.
• the enhanced HTTP server may determine whether the available file corresponding to the received file request (i.e., the requested file) is a complete version of the file. In an embodiment, the enhanced HTTP server may determine whether the file begins with missing/corrupted data portions and/or the file has intermediate missing/corrupted data portions to determine whether the available file is complete or incomplete. In another embodiment, the
• HTTP server may send the requested file to the client.
• the enhanced HTTP server may determine whether the file header indicated the client is capable of using an incomplete response, such as an incomplete version of a file.
• the response including the incomplete version of the file may include an indication that the response is an incomplete response, e.g., an indication that the response includes an incomplete version of the file, and not the full requested file.
• FIG. 7 illustrates an embodiment method 700 similar to method 600 described above with reference to FIG. 6, except that in method 700 the file request generated by the client device may not include any additional indication that the client device may be capable of using an incomplete version of a file in the file header.
• the enhanced HTTP server may receive a file request.
• the file request may not include an added indication in the file header that the client may be capable of using an incomplete version of a file.
• the enhanced HTTP server may determine whether the URL of the requested file indicated the client is capable of using an incomplete version of a file.
• the URL corresponding to the file request may be a modified URL indicating the client is incomplete version of a file capable.
• the location corresponding to the URL may be designated specifically for an incomplete version of a file and based on that file request corresponding to that location, the enhanced HTTP server may identify the client device is capable of using an incomplete version of a file.
• FIG. 8 illustrates an embodiment method 800 similar to method 600 described above with reference to FIG. 6, except that in method 800 the file request generated by the client device may include a request for at least two byte ranges.
• an enhanced HTTP server may be configured to treat a request for redundant byte ranges as an indication that a client is capable of using incomplete responses.
• the enhanced HTTP server may receive a file request including a request for at least two byte ranges.
• the enhanced HTTP server may determine whether the received file request includes two redundant byte ranges.
• redundant byte ranges may be two requested byte ranges that overlap in at least one requested byte.
• FIG. 9 illustrates an embodiment method 900 for delivering incomplete versions of files to a target application from an enhanced FLUTE client.
• the enhanced FLUTE client operating on a computing device may receive data for a file.
• the data may be a portion of a file, such as a segment of a media file transmitted to the computing device over the Internet.
• the data may also include source symbols and repair symbols.
• the enhanced FLUTE client may determine whether the file is or will be fully recoverable from the data received in block 902. As part of this determination, the enhanced FLUTE client may apply error corrections routines, such as FEC, to determine whether data was decoded and recovered from the received data.
• error corrections routines such as FEC
• block 905 the data may be passed to the target application receiving the data file, and the processor may return to block 902 to receive the next portion of data for the file or another file.
• determination block 908 the enhanced
• FLUTE client may determine whether the target application is enabled to utilize incomplete data or incomplete versions of files.
• the enhanced FLUTE client may determine whether the target application is enabled to utilize incomplete data or incomplete versions of files.
• FLUTE protocol may determine the target application is enabled to utilize the incomplete version of a file based on information stored in memory.
• the enhanced FLUTE client may assign one or more modified URLs (which may be unique) to the recovered data, to receive the recovered data or to receive the file.
• the modified URLs may include information associated with the incomplete version of a file data or the incomplete version of a file, such as byte ranges and substitution codes corresponding to a missing or corrupted portion of the incomplete data.
• the modified URL may identify whether the URL is associated with source data, repair data, and/or substitution codes for the incomplete version of a file.
• the enhanced FLUTE client may allocate at least one associated file for the modified URL.
• the associated file may be uniquely identified by the modified URL.
• the enhanced FLUTE client may allocate an associated file for each modified URL, in which case each associated file may be uniquely identified by one of the one or more modified URLs.
• the enhanced FLUTE player may assign two URLs and may allocate two associated files, one for each URL.
• the enhanced FLUTE client may store the incomplete data or incomplete version of a file in the allocated associated file. In an embodiment, all of the data received for the may be stored in the same allocated associated file. In another embodiment, a portion of the received data may be stored in one or more allocated associated files. In an embodiment, the portion of the received data stored in each of a plurality of allocated associated files may be different. In an embodiment, source symbols and repair symbols for the incomplete data may be stored together in the same associated file. In an embodiment, repair symbols and source symbols for the incomplete data may be stored in separate associated files. In block 916 the enhanced FLUTE client may send the modified URL to the target application. In an embodiment, the enhanced FLUTE client may send more than one modified URL to the target application.
• the enhance FLUTE client may store the URL(s) in a memory location accessible by the target application and the target application may retrieve the URL(s) at a given periodicity. The process may continue with the processor returning to block 902 to receive the next segment of data.
• FIG. 10 illustrates an embodiment method 1000 for utilizing a modified URL at a target application, such as a DASH client.
• the target application may receive the modified URL.
• the modified URL may be a URL generated by an enhanced FLUTE client in response to receiving incomplete data.
• the target application may receive the modified URL directly from an enhanced FLUTE client.
• the target application may retrieve the modified URL from a memory location where modified URLs may be stored by a FLUTE client.
• the target application may determine whether the associated file includes source symbols for the incomplete data.
• the target application may determine whether the associated file includes source symbols based at least in part on the modified URL.
• the modified URL may include in indication that the URL is associated with source symbols, such as a defined code or word, and the target application may include programming correlating the defined code or word with an associated file including source symbols.
• the modified URL may itself include source symbols, and the target application may determine the URL is associated with source symbols based on the included source symbols.
• the target application may determine whether the associated file includes repair symbols for the incomplete data.
• the target application may determine whether the associated file includes repair symbols based at least in part on the modified URL.
• the modified URL may include an indication that the URL is associated with repair symbols, such as a defined code or word, and the target application may include programming correlating the defined code or word with an associated file including repair symbols.
• the modified URL may itself include repair symbols, and the target application may determine the URL is associated with repair symbols based on the included repair symbols.
• the target application may determine the positions of any missing source symbols within the incomplete data.
• the target application may determine the positions of any missing source symbols within the incomplete data or incomplete version of a file based at least in part on the modified URL.
• the modified URL may include substitution codes and the target application may determine the positions of any missing source symbols within the incomplete data or incomplete version of a file by utilizing the substitution codes to determine the positions of any missing source symbols within the incomplete data or incomplete version of a file.
• the target application may retrieve the data from the associated file.
• the target application may retrieve the data utilizing the modified URL to access the associated file and read the data stored in the associated file.
• a further source such as another memory location, different server, etc.
• the target application may apply FEC decoding using data from the associated file to recover the incomplete data or incomplete version of a file as best as possible in block 1018.
• an enhanced FLUTE client may allocate a separate file and store information related to the byte ranges of any missing or corrupted portions of the incomplete data in that separate file.
• the enhanced FLUTE client may assign a modified URL to that separate file storing the byte ranges.
• FIG. 11 illustrates the prior art method 1100 employed by current HTTP servers for handling of client requests for incomplete versions of files.
• a file request is a message, such as a
• GET operation (i.e., method) requesting a file.
• the file request includes the
• file requests may also be performed using the "partial GET" operation which may include a request for a portion of a file at the URL/URI by including one or more byte ranges representing a subset of the total file associated with the URL/URI.
• the file request does not include an indication that the client is enabled to utilize an incomplete version of a file, with respect to either the full resource requested via the "GET," or a partial resource as indicated by the
• the HTTP server determines whether the full requested file is available.
• the error message may include a status code, such as 404 "Not Found.”
• FIGs. 12-15 illustrate embodiment methods for enhanced HTTP handling of client requests for incomplete versions of files. While discussed in terms of client devices and enhanced HTTP servers the operations of the embodiment methods illustrated in FIGs. 12-15 may be performed by any two devices and/or applications operating in a client/server relationship according to an enhanced HTTP as discussed herein.
• FIG. 12 illustrates an embodiment method 1200 for enhanced HTTP server handling of client device requests for incomplete versions of files.
• the client device may generate a file request including an incomplete version of a file capable indication.
• a file request including an incomplete version of a file capable indication may be a request message, such as a "GET" operation (i.e., method), including a header indicating the client device is capable of using an incomplete version of a file (e.g., an incomplete file and/or corrupted file).
• the client device may send the file request to the enhanced HTTP server and in block 1206 the enhanced HTTP server may receive the file request.
• the enhanced HTTP server may determine whether the full requested file is available.
• the enhanced HTTP server may determine whether the full requested file is available by looking to the URL URI associated with the file request and determining whether the file at the URL URI is missing data and/or is corrupted in any way. Those files not missing data and/or not including corrupted data may be determined to be full files. Those files missing data and/or including corrupted data may be determined to be incomplete versions of files.
• the enhanced HTTP server may determine whether a file is a full or incomplete version of a file based on data stored with the file at the URL/URI, such as header data, indicating the status of the file as a full or incomplete version of a file.
• the enhanced HTTP server may determine the file is a full or incomplete version of a file, and may indicate in a file header the status of the file.
• the response may include a status code indicating the entire requested file was retrieved successfully, such as 200 "OK.”
• the enhanced HTTP server may determine whether the client device has indicated it is capable of using an incomplete version of a file (e.g., an incomplete file and/or corrupted file). In an embodiment, the enhanced HTTP server may determine the client device is capable of using an incomplete version of a file based at least in part on the file request header.
• the enhance HTTP server 1216 may send an error message without the requested file and/or any portion of the requested file to the client device and in block 1224 the client device may receive the error message.
• the error message may be a message sent from the enhanced HTTP server to the client device including an error status code, such as 404 "Not Found.”
• the enhanced HTTP server may determine whether the file requested is or will be partially recoverable. As part of this
• the enhanced HTTP server may apply error correction routines, such as FEC, to determine whether data was fully or partially decoded and recovered from the incomplete version of a file.
• the enhanced HTTP server may send a response from the HTTP server to the client device including the incomplete version of a file and an incomplete version of a file header.
• the incomplete version of a file may comprise source symbols and repair symbols.
• the incomplete version of a file header may indicate that the response includes a file that was only partially recovered.
• the partial file header may include byte ranges and substitution codes corresponding to missing or corrupted portions of the partially recoverable file.
• the client device may receive the response including the incomplete version of a file.
• FIG. 13 illustrates an embodiment method 1300 similar to method 1200 described above with reference to FIG. 12, except that in method 1300 the file request generated by the client device may not include an indication that the client device is capable of using a incomplete version of a file and the enhanced HTTP server may send incomplete versions of files without determining the capability of the client device to handle incomplete versions of files.
• the client device may generate a file request.
• a file request including an incomplete version of a file capable indication may be a request message, such as a "GET" operation (i.e., method), and the file request may not include an indication of the client device's capability to handle incomplete versions of files.
• GET i.e., method
• the client device may send the file request to the enhanced HTTP server, and in block 1306 the enhanced HTTP server 1306 may receive the file request.
• the client device may receive the response including the incomplete version of a file and the incomplete version of a file header.
• the client device may determine whether the client device and/or any applications and/or clients running on the client device are incomplete version of a file handling enabled.
• a DASH client running on a smart phone may be capable of using incomplete versions of files, and the client device may therefore be incomplete version of a file handling enabled.
• the client device may determine whether the file received in the response is an incomplete version of a file based on the incomplete version of a file header.
• FIG. 14 illustrates an embodiment method 1400 similar to method 1300 described above with reference to FIG. 14, except that rather than sending a response with an incomplete version of a file header, the enhanced HTTP server may send an error message including the incomplete version of a file.
• the client device may perform the operations of like number blocks of method 1300 described above with reference to FIG. 13 to generate and send a file request to the enhanced HTTP server and receive a response including the full file when available or an error message without any portion of the requested file when the file is not partially recoverable.
• the enhance HTTP server may perform operations of like numbered blocks of method 1300 as described above with reference to FIG. 13 to receive the file request, determine whether the full requested file is available or partially recoverable, and send a response or error message accordingly.
• the enhanced HTTP server may send an error message including an incomplete version of a file status code and the incomplete recoverable file.
• the status code itself may indicate that at least a portion of the file identified in the file request is an incomplete version of a file.
• the assigned number status code of the number may indicate the file included in the error message is an incomplete version of a file.
• the assigned number of the status code may be in the 400' s, such as 499 to indicate it is associated with an error, for example a request for a file that is not fully available.
• the assigned number of the status code may be in a status code range that is undefined in current HTTP, such as the 600' s, and the new status code range may by definition indicate an incomplete version of a file is being provided in response to a file request.
• the incomplete version of a file included in the error message may comprise source symbols and repair symbols.
• the client device may receive the error message including the incomplete version of a file.
• the client device may determine the error message includes an incomplete version of a file based on the status code of the error message.
• the client device may perform operations of like numbered blocks of method 1300 described above with reference to FIG. 13 to determine whether incomplete version of a file handling is enabled and store or discard the incomplete version of a file accordingly.
• FIG. 15 illustrates an embodiment method 1500 similar to method 1200 described above with reference to FIG. 12, except that rather than sending a response with an incomplete version of a file header, the enhanced HTTP server may send an error message including the incomplete version of a file.
• the status code itself may indicate that at least a portion of the file identified in the file request is an incomplete version of a file.
• the assigned number status code of the number may indicate the file included in the error message is an incomplete version of a file.
• the assigned number of the status code may be in the 400' s, such as 499 to indicate it is associated with an error, for example a request for a file that is not fully available.
• the assigned number of the status code may be in a status code range that is undefined in current HTTP, such as the 600' s, and the new status code range may by definition indicate an incomplete version of a file is being provided in response to a file request.
• the incomplete version of a file included in the error message may comprise source symbols and repair symbols.
• the client device may receive the error message including the incomplete version of a file.
• the client device may determine the error message includes an incomplete version of a file based on the status code of the error message.
• FEC decoding may be performed by the consuming client/application of the incomplete version of a file which comprises
• the enhanced HTTP server may only be enabled to identify that a file it may provide is not complete, but may not be able to repair the incomplete version of a file or determine whether the incomplete version of a file is recoverable.
• the client may gather the available FEC symbols and determine whether the FEC symbols are sufficient to perform FEC decoding.
• the client may invoke a repair service, such as via the unicast network, to fetch additional FEC symbols to be used along with the ones obtained earlier to perform the FEC recovery.
• the mechanisms may pertain to the delivery of incomplete version of file content from the FLUTE receiver to a consuming application capable of handling such incomplete content, in support of different usage scenarios.
• an incomplete content file may be passed by the FLUTE receiver to the application. Missing data in such incomplete version of a file may result from the occurrence of transmission errors which are uncorrectable by Application Layer (AL) FEC processing performed by the FLUTE receiver (if FEC encoding was applied by the FLUTE sender).
• the associated consuming application may be referred to in this case as Application- Type A.
• AL FEC may be applied by the FLUTE sender, with subsequent FEC decoding performed by the consuming application instead of the FLUTE receiver.
• the content forwarded to the application may include source and/or repair encoding symbols (depending on the type of encoding symbols nominally sent on the broadcast bearer), along with FEC metadata (i.e. FEC Payload ID and FEC OTI elements). Should transmission errors result in the application receiving a (partial) set of source and repair data insufficient to facilitate successful FEC decoding, the application may utilize a repair service to obtain additional source or repair data over the unicast network.
• the associated consuming application may be referred to in this case as Application-Type B.
• incomplete version of a file delivery from the FLUTE receiver to the consuming application of Type A may utilize a single pair of request and response messages using the HTTP/1.1 protocol (RFC 2616 [18]).
• the application may use the conventional HTTP/1.1 GET or partial GET request to request delivery of the target file content from a standard HTTP/1.1 server function, the latter assumed to reside within the FLUTE receiver.
• This UE-based HTTP server entity may be abbreviated as HTTP-server ue .
• the HTTP-server ue may deliver in the response message body the corresponding file data that it had previously received.
• special extension headers may be defined to indicate the capability of the requesting application to accept an incomplete resource relative to its nominal request, as well as the intent of the HTTP-server ue to deliver such incomplete resource in the response message body.
• an extension-header "Incomplete-Resource:" may be included in the HTTP request message to indicate the willingness/capability of the requesting application to handle incomplete resource returned in the response message. There may be no need for a value field for this extension header given the presence of the header itself fully defines the context.
• This extension header, of the entity-header type may correspond to a Permanent Message Header as defined in RFC 3864 entitled “Registration Procedures for Message Header Fields", published September 2004, available at
• the HTTP-server ue may send in the response line the status code '404' (Not Found), and may include in the response message the same extension-header "Incomplete-Resource:". Similar to the case of its use in the request message, a value field may be unnecessary for this extension header since the presence of the header may be an indication of the server's intent to provide an incomplete resource in the response message.
• the Type A application may indicate in the HTTP GET request the target file being requested.
• the application may be assumed to have knowledge of the corresponding file URI (e.g. from the Schedule Description metadata fragment of the USD, the MPD, a Web page associated with the MBMS service, etc.).
• the extension-header "Reception- Capability:" may be included in the request message.
• An HTTP GET with a normal query may be used to request the sought data, according to HTTP1.1 defined in RFC 2616. Example schemas for such a request method in ABNF are shown below.
• local_resource_URI ⁇ the URI known to the application, representing the location within the local HTTP server from which the target file content can be retrieved
• byte-ranges ⁇ one or more byte ranges within the requested resource, as defined by the 'Range' request header in RFC 2616>
• the repair request may contain an indication of the MD5 hash value of the file, if present in the FDT instance declaring the file from which data may be being requested.
• the MD5 hash value may be used to identify a specific version of the file.
• the HTTP response message may include a message body for carrying the incomplete version of a file contents.
• the structure of the message body may be signaled according to the semantics of the '206' (Incomplete Content) status code as defined in RFC 2616 via various manners.
• the response may include the header field 'Content-Range' indicating the byte range included with this response.
• the response may contain the header field 'Content-Type' with the value "multipart/byteranges".
• a 'Content-Range' field may appear in each part to indicate the byte range for that part.
• the use of a single byte range or multiple byte ranges to convey the content of the message body if a 'Content-Length' header may be also present in the response, its value may match the actual number of octets carried in the message body of the HTTP response message.
• incomplete version of a file delivery from the FLUTE receiver to the consuming application of Type B may be assumed to utilize request and response messages defined by the HTTP/1.1 protocol (RFC 2616).
• HTTP/1.1 protocol RRC 2616
• Other delivery mechanisms/protocols for this interface may be used.
• the application may use the conventional HTTP/1.1 GET request to request from a standard HTTP/1.1 server function associated with the FLUTE receiver, encoding symbols and FEC metadata associated with the target file.
• this UE-based HTTP server may be designated as the HTTP- server ue .
• the HTTP-server ue then delivers via the response message body the corresponding set of encoding symbols it has available, along with the FEC metadata.
• the same extension headers as defined in 7.X.2 may be used to indicate the capability of the requesting application to accept an incomplete resource relative to its nominal request, and the intent of HTTP-server ue to deliver such incomplete resource.
• the Type B application may include in the HTTP GET request the URI of the file for which it may be requesting encoding symbols and FEC metadata.
• the application may be assumed to have knowledge of the corresponding file URI (e.g. from the Schedule Description metadata fragment of the USD, the MPD, a Web page associated with the MBMS service, etc.).
• the extension-header "Incomplete-Resource" as defined in above may be included in the request message.
• an HTTP GET with a normal query may be used to request the sought data, according to HTTP1.1 (RFC 2616).
• HTTP1.1 HTTP1.1
• An example syntax used for such request method in ABNF is shown below.
• local_resource_URI ⁇ the URI known to the application, representing the location within the local HTTP server from which the target FEC information can be retrieved >
• the incomplete version of a file request may contain an indication of the MD5 hash value of the file, if present in the FDT instance declaring the file from which data may be being requested.
• the MD5 hash value may be used to identify a specific version of the file.
• the overall mechanism and format of the incomplete version of a file response message may be similar to that defined for the symbol- based file repair response message for HTTP delivery of repair data, with differences as described below.
• the incomplete version of a file response message consists of HTTP header and file repair response payload (HTTP payload).
• the HTTP response message may include: HTTP status code set to 200 OK, Message header fields containing at least: the (same) extension header "Incomplete-Resource:” to indicate incomplete content to be returned in the message body, Content type of the HTTP payload as indicated below, Message body carrying the FEC encoding and FEC metadata.
• the incomplete version of a file delivery response message format may include a status line, message headers, FEC-OTI elements, length indicators, FEC payload IDs, and encoding symbols.
• FEC-OTI elements may be 14 bytes long, and may include FEC object transmission information comprising the concatenation of the encoded Common FEC Object transmission information and the encoded Scheme- Specific FEC Object Transmission information.
• a length indicator may be 2 bytes and indicate the number of encoding symbols in the group (e.g., in network byte order, i.e., high order byte first).
• an FEC payload ID may indicate which encoding symbols are included in the group. The format and interpretation of the FEC payload ID may depend on the FEC scheme in use.
• the encoding symbols may contain the encoding symbols, and all the encoding symbols may be the same length.
• the Content- Type may be set to "application/simpleSymbolContainer", which may indicate that the message body may be a simple container of encoding symbols.
• an example HTTP status line and message headers in the case of incomplete resource availability at the FLUTE receiver HTTP-server ue , may be as follows:
• encoding symbols may be included in the response in groups.
• Each group may be preceded by an indication of the number of symbols within the group and an FEC Payload ID coded according to the FEC scheme used for the original file delivery session.
• the FEC Payload ID identifies all the symbols in the group in the same way that the FEC Payload ID of an FEC source or repair packet identifies all the symbols in the packet.
• the file repair response payload may be constructed by including each FEC Payload ID and Encoding Symbol group one after another (these are already byte aligned). The order of these pairs in the repair response payload may be in order of increasing SBN, and then increasing ESI, value; however no particular order may be mandated.
• a single HTTP incomplete version of a file response message may contain, at most, the same number of symbols originally sent by the FEC encoder for transmission over the MBMS bearer.
• the application may have sufficient information to calculate the length of each encoding symbol and each FEC Payload ID. All encoding symbols are the same length; with the possible exception of the last source encoding symbol in the repair response. All FEC Payload IDs are the same length for an incomplete version of a file request-response message pair, since a single FEC scheme may be used for a single file.
• a new HTTP extension header "Incomplete- Resource:" may be used by the HTTP client to indicate to the server its willingness and capability to accept an incomplete or incomplete resource relative to the identified resource in the HTTP-URL.
• the same extension header may be used by the HTTP server to indicate, to the client, its intent to deliver an incomplete resource in the response message body, when only such incomplete content may be available, and upon detecting the client' s capability to handle such incomplete response.
• the procedures for registering header extensions in IANA's Permanent Message Header Field Registry are defined in RFC 3864.
• the mobile device 1600 may include a processor 1602 coupled to internal memories 1604 and 1610.
• Internal memories 1604 and 1610 may be volatile or nonvolatile memories, and may also be secure and/or encrypted memories, or unsecure and/or unencrypted memories, or any combination thereof.
• the processor 1602 may also be coupled to a touch screen display 1606, such as a resistive-sensing touch screen, capacitive-sensing touch screen infrared sensing touch screen, or the like. Additionally, the display of the mobile device 1600 need not have touch screen capability.
• the mobile device 1600 may have one or more antenna 1608 for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver 1616 coupled to the processor 1602.
• the mobile device 1600 may also include physical buttons 1612a and 1612b for receiving user inputs.
• the mobile device 1600 may also include a power button 1618 for turning the mobile device 1600 on and off.
• a laptop computer 1710 will typically include a processor 1711 coupled to volatile memory 1712 and a large capacity nonvolatile memory, such as a disk drive 1713 of Flash memory.
• the computer 1710 may also include a floppy disc drive 1714 and a compact disc (CD) drive 1715 coupled to the processor 1711.
• the computer device 1710 may also include a number of connector ports coupled to the processor 1711 for establishing data connections or receiving external memory devices, such as a USB or Fire Wire® connector sockets, or other network connection circuits for coupling the processor 1711 to a network.
• the computer housing includes the touchpad 1717, the keyboard 1718, and the display 1719 all coupled to the processor 1711.
• Other configurations of the computing device may include a computer mouse or trackball coupled to the processor (e.g., via a USB input) as are well known, which may also be use in conjunction with the various embodiments.
• the various embodiments may also be implemented on any of a variety of commercially available server devices, such as the server 1800 illustrated in FIG. 18.
• Such a server 1800 typically includes a processor 1801 coupled to volatile memory 1802 and a large capacity nonvolatile memory, such as a disk drive 1803.
• the server 1800 may also include a floppy disc drive, compact disc (CD) or DVD disc drive 1804 coupled to the processor 1801.
• the server 1800 may also include network access ports 1806 coupled to the processor 1801 for establishing network interface connections with a network 1807, such as a local area network coupled to other broadcast system computers and servers.
• the processors 1602, 1711, and 1801 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described above. In some devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 1604, 1610, 1712, 1713, 1802, and 1803 before they are accessed and loaded into the processors 1602, 1711, and 1801.
• the processors 1602, 1711, and 1801 may include internal memory sufficient to store the application software instructions. In many devices the internal memory may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to memory accessible by the processors 1602, 1711, and 1801 including internal memory or removable memory plugged into the device and memory within the processor 1602, 1711, and 1801 themselves.
• the hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor configured with processor-executable instructions, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.
• a general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
• a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more
• microprocessors in conjunction with a DSP core, or any other such configuration.
• some steps or methods may be performed by circuitry that is specific to a given function.
• the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium.
• the steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a tangible, non-transitory processor-readable storage medium.
• Tangible, non-transitory processor-readable storage media may be any available media which may be accessed by a processor of a computing device.
• non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a processor.
• Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non- transitory processor-readable media.
• the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a tangible, non-transitory machine-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Security & Cryptography (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (6)

Publications (1)

Family

ID=49236520

Family Applications (1)

Country Status (2)

Cited By (4)

Families Citing this family (17)

Citations (3)

Family Cites Families (11)

• 2013
  • 2013-03-15 US US13/838,744 patent/US9264481B2/en active Active
  • 2013-03-29 WO PCT/US2013/034608 patent/WO2013149144A1/fr not_active Ceased

Patent Citations (3)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events