Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
PROGRAMME FILE IN A DIGITAL BROADCASTING SYSTEM
Document Type and Number:
WIPO Patent Application WO/1997/023967
Kind Code:
A1
Abstract:
At the transmitting end of a DAB system, a special programme guide file is produced and transmitted. The file contains text and images to be presented to the user as well as data invisible to the user, intended only for the application software of the receiver. As receivers may have displays of different types, ranging from an alphanumeric display for a few characters to a VGA display, it is proposed that a new element be added to the data invisible to the user, an element used to separately mark up graphics and text passages that are to be displayed on a display of a given type. The display type is indicated by means of an attribute associated with the element. An attribute is also used to specify whether an original long text is to be replaced with a short text or a voice annoucement.

Inventors:
SALOMAEKI ARI (FI)
Application Number:
PCT/FI1996/000681
Publication Date:
July 03, 1997
Filing Date:
December 20, 1996
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
NOKIA OY AB (FI)
SALOMAEKI ARI (FI)
International Classes:
H04H20/30; H04H20/46; H04H20/57; H04H20/72; H04H20/86; (IPC1-7): H04H1/00; G06F7/10; G06F17/30
Domestic Patent References:
WO1997013336A11997-04-10
WO1997013339A11997-04-10
Foreign References:
DE4422015C11995-08-03
EP0718783A11996-06-26
EP0731575A21996-09-11
EP0306208A21989-03-08
US4908859A1990-03-13
Other References:
FUNKSCHAU, No. 22/95, October 1995, INGRID MITTERHUMMER et al., "Datenrundfunk mit DAB", pp. 45-48.
Download PDF:
Claims:
CLAIMS
1. Digital broadcasting system in which a transmission frame with time division multiplexing comprises: a fast information channel which contains general information relat¬ ing to audio and data services in a service ensemble, a channel for transmitting the audio and data services of an en¬ semble consisting of a number of subchannels, one of said subchannels being a reserve channel for information, characterized in that a hypertexttype programme combined from a number of separate plaintext files is transmitted in transmission frames, the files of said pro¬ gramme containing data invisible to the user that are used to control the functions of the receiver, at least some of which functions can be acti vated by the user, the data invisible to the user includes an element referring to the display type of the receiver and having attributes, and this element is used in the plaintext files to define functions that are intended to be im¬ plemented by a receiver whose display belongs to the class specified by the class name of the class attribute of said element.
2. System as defined in claim 1 , characterized in that the separate plaintext file is a HTML (Hypertext Markup Language) type programme file produced by each service supplier and relating to the service sup¬ plier's own service, and that the system operator adds his own files.
3. System as defined in claim 2, characterized in that the element is a new element (DISPLAY) to be added to the set of HTML elements.
4. System as defined in claim 2, characterized in that the class at¬ tribute (CLASS) is followed by a number of class names and the receiver interprets the class names hierarchically and carries out those functions which are appropriate for the class to which the receiver belongs.
5. System as defined in claim 2, characterized in that the element additionally has an attribute (ALT) defining an alternative text and speci¬ fying a format associated with the alternative text, and that the activa¬ tion of said format in the receiver causes the alternative text to be dis played instead of a graphic or text passage intended for a fullsize dis¬ play.
6. System as defined in claim 2, characterized in that the element additionally has an attribute (ALV) defining an alternative voice and speci¬ fying a format associated with a voice file, and that the activation of said format in the receiver produces voice information instead of a graphic or text passage.
7. Receiver in a digital broadcasting system in which audio and data services are transported in the subchannels of a transmission frame, and one of the services received is a hypertexttype programme com bined from separate plaintext files, the files of said programme containing data that is invisible to the user and is used to control the functions of the receiver, at least some which functions can be activated by the user, characterized in that the receiver belongs to a certain class determined on the basis of its display type, among the data invisible to the user, the receiver identifies in the programme an element referring to display type, as well as its attributes, and carries out the functions specified by said attributes.
8. Receiver as defined in claim 7, characterized in that, in response to an attribute (ALT) defining an alternative t~xt and specifying a format relating to the alternative text, the receiver displays the alternative text instead of a graphic or text passage intended for a fullsize display.
9. Receiver as defined in claim 7, characterized in that, in response to an attribute (ALV) defining an alternative voice and specifying a format relating to a voice file, the receiver produces voice information instead of a graphic or text passage.
10. 1 0. Receiver as defined in claim 9, characterized in that the attrib¬ ute (ALV) defining an alternative voice specifies the audio frame sub¬ channel in which the audio information is to be transferred.
Description:
Programme File in a Digital Broadcasting System

