CAPITULO 5 FINAL

Reception of the ensemble table does not mean that the tuned RDS service is carried on that ensemble. The purpose of the ensemble table is to allow the receiver to build up information about DAB enseñables. To lócate an equivalent DAB service for service following requires that the receiver tune to each ensemble and inspect the service linking information. This task can be simplified by using the service table (see section 5.4.5.4).
Table 5.10 illustrates the ensemble table format. The EId being referenced occupies the last 16 bits in block 4. The preceding 16 bits in block 3 are used to signal the frequency code. In block 2, 2 bits are used to indicate the transmission mode.
NOTE: In [EN 300401] the centre frequency oían ensemble is coded as an unsigned binary number in a 19 bit field, allowing a range from 16kHz to 8388592 kHz. As in this ODA only 18 bits are available, the frequency range will be limited from 16 kHz to 4194288 kHz.
A transmission of this RDS group is required for each EId and for each different frequency. Once all frequencies ha ve been broadcast for a particular EId, another EId with its list of frequencies may then be broadcast. Every group is complete in its own right, and data are usable directly, without reference to any other group.
5.4.5.4 Service Table
The service table pro vides additional information about services available on DAB. It allows a receiver to get information via the RDS-ODA rather than having to examine each DAB ensemble for FIC information. Variant O allows the receiver to build up a list of ensemble identifiers that a service is available on, and variant 1 allows the linkage information for the DAB service to be stored. The service provider will signal every ensemble that a service is carried in before signalling the other attributes for that service. Once all the information is signalled for one service, the information for the next service may be signalled, and so on.
Table 5.11 shows the service table format. The SId being referenced occupies the last 16 bits in block 4. The preceding 16 bits in block 3 are used to transmit the list of

Ids and all other required attributes of that service. The use of these 16 bits is indicated by the variant code that occupies the last 4 bits in block 2.
A transmission of this RDS group is broadcast for each Sld for each different Eld. Once all EIds have been broadcast (using variant 0) other variants are transmitted to describe the other attributes for that particular Sld. Other services may then be broadcast, each with its own list of EIds and service attributes. Every group is complete in its own right, and data are usable directly, without reference to any other RDS group. The transmission of the service table information is optional but when it is transmitted then both variant O and variant 1 information should be broadcast.
5.4.5.5 Opera t tonal Requirements
In order for the (RDS) receiver to know which application decoder to use and which group type is being used for carrying the ODA (Open Data Applications) data, the service provider must transmit two type 3A groups per minute.
If a service provider has many services carried on DAB in many ensembles up to two groups per second may be required to transmit all the application data.
1 The ensemble and service table carousel may be interleaved but data will be transmit¬ted in sequence within each carousel. All the ODA data will be transmitted within
2 minutes.
As already explained in section 5.4.5.3, application data from the ensemble table are transmitted such that all data for one enseñable are broadcast before data for the next ensemble are broadcast. As explained in section 5.4.5.4, application data from the service table are transmitted such that all data for one service are broadcast before data for the next service are broadcast. All ensemble information (carried in variant 0) relating to one service is broadcast before other data (carried in other variants) relating to that service are broadcast.
For service following it is recommended that the receiver use the linkage infor¬mation provided via RDS for the RDS service and via DAB for the DAB service to link between equivalent services. This means that basically only the ensemble table needs to be transmitted. However, single front-end receivers have to use the linkage information provided via RDS for both the RDS and the DAB service, and therefore both the ensemble table and the service table should be transmitted. The linkage information is provided either explicitly by RDS type 14A groups and DAB FIG type O extensión 6 (see section 5.4.2) or implicitly when the RDS PI code and DAB Sld are identical (see section 5.4.1).

5.5 Electronic Programme Guide (EPG) for DAB 5.5.1 General
Access to prográmeme listings for digital broadcast services is often difficult, as the traditional methods of promotion (such as newspaper listings) are often not avail-able. An Electronic Programme Guide (EPG) is typically an electronic versión of a printed programme guide, presenting the user with a short summary of programmes that are or will be available across a number of channels. As such, the EPG is an important tool for service providers, encouraging listener loyalty and attracting new listeners by providing a mechanism for supplying enhanced programme information and forward promotion of programmes.
Intelligent receivers of digital broadcast services such as DAB, digital TV or others will enable some interaction between the EPG and the receiver functions.
The example below offers a simple illustration of the type of differentiator that an electronic programme listings service can provide. Figures 5.8 and 5.9 are screenshots taken from PC-based DAB receivers used for an EPG trial in London in 2001. The receivers and the EPG application were developed by RadioScape. Figure 5.8 illus-trates the information that was presented to a user selecting to listen to a radio service on a non EPG-enabled receiver. In this example, the information is limited to the DAB Programme Type (Pty) code for the service.
Figure 5.9 illustrates the additional information that was presented to the user when an EPG-enabled versión of the receiver software was used. The EPG provided further information about the programme alongside links to associated websites and email addresses.

