WO2001086905A2

WO2001086905A2 - A method for the transmission of files over a digital channel, particularly over a dvb broadcasting channel, and a protocol for its implementation

Info

Publication number: WO2001086905A2
Application number: PCT/IB2001/000783
Authority: WO
Inventors: Paolo Casagranda; Luca Vignaroli
Original assignee: Rai Radiotelevisione Italiana S.P.A.
Priority date: 2000-05-12
Filing date: 2001-05-08
Publication date: 2001-11-15
Also published as: ITTO20000439A1; WO2001086905A3; ITTO20000439A0; IT1320347B1

Abstract

A start-of-transmission packet BTFTPWriteRequest and a set of data packets BTFTPData are sent to the receiver. All packets have headers of identical format, comprising a file identifier TID, an operative code identifying the nature of the packet OPCODE, the serial number of the packet BlockNumber, a field LastPacketFlag showing that the packet is the last in the current transmission, and others. In the start-of-transmission packet, the number of data packets is shown together with a sequential list of fields containing a description of the data. The successive data packets comprise, beside the common header, a sequential list of fields containing a description of the data, and a field containing a portion of the data.

Description

"A method for the transmission of files over a digital channel, particularly over a DVB broadcasting channel, and a protocol for its implementation"

SPECIFICATION

This invention is concerned with a method for transmitting files over a digital channel, particularly a broadcasting channel according to the DVB standard, and to a protocol for implementing said method. It is well known that, nowadays, file transfers through a broadcasting channel are more and more frequent, chiefly due to the growing use of digital television.

Over the years, many protocols have been devised for transferring files via digital channels, the most widespread of them probably being today the protocol known as FTP (File Transfer Protocol). Another, simpler protocol is TFTP (Trivial File Transfer Protocol), described in K. Sollins, "The TFTP Protocol - Revision 2", RFC1350, July 1992. These known protocols do not, however, satisfy the conditions necessary for use in the transfer of filed over a broadcasting channel.

Other known protocols, such as the DVB Data Carousel and the DVB Object Carousel, although they are suitable for broadcasting channels, are either relatively complex in implementation, or scarcely compatible with important standards such as IP (Internet Protocol).

Accordingly, this invention has the object of providing a datagram-based file transfer protocol, which is very efficient and which satisfies the requirements for transmission on a broadcasting digital channel according to the DVB standard, so that it can be used on broadcasting channels (e.g., video broadcasting digital channels, such as the terrestrial DVB-T and the satellite DVB-S [IS013818]).

Another object is to provide a protocol as above, which does not require a return channel, so that it can be used on a broadcasting channel, while allowing a return channel as an option for other applications having a higher degree of reliability.

Still another object is to provide a protocol as above, which involves a very small overhead. A further object is to provide a protocol that is very simple both in its specification and in its implementation.

Still another object is to provide an extensible protocol, so that it can satisfy special requirements.

A further object is to provide such protocol so that it is compatible with IP.

The above and other objects and advantages are achieved by the invention with a protocol for the transmission of files over a broadcasting digital channel according to the DVB standard having the features set out in claim 1.

The subordinate claims specify further advantageous features of the invention.

The method of file transmission according to the invention, which will be simply called BTFTP (acronym of Broadcast Trivial File Transfer Protocol), provides that a packet (BTFTPWriteRequest) is sent to the receiver to signify that a transmission is being started, and to supply the receiver with the information necessary to decode the file, whereupon a certain number of data packets (BTFTPData) follows. If a single BTFTPWriteRequest is not sufficient to contain a complete description of the transmission, a supplementary packet called BTFTPWriteRequestExtension is used.

The protocol can be used without a return channel, in a purely broadcasting fashion, i.e. without any interactivity. This is the main object of the protocol. In this mode, the contents are fixed, and the user chooses a channel and starts downloading the full data or a portion of the data on that channel. Reliability is secured in two ways: by the Forward Error Correction (FEC) of the underlying layers (e.g. Viterbi and Reed Solomon protection of a DVB channel) and or by redundancy, namely by the repetition of the transmission.

The invention also provides for the optional use of a low-bit-rate return channel, wherever a higher degree of reliability is called for, although the protocol itself has not been designed to offer interactivity, which is inherent to other protocols such as HTTP. When a return channel is used, the requests for packets are carried by a packet called BTFTPNak. In either versions, a check of data integrity is made by a CRC32 code.

It is expected that the protocol will have its best implementation with reference to the User Datagram Protocol (UDP), although other datagram-based protocols should not be excluded. In this way, the protocol can be encapsulated in the transport flow of Digital Video Broadcasting (Multi-Protocol Encapsulation Profile [IS013818]) and transmitted through broadcasting channels.

In practice, the protocol is based on a basic data packet, called BTFTPPacket, which contains a header, common to all the packets, and which takes on the various functions listed above, depending on the setting of an operative code OPCODE which is contained in it. In the preferred embodiment, the format of BTFTPPacket is defined as follows:

BTFTPPacketQ Length in bits

{ TID; 32

OPCODE; 8

BlockNumber; 32

BlockSize; 16

FutureUse; 5

LastPacketFlag; 1

RedundancyFlags; 2 if (OPCODE==0)

BTFTPWriteRequestQ; ϊ£(OPCODE=l)

BTFTPData(); if (OPCODE==2)

BTFTPNakO; if (OPCODE==3)

BTFTP WriteRequestExtension Q; if (RedundancyFlags^ OY)

Checksum; 32 If (RedundancyFlags 10) CRC32; 32

If (RedundancyFlags=00)

Ignored; 32 }

where the variables have the following meanings:

TID is a transmission identifier (Transmission Identifier), used for distinguishing each file transmission from the other, and allows multiplexed transmissions of files; the value of this field is the same for each packet of the same file transmission, and should be different from any other file transmission taking place at the same time; demultiplexing is made on the basis of the IP address, the UDP port and the TID;

OPCODE is the operative code for the current packet: this value specifies the packet type, i.e. any of: BTFTPWriteRequest (OPCODE = 0), BTFTPData (OPCODE = 1), BTFTPNak (OPCODE = 2) or BTFTPWriteRequestExtension (OPCODE = 3);

BlockNumber is the packet counter in the protocol, and is used to enumerate the packet of the same type, starting from value ' 1';

BlockSize is the size of the current packet in bytes; there is no restriction in the use of this field, but it is preferable to use a constant value for BlockSize for the BTFTPData packets in each file transmission;

FutureUse is a 5-bit field for future use;

LastPacketFlag is only used with OPCODE = 1 (BTFTPData), and value 1 shows that this is the last packet of a file being transmitted. If OPCODE is not BTFTPData, this field is ignored;

RedundancyFlags comprises 2 bits specifying the type of redundancy in the BTFTP packet;

Checksum is a 32-bit field containing the sum of all the bits in the packet, without carry;

CRC32 is a 32-bit containing the CRC that has been calculated for this packet, the CRC being calculated according to the specification of the MPEG2 system, as described in "ISO/IEC 13818 Specification";

Ignored shows that these 32 bits should be ignored by the decoding procedure if RedundancyFlags=00.

As stated above, if OPCODE = 0, the BTFTPPacket assumes the meaning of an announcement of the start of a file transmission. Accordingly, the packet, after RedundancyFlags, comprises a WriteRequest portion, in which all the information concerning the file and the transmission is contained. This information is encapsulated in a format TLV (Type Length Value), which is described below in detail. For each file transmission (having the same TID), only one WriteRequest packet exists: if the packet is insufficient for encapsulating all the file information, or if its necessary to transmit supplementary descriptive information, this is done by using the BTFTP WriteRequestExtension packet.

The format of section BTFTPWriteRequestQ of BTFTP Packet Q is:

BTFTPWriteRequestQ Length in bits (big endian notation)

{

TotalBlockNumberWRE; 32 TotalBlockNumberData; 32

TLV0; } where