The present invention relates to the processing of information relat¬ ing to service programmes in a digital broadcasting system which allows the transmission of audio and data services as well as selective reception of such services. The information to be transmitted over the transmission channel may be either a continuous audio or data stream or packet for¬ mat information.

In the Digital Audio Broadcasting (DAB) system, which has been developed to allow an efficient utilization of frequency bands, the trans¬ mission path is completely digital. DAB defines a digital radio channel based on multiple carriers, which is applicable for the transmission of both audio and data services. The transmission channel may be either a continuous data stream channel or a packet channel. The DAB system is described in detail in ETSI (European Telecommunication Standards Insti¬ tute) standard ETS 300 401 , February, 1 995, considering transmission, transfer and reception.

From the user's point of view, the highest level of abstraction in the DAB system is called ensemble, Fig. 1 . It contains all the services that are available in a given frequency band. A change from one ensem¬ ble to another is effected by tuning to a different frequency band, just as one changes channels in current FM radio reception. The ensemble is di¬ vided 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 is the transmission frame, which consists of three chronologically consecutive parts. The first part is a Synchronizing Channel, which con¬ tains no service information. The next part is a Fast Information Channel

FIC, which has a mode-specific fixed length. It contains general informa¬ tion SI (Service Information) relating to audio and data services which helps the user select the desired service and Multiplex Configuration In¬ formation (MCI) indicating the number, size and position of subchannels. The last part is a Main Service Channel MSC, which contains all the sub¬ channels. The position, size and number of subchannels within the MSC may vary, but still the size of the MSC is constant. The MSC contains a maximum of 63 different audio and/or data subchannels. The subchan¬ nels are numbered on the basis of a so-called Subchannel ID from 0 to 62. Moreover, the MSC may contain an Auxiliary Information Channel AIC, which has a fixed channel number 63. The AIC may contain the same type of information as the FIC.

At the receiving end, the information channel FIC and the MSC channel, which contains the audio and data services, are separated from each other, and the subchannels are separated from the MSC and passed on for further processing. From the information received via the FIC channel, the user will know what services the ensemble received con¬ tains and is thus able to select the service or services he/she wants. By combining subchannel service components, such as audio/speech, con- tinuous video and packet data in accordance with the application soft¬ ware, multimedia services, a hypermedia service, a file-based service and hypertext are formed. The services thus formed are then passed on to the user's display device or for further processing.

To help the user select a service, the receiver, making use of the information of the service information channel SI and the auxiliary infor¬ mation channel AIC, generates a user interface which may be either character-based or graphic. The user interface might e.g. include a text saying "This ensemble contains the services ALPHA RADIO 1 , BETA RADIO, ALPHA RADIO 2", followed by the prompt "Select service". The user then selects the service he/she wants, whereupon the application programme block commissions the information channel processing block

to separate the desired ones of the subchannels to produce the pro¬ gramme.

The problem with this type of selection is that the processing block of the application programme must observe a service hierarchy and rely on the rather scanty information relating to programme contents that is available in the service information channel SI and auxiliary information channel AIC currently used in the art. In the prior-art system, the infor¬ mation transmitted to the user via the FIC channel is only the name of the service, presented as a 1 6-character "service label". The labels are transmitted as a coded 6-bit binary number.

To provide a general solution to the problem, the applicant has, in its earlier, still secret application FI-954753, filing date 5.10.1 995, pro¬ posed a special electronic programme guide which, from the user's point of view, is of a graphic, easy-to-use, informative and interactive design and enables the user to start a desired programme directly via the guide. According to the application referred to, each service supplier produces its own service guide using the same uniform format. A particularly pre¬ ferred format is the HTML (Hypertext Mark-up Language), which is a simple data format designed for the creation of hypertext documents and documents intended to be transferred from one system to another.

The content of the concept of HTML will now be briefly described. HTML documents are SGML documents and their semantics allows the presentation of different types of information. The service supplier's source material, which may consist of text, pictures or combinations of text and pictures or structured documents containing graphics, is con¬ verted into a HTML document, using the HTML language. The document is transmitted over a communication network. The received document is handled and displayed so that it has the appearance defined in the docu¬ ment itself. SGML is defined by the standard ISO 8879: 1 986, Informa- tion Processing Text and Office Systems Standard Generalized Mark-up Language (SGML) . A well-known area of application is the WWW (World

Wide Web), which is a hypertext-based decentralized information system developed by CERN. Its use is particularly well known in reference to the Internet.

