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

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

Info

Publication number
WO2001086905A2
WO2001086905A2 PCT/IB2001/000783 IB0100783W WO0186905A2 WO 2001086905 A2 WO2001086905 A2 WO 2001086905A2 IB 0100783 W IB0100783 W IB 0100783W WO 0186905 A2 WO0186905 A2 WO 0186905A2
Authority
WO
WIPO (PCT)
Prior art keywords
field
packet
transmission
packets
data
Prior art date
Application number
PCT/IB2001/000783
Other languages
French (fr)
Other versions
WO2001086905A3 (en
Inventor
Paolo Casagranda
Luca Vignaroli
Original Assignee
Rai Radiotelevisione Italiana S.P.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rai Radiotelevisione Italiana S.P.A. filed Critical Rai Radiotelevisione Italiana S.P.A.
Publication of WO2001086905A2 publication Critical patent/WO2001086905A2/en
Publication of WO2001086905A3 publication Critical patent/WO2001086905A3/en

Links

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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
    • 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

  • 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.
  • 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).
  • 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]).
  • 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.
  • BTFTP broadcast Trivial File Transfer Protocol
  • BTFTPWriteRequest a packet of Broadcast Trivial File Transfer Protocol
  • BTFTPData a packet of data packets
  • 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.
  • FEC Forward Error Correction
  • 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.
  • a return channel 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.
  • the protocol will have its best implementation with reference to the User Datagram Protocol (UDP), although other datagram-based protocols should not be excluded.
  • UDP User Datagram Protocol
  • the protocol can be encapsulated in the transport flow of Digital Video Broadcasting (Multi-Protocol Encapsulation Profile [IS013818]) and transmitted through broadcasting channels.
  • BTFTPPacket a basic data packet
  • OPCODE an operative code
  • 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;
  • Transmission Identifier Transmission Identifier
  • 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
  • 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";
  • 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.
  • TLV Type Length Value
  • 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.
  • 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
  • the third field (Value) contains the information.
  • 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.
  • the Value field contains the name of the file to be transmitted.
  • the file name is coded in standard 8-bit ASCII code.
  • 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.
  • the Value field contains useful file information, e.g. an ASCII string describing the file. This TLV also is optional.
  • the Value field contains a command file, to be executed on a local machine. It must be a text file.
  • 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:
  • the TLV list terminates with a TLV of type O'.
  • 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:
  • 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.
  • 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.
  • section BTFTPNakQ of the BTFTPPacketQ is as follows :
  • 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.
  • TLVQ has the same meaning already stated above.
  • the Receiver begins to listen on a channel (address and port).
  • the Transmitter begins to transmit a file:
  • BTFTPData Receives BTFTPData, checks CRC32 and the sequential number of the packet.
  • 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.
  • 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:
  • BTFTPData Receives BTFTPData, checks CRC32 and the sequential number of the packet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

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
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. 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).
PCT/IB2001/000783 2000-05-12 2001-05-08 A method for the transmission of files over a digital channel, particularly over a dvb broadcasting channel, and a protocol for its implementation WO2001086905A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IT2000TO000439A IT1320347B1 (en) 2000-05-12 2000-05-12 PROCEDURE FOR TRANSMITTING FILES ON DIGITAL CHANNEL, PARTICULARLY ON DIFFUSIVE DVB STANDARD CHANNEL, AND PROTOCOL FOR
ITTO2000A000439 2000-05-12

Publications (2)

Publication Number Publication Date
WO2001086905A2 true WO2001086905A2 (en) 2001-11-15
WO2001086905A3 WO2001086905A3 (en) 2002-03-21

Family

ID=11457719

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2001/000783 WO2001086905A2 (en) 2000-05-12 2001-05-08 A method for the transmission of files over a digital channel, particularly over a dvb broadcasting channel, and a protocol for its implementation

Country Status (2)