TotalBlockNumberWRE informs the receiver of the total number of blocks in the Write Request Extension packets; if the value is 0, there is no Extension packet, otherwise the value tells how many Write Request Extension packets the receiver has to read in order to reconstruct the descripton of the entire data.

TotalBlockNumberData shows the number of packets containing file data; the value specifies how many BTFTPData the receiver has to read in order to reconstruct the transmitted file;

TLVQ contains the description of the data as a sequential list of triads of fields. In each triad, the first field (Type), 1-byte long, represents the data type, the second field (Length), comprising a fixed number of bytes for each type, shows the length of the first field, and the third field (Value) contains the information.

For each Type the following convention holds:

Type = 0: both the Length and the Value fields are missing. This Type signals to the decoder that the TLV list is terminated. It is required at the end of all TLV lists, even when they are empty.

Type = 1 : Length Length = 2 bytes. The Value field contains the name of the file to be transmitted. The file name is coded in standard 8-bit ASCII code. The presence of a TLV value of this type is required in a packet with OPCODE = 0 (packet of type BTFTPWriteRequest).

Type = 2: Length Length = 2 bytes. The Value field contains the type of the file to be transmitted (per es. gzip, text, html, png...). The file type is coded in standard 8- bit ASCII code. This TLV is optional.

Type = 3: Length Length = 2 bytes. The Value field contains useful file information, e.g. an ASCII string describing the file. This TLV also is optional.

Type = 4: Length Length = 2 bytes. The Value field contains a command file, to be executed on a local machine. It must be a text file.

Type = 128: Length Length = 2 bytes. The Value field contains a Nak list, i.e. a list of ranges of packets to be transmitted. Each item is 9 octets long. The format of the list is:

<OPCODE, 1 byte><Block number of the first packet, 4 bytes> <Number of packets, 4 bytes> <OPCODE><B\oc number of the first packetxNumber of ρackets> ...

Other possible values of the Type field are reserved for future use.

The TLV list terminates with a TLV of type O'.

When OPCODE = 1, the BTFTPPacket assumes the connotation of BTFTPData, whose Payload transports a portion of the file to be transmitted. The format of the section BTFTPDataQ of ^'the BTFTPPacket 0 is as follows:

BTFTPDataQ

{

TLVQ; Payload; } where

TLVQ has the same meaning already stated above.

Payload contains a portion of the transmitted file, and its size depends on the value of the BlockSize value and on the length of the preceding TL V list.

If OPCODE = 2, the BTFTPPacket assumes the connotation of BTFTPNak. This type of packet is only used in association with the return channel, over which the BTFTPNak packets, containing a request for the lost packets, are sent by the receiver to the transmitter.

The format of section BTFTPNakQ of the BTFTPPacketQ is as follows :

BTFTPNakQ

{

TLVQ;

} Finally, if OPCODE = 3, BTFTPPacket assumes the connotation of a BTFTPWriteRequestExtension. This type of packet is optional and is only used if the single BTFTPWriteRequest packet is not sufficient for the transport of the full fϊle description and of the transmission.

The format of section BTFTPWriteRequestExtensionQ of ^'the BTFTPPacketQ is:

BTFTPWriteRequestExtensionQ

{ TLVO;

} where

TLVQ has the same meaning already stated above.

In a transmission made without a return channel, the procedure develops as follows. The Receiver begins to listen on a channel (address and port). The Transmitter begins to transmit a file:

Transmitter Receiver

BTFTPWriteRequest Receives BTFTPWriteRequest, checks CRC32

BTFTPData Receives BTFTPData, checks CRC32 and the sequential number of the packet.

If the packet is out of sequence, sets a timeout for the preceding packets. If the packet is in sequence, but CRC32 is wrong: discards that TID. If the timeout is reached for that TID: discards the TID. The packet is in sequence, and CRC32 is correct: continues until the last packet is correctly received.

In the case of a transmission with a return channel, the Receiver again begins to listen on a channel (address and port), and in this case there is a return channel, which can be a low-bit-rate channel. The Transmitter begins to transmit a file:

Transmitter Receiver

BTFTPWriteRequest Receives BTFTPWriteRequest, checks CRC32

