WO2008096305A1

WO2008096305A1 - Method of providing service information for use by a digital broadcast receiver

Info

Publication number: WO2008096305A1
Application number: PCT/IB2008/050384
Authority: WO
Inventors: Robert A. Brondijk; Nick B. Shepherd
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2007-02-05
Filing date: 2008-02-01
Publication date: 2008-08-14

Abstract

A method of providing service information for use by a digital receiver decoder (17) includes providing service information identifying services available for selection. Each service is carried in a multiplex. The service information enables a receiver decoder (17) to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service. Advantageously, information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver to delete the service from the overview is included in the service information.

Description

Method of providing service information for use by a digital broadcast receiver

FIELD OF THE INVENTION

The invention relates to a method of providing service information for use by a digital receiver decoder, including: providing service information uniquely identifying services available for selection, each service carried in a multiplex, wherein the service information enables a receiver decoder to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service.

The invention also relates to a transmitter for transmitting services to digital receiver decoders, each service carried in a multiplex, wherein the transmitter is configured to transmit to the receiver decoders service information uniquely identifying services available for selection, the service information enabling a receiver decoder to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service. The invention also relates to a method of receiving services, each service carried in a multiplex, which method includes: receiving service information uniquely identifying services available for selection, and maintaining an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, using the service information.

The invention also relates to a receiver for receiving services each service carried in a multiplex, which receiver includes: an apparatus for retrieving service information uniquely identifying services available for selection; a system for tuning to a multiplex and for extracting data streams comprised in a selected service from the multiplex; and a system for maintaining in memory an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, based on the retrieved service information.

The invention also relates to a signal including at least one of a plurality of services, each service carried in a multiplex, which signal further includes service information, uniquely identifying services available for selection, wherein the service information enables a receiver decoder to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service. The invention also relates to a computer program.

BACKGROUND OF THE INVENTION

WO 2005/034506 discloses a DVB-terrestrial receiver that can be equipped with an "Automatic Service Update Installation" function to assist the end user in keeping track of new, moved or deleted services. The "Automatic Service Update Installation" function depends on signaling information such as Service Information (SI) as distributed by Digital Terrestrial Television (DTT) networks. A first descriptor may be used to obtain an improved "Automatic Service Update Installation" function in a DVB-T receiver. A new linkage-type may be used to signal a service that has moved within a network or that has moved from one network to another network. The first descriptor may be called "Automatic service update descriptor" and contains detailed information for DVB-T receivers on how to perform an Automatic Service Update Installation. This descriptor may be carried in the first loop of the Network Information Table (NIT). When a new version of NIT/actual is received, the receiver inspects the Transport Stream (TS) loop of the new version of NIT/actual to detect changes in the transport streams delivered by the network. A transport stream is deleted from the network when the transport stream is known by the list of installed services in the receiver (and delivered by this network) and this transport stream is not described in the TS loop. A transport stream is assigned to one or more new frequencies in the network when the delivery system descriptor or frequency list descriptor is changed. A service is removed from a network when the service id in the list of installed services is not listed in the set of service list descriptors in the new version of NIT/actual.

Known transmission systems have well-defined ways of declaring the availabilities of services. However, problems occur when services are discontinued and no longer available. It leads to situations that a receiver (hereafter: IRD) continuously adds new discovered services in its memory, but never can find cause to delete them. This can lead to errors or user frustrations, because IRD manufactures have usually chosen to request the user to "re-install" its receiver if there are too many unused services. Re-installing entails the deletion of all of the services which an IRD has found before, and rediscovering the available services. Like the original discovery of services, the rediscovery takes a lot of time.

A problem of relying on the absence of service identifiers in the service list descriptors is that not all broadcasters are suitably diligent in including all available services in every Network Information Table. Any absence will cause the decoder to remove the service from its overview of installed services, when in reality the service is still available. Services are sometimes cancelled (as opposed to merely being moved). If the overview of available services is not updated, the overview will become corrupted, and frequent complete re-installations will become necessary.

SUMMARY OF THE INVENTION It is an object of the invention to provide a method of providing service information for use by a digital broadcast receiver, a method of receiving services, a receiver, a transmitter, a signal and a computer program of the types referred to in the opening paragraphs, that reduce the need for frequent re-discovery of available services by a receiver when services are discontinued. This object is achieved by the method according to the invention, which includes including in the service information information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver to delete the service from the overview.

In digital transmission systems like DVB, ATSC, IPTV, ARIB, etc, there are "Services". A suitable definition of a service can be found in European Standard ETSI EN 300 468, v 1.8.1, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", in which a service is defined as a sequence of programs under the control of a broadcaster which can be broadcast as part of a schedule.

By providing service information uniquely identifying services available for selection, each service carried in a multiplex, wherein the service information enables a receiver to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, services can be pre-set for quick selection by a user and subsequent tuning. The unique identification ensures that there can be no confusion between services present under the same program number in different multiplexes, for example. By including in the service information information uniquely identifying a service that will no longer be available for selection, it is ensured that the overview can be kept compact and populated only with valid information. By providing the information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver to delete the service from the overview, services cannot "accidentally" be removed just because their declaration is not repeated. Moreover, discontinued services - as opposed to merely moved services - are removed, thanks to the explicit, as opposed to implicit signal provided by the data. An added effect of the invention is that the need for a separate descriptor or linkage type to signal a service move is obviated. This is because a move can be signaled by removing the service from the overview using its old unique identification in association with the data explicitly signaling to the receiver to delete the service from the overview, and then re-declaring the service using the new unique identification. Thus, the data structure(s) used to associate unique identifications of services with data explicitly signaling to the receiver to delete the service from the overview can be used in multiple use cases, simplifying the parsing of the service information by the receiver.

It is observed that draft European Standard ETSI EN 300 468, v 1.8.1, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", discloses a Service move descriptor providing a mechanism which enables an IRD to track a service between TSs if it is required to move a service from one TS to another. It includes a field containing the original _network_id of the TS in which the service is found after the move, a field containing the transport _str earn _id in which the service is found after the move, and a field containing the service Jd of the service after the move. It is intended for placement in the Program Map Table. A service identifier is identical to the program identification number contained in a Program Map Table relating to that service, the program map table being used to provide the mapping between the program number and the program elements that comprise it. The program number in a Program Map Table is only unique within the transport stream carrying the Program Map Table. The service move descriptor does not include data explicitly signaling to the receiver to delete a service from the overview, but to replace the tuple (ONID, TSID, SID} that identifies the service in the overview.

In an embodiment, at least the data explicitly signaling to the receiver decoder to delete a service from the overview is comprised in a data structure placed in a table. An effect is to provide the service information efficiently, since tables can be organized to indicate that all data structures in a column or row relate to the same service or multiplex. The data structures themselves need therefore comprise less information.

In an embodiment, the data structure is labeled with a pre-determined label, the label signaling to the receiver decoder to delete the service from the overview.

Thus, a private data structure can be used, as opposed to an existing data structure provided with a newly defined parameter or parameter value. An effect is that legacy receiver decoders that do not recognize the label can simply ignore it. In an embodiment, the service information is carried in at least one of the multiplexes carrying services.

An effect is to allow the service information to be retrieved whilst the receiver decoder is tuned to the multiplex, for example to receive a service. A receiver need not use a separate interface to a different communications link to obtain the service information.

In an embodiment, the information uniquely identifying a service includes a set of identifiers including an identifier that is unique within a delivery system and a unique identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system.

An effect is to be able to use a smaller space of service identifier values. A further effect is to obviate the need for co-ordination between the organizations managing delivery systems in order to ensure that the services are uniquely identified. A further effect is to allow a service to be moved to another delivery system without having to change the identifying information.

In an embodiment, the information uniquely identifying a service includes a set of identifiers including an identifier of a multiplex carrying the service, that is unique within a delivery system and an identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system. An effect is provided when an entire multiplex is dropped or moved to another delivery system. It is possible to retain the old (unique) identification of a service, but to associate it with tuning information for the multiplex in the new delivery system. This is because the original network identifier can be different from the identifier of the delivery system actually providing the service. In an embodiment, the information uniquely identifying a service that will no longer be available for selection is transmitted in association with data explicitly signaling to the receiver decoder to delete the service from the overview for a pre-determined period of time after discontinuation of the transmission of the service to which the data refers. An effect is that the receiver decoder can be switched off for some time, but still keep its overview accurate.

According to another aspect of the invention, the transmitter according to the invention is configured to include in the service information information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver decoder to delete the service from the overview.

The transmitter is thus not reliant on accurate service information providing a complete overview of all available services to a receiver decoder.

In an embodiment, the transmitter is configured to transmit service information obtainable by means of a method of providing service information according to the invention.