The term HTML is generally used to denote both document type and the events in a document. 'Events' means changes of elements in the document, such as e.g. the beginning and end of a title or a para¬ graph, images, hyperlinks, etc. The mark-ups are syntactic delimiters which are added to the document to describe its structure. The common¬ est mark-up is the so-called tag, which is used to separate elements from each other, for example the start tag, denoted by the symbol < > , and the end tag, denoted by the symbol < / > . Tags can also be used to give instructions to the software in the receiver; for example, the element "TITLE", for which the start tag is < TITLE > , indicates that the text fol¬ lowing it is a title, and the text terminates with the end tag < /TITLE > . For the present invention, an important element is the anchor A. It de¬ fines a hyperlink, which is the relationship between two anchors, one of the anchors being called 'head' and the other 'tail' . The anchors may be located in the same document or in different documents. This is what makes net surfing, familiar to Internet users, possible. For the user to be able to jump across a hyperlink from one anchor to the other, it is neces¬ sary to define a URI (Uniform Resource Identifier), which is used for un¬ ambiguous identification of hyperlink anchors. In practice, the URI is composed of a URL (Uniform Resource Locator) and a Relative URL. A link can be made to refer to the head anchor either directly by using a URI or indirectly by using a URL.

Referring now to Fig. 2, each supplier of DAB services creates an HTML-format guide file relating to their service, containing one or more pages. The file may comprise text and images. One page may contain a general description of the service, another a more detailed presentation of the programme of the day together with transmission times, while the other pages may contain a weekly programme. Some pages may contain

the lyrics of the music to be presented. In addition, there may be graph¬ ics files with still pictures. A page may contain several links pointing to certain parts on the other pages of the same file or to a graphics file. In other words, a link is associated with a head address URL. The DAB operator collects the HTML programme files of different service suppliers and possibly adds hyperlinks to them. Moreover, the operator generates a separate file which describes the various ensembles available and lists their services. To this file are also added hyperlinks pointing to the files of the service suppliers. Hyperlinks can be added to a page in the service supplier's programme file containing an overview of the services to enable the pages to be linked to the pages of other serv¬ ice suppliers or to the pages for other services by the same supplier as well as to the ensemble. In this way, the DAB operator generates a combined programme guide containing several HTML file pages. A passage from a service supplier's programme guide could look e.g. like this:

Alpha radio: This service mainly consists of music with occasional news. The programmes today are as follows.

8:00 - 9:00 Light music to start the working day. This is a multi- media programme. You may view the programme with all the multimedia features by clicking here, or you may choose to just listen to the pro¬ gramme with lyrics or without lyrics.

9:00 - 9: 10 News.

If you want to preview the Alpha Radio programmes for tomorrow, click here.

In the above passage, the parts shown in bold text are hyperlinks.

In the HTML language, they have the tag < A > at the beginning and the tag < /A > at the end. When the user clicks on one of the bold parts, the application software finds the address of the anchor at the other end of

the link and performs a jump to the file and position indicated by it, whereupon the new page is displayed.

The bold text Alpha Radio can be a link to the service list of the ensemble, which again may contain a link to a list of other ensembles. In 5 the former case, by clicking on a desired service, the user will see the channels available within that service. The programme guide, composed of successive HTML files, is placed in the DAB multiplex and transmitted. At least a part of it, preferably the start-up page, is placed in the AIC channel (Auxiliary Information Channel). The rest of the files can be i o placed either in the AIC channel or in one of the packet channels.

The electronic programme guide must contain up-to-date informa¬ tion. For this reason, hyperlinks associated with programmes already fin¬ ished must be deactivated or they as well as the associated texts must be removed. Correspondingly, the programme guide must be comple-

15 mented with prospective new programmes. According to the DAB file transfer principle, the version number of the file containing the pro¬ gramme guide must be incremented by one upon each change.

The exact instant of changing the file contents of the guide need not be synchronized with a possible change in the multiplex configura- 0 tion. If the service profile changes during the reconfiguration, changes may also be required in the programme file. On the other hand, as pro¬ grammes begin and end, the programme file changes much more fre¬ quently than the DAB multiplex, and it may even change before a given programme is ended, because the user probably should not be given a 5 chance to select a programme that is going to end in a few seconds. Be¬ cause of these considerations, the retransmission frequency of the pro¬ gramme file can be less than once per second. Moreover, large pro¬ gramme file elements, such as image and sound files, can be transmitted outside the AIC channel and their repetition frequency may differ from 0 that of the parts transmitted over the AIC channel.

