MinDig TV. System Software Update

Transcription

1 MinDig TV System Software Update Implementation Guideline for Digital Television Receivers for use in the Hungarian Digital Terrestrial Television Broadcasting Part of the MinDig TV Receiver Specification Version Created by: Company: Contact: Viktor Till Antenna Hungária

2 Table of contents 1. INTRODUCTION SCOPE DOCUMENT HISTORY REFERENCES TERMINOLOGY OVERVIEW OF SYSTEM SOFTWARE UPDATE SI SIGNALING BROADCAST ENVIRONMENT SSU Linkage Descriptor RECEIVER RULES General Cross-referencing PSI SIGNALING BROADCAST ENVIRONMENT Data Broadcast Id Descriptor RECEIVER RULES General DATA CARRIAGE IMPLEMENTATION INITIATION OF SSU PROCESS With SSU Linkage Descriptor Without SSU Linkage Descriptor Manually Initiated SSU VIEWER NOTIFICATION ABOUT THE AVAILABLE SSU DISCOVERING THE LOCATION OF THE SSU IMAGE DOWNLOADING AND WRITING THE SSU IMAGE SECURITY DELIVERY PACKAGE

3 1. Introduction 1.1. Scope The present document is part of MinDig TV Receiver Specification. It expands the descriptions of the MinDig TV General Receiver Requirements on the system software update. To develop a MinDig TV compliant receiver, all the mandatory requirements of the present document shall be satisfied, while it is strongly recommended to follow its recommendations. Furthermore, a MinDig TV receiver shall satisfy all the parts of the MinDig TV Receiver Specification. The MinDig TV Receiver Specification does not require the implementation of the IEC E-Book, but on those fields where no requirement is described here, the IEC should be handled as guideline Document History Version Date Comments Editor 0.1.x First public version V. Till Pre-release V. Till First official release V. Till 3

4 1.3. References [1] ISO/IEC : Information technology Generic coding of moving pictures and associated audio information: Systems. [2] ETSI EN : Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems. [3] ETSI TS v.1.3.2: Digital Video Broadcasting (DVB); Specification for System Software Update in DVB Systems. [4] ISO/IEC (1998): Information technology; Generic coding of moving pictures and associated audio information; Part 6: Extensions for DSM-CC. [5] ETSI EN Digital Video Broadcasting (DVB); DVB specification for data broadcasting. [6] ECCA EuroLoader Specification Version 1.2b 1.4. Terminology Shall (must, mandatory, required) Shall not (must not) Should (recommended, preferred) MinDig TV receiver (receiver) SSU These words mean that the item is mandatory. These words mean that the item is forbidden. These words mean that the item is not mandatory, but is highly recommended. This device is suitable for handling DVB-T services according to the requirements of the MinDig TV General Receiver Requirements and the related guidelines. The MinDig TV receiver may be an STB or IDTV device or a part of the above. In the present document, SSU means over-the-air SSU unless there is no other indication, like local SSU. 4

5 2. Overview of System Software Update The MinDig TV over-the-air SSU service allows network operators to remotely support the owners of the receivers that have got the official MinDig TV approval. From the other side, this is the only possible way for the manufacturers to remotely improve the facilities of the previously sold receivers. The present document introduces the SSU solution applied in MinDig TV platform, based on the ETSI TS v standard. Summary of the MinDig TV SSU service: - SSU simple profile is required, - SI signaling: use of SSU linkage_descriptor is strongly recommended, - PSI signaling: use of SSU data_broadcast_id_descriptor is mandatory, - either standard update carousel or compatible proprietary elementary stream is enabled, - only one manufacturer per SSU data streams is enabled, - the SSU data stream shall be provided by the manufacturer in correctly packetized MPEG-2 TS format, - the SI signaling may refer to SSU images placed into other multiplexes with different ONIDs, which case shall be handled by the receiver. Every receiver shall work with the same signaling mode, but without disturbing each other. 5

