FI98676C - Transfer of a file group in a digital broadcast radio system - Google Patents

Description

98676

This invention relates to file transfer in a digital broadcasting system that allows audio and data services to be transmitted and selectively received by these services.

In the digital audio system DAB (Digital 10 Audio Broadcasting) developed for efficient use of frequency bands, the transmission path is completely digital. The system is intended to replace the current commonly used analog broadcasting using frequency modulation. DAB defines a multi-carrier digital radio channel suitable for transmitting both audio-15 and data services. A fully digital transmission channel can be either a continuous data stream or a packet channel. Packet forwarding is more flexible and makes it easier to send data units of finite length. The DAB system is described in ETSI (European Te-20 lecommunication Standards Institute) standard 300 401, February, 1995.

From the user's point of view, the DAB system has the highest level of abstraction called ensemble, Figure 1. It contains all the services that are in a given single frequency band-25 la. The change of ensemble takes place by tuning to another frequency band, just like channel selection in the current FM radio reception. The ensemble is divided into services, in the figure Alpha Radio 1, Beta Radio and Alpha Radio 2 as an example. In addition, there may be data services, although they are not shown in the figure. Each service is further divided into service components. Each service component is either an audio channel or a data channel. For comparison, the FM radio has only one service and one service component (audio / voice) on each channel. At the lowest 35 level, the transmission frame, which has a duration of either 98 ms or 96 ms depending on the DAB mode 2 98 676, consists of three parts that are consecutive in time. The first is a synchronization channel that does not contain service information. Next is the Fast Information Channel (FIC), which is a fixed length for each mode. The last is the MSC (Main Service Channel) which contains all the subchannels. The location, size, and number of subchannels within the MSC may vary, but the size of the MSC is fixed. The MSC contains up to 63 different audio 10 and / or data subchannels. The subchannels are numbered so-called. based on sub-Channel Id from 0 to 62. In addition, the MSC may have an Auxiliary Information Channel (AIC) with a fixed channel number 63. The AIC may contain the same type of information as the FIC. One of the advantages of the DAB system is that data capacity can be allocated to service providers dynamically. At the moment, the capacity can be up to 1,728 Mbit / s. In this case, the data is transmitted in packets according to Fig. 2A, which consist of a hea-20 der field, a data field and a checksum. The meanings of the fields described are in accordance with the DAB standard. The Packet Header contains information about the length of the packet (Pkt Len), which can be 24, 48, 72 or 96 bytes, Continuity Index (Cont Ind), First / Last Packet Information (First / Last), Service Comm. - the component identification address (Pkt Address), the command (Command) and the actual data field length (Data Len). The data field contains the actual data to be transmitted and, if necessary, padding bits. Finally comes the pa-30 chain checksum (Pkt CRC).

The data fields of the packets form the so-called data grou-pin, Figure 2 B. Packets are formed from a DataGroup by simply breaking it into parts and placing each part in the data field of the data packet. In general, the data group 35 consists of the data fields of several packets to be transmitted in succession. At its simplest, one packet is enough to form a data group.

The data group is formed according to Figure 3. The meaning of the abbreviations in the Data Group header and Session header fields is as shown in the table below:

Data Group header Session header EXT FL extension flag LAST FL last CRC FL CRC flag SEG NUM segment number 10 SES FL session flags RFA reserved for future applications DG TYPE data group type LEN IND length of next address field CONT IND continuity index ADDR FIELD end user address REP IND repetition index EXT FIELD extension field 15 These header fields are followed by the actual data as well as the data group checksum DG CRC.

The DAB system enables the transmission of multimedia and hy-Permedia type services to 20 mobile users. In this case, at least some of the files related to the multimedia service must be stored in the receiver's memory, from where they are downloaded for playback as part of a multimedia program when a certain trigger condition is met.

25 If an audio or data stream is received, it is sufficient for the DAB receiver to simply switch to this channel and start receiving power immediately. More problematic is when receiving a file or files, that is, how the receiver is able to distinguish the correct file and operate as required by the file format. Because DAB is a one-way broadcast system, the system administrator must send all the file processing information required by the receiver. The problem is particularly pronounced in the transfer of multimedia and hyper-media services. This application specifically addresses the transfer of an HTML (Hypertext Markup Language) - 98676 4 file and the transfer of an MHEG (Multimedia Hypermedia information coding Experts Group) file.

