This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
The IETF RFC 3926 defines the File Delivery over Unidirectional Transport protocol, noted FLUTE. The protocol defined in this standard is well adapted to answer the problems of scalability in terms of number of clients and heterogeneity in terms of bandwidth supported by the clients. The standard DVB-H IP Data-casting standard, <<ETSI TS 102 472 V1.2.1 (2006-12), Digital Video Broadcasting (DVB); IP Datacast over DVB-H; Content Delivery Protocols (CDP)>>, noted CDP standard hereinafter, defines a file repair mechanism. This mechanism is further explained in a second document, ETSI TS 102 591 1.1.1, Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols (CDP) Implementation Guidelines.
The file repair strategy adopted in DVB-H IP Data-casting standard is a one level file repair strategy and adopts the centralized client-server “File Repair” mode. It uses a file repair mechanism to assist the FLUTE protocol for achieving reliable file delivery over broadcast/multicast networks. Once it has detected the reception of an incomplete file, the FLUTE receiver launches a file repair mechanism. It consists in requesting the packets that are missing or corrupted. According to the FLUTE terminology, these packets are named symbols. The request is sent to a repair file server using a point-to-point connection. The request gathers basically the name of the file to be repaired and the list of missing symbols.
Inside such a system several repair servers, each containing one or more repair services may coexist. The list of all possible repair services is published in an “associated delivery procedure configuration file”. This is an XML file that contains one URL for each usable repair service. When a repair server is needed, the client randomly chooses one of these services and addresses over the point to point link a repair request containing the list of requested symbols. The repair service either sends some or all of the requested symbols over the point to point link, or redirects the request to a different service. This redirection may indicate, instead of another repair server, the description of the FLUTE session over which the missing-or-corrupted received symbols are broadcasted again.
The file repair procedure is initiated by a client through the point-to-point link, and is further achieved using again a point-to-point link, or the broadcast channel, or even using a mix of these links. The client asks for all the missing symbols. After analyzing the list of symbols, the repair server selects the distribution mode. For efficient use of the resources, some symbols are distributed over the broadcast link and other symbols are sent over the point to point link.
An example of such a repair combining point-to-point and broadcast link usage is as follows. A client submits a repair query to a server. That server then answers to the repair request with a subset of the requested symbols over the point-to-point link. Then the repair client sends a second request for the still missing symbols to a repair server (that may be the same as previous). This time that repair server redirects it to the broadcast session where the remaining symbols may be recovered.
The distribution over the broadcast channel has the advantage of using less resource if a same symbol is requested by several client terminals. It may not be the best solution in certain conditions. For example, if a terminal has only access to the point-to-point network (after the loss of access to the broadcast channel), it will not receive any more content distributed in that broadcast channel. In the example of mixed repair depicted above, it will not be able to receive all the symbols requested in the repair query, as only part of the repair symbols are then distributed over the point-to-point network, while others are sent over the broadcast network. It would be desirable to provide a repair method for such devices that can receive content only in a specific manner (point to point only, mix mode, . . . ) or over specific networks, if, e.g., the terminal is connected via two different point-to-point links.
USPTO Backgrounds
USPTO Backgrounds