6 3. SI Signaling 3.1. Broadcast Environment SSU Linkage Descriptor The first goal of the SSU linkage_descriptor is to trigger the SSU process by its presence. Furthermore, it also provides reference to the data ( Bootloader ) service which is needed to discover the exact location of the available SSU images, even if it is broadcast in another multiplex. [3] This reference is the original_network_id / transport_stream_id / service_id triplet of the Bootloader service. Regarding the Bootloader service, see Chapter 4. The use of SSU linkage_descriptor is not mandatory, but strongly recommended. If an SSU image is present in a broadcast multiplex, then it should be indicated by an SSU linkage_descriptor (linkage_type: 0x09) contained by the first descriptor loop of the NIT (Network Information Table), which linkage_descriptor contains the identifiers of the targeted receiver model. These identifiers [3]: - OUI (Organization Unique Identifier) identifies the manufacturer, - selector byte(s) may identify the model and the version of the available software if present. In the MinDig TV platform, multiple instances of linkage_descriptors may be contained in the NIT, while multiple instances of OUI-loop may be contained in a linkage_descriptor. However, one linkage_descriptor must not contain different OUIs belonging to more than one manufacturer. See Figure 1. NIT linkage_descriptor_1 Manufacturer_1,... linkage_descriptor_2 OUI_1,... Manufacturer_2,... OUI_2,... linkage_descriptor_3 OUI_3, selector_byte(s)_3_1 Manufacturer_3, model_1 Manufacturer_3, model_2 OUI_3, selector_byte(s)_3_2 linkage_descriptor_4 Manufacturer_3, model_3 OUI_3, selector_byte(s)_3_3 Figure 1 Table 1 shows a possible structure of SSU linkage_descriptors placed in the first loop of the NIT ([1] [2] [3]): 6