The problem of file transfer has been proposed by the Eureka-147 project to be solved according to the following general basic principle. The file is divided into smaller units called segments. Each segment forms one Data Group. The successive segments of the file are numbered sequentially so that the number of the first segment in the Session-on header is 0. The last segment of the Tie-10 file is indicated in the session header of the data group formed from it by the LAST field flag.

The data groups are then formed into data packets in the usual way. The receiver receives the data packets and forms Data groups from them. If its checksum-15 ma indicates that bit errors have occurred in the transmission, the receiver extracts the data packets of the relevant Data Group from the file's new transmission.

In order for the receiver to be able to extract the correct files from the transmitted packet stream and to know the type of file in mind for file processing, the following mechanism has been proposed. In addition to data groups, the data field of which is thus placed in the file data, i.e. segment, a special information data group IDG (Information Data Group) is also formed. It 25 is a file transfer descriptor, i.e. it provides the necessary information about the file to which it refers and is multiplexed with the file segments.

One IDG is associated with only one file. It is placed at least first in the packet stream associated with the file, i.e. at the beginning of the file transfer, but may also be in the middle of the packet stream, i.e. the IDG may occur during the file transfer or the IDG may be sent some time before the actual file transfer.

Certain values of the IDG data group header and session header 35 fields are reported from the file. On 98676 5 it has been suggested that the data group type DG TYPE (Figure 3) 0011 be the IDG identifier. In the session header, the length indicator Len Ind is the same as the file length pointer and the address field Addr. The field is the same as the file address-5 field. The important thing that can be done with IDG is included in its data field, hereinafter referred to as file descriptor. The file description can be used to inform the receiver in detail of the necessary information about the file to be transferred.

File description, i.e. The structure of the Information DataGroup's IDG data field has been proposed to take into account the layered nature of the OSI model, ie whether the parameters are related to the application layer (application 15 oriented) or the transmission layer (transmission oriented).

Accordingly, three types of file descriptions can be distinguished, Figures 4a-4b. Figure 4a shows an IDG-T (IDG-Transport) file description containing transfer parameters (T parameters). The field T-para-20 m (Length of T-param.) At the beginning of it indicates the total length in bytes of the parameter fields included in the file description. The incoming field then contains only zeros, so the receiver immediately knows that it is IDG-T. This is followed by several consecutive parameter-25 fields. Each parameter field is associated with a unique description value of the parameter preceding it, which comprises a parameter indicator PI and a parameter length indicator LI. The parameter indicator PI is mandatory and may contain information to be provided later. The longest-30 indicator LI can be omitted if the parameter length is constant.

Figure 4b illustrates a file description IDG-A (IDG-Application) with application level parameters. Here, the first field contains all zeros, so the receiver-35 knew the IDG containing the application-level parameters 98676e in question. In the second field, the length of the A-parameter (Lenght of A-param.) Indicates the total length in bytes of the parameter fields included in the file description. The remainder of the structure with its parameter fields and the preceding 5 PI and LI fields is similar to that described in connection with Figure 4A.

Figure 4c shows the IDG-C (IDG-Combined) file description. The first field indicates the common length of the T-parameter fields (Length of T-parame-10 ters) and the second the common length of the A-parameter fields (Length of A-parameters), respectively. This is followed by the T-parameter fields all in sequence and then the A-parameter fields all in sequence.

The parameters are grouped into A or T parameters 15 according to their meaning. The T parameters contain the information needed to route the file through the DAB system. These include the path where the file is stored, the transmission channel, etc. The A parameters include all the information that is not necessary for processing the file and that comes from the user or application, i.e., information about synchronization, compression, names, and so on.

The table in Figure 5a shows the possible T parameters and the table in Figure 5b the A parameters, as well as a brief description of the 25 parameters. As an example, the A-parameter compression mode indicates whether the file is ZIP, JPEG, RLE, MPEG, or Musicam encoded. An example of a T parameter is a file type that indicates whether the file is ASCII, HTML, binary data JFIF (JPEG), or some other 30 files.