According to another aspect, the method of receiving services according to the invention includes, responsive to detecting within the service information information uniquely identifying a service that will no longer be available for selection in association with pre-determined data, deleting the service from the overview. Because the information uniquely identifying a service that will no longer be available for selection is provided in association with pre-determined data, an explicit signal that a service has been discontinued is processed. The receiver decoder does not need to make any inferences other than that a previously declared service is to be deleted.

According to another aspect, the receiver according to the invention is configured to delete a service from the overview responsive to detecting within the service information information uniquely identifying a service that will no longer be available for selection in association with pre-determined data.

In an embodiment, the receiver is configured to carry out a method of receiving services according to the invention. According to another aspect, the signal according to the invention includes service information further including information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver decoder to delete the service from the overview. In an embodiment, the signal is obtainable by means of a method of providing service information according to the invention.

According to another aspect, the computer program according to the invention includes a set of instructions capable, when incorporated in a machine-readable medium, of causing a system having information processing capabilities to perform a method according of providing service information according to the invention or a method of receiving services according to the invention.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will be explained in further detail with reference to the accompanying drawings, in which:

Fig. 1 illustrates a digital television broadcast system; Fig. 2 is a schematic diagram of a set-top box for use in the system; Fig. 3 is a flow chart illustrating analysis of network information carried in a broadcast transport stream; and

Fig. 4 is a flow chart illustrating analysis of service information relating to services carried in a particular transport stream.

DETAILED DESCRIPTION OF THE EMBODIMENTS Referring to Fig. 1 a terrestrial and a cable broadcaster provide respective delivery systems for transmission of digital services e.g. in accordance with the DVB-T and DVB-C standards, respectively. In the following, a delivery system will be understood to mean a physical medium by which one or more multiplexes are transmitted from a single emitting point. The terrestrial broadcaster has a system 1 for playing out elementary streams forming events, which are groupings of elementary broadcast data streams with a defined start and end time belonging to a common service. A first multiplexer 2 multiplexes the elementary data streams forming events of one or more services into a multiplex, hereinafter referred to also as a transport stream. The transport stream is a data structure in accordance with international standard ISO/IEC 13818-1 (MPEG-2 Systems). It further includes Program Specific Information provided by a first Program Specific Information (PSI) generator 3, as well as Service Information provided by a Service Information (SI) generator 4. A second multiplexer 5 multiplexes elementary data streams forming events of one or more services into a second transport stream. A second PSI generator 6 provides Program Specific Information that is included in the second multiplex. In the illustrated embodiment, no service information is included in the second multiplex, but in other embodiments the second multiplex may also comprise Service Information data.

First and second transmitters 7, 8 transmit the first and second multiplexes on different frequencies.

The cable broadcaster also uses a system 9 for playing out elementary streams forming events comprised in services. The events will generally be broadcast according to a schedule, but may also comprise events multicast or unicast on demand. A third multiplexer 10 multiplexes elementary streams forming events comprised in one or more services into a third transport stream. A third PSI generator 11 provides Program Specific Information that is also multiplexed into the transport stream. Similarly, a fourth multiplexer 12 multiplexes elementary streams forming events comprised in one or more services, as well data packets provided by a fourth PSI generator 13 into a fourth transport stream. Third and fourth transmitters 14, 15 broadcast the third and fourth multiplexes in separate channels over a cable network 16.

In the illustrated embodiment, the third and fourth multiplexes contain no Service Information data, the relevant service information being provided by the SI generator 4. In other embodiments, Service Information is carried in several multiplexes, either as duplicates or as part of a complete set of Service Information relating to all transport streams. It is further noted that services may be provided in duplicate in different multiplexes.

An Integrated Receiver Decoder (IRD) 17 is provided with an interface to the cable broadcast network and the terrestrial broadcast network. As an example, the IRD 17 is shown schematically as a set-top box in Fig. 2. This example is representative of a class of receiver decoders that include digital television sets, digital video recorders, specially adapted personal computers, specially adapted mobile telephone handsets, etc. Such devices may receive the transport streams, e.g. MPEG-2 transport streams, carried in another stream of packetized data, such as Internet Protocol (IP) packets, instead of as a directly modulated data stream. The IRD 17 includes a cable network tuner 18 and a terrestrial network tuner 19. Each is followed by a demodulator 20, 21 that demodulates the signal from the associated tuner 18, 19 in the manner appropriate to the network, using the appropriate physical parameters. A demultiplexer 22 retrieves certain elementary streams, identified by their Packet Identifier (PID), from the multiplex it receives from the first or the second demodulator 20, 21.