Country Link
IT (1) IT1320347B1 (en)
WO (1) WO2001086905A2 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1343099A2 (en) * 2002-03-06 2003-09-10 APE Ptacek Engineering GmbH Communication system for databases
WO2004084475A1 (en) * 2003-03-18 2004-09-30 Nokia Corporation Method, system and network entity for data transmission and reception with header protection
KR100711273B1 (en) * 2005-09-15 2007-04-25 노키아 코포레이션 Method, system and network entity for data transmission and reception with header protection
US7865610B2 (en) 2007-03-12 2011-01-04 Nautel Limited Point to multipoint reliable protocol for synchronous streaming data in a lossy IP network

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0838929A1 (en) * 1996-10-28 1998-04-29 Nextlevel Systems, Inc. Broadband-augmented computer communication system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0838929A1 (en) * 1996-10-28 1998-04-29 Nextlevel Systems, Inc. Broadband-augmented computer communication system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
J. POSTEL: "User Datagram Protocol UDP - RFC 768" IETF REQUEST FOR COMMENTS - RFC 768, [Online] 28 August 1980 (1980-08-28), pages 1-3, XP002173872 Retrieved from the Internet: <URL:http://www.rfc-editor.org/rfc/rfc768. txt> [retrieved on 2001-08-02] *
K. SOLLINS: "The TFTP Protocol (Revision 2) - RFC 1350" IETF REQUEST FOR COMMENTS - RFC 1350, [Online] July 1992 (1992-07), pages 1-11, XP002173871 Retrieved from the Internet: <URL:http://www.rfc-editor.org/rfc/rfc1350 .txt> [retrieved on 2001-08-02] cited in the application *
LADEBUSCH U: "Introduction to data broadcasting over the DVB system" FERNSEH UND KINOTECHNIK,DE,VDE VERLAG GMBH. BERLIN, vol. 52, no. 6, June 1998 (1998-06), pages 323-324,326-330, XP002108594 ISSN: 0015-0142 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1343099A2 (en) * 2002-03-06 2003-09-10 APE Ptacek Engineering GmbH Communication system for databases
EP1343099A3 (en) * 2002-03-06 2004-04-14 APE Ptacek Engineering GmbH Communication system for databases
WO2004084475A1 (en) * 2003-03-18 2004-09-30 Nokia Corporation Method, system and network entity for data transmission and reception with header protection
KR100711273B1 (en) * 2005-09-15 2007-04-25 노키아 코포레이션 Method, system and network entity for data transmission and reception with header protection
US7865610B2 (en) 2007-03-12 2011-01-04 Nautel Limited Point to multipoint reliable protocol for synchronous streaming data in a lossy IP network

Also Published As

Publication number Publication date
ITTO20000439A0 (en) 2000-05-12
ITTO20000439A1 (en) 2001-11-12
IT1320347B1 (en) 2003-11-26
WO2001086905A3 (en) 2002-03-21

Similar Documents

Publication Publication Date Title
US8478896B2 (en) Data packet encapsulation methods
US7506235B2 (en) Error correction apparatus and method
JP3999273B2 (en) Sending computer network data as part of a vertical blanking period
US7058043B2 (en) Multi-packet transport structure and method for sending network data over satellite network
KR101419287B1 (en) Apparatus and method for providing IPDC service and apparatus and method for processing IPDC service
Fairhurst et al. Unidirectional lightweight encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 transport stream (TS)
US6608841B1 (en) System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US7451235B2 (en) Dynamic delta encoding for cable modem header suppression
US7496821B2 (en) Data transmission system
US20070277209A1 (en) Robust transmission system and method for mobile television applications
WO2006003531A1 (en) Forward error correction decoders
EP1816767A2 (en) Method for transmitting/receiving data in a digital multimedia broadcasting system, and system thereof
WO2001086905A2 (en) A method for the transmission of files over a digital channel, particularly over a dvb broadcasting channel, and a protocol for its implementation
KR20080009766A (en) Method and apparatus for operating a receiver including forward error correction
Gardikis Transport and Time-Slicing Mechanisms in Multistandards for Mobile Broadcasting
Collini-Nocker et al. Ultra Lightweight Encapsulation for Efficient IPv6 Transport
Aghaei Nia et al. Mapping with cell addressing of train transport MPEG-2 over ATM cells via AAL-5
ENGINEERS PAL/SECAM IP and Trigger Binding to VBI
JP2005130277A (en) Device and method for error correction

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP