WO1997013337A1

WO1997013337A1 - Transfer of a file group in a digital broadcasting system

Info

Publication number: WO1997013337A1
Application number: PCT/FI1996/000524
Authority: WO
Inventors: Ari Salomäki
Original assignee: Oy Nokia Ab
Priority date: 1995-10-05
Filing date: 1996-10-04
Publication date: 1997-04-10
Also published as: FI98676C; AU7133396A; FI98676B; FI954752A0

Abstract

In a digital broadcasting system (DAB), the file to be transmitted is segmented and each segment is placed in the data field of a data group (DG) and the data group is divided into sections for transmission, which are placed in the data fields of data packets. For each file, at least one information data group (IDG) containing information parameters, one of which contains information as to which files constitute a group of files, is formed and transmitted. According to the invention, when the receiver is to receive an entire group of files, an integrity of group parameter consisting of a number is added to the information data group (IDG) associated with each file, a first value of said number indicating that the file in question is a file between the first and last files of the group while a second value indicates that the file is the first file of the group and a third value indicates that the file is the last file of the group. When the receiver is to receive only one special file from a group of files, a fourth value of said number is added as in integrity of group parameter to the information data group (IDG) for this file, whereas no integrity of group parameter is added for the other files in the group. In this way, it is possible to load only the startup file in the receiver while other files are only received as required.

Description

TRANSFER OF A FILE GROUP IN A DIGITAL BROADCASTING SYSTEM

The present invention relates to file transfer in a digital broadcasting system which allows the transmission of audio and data services and selective reception of such services.

In the Digital Audio Broadcasting (DAB) system, which has been developed to allow an efficient utilization of frequency bands, the transmission path is completely digital. The system is designed to replace the analog broadcasting system commonly used at present, which is based on the use of frequency modulation. DAB defmes a digital radio channel based on multiple carriers, which is applicable for the transmis¬ sion of both audio and data services. A completely digital transmission channel may be either a continuous data stream channel or a packet channel. Packet transmission is more flexible and permits easier transmission of data units of a limited length. The DAB system is presented in ETSI (European Telecommunication Standards Institute) standard 300 401 , February, 1995.

From the user's point of view, the highest level of abstraction in the DAB system is called ensemble, Fig. 1. It contains all services existing in a given frequency band. A change from one ensemble to another is effected by tuning into a different frequency band, just as one changes channels in current FM radio reception. The en- semble is divided into services, exemplified in Fig. 1 by Alpha Radio 1, Beta Radio and Alpha Radio 2. 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, let it be stated that FM radio contains only one service and one service component (audio) in each channel. At the lowest level, the transmission frame, whose duration is either 24 ms or 96 ms depending on the DAB mode, consists of three chronologically con¬ secutive parts. The first part is a Synchronizing Channel, which contains no service information. The next part is a Fast Information Channel FIC, which has a mode- specific fixed length. The last part is a Main Service Channel MSC, which contains all the subchannels. The position, size and number of subchannels within the MSC can vary, but the size ofthe MSC is constant. The MSC contains a maximum of 63 differ¬ ent audio and/or data subchannels. The subchannels are numbered on the basis of a so- called Channel Id from 0 to 62. Moreover, the MSC may contain an Auxiliary Infor¬ mation Channel AIC, which has a fixed channel number 63. The AIC may contain the same type of information as the FIC. One ofthe advantages ofthe DAB system is that data capacity can be offered to the service providers on a dynamic basis. The maxi¬ mum instantaneous data capacity is 1.728 Mbit/s. In this case, the data is transmitted in packets according to Fig. 2A, consisting of a header field, a data field and a check¬ sum. The meanings ofthe fields described are in accordance with the DAB standard. The Packet Header contains data giving packet length (Pkt Len), which may be 24, 48, 72 or 96 bytes, a continuity index (Cont Ind), first/last packet data (First/Last), an ad¬ dress (Pkt Address) identifying the service component, the command and the length of the actual data field (Data Len). The Data Field contains the actual data to be transmit¬ ted plus fill characters if required. Finally there is the packet checksum (Pkt CRC).

The data fields ofthe packets form a so-called data group, Fig. 2B. The pack¬ ets are formed from the DataGroup by simply cutting it into sections and placing each section into the data filed ofthe data packet. Generally the data group consists ofthe data fields of a number of consecutive packets transmitted. In the simplest case, one packet is sufficient to form a data group.

The data group is formed as illustrated by Fig. 3. The meanings ofthe data group header and the session header are as indicated in the table below:

Data Group header Session header

EXT FL extension flag LAST FL last

CRC FL CRC flag SEG NUM segment number

SES FL session flags RFA reserved for future applications

DG TYPE data group type LEN IND length of the next address field

CONT IND continuity index ADDR FIELD address of the end user

REP IND repetition index

EXT FIELD extension field

These fields are followed by the actual data and the data group checksum DG

CRC. The DAB system enables the transmission of multimedia and hypermedia type services to mobile users. In this case, at least some ofthe files needed for multimedia service have to be stored in the memory ofthe receiver, from where they are loaded to be presented as part of a multimedia program when a given trigger condition is met. When an audio or data stream is to be received, it suffices that the DAB re¬ ceiver simply switches to this channel and immediately starts to receive the stream. A more difficult situation is encountered when a file or files are to be received; in other words, how is the receiver to distinguish the right file and work in the manner re¬ quired by the file format. Since DAB is a unidirectional broadcasting system, the maintainer ofthe system must transmit all information relating to the handling of files that the receiver requires. This problem is particularly prominent in the transfer of multimedia and hypermedia services. In the present application, especially the transfer of HTML (Hypertext Markup Language) and MHEG (Multimedia Hypermedia in¬ formation coding Experts Group) files is considered. In the Eureka- 147 project, the following general basic principle has been pro¬ posed to solve the file transfer problem. The file is divided into smaller units, called segments. Each segment constitutes one data group. Consecutive segments ofthe file are assigned consecutive segment numbers, the first segment in the Session header being number 0. The last segment ofthe file is indicated with a LAST field flag in the session header ofthe data group formed from it. From the data groups, data packets are then formed in the usual manner. The receiver receives the data packets and forms data groups from them. If its checksum indicates that bit errors occurred during the transfer, the receiver picks up the data packets ofthe relevant data group from the re¬ transmission ofthe file. To enable the receiver to select the correct files from the packet stream transmitted and recognize the file type, the following mechanism has been suggested. In addition to the data groups, whose data field contains data from the file, i.e. a seg¬ ment as explained above, a special Information Data Group IDG is formed. This is a file transfer descriptor, in other words, it gives the necessary information about the file it refers to and it is multiplexed with the file segments. One IDG refers to only one file. It is placed at least at the beginning ofthe packet stream relating to the file, i.e. at the beginning of the file transfer, but IDGs can also be inserted in the midst ofthe packet stream, in other words, an IDG may occur during file transfer or it can be transmitted some time before the actual file transfer.

Certain values ofthe data group header and session header ofthe IDG are used to give information about the file. It has been suggested that data group type DG

5 TYPE (Fig. 3) 0011 should be the identifier of the IDG. In the session header, the length indicator Len Ind is the same as the file length indicator and address field Addr.Field is the same as the address field ofthe file. The important thing the IDG can be used for is included in its data field, subsequently designated as file descriptor. Via the file descriptor, the receiver can be given the required information in detail l o about the file being transferred.

As for the structure ofthe file descriptor, i.e. the data field o the Information Data Group, it has been proposed that it should take into account the layered structure ofthe OSI model, in other words, whether the parameters are application oriented or transmission oriented. Accordingly, three types of file descriptor can be distinguished,

15 Fig. 4a-4b. Fig. 4a presents a file descriptor IDG-T (IDG-Transport) containing transmission parameters (T-parameters). Its first field (Length of T-param.) indicates the total length in bytes ofthe parameter fields contained in the file descriptor. The next field contains only zeros, so the receiver will immediately recognize that an IDG- T is being transmitted. After this, a number of parameter fields are sent in succession.