The illustrated IRD 17 is provided with a mass-storage device 23, e.g. a hard disk unit, to store an event. A media processor 24 and main memory 25 enable the IRD 17 to decode the elementary streams provided by the demultiplexer 22, and to provide as output the audio and video signals making up an event in the appropriate format for a video output stage 26 and an audio output stage 27 to provide audio and video signals to e.g. a television set (not shown) via audio and video output interfaces 28, 29. The IRD 17 is controlled by a controller 30, and provided with non- volatile memory 31 for storing firmware controlling its operations and providing it with its functionality.

The non- volatile memory 31, or the mass-storage device 23 are used by the IRD 17 to maintain an overview grouping services available for selection with tuning information including physical parameters for each multiplex. The relevant information is retrieved from the Service Information provided by the SI generator 4 in a manner to be described with reference to Figs. 3 and 4, which also show how entries for particular identified services are deleted from the overview again.

The tuning information kept in the overview depends on the delivery system to which the transport stream that carries the service belongs. Where a service is provided in duplicate, one multiplex is selected and the other information is stored in a reserved area of the overview.

For the cable network 16, the information will, for example, generally include the frequency at which the transport stream is transmitted, the forward error correction scheme used by the transmitter, the modulation scheme used by the transmitter and the symbol rate. For a satellite network, the information will, for example, include the frequency, orbital position of the satellite, polarization of the signal, modulation system, modulation type, symbol rate and forward error correction scheme used by the satellite transmitter. For a terrestrial network, the tuning information can, for example, include the frequency and bandwidth of the carrier wave, the forward error correction scheme used, the modulation scheme, code rate and guard interval value (for an OFDM modulation scheme). The overview enables the IRD 17 to present the available services in a list or menu to the user, and then rapidly retrieve them when selected by the user. The IRD 17 sets one of the cable network tuner 18 and the terrestrial network tuner 19 and the appropriate one of the demodulators 20, 21 in accordance with the information pre-stored in the overview. This allows it to obtain the transport stream carrying the service. Program- specific information carried in the multiplex allows for the relevant elementary streams to be retrieved from the multiplex. In particular, the Program Specific Information includes a Program Allocation Table, carried in packets with a default PID value, which lists the available programs. Program Map Tables (PMT) are provided for each program, and list the PID values of the elementary streams comprised in the program. The PMTs include a program number, which corresponds to the service identifier (SID) of the service in which the program is comprised. Thus, a specific service can be retrieved from a multiplex using the SID value and the PSI data provided in the multiplex carrying the service. The overview, however, provides the information for obtaining the multiplex in the first place, which information is obtained by the IRD 17 from the Service Information included in one or more of the multiplexes (not necessarily the one carrying the services about which the Service Information informs).

Within the Service Information, a service is identified by a tuple (ONID, TSID, SID}. The Original Network Identifier (ONID) is a unique identifier of an original one of a plurality of networks, a network being a collection of transport stream (TS) multiplexes transmitted on a single delivery system. Each such collection has a unique identifier, the network identifier (NID). The original network identifier (ONID) identifies the one on which the service was originally transmitted. It need not correspond to the NID value of the network on which the service is actually transmitted, because transport streams and/or services may be moved between networks. To improve coverage of services over a large physical area, services are "copied" in different MUXs in different frequencies of a terrestrial broadcast network. This means that an IRD 17 at a given location may be able to receive the same service at different frequencies. The IRD 17 can detect a duplicate service, because the copy will not be identified using a set of identifiers including the actual NID value, but by a set including the ONID value. The rules for detection of duplicate services are given in the operational rules. For example, DGTVi D-Book, "Compatible DTV receivers for the Italian market: baseline requirements",DGTVi, 2006, requires the tuplet (ONID, TSID, SID} to be the same, whereas EACEM Technical Report "Baseline Digital Terrestrial TV Receiver Specification" (E-Book) just requires the duplet (ONID, SID} to be the same. The latter is sufficient, because the information uniquely identifying a service includes a set of identifiers including an identifier (the SID) that is unique within a given delivery system and a unique identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system. It is noted that the Transport Stream Identifier (TSID) is also unique within each ONID. That is to say that no two multiplexes can have the same ONID and TSID value. It is further noted that the ONID value for a particular collection provided by a delivery system is unique over all available delivery systems. This is in contrast, for example, to the Logical Channel Number, which is a number some broadcasters use to label the services provided by a particular delivery system. Where a service is moved from one delivery system to the next, Logical Channel Numbers cannot be used to identify services that are to be deleted from the overview of services maintained by the IRD 17. For that, services must be uniquely identified across the delivery systems available to the IRD 17. Before going further into the disclosure, the current methods used in DVB-T for service availability will be described first.