5.5.2 Development of the DAB EPG
In early 2001, the WorldDAB Forum ([www.WorldDAB], see also section 1.4) set up a task forcé to define an open standard for a DAB EPG. From the outset the group agreed a number of fundamental key objectives, in order that the DAB EPG would meet all customer expectations:
• Display of radio schedules at varying levéis of detail on a range of future receivers.
• Descriptions of and contact details for services and programmes.
• Selection of services and programmes by the receiver, and link to related content.
• Selection of services and programmes for recording at a given time by the receiver.
• Work for both audio and data services.
It was also important that howeyer listeners consumed radio (whether it was on a hi-fi, portable, car-radio or PC-based receiver) the EPG should be available to them.
From these objectives, WorldDAB produced a draft specification for the EPG, that enabled the creation of the ETSI specification [TS 102 818].
Currently (early 2003), work is still ongoing within WorldDAB to define a suitable method for transporting, compressing and fragmenting the EPG data.
5.5.3 Data formatting
The formatting of the EPG data is significant in that it has to offer the flexibility to work on a range of receivers with differing displays, resources, storage and connect-ivity. Ideally, it should also be backwards compatible to future XML specifications, easy to decode and effícient.

1 78 Digital Audio Broadcasting: Principies and Applications of Digital Radio
The DAB EPG uses Extensible Markup Language (XML) [W3C, 2000], with the structure and contení of the XML documents defined using XML Schema's. XML is ideal for this application as:
• Many applications and APIs already exist for manipulating XML.
• XML parsers are freely and readily available (which is useful for importing and exporting the contení).
• XML also offers future expandability and backwards-compatibility; a well-designed XML application can be updated in the future without breaking any previous systems.
The last point is particularly important in the case of the EPG, where there are a number of potential future applications that may draw on this specification, but which are unknown at the moment.
The structure of the EPG is outlined in Figure 5.10. There are three main elements:

• Service information: This contains Information relating to the enseñables and the services on those enseñables.
• Schedule information: This contains information about programmes and timed events that occur within those programmes and a reference to the service (or services) on which they broadcast.
• Group information: This enables programmes and events to be linked together into groups, such as seriáis or series. Additionally groups may also be linked to other groups. For example, a programme called "The Ultimate Radio Quiz" may be a member of the series group "The Ultimate Radio.Quiz Series". This "The Ultimate Radio Quiz Series" group could then be a member of the "Quiz Programmes" group, which links together all of the programmes on the EPG that relate to quizzes.
A typical XML schedule file for a single programme is shown below:

The example above highlights a number of the key features of the specification:
• "Link" enables broadcasters to link to additional information not transported within the EPG data stream (for example websites, wapsites, or DAB data channels).
• "mediaDescription " enables the user to access multimedia contení such as images, video or audio clips associated with programmes.
• "xml.'lang" enables multi-lingual EPGs to be broadcast.
• "recommendation" allows the broadcaster to recommend specific programmes or groups of programmes to enable the automatic selection of programmes on future devices.
• "trigger" enables a suitably equipped receiver to accurately timer record pro¬grammes, using a combination of data contained with the EPG and the PNum bytes broadcast within DAB FIG 0/16.
5.5.4 Transportation and compression of the EPG
Whilst XML has many advantages it is yerbóse compared to other formats and as such is not necessarily suited to the restricted bandwidth channels in which the DAB
will VIP

• Working in a standalone data channel and in a Programme Associated Data (PAD) channel
• Significantly reducing the size of the XML data
• Minimising the overhead/complexity of the receiver.
Whilst it has not been a pre-requisite that the EPG should be file-based, indeed the specifícation has been designed such that it could be streamed or file based, to date all triáis have used the Multimedia Object Transfer (MOT) protocol (see section 4.3) to transport the data.
Uncompressed XML data is generally too large to broadcast within a limited bandwidth DAB channel. To give an indication of the order of files sizes, Table 5.12 compares a weeks worth of typical uncompressed and compressed EPG data for the national BBC multiplex.
In an 8 kbps channel the uncompressed data would take approximately 20 minutes to be received in good reception conditions. The compressed data, meanwhile would take approx 200 seconds to be received. In this example, some services contained detailed schedules including lengthy descriptions and links. Clearly in order to provide an acceptable user experience, a compression and profiling strategy is required. Currently for the EPG, the GZIP [RFC 1952] compression algorithm (as defined in the Broadcast Website specifícation [TS 101498] ) is employed. Whilst it has a high processing overhead, it is very effective at compressing text-based data, generally reducing the file sizes by over 80%.
5.5.5 EPG data management
Collection, warehousing, scheduling and validation of EPG data is important whether the data is transported in an individual service provider's X-PAD capacity or whether the data for all of the services is aggregated into a single data channel. In the case where the data from a nuniber of service providers is combined into a single