With the aid of the IDG elements described in detail above, it is possible for the receiver to extract from the incoming packet stream those packets which form the desired file. The IDG element indicates where the data groupeis-35 sa segments of the file are and will be retransmitted, etc. By sending the IDG long before the actual file is sent, the receiver has time to decide whether or not to receive the file. By sending IDGs every now and then between the data groups carrying the file segments 5 themselves, the receiver can start reception in the middle of the file, receive the end of the file and in retransmission receive the missing first part. This saves time.

The parameters 10 relevant to the present invention are grouping of files, Integrity of a group, and file type. In the list in the table of Figure 5b, the second A parameter, grouping of files, is important because it can be used to inform the receiver of the different files that belong to the same group. Such files can be, for example, file components belonging to the same computer program. This parameter can also be used to group files in order to inform the receiver of a file hierarchy, e.g. ha-20 directory structure. The same file grouping parameter is associated with the Information data Group of each file that belongs to the same group. The parameter itself is an identifier that gives a group name to all files in the same group. A certain value of the PI (Parameter Indicator) preceding the parameter indicates that the next parameter is a file grouping parameter.

The third A parameter in Table 5b, Integrity of group, is a file attribute for which two values have been proposed by EU-147. The first proposed value of 0 indicates that the file to which the IDG refers (i.e., either the file currently being sent, the next file to be sent, or the file to be sent after the number of files indicated in the reference) is not the last file in the group.

98676 8

The receiver then knows that files from the same group are still coming in and thus knows how to work in the right way.

After all, the implementation of a file that has already been received may require the receipt of an upcoming file. The second value of the Atri-5 boot, the value 1 in the proposal, indicates that the file to which the IDG refers is the last in the group. After twinkling the attribute, the receiver knows that after receiving the referenced file, all the files in the group have been sent. This A parameter is, of course, preceded by a predetermined PI value of 10, from which the receiver recognizes that it is an Integrity of group parameter.

The file type value of the T parameter indicates the type of file referenced in the IDG. At least the following 15 file types are defined, in brackets the type abbreviation: text file (ASCII), World Wide Web (HTML), JPEG image compression (JFIF), computer graphics (GIF), encoded image sequence (RLE), audio compression (MPEG), video compression (MPEG), a data stream synchronization file, and 20 Multimedia Object (MHEG). This parameter is also preceded by a specified PI value.

In principle, the proposed mechanisms solve the problem of how to transfer multi-component multimedia services in a DAB system. Components are transferred in data groups as files and groups of files. All the information needed in the receiver for file management and processing is transferred in the data groups IDG containing the information.

In contrast, the proposed mechanisms do not solve the 30 problem of how to speed up the time it takes for a receiver to receive all the files in a file group. The problem is that these two group integrity parameter values do not give the receiver enough information to conclude that all the files in group 35 have been received and what is the first file in the group 98676 9: if the receiver starts receiving files between files then parameter 1 of the last file indicates that the last file has been received. In this case, the receiver knows that after this file with para-5 meter 1, the first file received from the retransmission is the first file in the group. The receiver receives and stores files from this file until a file with a trailing mark, or para-10 meter 1, is received from the retransmission. Now the receiver has found out the whole file group and the order of the files. This can mark the recipients of the entire group file twice to determine its integrity.

15 Another problem is that, using the proposed mechanisms, the receiver must first receive the entire group of files before launching the application. In this case, the receiver must have a high-capacity memory, such as a hard disk. However, in many applications 20, not all files in a group are needed immediately or not at all, but files are downloaded as needed. In many applications, such as multimedia applications, the receiver must first download the startup file from which the application is launched. The startup file may not be a startup file, but may contain a reference to the actual startup file, or the startup file may contain a list of files in the group that are required to perform a particular function. An example of a start file is the start page of an HTML-30 file. The other files required will be selected according to the hyperlinks that the user activates, and in this sense the number and type of files required are random. The files needed to start the program thus appear only in the 35 start files themselves. It would thus be advantageous to receive only the start file and other files in the group only as needed. However, with the current mechanisms it is not possible to pass information about the startup file. 5 As a solution to the problem, it has been suggested that the file type parameter be used to indicate the startup file, eg the HTML home page. This parameter is used in the sense of "file content classification" and is thus quite different in nature from the "initial file". In the case of an HTML file where the start page is the home page, the file type parameter should be both "startup" and "HTML" at the same time, which is impossible.