A service is discovered in the following steps:

1. Scan the frequency spectrum for a DVB-T modulated signal.

2. Demodulate the signal found at a given frequency. The resulting data stream is referred to as a "multiplex", or MUX.

3. Parse the data stream to find the Network Information Table (NIT) for information of this MUX and other MUXs that are available at other frequencies. In the NIT, important information such as ONIDs and TSIDs are found.

4. Parse the data stream to find the Service Description Table (SDT) for information of the services available in this MUX.

An issue around services arises when frequencies and TSIDs change. In DGTVi D-Book, "Compatible DTV receivers for the Italian market: baseline requirements", DGTVi, 2006, it is suggested that a service can be deleted if the (ONID, TSID, SID} can no longer be found in the MUX in which (ONID, TSID} was originally found. This algorithm only covers the use-case that an SID has been dropped from a MUX. However, broadcast changes tend to be more rigorous. An entire frequency is dropped or, at a given frequency, a new TSID is transmitted which may contain a different selection of services. The services that were in that frequency or that TSID, cannot be deleted. It is exactly these use cases which the present disclosure addresses. More specifically, a service that is no longer available is explicitly declared as

"deleted" or "removed" or "unavailable" by the transmission of a declaration. The declaration can be contained in specific "descriptors" (i.e. structures sent in the data stream), or defined as "status" (i.e. variables that are contained in those structures). The method can be described as follows. Digital television transmission systems such as DVB and ATSC have well-defined ways of identifying which services are available. However, problems occur when services are discontinued. It leads to the situations that a digital TV receiver or Set Top Box will never find cause to delete a service from a list of services that are selectable by the user. To obviate this problem, it is proposed here to include a declaration in the data stream that a previously available service is no longer available. Such a declaration allows the receiver to delete unavailable services from memory, thereby making room free for new ones. This saves the user from having to carry out a time-consuming "re-scan". It also makes it possible for the broadcasters to move around services more easily.

In an embodiment, the declaration that a service is unavailable is conveyed in a similar manner as the method in which services are declared to be available. In DVB, services are declared by descriptors placed in "tables". The tables are the NIT and in the table SDT. It is important that if a service is declared unavailable, it must be clear exactly which service that declaration refers to. This is not trivial, since a "service" is more than just a service Jd value. It is also associated with an ONID and a TSID.

The declaration of unavailability preferably resembles the declaration of its availability.

Turning to Fig. 3, some steps in the processing of the service information by the IRD 17 are illustrated. In a first step 32, the NIT is retrieved from one of the multiplexes, which also carries one or more of the services. This step 32 can thus be carried out whilst the IRD 17 is in use to decode an event comprised in a service.

The NIT is carried in packets with a specific PID value in case it informs about the delivery system providing the multiplex in which it is contained (in which case the NIT is called NIT/actual), or a specific PID value to inform the IRD 17 that it informs about another delivery system (in which case it is called NIT/other). Thus, the SI generator 4 can provide information also on services provided by means of the cable network 16. Table 1 shows the definition of the NIT, and corresponds to Table 3 on page 19 of ETSI technical standard EN 300468.

Syntax Number of bits Identifier network_information_section() { table id 8 uimsbf section syntax indicator 1 bslbf reserved_future_use 1 bslbf reserved 2 bslbf section length 12 uimsbf networkid 16 uimsbf reserved 2 bslbf versionnumber 5 uimsbf currentnext indicator 1 bslbf sectionnumber 8 uimsbf last sectionnumber 8 uimsbf reserved_future_use 4 bslbf network descriptors length 12 uimsbf for(i=0;i<N;i++){ descriptor()

} reserved_future_use 4 bslbf transport stream loop length 12 uimsbf for(i=0;i<N;i++){ transport streamid 16 uimsbf originalnetwork id 16 uimsbf reserved_future_use 4 bslbf transport descriptors length 12 uimsbf forO=0;j<N;j++){ descriptor()

} } CRC 32 32 rpchof

} Table 1 - Network information section NIT