channel, the efficient and reliable management of this data becomes even more critical. Ensuring that the XML data is properly formed and that individual services providers do not corrupt the data from other service providers presents a signifícant challenge.
Management and efficient carouselling of the data for broadcast is difficult. To overeóme this problem, a process (outlined in Figure 5.11) has been adopted by a number of commercial multiplex operators. In the situation where múltiple service providers are generating and uploading their own contení, a management server is placed in-between the content generation and the transportation of that data. The service providers still retain the capability to produce the EPG data locally, but prior to broadcast the information is validated and cached. The management of the broadcast bandwidth between múltiple service providers enables the limited capacity to be used as efficiently as possible. It also provides a single point for archiving and logging the EPG data for security and licensing purposes.
5.5.6 Launch of the EPG in the UK
Through the work of WorldDAB, triáis began in the UK in 2001. In London, content from several broadcasters was aggregated and broadcast on a test ensemble with PC-based DAB receivers distributed to a closed user group: the EPG transmit-ted on the NTL Experimental ensemble was managed by DAB data application developer, Unique Interactive, and broadcast by ntl broadcast. The trial broadcast the XML-formatted data within an Skbps packet-data sub-channel using the Multi¬media Object Transfer (MOT) protocol and compressed using the GZIP algorithm.
DAB technology provider, RadioScape, developed an application for the Psion Wavefinder PC-based DAB receiver that was capable of decoding and displaying the EPG content.
With the standardisation of the XML format a number of services were launched in the UK in October 2002 by the BBC, Chrysalis Radio and Capital Radio pie with


DAB EPG management software developed for the commercial broadcasters by Unique Interactive. The launch of these services was supported by EPG software for existing PC-based DAB receivers, the Modular Technology PCI card and the Psion Wavefinder. Although the EPG is potentially a complex application, it is quite possible to créate an implementation for a radio receiver with limited facilities.
The functionality of the VAP-1 (Valué Added Platform) created by Panasonic for the ADEPT Consortium [ADEPT] was extended to include support for the EPG. This DAB receiver is based on the Technics ST-GT1000 Tuner and uses simple front panel buttons and knobs coupled with a two-line alphanumeric display. The EPG data is decoded within the receiver using proprietary Packet and MOT decoders before being stored in a temporary file system. Once all files have been captured, the critical information is extracted by an XML parser and used to créate an internal tree structure of services and programmes. When the EPG button on the front panel is pressed, the display shows a programme title and the date and time of transrnission. Using two navigation controls, the user can scroll through services to see which programmes are being broadcast at the same time, or through programmes to see what is due to be broadcast later. Pressing the record button causes a request to be queued until the appropriate time. Because of the limitations of the display, not all information about a programme can be displayed at once. However, the VAP-1 allows the information displayed to be changed by use of a control button, and can scroll long text ítems, such as the programme description. User triáis have shown this to be an example of a perfectly acceptable user interface.
With the final standardisation of the full EPG specification it is expected that the number of DAB markets broadcasting the EPG, and the range of DAB receivers supporting the EPG will increase.
5.6 Possible New Audio Services 5.6.1 Background
The Internet with its interactive user behaviour, the convergence of telecommuni-cation networks and receiving platforms and the market penetration of intelligent personal devices will have a lasting effect on radio too.
With today's approximately 9000 radio stations available over the Internet, 3500 radio Uve streams and numberless produced or personalised audio services the web offers an increasing source of different radio formats and audio services supported with navigation aids and additional metadata information.
With Internet radio appeared the term of personalisation. This means an inter-activity through the listener and contení pre-selection by user preferences. The user becomes a kind of programme director (Prosumer = producer and consumer in one) with possibilities to store or skip individual pieces of audio. The result is a form of non-linear radio programme, in contrast to the linear programme of traditional radio.
New generation of high integrated DAB chipsets with lower power consumption and interfaces to multimedia environments will allow "DAB in Everything" in the
future. The convergence of telecommunication networks and the integration of the next step of radio technology will lead to new dual or triple mode devices (e.g. DAB+GSM, DAB+GPS, DAB+PDA, DAB+MP3-Player) and from there to new radio formats and marketing opportunities.
Traditional analogous radio is embedded inside broadcast bearers without this technical flexibility, but is very successful. Traditional radio is easy to handle, is fast and actual, is local and regional, is mobile and portable receivable, is a daily companion, is anonymous and cost-effective in the distribution of information.
Therefore one tries to combine step by step the strength of traditional radio with new technologies to open a window of opportunities in digital radio.
5.6.2 Dynamic Reconfíguratíon for Temporary Service Splitting
A main objective of the STI Standard [EN 300797] was to submit a dynamic reconfíguration of the DAB multiplex. This is necessary if services are added or removed within a DAB ensemble, or data rales of the services are changed. The STI standard provides with the multiplex reconfíguration a mechanism for the synchron-ous change of the multiplex structure of the whole provisión chain (from ensemble multiplexer to broadcasting studios) without any impairment of the services (see section 6.2).
Synchronised with the service provider's programme schedule, the feature allows one to extend the service structure at a particular time. An audio service can be split into two or three sub-services. For instance, an audio service with a bit rate of 192 kbit/s into three services with a bit rate of 64 kbit/s. In the case of low audio bit rates the appliance of half-sampling-rate coding (LSF) improves the audio qual-ity.
Temporary reconfíguration may be reasonable for multilingual channels in multicultural programmes, for different regional programmes or during parallel sport events (e.g. Football leagues, World Championships, Olympic Games, etc.).
5.6.3 Secondary Service Components for Main and Sub-Services
The DAB standard provides for the organisation of a service's primary and second-ary service components (see section 2.3.6). Primary service components can contain a number of secondary service components. One secondary service component can be linked to several primary service components. This mechanism allows an "audio-linking" from main services to sub-services. For instance, if the secondary service component contains detailed information on a topic in the main service. It is the listeners decisión to switch to the sub-service.
The service is provided by a service provider in collaboration with the ensemble provider. The availability of a secondary service at the receiver is signalled acoustic-ally or visually to the listener.

