JP2011519515A - System and method for improving reliability of file transmission - Google Patents

Abstract

The present invention concerns a method at a file server (1.1) for sending more than one file (41, 42, 43) to more than one receiver (1.7), comprising the steps of aggregating the files into a container (40), splitting the container into more than one packet (401, 402, 403), and transmitting the more than one packet to the more than one receiver, wherein, the reception of at least one packet of the container enables a receiver to request the reception of lost packets of the container. To this end, the method comprises the steps of receiving an indication of the number of consecutive lost packets of the container per the more than one receiver and adapting the size of the container, in function of the number of consecutive lost packets at the receivers.

Description

  The present invention relates generally to video broadcast to mobile receivers, and more specifically to a method and system for improving transmission reliability.

  This section is intended to provide the reader with various aspects of the art according to various aspects of the invention described and / or claimed below. We believe that this discussion will help provide readers with background information that facilitates a better understanding of the various aspects of the present invention. However, it should be understood that these descriptions should be read from this point of view and not as prior art approval.

  Distribution of content between the server and multiple receivers requires setting up either a point-to-point connection or a multipoint connection between the server and each receiver. A point-to-point connection allows content to be distributed by unicast to each receiver and provides robust delivery. However, if there are a significant number of receivers, it requires management beyond the connection limit. It also dramatically increases traffic on the network. Multicast delivery has a lower network load, but delivery is less robust due to the lack of an acknowledgment mechanism. If multicast delivery is used, a solution should be found to repair the error in reception, for example by a retransmission request. As an example of content multicast delivery, IETF RFC 3926 defines the File Delivery over Unidirectional Transport (FLUTE) protocol. The protocol defined in this standard is well adapted to respond to scalability issues for the number of clients and non-uniformity issues for bandwidth supported by clients.

  DVB-H IP Datacasting Standard, << ETSI TS 102 472 V1.1.1 (2006-06), Digital Video Broadcasting (DVB); IP Dataover DVB-H; Content Delivery Protocols (hereinafter referred to as CD) (Referred to as “CDP standard”) defines a file repair mechanism. The file repair technique adapted by the CDP standard is a one level file repair technique and introduces a “File Repair” mode in a centralized client server. It uses a file repair mechanism to support the FLUTE protocol to achieve reliable file delivery over broadcast / multicast networks. When an incomplete file reception is detected, the FLUTE receiver activates a file repair mechanism. It is in requesting lost or corrupted packets. According to FLUTE terminology, these packets are called symbols. A point-to-point connection sends a request to the repair file server. The request basically gathers the name of the file to be repaired and a list of missing symbols.

  The FLUTE protocol defines an FDT (File Delivery Table) that includes file description information of a file to be transmitted within a file delivery session. The FLUTE protocol transmits FDT from the content server in the multicast mode to all clients. If this assumes transmission errors, the reliability of FDT file transmission can be achieved by a mechanism such as forward error correction, which is well known per se, or by retransmitting FDT during a session. Can be enhanced. Thus, at the end of multicast content delivery, each client knows exactly which files are to be sent and received in the session. Each client can then suggest the lost file to the index server.

  The mechanism defined by the CDP standard requires the receiver to receive at least a file packet. If a packet is received, the receiver cannot detect that the file was not received immediately and accurately.

  The present invention seeks to address at least some of the concerns associated with transmission to multiple receivers in the prior art by providing a mechanism to improve reliability.

  The present invention is a method for transmitting more than one file to more than one receiver in a file server, comprising: integrating the file into a container; dividing the container into more than one packet; Sending more packets to the more than one receiver, the reception of at least one packet of the container allowing the receiver to request retransmission of the missing packet of the container And a method. To this end, the method includes receiving an indication of the number of consecutive missing packets in the container for each of the more than one receiver, and the container in a function of the number of consecutive missing packets at the receiver. Adapting the size of the.

  In this way, the present invention allows the server to adapt the integration size to the receiving capability of the receiver. The reception environment at the receiver is variable. It is reported to the server and the server reacts to improve the transmission. The system of the invention makes it possible to adapt the transmission parameters to the network environment. Packet loss burstiness is characterized by a relatively short period of packet loss. File integration technology ensures that small files are not completely lost in many short loss periods. In that case, repair is not possible.

  According to an embodiment, the size of the container is based on the number of receivers reporting the number of consecutive missing packets above or below the default value.

  According to an embodiment, the size of the container increases if the number of receivers exceeds a default value, and the size of the container decreases if the number of receivers falls below the default value.

  According to an embodiment, the size of the container depends on the receive buffer size of the receiver greater than 1.

  According to an embodiment, the packet is transmitted according to the File Delivery over Unidirectional Transport (FLUTE) protocol.

  According to an embodiment, receiving the indication comprises obtaining information on a repair request received from the receiver at a repair server.

  According to an embodiment, receiving the indication comprises receiving a report regarding the number of consecutive missing packets from the receiver.

  According to an embodiment, the size of the container is initially set to a default value, and the value of the size of the container can only be greater than or equal to the default value.

  The present invention also provides communication means for communicating with a server and receiving a file from the server, file reception calculating means for confirming reception of the file, and file reception reporting means for reporting whether or not the file has been received to the server And a DVB-H mobile terminal.

  The present invention also provides communication means for transmitting more than one file integrated into a container having a certain size to more than one receiver, and the number of consecutive missing packets in at least one receiver. An integrated loss value calculating means for adapting the size of the file, and a file integration means for constructing the container, dividing the container into more than one packet, and transmitting the packet to the at least one receiver. Related.

  Specific embodiments corresponding to the disclosed embodiments and within the scope are listed below. It will be appreciated that these aspects are merely presented to give the reader an overview of the specific forms that the invention can take, and these aspects limit the scope of the invention. Not intended for that. Indeed, the invention may encompass a variety of aspects not listed below.