The network identifier network Jd identifies the delivery system to which the table pertains. Thus, when parsing the table, the IRD 17 identifies this network (step 33). Fig. 3 only shows how the IRD 17 first reads (step 34) the network descriptors, going through the first loop of the NIT, and then goes through the transport descriptors loop, the second loop of the NIT. With each iteration through the second loop, it identifies the transport stream (step 35) from the field transport _str earn _id and the field original _network_id. It then reads the descriptors (step 36). If the descriptor includes a list of services provided in the transport stream identified by the tuple (ONID, TSID}, then the services are added to the overview (step 37). This type of descriptor lists the available services by type and SID. If the descriptor includes tuning information, then this information is added to the overview (step 38), such that it is linked to identifications of the services available on that transport stream. In accordance with the invention, the descriptor is a descriptor introduced to identify the declaration of a deleted service. Care must be taken that the descriptor contains all of the attributes of the original service. It must also be able to be placed in the NIT, so that it is visible throughout the entire network and not just in the present transport stream. The descriptor can be either a "public" descriptor or a "private" descriptor, depending on whether it is standardized. If it is a private descriptor, it is labeled with a pre-determined label, the label signaling to a specially adapted IRD 17 to delete the service identified in the descriptor from the overview. The descriptor itself need only carry the SID value, since it is placed in a table and the IRD 17 has previously (step 35) already identified the transport stream. Thus, by virtue of the ONID and TSID values in the second loop of the NIT, as well as the SID value in the special descriptor, information uniquely identifying a service that has been discontinued is provided in association with data (identifying the special descriptor) signaling to the IRD 17 to delete the identified service from the overview.

In another embodiment, a similar private or public descriptor is provided in the first loop of the NIT. In that case, the descriptor includes the entire tuple (ONID₅TSID, SID} identifying the service that has been deleted, removed or is no longer available.

The new descriptor can be called the "service deleted descriptor". As explained, the contents of the descriptor depend on the context in which it is used. If the descriptor is defined as being in the descriptor loop of the Service Description Section (to be explained with reference to Fig. 4), then it needs no other parameters. If the descriptor is contained in the first descriptor loop of the Network Information Table, then it must contain at least the ONID and the SID, and may also contain a list of TSIDs and/or the service descriptor, shown in Table 2. If the new descriptor is defined in the second loop of the NIT, then it must contain the SID and may also contain one or more of the "Service_Type", the "service_descriptor", and a list of TSIDs in which the service was declared while it was running. Optionally or alternatively, the service deleted descriptor may also contain information about the time at which the service will be deleted. The aforementioned service descriptor provides the name of the service provider and the service in text form together with the type of the service (digital television, teletext, digital radio, data broadcast, Near Video-on-Demand service, etc.). It is shown in Table 2, which corresponds to Table 78 on page 61 of ETSI technical standard EN 300 468.

Syntax Number of bits Identifier service_descriptor() { descriptor tag 8 uimsbf descriptor length 8 uimsbf service_type 8 uimsbf service_provider_name_length 8 uimsbf for (i=0; i < N; i++){ char uimsbf

} service_name_length uimsbf for (i=0; i < N; i++){ Char uimsbf

} } Table 2 - Service descriptor

The declaration that a service is no longer available can also be identified by using a special interpretation of the "service availability descriptor", which is shown in Table 3, for example, by making clear that the values "availability_flag==l" and an empty cell list means that the service is no longer available. Thus, in this embodiment, the step 39 is carried out upon finding a service availability descriptor with a particular combination of field values within a part of the Network Information Table associated with the identified service. This variant of the method is only useable in case the service is one provided by the terrestrial broadcaster, incidentally. The service availability descriptor normally provides an identification of the cells in which the service is available or not available. When the field availability descriptor is set to value "1", this normally indicates that the service is available on the cell(s) identified by the values of the field cell Jd in the following loop.

Syntax Number of bits Identifier service availability descriptor() { descriptor tag 8 uimsbf descriptor length 8 uimsbf availability flag 1 bslbf reserved 7 bslbf for (i=0; i < N; i++){ cell id 16 uimsbf }

} Table 3 - Service availability descriptor