The present invention provides a way to both speed up the reception of a group of files and to notify the receiver of an initial file.

The invention is characterized by what is stated in claim 1.

According to the invention, new values are proposed for the Integrity of files parameter of the tie-20 file. There are four different values. The first value indicates that the file referenced in the IDG is an intermediate file of the file group to be transferred, i.e. one of the files between the first and last file. The second value indicates that the file to be transferred is the first file of the file group. The third value indicates that the file to be transferred is the last file in the file group. The fourth value indicates that the file to be transferred belongs to a file group and 30 indicates that it is an initial file.

When group information is to be transmitted, the first, second and third parameters are used, i.e. the IDGN "group unity" parameter associated with the file can only have one of these parameter values. These ar-35 vot are fully sufficient to convey group information. Because the first file in group 98676 is named, the receiver does not need to receive the entire retransmission. This will solve the first problem. The integrity of the group is checked by the DAB transfer mechanism.

5 To pass the start file, the fourth parameter value is used. The start file is a group of files that contains only one file, so the parameter indicating the first, intermediate, and last files is not required. In this way, another problem can be solved. The group integrity check has been transferred from the DAB transfer mechanism to the application program.

The invention will now be described in more detail with reference to the accompanying drawings, in which: Figure 1 shows a known DAB hierarchy, Figure 2a shows the structure of DAB packets, Figure 2b shows a data group of packets, Figure 3 shows a data group structure, Figure 4a shows an IDG-T file description, Fig. 4b illustrates an IDG-A file description, Fig. 4c illustrates an IDG-C file description, Fig. 5a is a table of T parameters, Fig. 5b is a table of A parameters, and Figs. 6a and 6b show an IDG-T file-25 description using the invention. parameters.

If the first parameter field "file de-30 scriptor offset" of the transmitted IDG-T (not shown) is zero, then the IDG contains information related to the files just being transmitted (viewed from the receiver). If the parameter is 1, then the IDG contains the information of the file to be sent next, etc. In the parameter field, the file name 35 (file name) is given in the file description transfer. These and possibly other IDG-T fields allow the receiver to start receiving the file (s). This is known per se.

5 In IDG-A, Fig. 6a is a parameter field grouping of files. A specific PI field preceding it indicates that the next parameter field below is exactly a group of files. The incoming parameter field then has an identifier that uniquely identifies the file group, i.e., each file group has its own identifier. Based on the information in these fields, the receiver's application program begins to compile the files belonging to the file group under shared management. In the file integrity check, the parameter field Integrity of group, known per se, is used, but with the parameter value meanings according to the invention, which are shown in Figure 6a. The parameter can have four different values, and the possible values depend on whether the files in the storage group of the receiver 20 are desired in their entirety and in a given order, in which case the receiver's firmware performs a consistency check or allows the receiver's application software to decide which files to receive. The 25 created application program performs a consistency check.

If you want to transfer the entire file group to the receiver, use the first, second and third parameter values as follows:

The first value, which can be denoted by 0, 30, indicates that the file referenced in the IDG is an intermediate file of the file group to be transferred, i.e. a file belonging to the first and last file.

The second value, which can be denoted by 1, il-35 indicates that the file to be transferred is the first file in file group 13 98676.

The third value, which can be denoted by 2, indicates that the file to be transferred is a file. the last file in the group.

5 Thus, when the receiver starts receiving group files, the group in the middle first receives files with a parameter value of 0, i.e. the first value. In this case, it knows the intermediate files of the group in question. Files are stored in memory as they are received. Finally, there is a file with parameter 2, i.e. the third value, so that the receiver knows the last file in the group in question, which is also stored. The receiver then waits for the group to retransmit by examining future Information-data groups.

15 One of them indicates the relative start time of the beginning of the retransmission, at which the receiver starts receiving the files. The first received file may not have a group integrity parameter, so only the file that has this parameter and the additional parameter is 1, i.e., the second value indicating that the file is the first file in the desired group, is stored in memory. After that, intermediate files are received, i.e. files with a parameter value of 0, until the file that has already been received is reached. In this way, the entire file group can be received by first receiving the rest of it and from retransmission by receiving the missing beginning and the file download order will be correct.