20 Associated with each parameter field is an individual parameter description value which precedes the parameter field and comprises a parameter indicator PI and a pa¬ rameter length indicator LI. The parameter indicator PI is necessary and it may con¬ tain information as described later on. The length indicator can be omitted if the pa¬ rameter length is constant.

25 Fig. 4b represents a file descriptor IDG-A (IDG-Application) containing appli¬ cation oriented parameters. Here the first field contains only zeros, so the receiver will know that an IDG containing application oriented parameters is being transmitted. In the second field, the length of A-parameter (Length of A-param.) indicates the total length in bytes ofthe parameter fields comprised in the file descriptor. The rest ofthe

30 structure consisting of parameter fields and PI and LI fields preceding them is as de¬ scribed in connection with Fig. 4A. Fig. 4c presents a combined file descriptor IDG-C (IDG-Combined). The first field indicates the total length of T-parameter fields (Length of T-param.) and the sec¬ ond the total length of A-parameter fields (Length of A-param.). After this, all T- parameter fields are sent in succession and then all A-parameter fields in succession. The parameters are grouped as A- or T-parameters according to their mean¬ ings. The T-parameters contain information that is needed for the routing ofthe file through the DAB system. They include the path in which the file is stored, the trans¬ mission channel, etc. The A-parameters contain all the information that is not neces¬ sary for the handling ofthe file but is rather intended for the user or application, i.e. information relating to synchronization, compression, names, etc.

The table in Fig. 5a presents possible T-parameters and the table in Fig 5b possible A-parameters, with a short description of each parameter. For example, A- parameter Compression Mode indicates whether the file is a ZIP, JPEG, RLE, MPEG or a Musicam coded one. As an example of T-parameters, File Type indicates whether the file is an ASCII, HTML, binary data, JFIF (JPEG) file or some other type of file. By means of IDG elements as described in detail in the foregoing, it is possible for the receiver to select from an incoming packet stream those packets which form a given file. The IDG element indicates the data groups containing segments ofthe file and whether they are going to be retransmitted etc. By transmitting the IDG well in advance ofthe file itself, the receiver is allowed time to decide whether to receive the file or not. If the IDG is transmitted every now and then between data groups carrying file segments proper, the receiver will be able to start receiving in midstream of the file transmission, to receive the remaining part ofthe file and then receive the missing first part of it from the retransmission. This saves time. For the present invention, the essential parameters are grouping of files,

"integrity of group", and file type. Ofthe parameters listed in Fig. 5b, the second A- parameter, grouping of files, is important, because it tells the receiver which files be¬ long to the same group. Such files can be e.g. file components belonging to the same computer program. This parameter can also be used to group the files in order to let the receiver know the file hierarchy, e.g. a directory structure. The same grouping of files parameter is included in the Information Data Group of each file belonging to the same group. The parameter itself is an identifying number used to give a group name to all files belonging to the same group. A certain value ofthe PI (Parameter Indica¬ tor) preceding the parameter indicates that the next parameter is a grouping of files parameter.

The third A-parameter in table 5b, integrity of group, is a file attribute, for which EU-147 proposes two values. The first suggested value 0 indicates that the file to which the IDG refers (in other words, either the file being currently transmitted or the file to be transmitted after an indicated number of files) is not the last file in the group. This lets the receiver know that more files belonging to the same group are coming, so the receiver can choose the correct action. Implementing a file already re- ceived may require the reception of another file yet to be transmitted. The second value ofthe attribute, value 1 in the proposal, indicates that the file referred to by the IDG is the last one in the group. After deciphering the attribute, the receiver knows that after the file in question has been received, all the files ofthe group will have been transmitted. This A-parameter is of course preceded by a certain PI value, from which the receiver recognizes that it is about to receive an "integrity of group" pa¬ rameter.