Referring to Fig. 4, the IRD 17 also parses the multiplex to retrieve one or more Service Description Tables (SDTs). In a first step 40, it retrieves an SDT from the multiplex. The SDT is carried in packets identified by one particular PID value in case the SDT informs about the current multiplex (in which case the SDT is referred to as SDT/actual), or another particular value if it informs about another multiplex (in which case the SDT is referred to as SDT/other).

Table 4 shows the definition of the service description table, corresponding to the definition given in ETSI technical standard EN 300468, Table 5, page 22.

Syntax Number of bits Identifier service_description_section() { table id 8 uimsbf section syntax indicator 1 bslbf reserved_future_use 1 bslbf reserved 2 bslbf section length 12 uimsbf transport stream id 16 uimsbf reserved 2 bslbf versionnumber 5 uimsbf currentnext indicator 1 bslbf sectionnumber 8 uimsbf last sectionnumber 8 uimsbf originalnetwork id 16 uimsbf reserved_future_use 8 uimsbf for(i=0;i<N;i++){ service_id 16 uimsbf reserved_future_use 6 bslbf

EIT schedule flag 1 bslbf

EIT_present_fo Ho wing flag 1 bslbf running status 3 uimsbf bslbf free CAmode 1 uimsbf descriptors loop length 12 forO=0;j<N;j++){ descriptorQ

}

} rpchof

CRC 32 32

}

Table 4 - Service description section As with the PID of the packets carrying the SDT sections, a first value of the field table Jd indicates that the table pertains to the current transport stream, whereas a second value indicates that it pertains to another transport stream. The fields transport _str earn _id and original _network_id serve to identify the transport stream uniquely, even if it has been moved to another network. Thus, in a next step 41, the IRD 17 identifies this transport stream. It then goes through the descriptor loop of the SDT, each time identifying the service (step 42) from the values in the fields original _network_id and service Jd, and optionally that of the field transport _str earn _id. Subsequent to this step 42, it checks the running status using the value in the field running _status. Table 5 shows the values currently defined in ETSI standard EN 300 468, Table 6 on page 23.

Value Meaning

0 undefined

1 not running

2 starts in a few seconds (e.g. for video recording)

3 pausing

4 running

5 to 7 reserved for future use

Table 5 - Running status

In the illustrated embodiment, the IRD 17 is configured, responsive to detecting a particular value of the running status in association with the service to which the current traversal of the loop corresponds, to delete (step 44) the identified service from the overview. The current version of the DVB standard provides reserved values, as shown in Table 5. In accordance with the method illustrated in Fig. 4, a new value, for example, "5", can be defined to mean "this service is deleted" or "this service is no longer available". Note that deleted services continue to broadcast their SDTs (and only their SDTs), but the running status now "deleted" gives an unambiguous indication that the service is deleted. Deleted SDTs need only be broadcast for a restricted period of time, e.g. a few weeks, in the MUX where they would have been if there were not deleted

In another variant, a service may additionally or alternatively be declared no longer available using the Running Status Table (RST) in a transport stream. The RST is normally provided to update the timing status of one or more events. Sections forming part of an RST are transmitted in packets with a specific PID value. Table 6 shows the composition of the RST, and corresponds to Table 10 on page 27 of ETSI technical standard EN 300 468.

Syntax Number of bits Identifier running_status_section() { table id 8 uimsbf section syntax indicator 1 bslbf reserved_future_use 1 bslbf reserved 2 bslbf section 12 uimsbf section length for (i-0; i < N; i++){ transport stream id 16 uimsbf original network id 16 uimsbf service_id 16 uimsbf event id 16 uimsbf reserved_future_use 5 bslbf running status 3 uimsbf } } Table 6 - Running status section

It will be clear that, as for the SDT, a particular value of the field running _status can be used to indicate that the service identified by the values of the fields original _network_id and service Jd, and optionally transport_stream_id, should be deleted from the overview maintained by the IRD 17 .

It will be clear from the foregoing description that there have been disclosed variants of a method of transmitting services including the step of declaring a service unavailable. This allows the IRD 17 to delete that service from its memory 23,31, thereby making room free for new ones. It spares the user from having to request a time-consuming "re-scan". It also makes it possible for the broadcasters to move around services more easily, because they do not have to worry about users needing to re-scan their IRDs 17.

It should be noted that the embodiments described above illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. In a further embodiment of the invention, a parameter value in the Event

Information Table is used to signal that a service is to be deleted, in a manner similar to the embodiment in which the RST is used.