1 represents a system for video distribution according to an embodiment. 1 represents a mobile terminal according to an embodiment. 2 represents a file server according to an embodiment. Represents a measurement report of packet loss burstiness. Fig. 4 represents file integration according to an embodiment.

  The present invention will be better understood with reference to the following embodiments and examples, without being limited in any way, with reference to the accompanying drawings.

  The blocks represented in FIGS. 1-3 are merely functional entities and do not necessarily correspond to physically separated entities. That is, they may be developed in the form of hardware or software, or may be implemented on one or more integrated circuits.

  An exemplary embodiment is within the framework of DVB-H transmission, but the present invention is not limited to this particular embodiment, and the server is integrated into multiple receivers to improve transmission reliability. It may be applied within other frameworks that send data in a form.

  A video distribution system according to an embodiment is represented in FIG. The video broadcast network 1.6 is ETSI TS 102 472 V1.1.1 (2006-05), “Digital Video Broadcasting (DVB); IP Data over DVB-H: Architecture” (hereinafter referred to as “IP data cast standard”). Follow.)

  The system is also referred to as ETSI TS 102 472 V1.2.1 (2006-12), “Digital Video Broadcasting (DVB); IP Dataover over DVB-H: Content Delivery Protocols” (hereinafter “CDP Standard”). Follow.

  The file server 1.1 transmits a data file according to the CDP standard and the FLUTE protocol. The data file is sent to the mobile terminal 1.7 via the IP network 1.3 and the DVB-H broadcast network 1.6. The IP network may be any IP network assisted multicast transmission such as the Internet. The DVB-H transmission network has, among other things, a DVB-H IP Encapsulator 1.4 and a DVB-H transmitter 1.5. Of course, embodiments are not limited to DVB-H networks. It is applicable to other broadcast distribution networks, such as the digital subscriber line family.

  The system further has a return channel through the cellular network 1.8. The mobile terminal can send and receive data (particularly interactive data) via the return channel. Of course, the return channel may be any other type of channel that provides a point-to-point bi-directional connection. The system is a simplified file repair infrastructure associated with DVB-H as defined in the CDP standard. The terminal presents a repair request to the repair server 1.2 to recover packets that are detected to be lost or corrupted (these are FLUTE symbols). The repair server stores a copy of the downloaded file. If the repair server is available, it sends the requested packet back to the terminal.

  The mobile terminal, among other things, sends packet loss information defined below to the file server via the return channel.

  A mobile terminal 1.7 is represented in FIG. According to an embodiment, it is a terminal that follows the IP datacast standard. The mobile terminal 1.7 has a communication module 24 that receives data from a broadcast network (in particular, a DVB-H network) and transmits / receives data on a return channel (in particular, a cellular network). The mobile terminal 1.7 has a storage module 22 for storing data (especially FDT and ESG information) received from the broadcast channel. The mobile terminal 1.7 has a processing module 21 and an internal bus 26 that enables communication between the modules. The mobile terminal 1.7 includes a file reception calculation module 25 that confirms file reception according to the embodiment. The mobile terminal 1.7 further includes a file reception report module 23 that reports a received or not received file to the file server.

  The file server 1.1 is represented in FIG. It follows the CDP standard. The file server 1.1 has a communication module 34 that communicates with a mobile terminal via a return channel and transmits content via a distribution channel. The file server 1.1 has a storage module 32 that stores the integrated value and the packet loss value received from the mobile terminal. The file server 1.1 has a processing module 31 and an internal bus 36 that enables communication between the modules. The file server 1.1 has an integrated loss value calculation module 33 that calculates an aggregation value based on consecutive missing packets of containers received from each of the mobile terminals. The integrated values are further described below. The server has a file integration module 35 that constructs an integrated file and transmits the file to the mobile terminal.

  The individual number of consecutive packet losses associated with packet length X is referred to as INCPL-X. INCPL-X is calculated at the server. MSAF-X represents the minimum size of an integrated file and is described further below. The value of MSAF-X is adjusted based on the value of INCPL-X.

  The number of consecutive packet losses corresponding to a particular appearance threshold (T) and a typical packet length X is NCPL-TX. It is a constant value. For example, for a 1400 byte broadcast packet, NCPL-80-1400 indicates the NCPL value for the associated broadcast system and receiver, so 80% of the continuous packet loss period observed from the receiver is It has a continuous packet loss of “NCPL-80-1400” or less. According to FIG. 4, about 80% of the loss period has 162 or fewer packets. That is, the value of NCPL-80-1400 has a value of 162. In other words, if NCPL-80-1400 is set to 162, 80% of the receivers will receive at least one packet. Here, 1400 is a minimum length, which means that the value of NCPL-80-1400 is applied to a packet having a length of 1400 or more.

  More generally, the calculation of the NCPL-T-X configuration is either a model ascertained by field measurements or a dynamic evaluation based on periodic measurements performed by the mobile terminal using its broadcast system. Based.

  The reception report information is provided to the server by the receiver. It is provided by each one of the receivers. It may be provided by only a part of the receiver. The receiver uses a bidirectional link to transmit the information in so-called transparent mode or non-transparent mode.

  In the non-transparent mode, the mobile terminal transmits reception report information using a bidirectional channel. Reception report information is transmitted periodically. It corresponds to a measurement report on recent file reception.

  One non-transparent mode is broadcast, a list of files that are delivered or downloaded via the media and their scheduled delivery times, thanks to the electronic service guide (ESG) of other similar types of lists. Based on the fact that it is usually known in advance. The receiver detects whether it has received the file. Next, the receiver transmits confirmation response or non-acknowledgement information related to reception of the file to the file server. The terminal uses the reception report procedure defined in chapter 7.4.3 of ETSI TS 102472 to report the file delivery status. Such a standard defines a file receipt report with a reportType parameter. According to an embodiment, a report type parameter different from that standard is defined to report that the file was not received. The report type value is set to “rnack”. Of course, the terminal may use the reception report procedure defined in OMA-BCAST. When the file server receives a report from the mobile terminal, the file server calculates the value of INCPL-X for each terminal during the observation period. The file server then calculates MSAF-X for the entire file distribution system to drive the size of the next consolidated file to be broadcast.

  Other non-transparent modes that obtain such reports at the server can use the Real-Time Transport Protocol (RTP). It is based on monitoring the medium for dedicated transmission. For example, successful reception of consecutive RTP packets of length Yn for terminal n makes it possible to calculate INCPL-X for that terminal n. The associated RTCP receiver reports collection information regarding packet loss, and then allows the file server to obtain an INCPL-X overview for each reporting receiver in the system.

  In transparent mode, the mobile terminal presents a file repair request to the repair server. The repair server calculates an INCPL-X value for each one of the mobile terminals based on the repair request received from that terminal. If the repair server is expected to know the original sequence of FLUTE packet transmissions, it calculates INCPL-X from the repair request. The repair server makes a set of values available to the server. The file server may retrieve the set of values periodically. The file server can then determine a new value for MSAF-X.

  Alternatively, the repair server further calculates a ratio Rref. The repair server then presents Rref to the file server by some IP notification mechanism that is well known per se.

  According to the embodiment, at the start, the value of NCPL-TX is given to the server. The value is manually set by the operator via the graphic user interface. Of course, it may be indicated to the server by a configuration file or via some local or remote configuration means.

  The NCPL-T-X value is used to calculate the initial minimum size for building an integrated file that is broadcast to the receiver.

  The server defines an adjustable period. The period has a value corresponding to the broadcast and two or three file repair periods. Further, the adjustable value may be set by an operator in the server. After an adjustable period, the minimum size of the consolidated file is dynamically adjusted according to the information reported by the terminal.

  The value of MSAF-X calculated at the server always takes into account the capacity of each receiver buffer. The receiver buffer size is a setting parameter that is set by the operator and sent to all receivers and servers. Of course, it may be set dynamically at the server in response to receiving the maximum buffer size capability from the receiver.

  The server is presented with a default NCPL-TX value set by the operator. This set of values allows the server to begin sending consolidated packets. This set of values comes from a campaign measurement. An example of a measurement may be performed in an actual DVB-H service area, allowing the basic characteristics of packet loss to be determined for such a network. Measurements are made by coupling an IP / RTP packet generator to the headend transmitter and by recording received packets at fixed and moving points within the service area with a portable receiver. Analysis of the receiver log allows the packet loss rate and burst characteristics to be determined when each transmitted packet is individually numbered. FIG. 4 is an example of measurement of packet loss burstiness when the packet length is 1400 bytes. It indicates that the packet loss period occurs with a high probability when consecutive packet losses are relatively small. About 80% of the loss period has no more than 162 packets. Thus, an appearance threshold of 80% gives a value of 162 NCPL-80-1400. It provides an estimate of the NCPL-T-X value.

  The INCPL-TX calculated for each receiver then makes it possible to determine the value of MSAF-X. Its value increases or decreases. MSAF-X represents the minimum size of an integrated file. It corresponds to the number of packets of length X that are integrated.

  At the start, the value of MSAF-X is generated using the value of NCPL-T-X. The value of MSAF-X is larger than the value of NCPL-T-X. It is set to MSAF-X = NCPL-T-X + N. N is set to 5. If the value of N is large, the opportunity for the client to receive at least one packet in the consolidated file increases. However, it requires a large buffer size at the client. N should then be set to a value greater than 1, but less than the threshold set by the operator, depending on the receiver buffer size requirement.

  Once selected, the value is retained and used for an adjustable period. As described above, the adjustable period is set to the duration of the broadcast of 2 or 3 consolidated files of size MSAF-X and the associated repair period. It gives the distribution system time to obtain a reception report from the receiver through a transparent or non-transparent method.

  The server then calculates the reference ratio (R) of the receiver. Therefore, the reported INCPL-X is larger than NCPL-TX. The ratio Rref is used for reference in the next step.

  Once the value Rref is obtained, the system periodically adapts MSAF-X as follows. In each period, R is calculated by the last reception report from the receiver.

  In the first case, R is lower than Rref. That means that fewer receivers reported INCPL-X higher than the selected NCPL-T-X in the past period. Then, the value of MSAF-X decreases. Of course, it does not take a value below NCPL-T-X + N.

  In the second case, R is higher than Rref. That means that there were more receivers that reported INCPL-X higher than the selected NCPL-T-X in the past period. Then, the value of MSAF-X increases. Of course, it does not exceed the maximum file size value for the receiver memory constraints.

  • If R has the same value as Rref, the value of MSAF-X remains unchanged.

  The calculation of MSAF-X may also be based on other mechanisms. It may also be based on reception reports received from only one receiver or from a subset of receivers. It then allows the server to drive the integration size without having feedback from all receivers. It optimizes the reporting mechanism in that the reporting receiver is considered reliable for the server.

  The file grouping mechanism according to the embodiment is GZIP, ie GNU ZIP free compression software. The file is compressed by the GZIP format. The server considers the size of the resulting compressed file. After integrating the N files into one, using GZIP, the file integration module stores the obtained file in the local storage unit using the automatically assigned name. The terminal uses the GZIP format to detect that the transmitted object is an integrated file object, thus triggering the file splitting function. The name prefix may be “GroupedFile_” and the suffix may be an integer value incremented for each new unified file object.

  The file integration module may group files based on local rules. If the files are only known by the FDT file, the server may buffer the files and consolidate them based on the file category. For example, files that correspond to the same web page may be grouped together. If the file is informed by the ESG, the server may perform such buffering and integration only if the file transport follows ESG. The broadcast time of the file follows the time indicated by ESG.