7 Syntax Number of bits Identifier Value linkage_descriptor() { descriptor_tag 8 uimsbf 0x4A descriptor_length 8 uimsbf automatically calculated transport_stream_id 16 uimsbf defined by AH original_network_id 16 uimsbf defined by AH service_id 16 uimsbf defined by AH (service_id of the referred Bootloader) linkage_type 8 uimsbf 0x09 OUI_data_lenght 8 uimsbf automatically calculated for (i=0; i < N1; i++) { OUI 24 bslbf given by manufacturer selector_lenght 8 uimsbf automatically calculated for (j; j < N2; j++) { selector_byte 8 uimsbf given by manufacturer Table Receiver Rules General The use of SSU linkage_descriptor is not mandatory, but strongly recommended for the receiver. If it is used, then the receiver shall be able to interpret multiple instances of SSU linkage_descriptors placed into the first loop of the NIT, and based on its OUI and selector byte(s), it shall be able to find its own linkage_descriptor, independently from its position inside the descriptor loop. If more then one receiver model, belonging to the same manufacturer, is targeted from the same SSU linkage_descriptor, then the receiver shall be able to find its own reference Cross-referencing If the receiver is using the SSU linkage_descriptor, then it shall be able to handle the SSU cross-referencing. It means that the receiver shall be able to find the referred data service, even if it is broadcast in another multiplex, independently if the referred multiplex was tuned before, or not. Therefore, the receiver shall be able to dynamically extract the necessary broadcast parameters from the second (TS) loop of the NIT by using the ONID and TSID, see Figure 2. The receiver shall be able to handle the frequency_list_descriptor. If there is no RF channel found at the frequency referred by the centre_frequency field of the (terrestrial) delivery_system_descriptor, then the receiver shall check the frequencies listed in the frequency_list_descriptor. The further broadcast parameters listed in the delivery_system_descriptor shall be handled only as recommendation, but during the tuning processes, the receiver shall be able to use the broadcast TPS. 7

8 Transport Stream 1 ts_id 1 on_id 1 broadcast frequency f Transport Stream 2 ts_id 2 on_id 2 broadcast frequency f PAT NIT (actual) linkage_descriptor ts_id 2 on_id 2 service_id 9 OUI x selector_byte(s) y TS_1 ts_id 1 on_id 1 TS_2 ts_id 2 on_id 2 PAT NIT (actual) linkage_descriptor ts_id 2 on_id 2 service_id 9 OUI x selector_byte(s) y PMT (Bootloader) program_number 9... delivery_system_desc. centre_frequency f frequency_list_desc. centre_frequency f3 centre_frequency f Figure 2 8

9 4. PSI Signaling 4.1. Broadcast Environment Data Broadcast Id Descriptor In the MinDig TV platform, one multiplex may contain maximum one data service used for SSU purpose, called Bootloader service. Each elementary stream of the multiplex which carries SSU data (SSU data carousel) will be referred by this service. However, the name of the service may be different than Bootloader, and it may contain further components used for other purpose. During the discovering of the targeted SSU image, the receiver must not be disturbed by the other components of the Bootloader. In the second loop of the PMT of the Bootloader service, all the components, carrying SSU data, shall be marked by a data_broadcast_id descriptor with the data_broadcast_id value of 0x000A. Table 2 shows the body of the second (component) loop of the PMT describing a Bootloader service: [1] [2] [3] Syntax Number of bits Identifier Value stream_type 8 uimsbf given by manufacturer 0x0B is recommended (ISO/IEC type B) reserved 3 bslbf elementary_pid 13 uimsbf defined by AH, PID of the elementary stream containing the referred SSU image(s) reserved 4 bslbf ES_info_length 12 uimsbf for (i=0; i < N1; i++) { descriptor_tag 8 uimsbf descriptor_length 8 uimsbf if (descriptor_tag!= 0x66) { for (j=0;j<n2;j++){ data_byte 8 uimsbf if (descriptor_tag = = 0x66) { data_broadcast_id 16 uimsbf 0x000A OUI_data_lenght 8 uimsbf automatically calculated for (j=0; j < N2; j++) { OUI 24 uimsbf given by manufacturer reserved 4 bslbf update_type 4 bslbf given by manufacturer (0x0 or 0x1) reserved 2 bslbf update_versioning_flag 1 bslbf given by manufacturer update_version 5 bslbf given by manufacturer selector_lenght 8 uimsbf automatically calculated for (k; k < N3; k++) { selector_byte 8 uimsbf given by manufacturer Table 2 9

10 The SSU data_broadcast_id descriptor shall contain at least the OUI and the type of the SSU data stream (update_type field). In addition, it is recommended to contain selector_byte(s) as well, in order to specify the exact model and software version of the targeted receiver(s). Any instance of the second loop in the PMT of the Bootloader service may contain multiple instances of data_broadcast_id descriptors. In other words, more than one data_broadcast_id descriptor may belong to the same SSU data carousel. Furthermore, more than one receiver model, announced by the same OUI, may belong to the same data_broadcast_id descriptor Receiver Rules General If multiple components belong to the Bootloader service, then the receiver shall be able to interpret all of these. Based on its OUI and selector byte(s), the receiver shall be able to find its own SSU data_broadcast_id descriptor, even if more than one descriptor belongs to same component. In the same way, if more then one receiver model is targeted by the same SSU data_broadcast_id descriptor, then the receiver shall be able to find its own reference. 5. Data Carriage The format of the elementary stream, referred from the Bootloader, carrying the SSU data, is not strictly defined, but the use of DSM-CC type B object carousel is strongly recommended. However, the use of proprietary SSU data carousel format is also enabled. The type of the SSU data stream shall be indicated by the update_type field of the data_broadcast_id descriptor. One elementary stream may contain multiple instances of SSU images, if these images belong to the same manufacturer. In other words, only one manufacturer per carousel is enabled in the MinDig TV platform. As it was mentioned above, the use of multiple SSU images per one data carousel is acceptable, but it is rather recommended to place the different receiver models into separated data streams. However, if more than one SSU image is deployed, then the receiver shall be able to find its own one inside the SSU data stream by using its inner signaling. It is the responsibility of the receiver manufacturer that the receiver is able to extract the SSU image in correct form. Similarly, it is also the responsibility of the receiver manufacturer to implement the necessary code validation functions. 6. Implementation 6.1. Initiation of SSU Process With SSU Linkage Descriptor In this case, the receiver shall continuously monitor the NIT of the actually selected multiplex in operation mode, in accordance with Chapter 3. Or, as an alternative, it shall check the NITs of all the pre-stored multiplexes by the quasi-static update function, e.g. after switching off to stand-by state. It is recommended to implement a method (e.g. a full-band scan in stand-by state), that can discover all the available SSU images, even if these images are contained in a multiplex which was not stored before Without SSU Linkage Descriptor In this case, the receiver shall perform a full-band frequency scan in stand-by mode for an appropriate SSU image, in accordance with Chapter 4., at least once per day (but typically after every switch off the device). 10

11 Manually Initiated SSU It is recommended to offer an appropriate item in the system menu to allow the viewer to manually initiate the execution of the SSU process in operation mode. In this case, the receiver should perform a full-band search for finding an appropriate SSU image, but at least the NIT of the actually selected multiplex (or rather all the prestored multiplexes) shall be examined. If the receiver does not monitor the NIT for SSU images continuously in operation mode, and it does not perform the full-band frequency scan immediately after switching to stand-by state either (e.g. this scanning is performed at a fix time, e.g. at 3:00 AM), then the receiver shall offer the possibility of manually initiated SSU from the system menu Viewer Notification about the Available SSU If the downloading of the SSU image is automatically performed in stand-by state, then it is not necessary to notify the viewer about its availability. In other cases, the update process cannot be initiated without the viewer s confirmation; therefore a pop-up notification message shall be displayed with the following information, in Hungarian language (e.g. immediately after the SSU linkage_descriptor is found or before switching off to standby state): - it seems that a new software is available, - it is strongly recommended to accept the software update, - it may take several minutes, - during the software update process, do not power off the device, - during the software update process, the display may become black. In the notification message, the receiver shall offer at least 2 options: - acceptance of the software update, - refusal of the software update. If the viewer refuses the software update, it is recommended that the receiver offers the possibility again when switching off the device to stand-by state. If the viewer refuses the process again, then the possibility of the update shall be displayed again next time Discovering the Location of the SSU Image If the SSU process is initiated by SI signaling (Chapter 3), and it is confirmed by the viewer, then the receiver shall be able to discover the location of the Bootloader service according to the reference of the found SSU linkage_descriptor. If this descriptor refers to another multiplex, then the receiver shall be able to automatically tune this multiplex according to the clause 3.2., even if the referred multiplex has never been tuned before. If the SSU process is executing in stand-by state by performing full-band scan, then the receiver shall examine all the components of all the available data broadcast type services, in accordance to Chapter 4. By knowing the location of the Bootloader service, the receiver shall be able to locate the SSU data stream carrying the referred SSU image, see Chapter Downloading and Writing the SSU Image If the SSU process is initiated in operation mode, then the receiver should be continuously displaying the detailed status information on the whole process, like progress-bar, name of the actually performing function (downloading, flash writing, etc.) and so on. If the software download is executing in stand-by state, the viewer shall be enabled to wake up the receiver anytime (abortion of the SSU process). In this case, the process shall be automatically started again after the next switch off. It is not necessary to give the possibility of the abortion during the memory erasing/writing phases. However, these phases shall not be longer than 2-3 minutes, and it is recommended to inform the viewer about the cause why not possible to wake up the device. 11

12 6.5. Security It is the responsibility of the receiver manufacturer that the device is able to extract its correct SSU image from the tuned multiplex. If any problem occurs during the update process (e.g. power down, TS error, etc.) then the receiver shall be able to handle it as much as possible, and the viewer shall be informed about the critical problems. The receiver manufacturer shall apply some content validation coding when creating the SSU image and/or the carrier SSU data stream, while the receiver shall have an appropriate bootloader software component which can extract the SSU image from the tuned multiplex, and which can release the content validation code before overwriting the old software. If any critical problem occurs during the update process which damages the actually deployed system software (e.g. power down during the flash writing phase), then the receiver should have a secondary safety solution which is capable for restoring a correct state, e.g. by performing an automatic full-band search for a new SSU image. After the successful SSU process, all the system and viewer settings shall be remained the same as were before the SSU. 7. Delivery Package The delivery format in which the manufacturers shall provide the SSU image is the MPEG-2 TS, which shall contain at least the correctly packetized SSU data stream in one, single PID with continually increasing continuity counter, and with 128 kbps bandwidth. It is recommended that the transport stream provided by the manufacturer contains the correctly formatted NIT and the Bootloader service with the necessary SSU linkage_descriptor and data_broadcast_id descriptor as well, but the SSU delivery package shall contain the necessary information (OUI, selector bytes, etc.) at least in an appropriate electronic document format. It is recommended that the transport stream provided by the manufacturer is able to upgrade in itself the software of the targeted receiver model if played-out directly without any modification. It should contain at least one television or radio service as well. The operator will use the received transport stream provided by the manufacturers as input of a process that regenerates the SSU service(s). Therefore, only the SSU data carousel elementary stream will be directly used, while the SI/PSI tables will be re-built. The receivers shall tolerate the changes of the structure of the originally created NIT/PMT; and the changes of the original PIDs and bandwidths. The reserved bits will be changed to 0. The delivery package provided by the manufacturer shall contain the following: 1. correctly packetized MPEG-2 Transport Stream containing at least the SSU data stream, on 128 kbps bandwidth, 2. Identification information (fill out Table 1 and Table 2): model type, OUI, selector_byte(s) of the linkage_descriptor in the NIT, id_selector_byte(s) of the data_broadcast_id_descriptor in the PMT of the Bootloader service, 3. release notes document: at least the list of the receiver functions repaired by the SSU, 4. a description (and the necessary data) about a method which can be used to downgrade the software of the receiver in order to make the SSU testing repeatable. 12