The value ofthe file type T-parameter indicates the type ofthe file referred to in the IDG. At least the following file types have been defined: text file (ASCII), World Wide Web (HTML), JPEG image compression (JFIF), computer graphics (GIF), run-length encoded image (RLE), audio compression (MPEG), video com¬ pression (MPEG), data stream synchronizing file and multimedia object (MHEG). This parameter, too, is preceded by a certain PI value.

In principle, the proposed mechanisms solve the problem of how to transmit multimedia services comprising several components in the DAB system. The compo- nents are transmitted in data groups as files and file groups. All the information that the receiver needs for the management and handling ofthe files is transmitted in in¬ formation data groups IDG.

On the other hand, the proposed mechanisms do not solve the problem of how to shorten the time that the receiver needs for the reception of all files belonging to a file group. The problem is that these two "integrity of group" parameter values do not give the receiver sufficient information to enable it to decide that all files ofthe group have been received and which one is the first file in the group: if the receiver starts receiving between files, then the parameter 1 for the last file does indicate that the last file has been received. Now the receiver knows that the file received first after this file with the parameter 1 from the retransmission is the first file ofthe group. Starting from this file, the receiver goes on receiving and saving files until receiving the file provided with the end sign, i.e. the parameter 1, from the retransmission. The receiver has now recognized the whole file group and the order ofthe files. This may mean receiving the whole group file twice to establish its integrity.

Another problem is that when the proposed mechanisms are used, the receiver has to receive the entire file group before starting the application. This means that the receiver must have a high-capacity storage, e.g. a hard disk. However, in many appli¬ cations it is not necessary to have all files ofthe group at once or they are not needed at all, but files are instead loaded as they are needed. In many applications, such as e.g. multimedia applications, the receiver must first load a startup file, from which the application is started. The startup file is not necessarily an activation file, but it may contain a reference to an activation file, or the log-in file may contain a list ofthe files in the group which are needed to implement a given function. An example of a startup file is the startup page of a HTML file. The required other files are selected according to the hyperlinks activated by the user, and in this sense the number and type of files needed are incidental. Thus, the files required to start the program can only be seen from the startup file itself. It would therefore be advantageous to receive only the startup file and additional files ofthe group only as needed. However, with the current mechanisms, it is not possible to transmit information about the startup file.

A suggested approach to solve this problem is to use the file type parameter to indicate a startup file, e.g. a HTML home page. However, this parameter is used in the sense of "classifying the content ofthe file" and is therefore of a quite different nature than a "startup file". In the case of a HTML file, where the startup file is the home page, the file type parameter would have to be both "startup" and "HTML" at the same time, which is impossible.

This invention presents a method whereby it is possible both to achieve faster reception of a file group and to inform the receiver about a startup file. The invention is characterized by what is said in claim 1. According to the invention, new values are proposed for the integrity of files parameter. There are four different values. The first value indicates that the file re¬ ferred to in the IDG is an intermediate file in the file group being transferred, i.e. any file between the first and last files. The second value indicates that the file being trans- mitted is the first file in the file group. The third value indicates that the file being transmitted is the last file in the file group. The fourth value indicates that the file be¬ ing transmitted belongs to the file group and is a startup file.

When group information is to be transmitted, the first, second and third pa¬ rameters are used, in other words, the IDGN "integrity of group" parameter can only have one of these parameter values. These values are fully sufficient for the transmis¬ sion of group information. Since the first file ofthe group has been designated, the receiver need not receive the entire retransmission. This provides a solution to the first problem. The integrity ofthe group is checked by the DAB transmission mechanism. When a startup file is to be transmitted, the fourth parameter value is used. The startup file forms a file group comprising only one file, so there is no need for a pa¬ rameter indicating the first, intermediate and last files. This provides a solution to the second problem. The task of checking the integrity ofthe group is transferred from the DAB transmission mechanism to the application program.

The invention is now described in more detail by referring to the attached drawings, in which:

Fig. 1 illustrates a known DAB hierarchy Fig. 2a illustrates the structure of DAB packets Fig. 2b illustrates the formation of a data group from packets Fig. 3 illustrates the structure of a data group Fig. 4a represents an IDG-T file descriptor

Fig. 4b represents an IDG-A file descriptor Fig. 4c represents an IDG-C file descriptor Fig. 5a is a table of T-parameters Fig. 5b is a table of A-parameters, and Fig. 6a and 6b represent an IDG-T file descriptor which uses parameters as provided by the invention. If the first parameter field "file descriptor offset" of a transmitted IDG-T (not shown) is zero, the IDG contains information relating to the files being transmitted (or received as seen from the receiver). If the parameter is 1, then the IDG contains in¬ formation relating to the file to be transmitted next, and so on. In the file name pa- rameter field, the name ofthe file referred to in the transmission ofthe file descriptor is given. Based on the information in these and possibly other IDG-T fields, the re¬ ceiver can start receiving the file/files. This is known in itself.

The IDG-A, Fig. 6a, comprises a parameter field called "grouping of files". A given PI field preceding it indicates that the parameter field to follow is a group of files. The next parameter field contains an identifying number which unambiguously identifies the file group, in other words, each file group has its own identification number. Based on the information in these fields, application software in the receiver begins to gather the files belonging to the file group to bring them under common management. In the checking ofthe integrity of files, the "integrity of group" field known in itself is utilized, but with meanings of parameter values according to the in¬ vention, which are presented in Fig. 6a. The parameter can have four different values, and the possible values are determined depending on whether the receiver is to save the files ofthe group in their entirety and in the given order or whether the application software is allowed to decide which files to receive, in which case the application software takes care of checking the integrity.

If a complete group of files is to be transferred to the receiver, the first, second and third parameter values are used as follows:

The first value, which can be denoted as value 0, indicates that the file referred to in the IDG is an intermediate file in the group of files being transferred, i.e. any file between the first and last files.

The second value, which can be denoted as value 1 , indicates that the file be¬ ing transferred is the first file in the file group.

The third value, which can be denoted as value 2, indicates that the file being transferred is the last file in the file group. Thus, when the receiver starts reception at the middle of a group of files, it first receives files for which this parameter value is 0, i.e. the first value. This allows it to know that the files are intermediate files in the group. Files are saved in memory as they are received. Finally there comes a file with parameter value 2, i.e. the third value, from which the receiver knows that this is the last file in the group, which is also saved. The receiver then remains waiting for the retransmission ofthe group, ex¬ amining the incoming Information Data groups. One of them indicates the relative starting time ofthe retransmission, which is when the receiver starts receiving files. The file received first does not necessarily have a group integrity parameter, so the files are not saved in memory until a file is received that does have this parameter and the parameter is 1, i.e. the second value, indicating that this is the first file ofthe de¬ sired group, so this file is saved in memory. After this, the receiver goes on receiving intermediate files, i.e. files with value 0 for this parameter, until it encounters the file which had already been received. In this way, the entire file group can be received by first receiving its latter part and then receiving the missing first part from the re¬ transmission, and the correct loading order ofthe files is achieved.

If the application software is to decide which files to receive, in which case the application software performs the integrity check, a fourth value ofthe "integrity of group" parameter is used, which can be denoted as value 3. It indicates that the file being transmitted belongs to the file group and is the startup file ofthe application (e.g. multimedia software). Only one file in the file group can have the parameter value 3, i.e. only one file is a startup file. The other files in the group may not have an "integrity of group" parameter at all, in other words, when the parameter value 3 is in use for the group, parameters 0, 1 and 2 are not in use.

As this startup file contains integrity information and information about the order in which the files are to be loaded, it must always be loaded before the other files ofthe group. This is mainly because the grouping of files parameter in the IDG-T does not necessarily contain information defining the file group. This information is only contained in the startup file itself and is therefore inaccessible to the firmware of the receiver.