5.6.4 Announcement Channels for a "Near Radio on Demand"
Every radio listener's wish is getting information just-in-time that he or she is interested in. Announcement channels are based on the idea of transporting audio information (e.g. news, sport, weather, traffic update, etc.) in parallel audio channels with narrow bit rates (e.g. 48 or 64kbit/s). Beside the new source of information for listeners, the benefit for broadcasters is to discharge regular radio services from endless monotone announcements.
Possible audio sources for this kind of service are yoice response systems, text-to-speech systems and auto-record/replay systems.
A voice response system assembles speech phrases, pre-stored in a datábase, to a whole message and replays this information over the broadcasting channel. The particular phrase used depends on the incoming encoded information. An example for such a system is VERA (Verkehr in Real Audio) a voice response system for traffic information of the Westdeutscher Rundfunk (Germán broadcasting organisa-tion WDR). More than 7000 audio files based on the RDS/TMC location and event list are stored in the system. It offers a 24 hour 7 day a week automatic spoken traffic channel "WDR Verkehr". The system provides very impressive quality, but the flexibility of the system is restricted in cases of input data which are not pre-stored in the phrase datábase.
A further alternative is to auto-record spoken messages from existing radio pro-grammes (e.g. news channel) in a digital audio server and auto-replay this message in durable audio loops. The disadvantage of this approach is that the messages nave to have already been spoken on air and additional detailed information cannot be appended.
Most flexibility offers text-to-speech systems. New synthesis technologies im-proved the former poorly speech quality of text-to-speech systems and allow a natural language processing. The nationwide FM weather service NOAA of the U.S. Department of Commerce is operating with a text-to-speech system.
5.6.5 Announcement Switching for Personal Preferences
The announcement switching is known from the FM/RDS Traffic Announcement (TA) feature. The TA service supports traffic information updates while listening to other radio programmes or local audio sources (e.g. MC, CD, MP3). The DAB standard presently offers 10 announcement types more than FM/RDS (see Table 5.8). Besides the essential announcements (e.g. traffic, warning and alarm) DAB supports more announcement types (e.g. for sport, news, weather, etc.) for personal preferences. A benefit for broadcasters is to gain listeners who are using local audio sources.
Additional mechanisms like new and región flags enhance the feature in cases of updates for the same topics and regional interests. Furthermore a support of an¬nouncement storage is imaginable at the receiver side. Broadcaster strategies for traffic announcements could comprise announcement channels combined with an¬nouncement switching in the future.

5.6.6 Mailbox Radio
With internet radio the term non-linear radio has appeared. Linear radio relates to our well known tune-in radio, where the listener depends on the programmers schedule. In non-linear radio applications, the listener is able to choose previously broadcast audio pieces, which are held in local storage of the receiver ("máilbox"). The feeding of the "máilbox" is possible either with DAB audio sub-channels or with MOT audio data service applications transported in Programme Associated Data or Packet Mode data channels. The development of differeüt projects has already started.
The U.S. company Command Audio offered a complete solution for a personalised pay radio to broadcasters, content providers, network providers and manufacturers.
Panasonic is working on a Valué Added Platform which combines a radio tuner and hard disk for a time shift radio, and Bosch-Blaupunkt initialised under the project ñame TopNews a consortium for the development of an audio based data service