If the receiver's application program (ap-30 plication software) is to decide which files it receives, in which case the application program performs a integrity check, a fourth value is used for the integrity parameter, which can be denoted by 3. It indicates that the file to be transferred belongs to file group 35. multimedia program) start file. Only one file in a file group can have a parameter value of 3, i.e. only one file is a start file. The other files in the group must not have an Integrity of group parameter at all, i.e.

5 when parameter value 3 is used in the group then parameters 0,1 and 2 are not used.

Because this startup file contains unity information and information about the order in which the files are to be downloaded, it must always be downloaded before the other files in group 10. This is especially so because the IDG-T parameter grouping of files does not necessarily contain information that would define the file group. This information is only included in the startup file itself and is thus beyond the reach of the firmware of the receiver.

15 For example, the IDG may specify a group unity parameter of 3 (start file) and the file type parameter is an HTML file. In this case, the financial file in question is known to be the home page in hypertext, which consists of 20 groups of files comprising several files. Typically for hypertext, the start file, i.e. the home page, can contain hyperlinks that can refer either to the same file or to other files in the group. If a hyperlink to another file in the group is activated, the referenced file must be downloaded.

25 The file has not been received and stored in memory but is only now being received from the DAB subchannel. This file may still contain hyperlinks to other files that must also be downloaded when activated. The application program that interacts with the user receiving the DAB program 30 and retrieves the files is the DAB HTML browser. The browser works in the same way as the browser used to connect to the Internet.

Similarly, if the IDG reports a value of 3 (start file) as the group integrity-35 parameter and the file type parameter is MHEG file O / then it is known that the file is the startup container of the MHEG multimedia presentation. When the application program, the so-called. The MHEG machine, »has loaded this start container, can, under the control of the MHEG machine 5, receive from the DAB channel and download other MHEG objects and data files.

Finally, it should be noted that if the IDG-A has a group unity parameter (the parameter may not exist) and has a value indicating the first file, the intermediate file 10 or the last file, i.e. a value of 2, 0 or 1, then in the same IDG-A: must also have a grouping of files parameter. But if the file group parameter is present in IDG-A, then the group unity parameter is optional: .this means that when the 15 group unity parameter is either a start file, a stop file, or an intermediate file (i.e., a non-start file), it already contains in itself the knowledge that it is a group. However, the integrity parameter "start file" does not provide this information. The presence of a "file group" of para-20 meters, on the other hand, does not in itself contain information that the parameter "group integrity" is set to IDG-A.

The presented mechanism for determining the group start file so that it can be easily found by the receiver application program 25 is particularly well suited in connection with the patent application "Processing a file file in a digital broadcasting system" filed simultaneously with this application, application number FI-XXXXX.

It will be apparent to those skilled in the art that as technology advances, the basic idea of the invention may be implemented in many different ways. The invention and its embodiments are thus not limited to the examples described above but may vary within the scope of the claims.

Claims (7)

98676 16 A method for transferring files in a digital broadcasting system, wherein the file 5 is segmented and each segment is placed in a data group (DG) data field and the data group is divided for transfer into parts placed in data packet data fields, at least one information parameter is formed and transferred for each file. a data group (IDG), one of the parameters of which contains information on which files form a file group, characterized in that if the receiver receives the whole file group, a number is added to each file information data group (IDG) as a integrity parameter, the first value indicating which the file is between the first and last file. the second value indicates that file is the first file in the group and the third value indicates that file is the last file in the group if, if the receiver receives only one special file from the file group, the unity parameter is the fourth value of the number in the information data group (IDG) of this file, and no other unity parameter is added to the other files in the group. A method according to claim 1, characterized in that the special file is a file group start-up file containing references to other files. A method according to claim 2, characterized in that other files in the group are received at the receiver according to this information contained in the boot file. 98676 17 A method according to claim 1, characterized in that the group of files to be transferred is a multimedia program and the specific file is the home page of the multimedia. A method according to claim 4, characterized in that the other file of the file group is received after the user has activated the hyperlink on the home page, wherein the hyperlink contains an indication of the file to be received. A method according to claim 5, characterized in that when the user activates the hyperlink contained in the received other file, the file indicated by it is received. A method according to claim 2, characterized in that the user communicates with the application program and selects the desired files from the boot file, which are then received. 98676 18