More generally, any private or conventional file transport format is possible. The requirements associated with the file format are as follows:
The possibility of transporting multiple components,
The possibility to encode the name of each component; and the possibility to encode other information associated with each component.

  When constructed, the consolidated file is sent to the FLUTE stack for transmission to the receiver. An example of file integration is shown in FIG. The file server integrates the files into the container 40 to reach the length L. Note that L = X × MSAF-X, where X represents the packet length. The server integrates file 1, file 2 and file 3 into the container. The container is then divided into three packets of length X, namely packet 1, packet 2 and packet 3. At this time, the value of MSAF-X is 3.

  The adjustable mechanism described above is naturally more accurate for smaller cells. Considering a mobile broadcast or multicast network, it is preferable to have a plurality of file servers and associated repair server infrastructure, each serving at least one transmission point area. In that case, NCPL-T-X and MSAF-X may be estimated and provided for each area covered by each file server providing greater efficiency of the entire file distribution system. The service platform causes a file to be transmitted in all file servers. Each file server collects a file integration module that maintains its own minimum size for the integrated files.

  The above mechanism is within the scope of DVB-H. Of course, it applies to any system in which the server broadcasts content to multiple servers in an integrated manner and the receiver communicates with the server via a return channel. An example of such a system may be UDP packet integration. At this time, the UDP packet is labeled to allow the receiver to detect the missing packet.

  References disclosed in the description, the claims and the drawings may be provided individually or in any appropriate combination. Features may be implemented in hardware, software, or a combination thereof, as desired.

  References herein to “one embodiment” or “an embodiment” mean that a particular feature, configuration, or characteristic described in connection with that embodiment can be included in at least one implementation of the invention. To do. The phrases “in an embodiment” appearing in various places in the specification are not necessarily all referring to the same embodiment, and are not necessarily separate or alternative from each other. Is not.

  Reference numerals appearing in the claims are by way of illustration only and shall have no effect on limiting the scope of the claims.