For example, the IDG may indicate that the "integrity of group" parameter is value 3 (startup file) and the file type parameter is HTML file. From this information, the receiver knows that the startup file in question is a home page in hypertext consist¬ ing of a file group comprising a number of files. As is typical of hypertext, the startup file, i.e. home page, may contain hyperlinks, which may refer either to the same file or to other files in the group. If a hyperlink referring to another file in the group is acti¬ vated, the file referred to has to be loaded. The file has not been received and stored in memory, but it is only now received from a DAB subchannel. This file may again contain hyperlinks to other files, which also have to be loaded upon activation ofthe hyperlink. The application software that takes care of interaction with the user receiv¬ ing the DAB program and fetches the files is a DAB HTML browser. As to its opera¬ tion, the browser is ofthe same type as the browser used in the internet connection.

Correspondingly, if the IDG indicates that the "integrity of group" parameter is value 3 (startup file) and the file type parameter is MHEG file, then the receiver will know that the file is the startup container of a MHEG multimedia presentation. After the application software, so-called MHEG machine, has loaded this startup container, the rest of the MHEG objects and data files can be received and loaded under control of the MHEG machine from a DAB channel.

Finally, it has to be noted that if the IDG-A contains an "integrity of group" parameter (this parameter is not necessarily present) and it has a value indicating the first file, an intermediate file or the last file, i.e. value 2, 0 or 1, then the same IDG-A must also contain a grouping of files parameter. But if a grouping of files parameter is present in the IDG-A, the "integrity of group" parameter is optional. This means that when the integrity of group parameter is either first file, last file or intermediate file (i.e. other than startup file), it incorporates in itself the information that a group is be¬ ing transmitted. However, an "integrity of group" parameter indicating a startup file does not give this information. On the other hand, the presence of a grouping of files parameter does not in itself contain the information that an "integrity of group" pa¬ rameter has been set in the IDG-A. The above-described mechanism for defining the startup file of a group so as to enable it to be easily identified by the receiver is especially applicable in connec¬ tion with patent application "Handling of a program file in a digital broadcasting sys¬ tem", application number FI-954753, filed by the applicant at the same time with the present application. It is obvious to a person skilled in the art that, in the progress of technological development, the basic idea ofthe invention can be implemented in many ways. The invention and its embodiments are not restricted to the examples described above, but they may be varied within the scope ofthe claims.

Claims

1. Procedure for transmitting files in a digital broadcasting system, in which procedure the file is segmented and each segment is placed in the data field of a data group (DG) and the data group is divided into sections for transmission, which are placed in the data fields of data packets, for each file at least one information data group (IDG) containing information parameters, one of which contains information as to which files constitute a group of files, is formed and transmitted characterized in that when the receiver is to receive an entire group of files, an integrity of group parameter consisting of a number is added to the information data group (IDG) asso¬ ciated with each file, a first value of said number indicating that the file in question is a file between the first and last files ofthe group while a second value indicates that the file is the first file ofthe group and a third value indicates that the file is the last file ofthe group, when the receiver is to receive only one special file from a group of files, a fourth value of said number is added as an integrity of group parameter to the infor- mation data group (IDG) for this file, whereas no integrity of group parameter is added for the other files in the group.

2. Procedure as defined in claim 1, characterized in that the special file is the startup file ofthe group of files and contains references to the other files.

3. Procedure as defined in claim 2, characterized in that, in the receiver, other files are received in accordance with the information contained in the startup file.

4. Procedure as defmed in claim 1, the group of files to be transmitted is a multimedia program and the special file is the home page ofthe multimedia.

5. Procedure as defined in claim 4, characterized in that another file is re¬ ceived after the user has activated a hyperlink in the home page, said hyperlink con- taining a reference to the file to be received.

6. Procedure as defined in claim 5, characterized in that, after the user has ac¬ tivated a hyperlink contained in the other file, the file referred to by this hyperlink is received.

7. Procedure as defined in claim 2, characterized in that the user communi¬ cates with the application software and selects desired files from a list contained in the startup file, whereupon the selected files are received.