The application software in the receiver forms HTML pages from the files received and generates a graphic user interface as defined by them, in which the hyperlinks are visible. By means of the hyperlinks, the user can select a desired service. After the user has activated a hyperlink, an application software block performs a search based on the address and displays the file containing the anchor. Files are loaded and started immediately in response to the user's actions.

However, the programme file mechanism presented in patent ap¬ plication FI-954753 has certain drawbacks. One of these is that a pro- gramme file implemented as hypertext as proposed is in the first place only suited to be displayed on a PC display screen because it contains large amounts of alphanumeric characters and images. However, the display of a DAB receiver may be anything from a modest 8-character re¬ ceiver display to a VGA-level display of a general-purpose PC. No mechanism has been presented that would enable the receiver to func¬ tion properly in cases where only part of the text intended to be dis¬ played can be accommodated on the display and no pictures can be dis¬ played at all.

The present invention proposes a system which is free of the drawbacks described above. The system is characterized by what is said in claim 1 . A receiver designed for the system is defined in claim 7.

According to the invention, a new element relating to the display type of the receiver as well as attributes for that element are defined in the language in which the programme file is written. The element indi- cates the type of receiver display that the information between a start tag and an end tag is intended for. Correspondingly, different display types are divided into display classes. A display class attribute associated with the element tells the receiver that the programme file contains in¬ formation intended for this type of receiver. The nature and source of the information are indicated by separate attributes, and the information may be audio information, condensed text information or a combination of

these. In the programme file received, the receiver detects an element relating to display type and examines its display class attribute too see whether it contains information relating to the display of the receiver in question. If such information is found, then the receiver will function in accordance with the attributes indicating the nature of the information, displaying condensed text and/or reproducing the audio information.

In the following, the invention is described by referring to the at¬ tached drawings, in which

Fig. 1 presents the hierarchy levels in the DAB system,

Fig. 2 is a diagram illustrating the basic idea of the programme guide,

Fig. 3 is a diagrammatic representation of a programme fragment,

Fig. 4 is a modified programme fragment, and

Fig. 5 is another modified programme fragment.

The display of a DAB receiver may be anything from a modest 8- character receiver display to a VGA-level display of a general-purpose personal computer. The programme file, implemented as hypertext, con¬ tains assemblies comprising alphanumeric characters and intended to be displayed completely in a single screen, so it is best suited for a PC dis¬ play. If the display can only display 8 or 1 6 characters, then the applica¬ tion software of the receiver must decide what to display. An obvious solution would be to display only the beginning of the text or to scroll the text across the display, thereby reducing its intelligibility. According to the invention, different display types are taken into account when the programme file is created, by setting the element DISPLAY in the programme file language and defining attributes for it.

The DISPLAY element is only used in the BODY part of a HTML document. As is well known, that is the part that contains the text flow of the document, including titles, paragraphs, lists, etc. This element is used to mark those very short segments in the text of the programme file

that are intended for the display class indicated by the relevant attribute of the element, such as a modest 8-character receiver display. These segments may be the same as the most important hyperlinks in the text. Less important hyperlinks, such as links to pictures, are left out. The segmenting changes the text visible on the minimal display into a hierar¬ chic menu structure, allowing the user to scroll the display one line at a time.

In the following, the attributes proposed for the DISPLAY element are described. The attributes are set in accordance with the HTML lan- guage element structure and they include: ID, CLASS, ALT and ALV.

The ID attribute is an SGML identifier and it is used as the head of a hypertext link or in style lists relating to the designation of certain ele¬ ments. The identifiers are NAME signs and they must be unambiguous within the document. The CLASS attribute is used to classify display device types. For example, < DISPLAY CLASS = MINIMAL > could define an 8- or 1 6- character display. According to the convention, the "class" names are interpreted observing a hierarchy where the most general class is at the left end and the most specific class at the right end. The class names can be separated by a void character. The application programme of the re¬ ceiver identifies the DISPLAY element and its CLASS attribute and then only displays the characters that are intended for the display class of the particular receiver.

The ALT (Alternate Text) attribute refers to an optional text which can be displayed as an alternative to graphics or long text intended for a PC-level display. The optional text may contain hyperlinks (anchors) but no hidden DISPLAY elements.

The ALV (Alternative Voice) refers to a voice file which can be presented instead of or in addition to a marked-up portion. This attribute is a particularly handy device because when it is used together with marked-up short text segments, the result is a user interface for receivers

with a small display, an interface with a menu and a helpful voice an¬ nouncement associated with each menu item. The voice file can be trans¬ ferred over a packet channel, in the PAD field of the audio frame, by set¬ ting the application type parameter to the value of 1 6 or 1 7, or the voice file may be a marked-up passage in a continuous audio stream. The latter alternative provides the advantage that the voice file need not be stored in memory but is presented immediately upon reception This allows the use of receivers of a cheaper and simpler design