The invention can be summarized as follows. A method of providing service information for use by a digital receiver decoder (17) includes providing service information identifying services available for selection. Each service is carried in a multiplex. The service information enables a receiver decoder (17) to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service. Advantageously, information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver to delete the service from the overview is included in the service information.

Claims

CLAIMS:

1. Method of providing service information for use by a digital receiver decoder (17), including: providing service information uniquely identifying services available for selection, each service carried in a multiplex, wherein the service information enables a receiver decoder (17) to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, and including in the service information information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver to delete the service from the overview.

2. Method according to claim 1, wherein at least the data explicitly signaling to the receiver decoder (17) to delete a service from the overview is comprised in a data structure placed in a table.

3. Method according to claim 2, wherein the data structure is labeled with a predetermined label, the label signaling to the receiver decoder (17) to delete the service from the overview.

4. Method according to any one of the preceding claims, wherein the service information is carried in at least one of the multiplexes carrying services.

5. Method according to any one of the preceding claims, wherein the information uniquely identifying a service includes a set of identifiers including an identifier that is unique within a delivery system and a unique identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system.

6. Method according to any one of the preceding claims, wherein the information uniquely identifying a service includes a set of identifiers including an identifier of a multiplex carrying the service, that is unique within a delivery system and an identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system.

7. Method according to any one of the preceding claims, wherein the information uniquely identifying a service that will no longer be available for selection is transmitted in association with data explicitly signaling to the receiver decoder (17) to delete the service from the overview for a pre-determined period of time after discontinuation of the transmission of the service to which the data refers.

8. Transmitter for transmitting services to digital receiver decoders (17), each service carried in a multiplex, wherein the transmitter is configured to transmit to the receiver decoders (17) service information uniquely identifying services available for selection, the service information enabling a receiver decoder (17) to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, and wherein the transmitter is configured to include in the service information information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver decoder (17) to delete the service from the overview.

9. Transmitter according to claim 8 configured to transmit service information obtainable by means of a method according to any one of claims 1-7.

10. Method of receiving services, each service carried in a multiplex, which method includes: receiving service information uniquely identifying services available for selection; maintaining an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, using the service information; and, responsive to detecting within the service information information uniquely identifying a service that will no longer be available for selection in association with predetermined data, deleting the service from the overview.

11. Method according to claim 10, wherein at least the pre-determined data is comprised in a data structure retrieved from a table.

12. Method according to claim 11, wherein the service is deleted from the overview responsive to identifying a data structure labeled with a pre-determined label.

13. Method according to any one of claims 10-12, wherein the service information is retrieved from at least one multiplex carrying services.

14. Method according to any one of claims 10-13, wherein the information uniquely identifying a service includes a set of identifiers including an identifier that is unique within a delivery system and a unique identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system.

15. Method according to any one of claims 10-14, wherein the information uniquely identifying a service includes a set of identifiers including an identifier of a multiplex carrying the service, that is unique within a delivery system and an identifier of an original one of a plurality of collections of transport streams, each collection provided on a single respective delivery system.

16. Method according to any one of claims 10-15, wherein the service is deleted from the overview responsive to receiving the information uniquely identifying a service that will no longer be available for selection in association with pre-determined data after the service has been discontinued.

17. Receiver for receiving services each service carried in a multiplex, which receiver includes: an apparatus (18-22,24,25) for retrieving service information uniquely identifying services available for selection; a system (18-22) for tuning to a multiplex and for extracting data streams comprised in a selected service from the multiplex; and a system (24,30) for maintaining in memory (23,31) an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, based on the retrieved service information, wherein the receiver is configured to delete a service from the overview responsive to detecting within the service information information uniquely identifying a service that will no longer be available for selection in association with pre-determined data.

18. Receiver according to claim 17, configured to carry out a method according to any one of claims 10-16.

19. Signal including at least one of a plurality of services, each service carried in a multiplex, which signal further includes service information, uniquely identifying services available for selection, wherein the service information enables a receiver decoder (17) to maintain an overview grouping services available for selection with tuning information including parameters for obtaining a multiplex carrying the service, the service information further including information uniquely identifying a service that will no longer be available for selection in association with data explicitly signaling to the receiver decoder (17) to delete the service from the overview.

20. Signal according to claim 19, obtainable by means of a method according to any one of claims 1-7.

21. Computer programs including a set of instructions capable, when incorporated in a machine-readable medium, of causing a system having information processing capabilities to perform a method according to any one of claims 1-7 or 10-16.