If the packet is out of sequence, sets a timeout for the preceding packets. If the packet is in sequence, but CRC32 is wrong: discards that TID. Periodically send a BTFTPNak packet for requesting lost or corrupted packets.

If the timeout is reached for that TID: discards the TID.

The packet is in sequence, and CRC32 is correct: continues until the last packet is correctly received. It should be evident that the preferred embodiments disclosed above are suceptible of changes and modifications in non-essential aspects, without exceeding the scope of the invention: more particolarly, as a way of example, the fields as defined above could have different lengths, or could be arranged in a different order, or some of the non-essential fields, such as FutureUse or RedundancyFlags, could be dis- pensed with.

Claims

1. A method for the transmission of files over a digital channel, characterized in that the transmitter sequentially sends to the receiver, through said broadcasting digital channel, a set of packets, each having a common header comprising:

a field identifying a file to be transmitted (TID);

an operative code identifying the nature of the packet (OPCODE),

a field bearing the serial number of the packet (BlockNumber),

a field containing the size of the packet (BlockSize),

a field denoting whether the packet is the last one in the current transmission (LastPacketFlag),

an error detection-and/or-correction field (Checksum, CRC32);

in that the first transmitted packet is a start-of-transmission packet (BTFTPWriteRequest), which can be identified from a first setting of the operative code (OPCODE) and comprising, in addition to said header:

a packet-number field, indicating the number of packets containing data in the file (TotalBlockNumberData), and

a sequential list (TLV) of fields containing a description of the data;

and in that the successive transmitted packets are packets of file data (BTFTPData), which can be identified from a second setting of the operative code (OPCODE), the number of packets of file data being equal to the number shown in the packet- number field (TotalBlockNumberData), each packet of file data comprising, in addition to said common header:

a sequential list (TLV) of fields containing a description of the data, and

a field (Payload) containing a portion of the file data.

2. A method for the transmission of files according to claim 1, characterized in that said sequential list (TLV) comprises a sequence of triads of fields, each comprising in succession:

a typing field (Type) showing a selected type of information in a range of predetermined types,

a length field (Length) showing a length of data to be transmitted in relation to the typing field in the same triad, and

a value field (Value) containing a desired piece of information of the type shown in the typing field within the same triad, and of a length as shown in the length field within the same triad.

3. A method for the transmission of files according to claim 2, characterized in that the last typing field (Type) in the sequential list contains the value 0, and that no further length field or data field follows it.

4. A method for the transmission of files according to any of claims 1 to 3, charac- terized in that the transmitter, if necessary, also sends to the receiver, after the start- of-transmission field and before the data packets, one or more extension fields,

in that each of the extension fields can be identified from a third setting of the operative code (OPCODE), and that it comprises, in addition to the common header, a sequential list (TLV) of fields containing the description of the data;

and in that the common header comprises a further extension-number field (TotalBlockNumberWRE), which contains, in the start-of-transmission packet, the total number of blocks of extension packets, while it has no meaning in the other packets.

5. A method for the transmission of files according to any of claims 1 to 4, charac- terized in that the receiver, if it receives any non-sequential packets, after a predetermined time, sends to the transmitter, through a return channel, a lost-packet request packet (BTFTPNak), containing an indication of the serial numbers of the data packets that are missing in the sequence.

6. A method for the transmission of files according to claim 5, characterized in that the receiver also includes in said request packet (BTFTPNak) the serial numbers of any packets that were not correctly received.

7. A method for the transmission of files according to claim 5 or 6, characterized in that said lost-packet request packet can be identified from a fourth setting of the operative code (OPCODE), and in that it comprises a header having an identical format to said common header and a list of serial numbers of the packets that were not received or that were incorrectly received (TLV).

8. A method for the transmission of files according to any of claims 1 to 7, charac- terized in that the common header further comprises a field showing the nature of the method used to build the field of error detection and/or correction

(RedundancyFlags) .

9. A method for the transmission of files according to any of claims 1 to 8, characterized in that said common header further comprises a field reserved for future use (FutureUse).