Next, the use of the element and attributes provided by the mven- tion is illustrated by the aid of a few examples.

Let us assume that a fragment of the programme file contains the following text:

8:00 - 8:30 Music magazine. This is mainly music with some dis¬ cussion on actual topics in between The language is French. In HTML format without the element of the invention, this text would be as follows.

8:00 - 8:30 <A HREF= "dab://5/23: 16/4:A "> Music magazine. </A > This is mainly music with some discussion on actual topics in between. The language is French This is represented by the diagram in Fig. 3, which is read from left to right The text giving the times comes first. Next is a hyperlink anchor start tag, which contains an address reference to a dab audio service Af ter that there is the text 'Music magazine' followed by the hyperlink end tag. By clicking on this text, the user activates the hyperlink This text is designated in the figure as "long text". The programme file then contin¬ ues with text. Only the text portions are visible to the user.

By using a DISPLAY element as provided by the invention, it is possible to use a hyperlink that includes the text to be shown on the display of a receiver provided with a minimal display, in which case the HTML format would be as follows-

8:00 - 8:30 < DISPLA Y CLASS = minimal AL V-

"dab://5/23: 16/5:D/musmag. mpg:N"> < A

HREF = "dab:// 5/23: 16/4: A " > Music magazine.

</A > </DISPLA Y> This is mainly music with some discussion on actual topics in between. The language is French.

The receiver identifies the DISPLAY element of the start tag and thus knows that the anchor contains information relating to display type. From the value 'minimal' of the CLASS attribute, it recognizes that re¬ ceivers with a minimal display can receive the information indicated by the ALV attribute, i.e. decode the mpeg-encoded audio file from the con¬ tinuous audio stream. It is only after this start tag that there comes the same start tag as in the example without a DISPLAY element, in other words, the same hyperlink text "Music magazine" together with its an¬ chors is still the same and this text is displayed on the screen of a re- ceiver with a better display.

If the receiver is not able to display the hyperlink text "Music magazine" in bold or otherwise distinguish it from the rest of the text or if the character screen is too small to display more than this text, then the receiver can play back the audio file specified in the ALV attribute. In this example the audio file is placed in service 23 of ensemble 5 (service id = 23) and, more specifically, in packet mode (identifier D) service component 5 under the filename musmag.mpg. In this case, the receiver gives voice information describing the Music magazine.

Fig. 4 shows a diagram representing the programme passage of Fig. 3 with the addition of an element and attributes as provided by the invention. The addition is a DISPLAY start tag with its attributes CLASS and ALV, of which the ALV attribute indicates where the audio file is to be found. This is followed by the same hyperlink as in Fig. 3, with a DISPLAY end tag after it. The original hyperlink is thus placed between the DISPLAY start and end tags.

The ALT attribute relating to an alternative text can be used to re¬ fer to a text intended for receivers with a minimal display. In this case, the original HTML format shown above could look like this:

8:00 - 8:30 <DISPLA Y CLASS -minimal ALT = "8:00 <A HREF = "dab://5/23: 16/4: A "> Mus Mag "<A HREF-

"dab://5/23: 16/4: A "> Music magazine. </A X/DISPLA Y> This is mainly music with some discussion on actual topics in between. The language is French.

The original hyperlink is preserved and in addition the ALT attribute brings the alternative text "8.00 Mus. Mag. " hidden in this hyperlink. In other words, the receiver may display the text "Music magazine" or the text "8.00 Mus. Mag.", and clicking on any one of them will activate the same hyperlink.

The diagram in Fig. 5 illustrates this alternative. The ALT attribute after the DISPLAY start tag is associated with the short text "Mus. Mag. " together with an anchor address. The address is the same as for the long text (Fig. 3), so in both cases activation will start exactly the same re¬ ceiver functions. After this there comes a hyperlink as in Fig. 3 and fi¬ nally a DISPLAY end tag. In the foregoing, separate descriptions of the use of the ALV and

ALT attributes were given, but it is naturally possible to use both attrib¬ utes simultaneously in conjunction with the DISPLAY element. The CLASS attribute is a handy tool for the classification of displays into de¬ sired classes, and the ALV and ALT attributes can then be used to iden- tify information intended for receivers of these classes only. Still, the re¬ ceiver can always decide whether it is going to use the original format or take the DISPLAY element parameters into account.

The proposed new element and its attributes added to a pro¬ gramme file allow receivers with different display classes to make maxi- mum use of the programme file.