Claims (10)

A method of sending more than one file to more than one receiver in a file server, comprising:
Integrating the file into a container having a size;
Dividing the container into more than one packet and transmitting the more than one packet to the more than one receiver, wherein the receiver receives at least one packet of the container Allowing to request retransmission of missing packets;
Receiving an indication of the number of consecutive missing packets in the container for each of the more than one receiver;
Adapting the size of the container in a function of the number of consecutive missing packets at the receiver. The size of the container is further based on the number of receivers reporting the number of consecutive missing packets.
The method according to claim 1. If the number of receivers exceeds the default value, the container size increases,
If the number of receivers is below the default value, the size of the container is reduced.
The method according to claim 2. The size of the container depends on the receive buffer size of the receiver greater than 1.
4. A method according to any one of claims 1 to 3, characterized in that The packet is transmitted according to the FLUTE protocol;
A method according to any one of claims 1 to 4, characterized in that Receiving the indication comprises obtaining information on a repair request received from the receiver;
6. The method of claim 5, wherein: Receiving the indication comprises receiving a report on the number of consecutive missing packets from the receiver;
7. A method according to any one of claims 1 to 6, characterized in that The container size is initially set to a default value,
The container size value can only be greater than or equal to the default value;
A method according to any one of the preceding claims, characterized in that Communication means for communicating with the server and receiving packets from the server that are part of a container that is a collection of more than one file;
File reception calculation means for confirming reception of the packet;
A DVB-H mobile terminal comprising: file reception reporting means for reporting the number of consecutive missing packets in the container to the server. Communication means for sending more than one file integrated into a container having a size to more than one receiver;
File integration means for constructing the container, dividing the container into more than one packet, and transmitting the packet to more than one receiver;
Combined loss value calculation that adapts the size of the container to the number of consecutive missing packets at more than one receiver upon receipt of an indication of the number of consecutive missing packets in the container for each more receiver And a file server.

Images