4.6-E1

ARIB TR-B15

Version 4.6-E1

ENGLISH TRANSLATION

OPERATIONAL GUIDELINES FOR DIGITAL

SATELLITE BROADCASTING

ARIB TECHNICAL REPORT

ARIB TR-B15 Version 4.6

(Fascicle 1)

Established on October 26th, 1999

Revised on March 29th, 2000

Revised on May 31st, 2001

Revised on July 27th, 2001

Revised on January 24th, 2002

Revised on March 28th, 2002

Revised on July 25th, 2002

Revised on September 26th, 2002

Revised on March 26th, 2003

Revised on June 5th, 2003

Revised on July 29th, 2003

Revised on October 16th, 2003

Revised on February 5th, 2004

Revised on July 22nd, 2004

Revised on September 28th, 2004

Revised on December 14th, 2004

Revised on March 24th, 2005

Revised on September 29th, 2005

Revised on November 30th 2005

Revised on March 14th, 2006

Revised on May 29th, 2006

Revised on September 28th, 2006

Revised on December 12th, 2006

Revised on May 29th, 2007

Revised on September 26th, 2007

Revised on December 12th, 2007

Revised on March 19th, 2008

Revised on Jun 6th, 2008

Revised on September 25th, 2008

Revised on December 12th, 2008

Association of Radio Industries and Businesses

Version 1.1

Version 1.2

Version 2.0

Version 2.1

Version 2.2

Version 2.3

Version 2.4

Version 2.5

Version 2.6

Version 2.7

Version 2.8

Version 2.9

Version 3.0

Version 3.1

Version 3.2

Version 3.3

Version 3.4

Version 3.5

Version 3.6

Version 3.7

Version 3.8

Version 3.9

Version 4.0

Version 4.1

Version 4.2

Version 4.3

Version 4.4

Version 4.5

Version 4.6

General Notes to the English translation of ARIB Standards and Technical Reports

1. The copyright of this document is ascribed to the Association of Radio Industries and Businesses (ARIB).

2. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without the prior written permission of ARIB.

3. The ARIB Standards and ARIB Technical Reports are usually written in Japanese and approved by the ARIB

Standard Assembly. This document is a translation into English of the approved document for the purpose of convenience of users. If there are any discrepancies in the content, expressions, etc., between the Japanese original and this translated document, the Japanese original shall prevail.

4. The establishment, revision and abolishment of ARIB Standards and Technical Reports are approved at the ARIB

Standard Assembly, which meets several times a year. Approved ARIB Standards and Technical Reports, in their original language, are made publicly available in hard copy, CDs or through web posting, generally in about one month after the date of approval. The original document of this translation may have been further revised and therefore users are encouraged to check the latest version at an appropriate page under the following

URL: http://www.arib.or.jp/english/index.html

ARIB TR-B15

Version 4.6-E1

Preface

The Association of Radio Industries and Businesses (ARIB) works with broadcasters, manufacturers of broadcast equipment, manufacturers of radio equipment, telecommunications carriers and end users to produce standard specifications and technical documents constituting the basic technological requirements of various different forms of radio equipment and systems.

ARIB technical documents provide the industry with specifications designed to ensure the quality and compatibility of radio equipment, particularly with regards to measurement and operational methods, based on “standard specifications” derived from technical standards released by the national government as well as voluntary standards used in the industry.

The current document sets out guidelines for the operation of BS and CS satellite digital broadcasting stations and function specifications for BS satellite digital broadcast receivers and joint BS and CS satellite digital broadcast receivers. The document has been prepared by the ARIB Standards and Specifications

Committee through a fully inclusive process involving close consultation with a range of interests, including manufacturers of radio equipment and devices, telecommunications carriers, broadcasters and end users, in order to guarantee proper levels of fairness and transparency.

This document consists of the following sections:

Part 1 Operational Guidelines for BS Digital Satellite Broadcasting

Volume 1 BS digital satellite broadcasting - Operational guidelines for downloading

Volume 2 Function specifications for BS digital satellite receivers

Volume 3 BS digital satellite broadcasting - Operational guidelines for datacasting

Volume 4 BS digital satellite broadcasting - Operational guidelines for PSI/SI

Volume 5 BS digital satellite broadcasting - Operational guidelines and reception specifications for

Conditional Access System (CAS)

Volume 6 BS digital satellite broadcasting - Operational guidelines for interactive systems

Volume 7 BS digital satellite broadcasting - Operational guidelines for transmission

Volume 8 BS digital satellite broadcasting - Content protection regulations

Part 2 Operational guidelines for CS satellite digital broadcasting and function specifications for joint

BS and CS satellite digital broadcast receivers

Volume 1 CS satellite digital broadcasting - Operational guidelines for downloading

Volume 2 Function specifications for joint BS and CS satellite digital broadcast receivers

Volume 3 Operational guidelines for datacasting to joint BS and CS satellite digital broadcast receivers

Volume 4 CS satellite digital broadcasting - Operational guidelines for PSI/SI

ARIB TR-B15

Version 4.6-E1

Volume 5 CS satellite digital broadcasting - Operational guidelines and receiver specifications for

Conditional Access System (CAS)

Volume 6 CS satellite digital broadcasting - Operational guidelines for interactive systems

Volume 7 CS satellite digital broadcasting - Operational guidelines for transmission

Volume 8 Content protection regulations for joint BS and CS satellite digital receivers

This technical document has been produced for the benefit of manufacturers of radio equipment and devices, broadcasters and end users.

ARIB TR-B15

Version 4.6-E1

Table of Contents

Part 1 Operational Guidelines for BS Digital Satellite Broadcasting

Volume 1 BS digital satellite broadcasting - Operational guidelines for downloading··········· Fascicle 1

Volume 2 Function specifications for BS digital satellite receivers·········································· Fascicle 1

Volume 3 BS digital satellite broadcasting - Operational guidelines for datacasting ················ Fascicle 1

Volume 4 BS digital satellite broadcasting - Operational guidelines for PSI/SI····················· Fascicle 2

Volume 5 BS digital satellite broadcasting - Operational guidelines and reception specifications for

Conditional Access System (CAS) ··········································································· Fascicle 3

Volume 6 BS digital satellite broadcasting - Operational guidelines for interactive systems·········Fascicle 3

Volume 7 BS digital satellite broadcasting -Operational guidelines for transmission ············ Fascicle 3

Volume 8 BS digital satellite broadcasting - Content protection regulations ························· Fascicle 3

Part 2 Operational guidelines for CS satellite digital broadcasting and function specifications for joint BS and CS satellite digital broadcast receivers

Volume 1 CS satellite digital broadcasting - Operational guidelines for downloading··········· Fascicle 4

Volume 2 Function specifications for joint BS and CS satellite digital broadcast receivers ········ Fascicle 4

Volume 3 Operational guidelines for datacasting to joint BS and CS satellite digital broadcast receivers ·································································································Fsscicle 4

Volume 4 CS satellite digital broadcasting - Operational guidelines for PSI/SI ······················· Fascicle 4

Volume 5 CS satellite digital broadcasting - Operational guidelines and receiver specifications for

Conditional Access System (CAS) ··········································································· Fascicle 4

Volume 6 CS satellite digital broadcasting - Operational guidelines for interactive systems···· Fascicle 4

Volume 7 CS satellite digital broadcasting - Operational guidelines for transmission ··········· Fascicle 4

Volume 8 Content protection regulations for joint BS and CS satellite digital receivers ············· Fascicle 4

ARIB TR-B15

Version 4.6-E1

Part 1

Operational Guidelines for BS Digital Satellite

Broadcasting

Volume 1

BS Digital Satellite Broadcasting -

Operational Guidelines for Downloading

ARIB TR-B15

Version 4.6-E1

Contents

1

Introduction ·········································································································································· 1-1

2

Related documents································································································································ 1-1

3

Definition of terms································································································································ 1-1

4

Download uses and prerequisites ·········································································································· 1-2

5

Download transmission guidelines ······································································································· 1-4

5.1

Notifications......................................................................................................................................1-4

5.1.1

Transmission route ················································································································· 1-4

5.1.2

SDTT (Software Download Trigger Table) ············································································ 1-4

5.1.2.1

Receiver software update...................................................................................................1-4

5.1.2.2

Data common to all receivers ............................................................................................1-5

5.1.3

Transmission cycle and transmission speed············································································ 1-5

5.1.3.1

Receiver software updates .................................................................................................1-6

5.1.3.2

Data common to all receivers ............................................................................................1-6

5.1.4

SDTT updates························································································································· 1-6

5.1.5

TS packet conversion of SDTT and associated transmission regulations ······························· 1-6

5.1.6

Version number ······················································································································ 1-6

5.1.6.1

Receiver software update...................................................................................................1-6

5.1.6.2

Data common to all receivers ............................................................................................1-6

5.2

Transmission of download content ...................................................................................................1-7

5.2.1

Transmission route ················································································································· 1-7

5.2.2

Transmission speed ················································································································ 1-7

5.2.3

Download time, period and cycle ··························································································· 1-8

5.2.3.1

Receiver software updated .................................................................................................1-8

5.2.3.2

Data common to all receivers ............................................................................................1-8

5.2.4

PID and tag values assigned to download content ·································································· 1-9

5.2.5

Module and Carrousel structure······························································································ 1-9

5.2.5.1

Receiver software update...................................................................................................1-9

5.2.5.2

Data common to all receivers ............................................................................................1-9

5.2.6

DII (DownloadInfoIndication) ····························································································· 1-10

5.2.6.1

Receiver software update.................................................................................................1-10

5.2.6.2

Data common to all receivers ..........................................................................................1-10

5.2.7

DDB (DownloadDataBlock) ·································································································1-11

5.2.7.1

Receiver software update.................................................................................................1-11

5.2.7.2

Data common to all receivers ..........................................................................................1-11

5.3

Transmission timing of notification information and download content........................................1-13

5.3.1

Receiver software update ····································································································· 1-13

5.3.2

Data common to all receivers ······························································································· 1-14

1-i―

ARIB TR-B15

Version 4.6-E1

5.4 Emergency halt in receiver update service .....................................................................................1-14

5.5 Suspension of receiver update service ............................................................................................1-14

5.6 Summertime (daylight saving time)................................................................................................1-14

5.7 Security ...........................................................................................................................................1-14

5.7.1 Receiver software update ······································································································1-14

5.7.2 Data common to all receivers ································································································1-14

6 Receiver guidelines for downloads ······································································································1-14

6.1 Memory...........................................................................................................................................1-14

6.2 Operation.........................................................................................................................................1-15

6.2.1 Reservation function ·············································································································1-15

6.2.2 Reception function ················································································································1-16

6.2.3 Consent function ···················································································································1-16

6.2.4 Recovery from abnormal event function ···············································································1-16

6.2.5 Power function ······················································································································1-17

6.2.6 Version number display function···························································································1-17

6.3 Common data reception guidelines.................................................................................................1-17

6.3.1 Cross-media standardization of genre codes, program characteristics codes and keywords·······························································································································1-17

6.3.2 Receiver tracking of version number of common data ··························································1-18

6.3.3 Downloading·························································································································1-18

7 Operational guidelines for receiver information update services ·························································1-18

7.1 Uploading guidelines ......................................................................................................................1-18

7.1.1 Provision of download software ····························································································1-18

7.1.2 Quality check ························································································································1-18

7.1.3 Data common to all receivers ································································································1-18

7.1.4 Creation and delivery of notification information ·································································1-19

7.1.5 Scope of responsibility ··········································································································1-19

7.1.6 Download costs ·····················································································································1-19

7.1.7 Fee-paying download services ······························································································1-19

7.1.8 Pre-download test signal ·······································································································1-19

7.2 Engineering services .......................................................................................................................1-19

7.2.1 Definition ······························································································································1-19

7.2.2 Operation ······························································································································1-19

7.2.2.1 Objective..........................................................................................................................1-19

7.2.2.2 Model ...............................................................................................................................1-19

7.2.2.3 Engineering slot transmission signal ...............................................................................1-20

7.2.2.4 Engineering slot transmission guidelines ........................................................................1-21

7.2.2.5 Engineering slot reception guidelines..............................................................................1-21

Appendix 1 Operational rules for download service ·····································································1-23

1-ii―

ARIB TR-B15

Version 4.6-E1

1 Introduction

BS digital broadcast receiver data updating services are provided in accordance with ministerial ordinances and notifications from the Ministry of Internal Affairs and Communications, as well as specifications and guidelines set out by the Association of Radio Industries and Businesses (ARIB) including specifications for Receiver for

Digital Broadcasting (ARIB STD-B21), Data Coding and Transmission Specification for Digital Broadcasting

(ARIB STD-B24) and Service Information for Digital Broadcasting System (ARIB STD-B10). The current document, BS Digital Satellite Broadcasting — Operational Guidelines for Downloading, was formulated in response to the need for detailed operational guidelines on the actual design of receiver units.

For details of operational matters, see the Download Service Usage Agreement from The Association for

Promotion of Digital Broadcasting (Dpa).

(1) ARIB STD-B21 Receiver for Digital Broadcasting

(2) ARIB STD-B10 Service Information for Digital Broadcasting System

(3) ARIB STD-B24 Data Coding and Transmission specification for Digital Broadcasting

3 Definition of terms

Receiver software

Data common to all receivers

Logo

Logo ID

Logo type

Genre code

Constituent components of the receiver software, including applications, libraries, the OS, drivers and data.

Data which is stored in and used by all receiver units, including logo data, genre code tables, program characteristics code tables and keyword lists. Common data is normally stored in non-volatile memory.

Logos for operations such as EPG and program selection are common to all receivers and are defined separately for every broadcaster and/or service.

IDs are assigned to all broadcaster logos, to ensure consistency of usage by broadcaster associations and other organizations. Logo IDs are common to all six logo types.

Six different types of logo data defined for various display formats including

SDTV and HDTV.

Code used in content_nibble_level_1 (4 bit) and content_nibble_level2 field (4 bit) to indicate the genre. Often used in content descriptors.

Program characteristics code

Keywords

Code used in user_nibble field (8 bit) to indicate the genre. Often used in content descriptors.

Pre-defined terms used in program descriptions, such as “starring,” “producer” and “storyline.”

Module information Download module information contained in moduleInfoByte in DII.

Notification information

Information used for notifications including download service ID, schedule information and receiver type. Sent via SDTT.

Schedule information Download start time and duration stored in SDTT schedule loop.

Forced download

Selected/optional

Download requiring forced execution.

A download that has been chosen by the viewer from a list of executable download downloads on the selection screen.

License information Information about whether a forced download is permitted without restrictions using the receiver’s consent function.

1-1-

ARIB TR-B15

Version 4.6-E1

4 Download uses and prerequisites

• Update receiver software

Modifies the receiver software. Includes bug fixes, modifications designed to repair problems caused by differences in interpretation of operation between transmitter and receiver, and general improvements to the display and to response speed and user controls.

• Update common receiver data

Updates broadcaster logo data, program genre code tables, program characteristics code tables and keyword lists common to all receivers.

(1) Update genre code tables and program characteristics code tables a. Adds information only; does not modify previously defined areas b. Maximum length of table definitions is 20 characters; this applies to updated data. c. Program characteristics code applies to 0xE0 content_nibble only. Text information is statement based on actual display.

(2) Update keyword list a. Adds information only; does not modify previously defined areas. b. Maximum length of keywords is 8 characters/16 bytes; this applies to updated data. c. Keywords are item names encoded within SI extension format event descriptors, rather than codes as such.

(3) Logo data updates a. Updating may involve additions and/or modification of previously defined information. Logo data can be immediately transmitted after a logo ID (9-bit) is assigned to it. For more information on logo IDs, see descriptions and lists related to logo IDs in 8.2.4 in Section 7. b. Logo data is compressed by the broadcaster. Large logos should be compressed to no more than 50% of the original data size, and small logos by no more than 75%. A single piece of logo data may be shared among multiple service_id. Based on the anticipated number of broadcasters and services during the

BS-5 satellite phase, receiver units must be designed to hold 1,000 services and 300 pieces of logo data in non-volatile memory. Logo data is administered within the receiver unit in accordance with the logo

ID. The logo ID is common to all six logo types. c. Table 4-1 shows logo size patterns

1,2

.

1

2

HD logo size patterns assume screen resolution of 960

× 540 pixels.

720P format is the same as for HD.

1-2-

ARIB TR-B15

Version 4.6-E1

Table 4-1 Size patterns (logo types) of transmission logos

Type of logo Vertical bits

HD large

36

Horizontal bits

64

Expected aspect ratio

Display format

Square pixel 9 : 16

Value of logo_type

0x05

Memory bytes required per logo

1152

HD small

SD4:3 large

SD4:3 small

SD16:9 large

SD16:9 small

27

36

24

36

24

48

72

48

54

36

Square pixel

1.118 : 1

1.118 : 1

1.118 : 1.333

9 : 16

1.118 : 1.333

9 : 16

9 : 16

9 : 16

9 : 16

0x02

0x03

0x00

0x04

0x01

972

1296

864

972

648

The design and color must be the same within the service, irrespective of size pattern differences.

Logo data designs may only use the 128 common fixed colors. No other colors may be used.

Prior to compression, the logo data must use 8-bit color per dot. The color palette of common fixed colors is used to convert between dot color values and the actual colors to be displayed. The color palette and the common fixed colors are stipulated in Common Fixed Colors and Conversion Table

(Ed. 3).

PNG is used to compress logos. PNG employs the following format, as per “W3C

Recommendations 1996/10/01 Version 1.0.”

1) Only IHDR, IDAT and IEND chunks may be used.

2) IHDR description consists of the following information:

Width: 4 bytes Number of horizontal dots in logo

Height:

Color depth:

Color type:

4 bytes Number of vertical dots

1 byte

1 byte

=8

As per Ed. 3

Filtering: =0

Interlace: =0

3) All other parameters are as per Ed. 3. d. The logo ID, reference service ID and logo data associated with a logo are all sent in the event of a change to any one of these. The updated data must be sent, rather than the changes to the original data.

Where the update results in deletion of the reference service ID, the data must be overwritten the next time the logo ID is used.

Example 1

When this logo:

Logo ID 10, reference service ID A, B, C and logo data X is modified to:

Logo ID 10, reference service ID A and logo data X, and

1-3-

ARIB TR-B15

Version 4.6-E1

Logo ID 11, reference service ID B & C and logo data Y the download data will be:

Logo ID 10, reference service ID A and logo data X, and

Logo ID 11, reference service ID B & C and logo data Y.

Example 2

When these logos:

Logo ID 10, reference service ID A and logo data X

Logo ID 11, reference service ID B and logo data Y are modified to:

Logo ID 10, reference service ID A & B and logo data X the download data will be:

Logo ID 10, reference service ID A & B and logo data X

5.1 Notifications

Fully TS transmission.

5.1.2 SDTT (Software Download Trigger Table)

For the time being, service_id defined in SDTT and used for transmission content shall be limited to 929.

The maximum length of each section in SDTT is 4,096 bytes. Multi-sections are permitted in sub-tables in the event of a receiver software update. The maximum number of sections is 180, including receiver software updates and data common to all receivers.

5.1.2.1 Receiver software update

Schedule information can be displayed for the current day only, both the current and next day, or the next day only. The maximum size of SDTT sections is 4,096 bytes. Provided that this is not exceeded, there are no restrictions on the number of schedule loops or superimposed download content descriptors, the type of information in download content descriptors, the text length or the number of modules. The number of schedule loops is, however, subject to limitations associated with compilation. The download_id is the same in all cases, irrespective of the number of download content descriptors. More than one content may be used, for instance, in order to use group_id to display a different message for each group; however the schedule and download IDs must be the same.

Further, maker_id must use the assigned ID (numbered by ARIB). In the case of downloads requested by the

1-4-

ARIB TR-B15

Version 4.6-E1 manufacturer (such as receiver software updates), model_id, version_id and group_id are administered by the respective manufacturers and are not subject to any restrictions.

Multi-sections are permitted in all sub-tables, for instance, in order to use group_id to send different content for each group.

Table 5-1 Update IDs

Bits

SDTT structure and meanings are as per ARIB STD-B21, 12.2.1 “Transmission Scheme of Notification

Information.”

Examples of notification information are given in ARIB STD-B21, Appendix-3, 3.1 “Notification

Information.”

5.1.2.2 Data common to all receivers

Sub-tables for data common to all receivers are configured as a single section. The number of schedule information loops is 0. SDTT is sent simultaneously with the Carrousel that transmits the download content, but not at any other time. Since downloads of data common to all receivers are treated as “Common to All

Receiver” models, maker_id and model_id must use 0xfffe or similar that shows “Common to All

Receivers.”

Section 5.1.4.2 describes version_id. The group_id is always 0; group_id is not used in the case of data common to all receivers.

The number of download content descriptors and num_of_contents is 1. compatibility_flag and text_info_flag in the download content descriptor are normally 0; these can be ignored by receivers.

Descriptions in module_infor_byte are the same as moduleInfoByte in DII, normally superimposition of

Name descriptors only; other information can be ignored by receivers. Private data length is normally 0; this can be ignored by receivers. Download content descriptor add_on is always 0, and is not used.

5.1.3 Transmission cycle and transmission speed

The SDTT is sent once every ten minutes or more. Maximum transmission speed is 10 kbps (see also estimated transmission speeds below).

The SDTT is not sent if no download schedule exists. If the SDTT has not been received after waiting for at least 10 minutes, the receiver may assume there to be no SDTT for the current day. Note however that the

1-5-

ARIB TR-B15

Version 4.6-E1 absence of SDTT transmission for a given TS may in fact be due to an equipment fault.

○ Assumptions used in calculation

• Maximum length of individual SDTT sections = 4,096 bytes

• Maximum number of sections = 180

• No multi-section transmission for TS packets

• Sent once every ten minutes

○ The number of TS packets required for each section is:

4096/183 = 23 TS packets

○ The number of TS packets required for the entire table is:

23

× 180 = 4140 TS packets

○ The average TS rate (based on one sent every 10 minutes) is:

(4140

× 188 × 8) ÷ 600 ≈ 10.38 kbps

5.1.3.1 Receiver software updates

The SDTT schedule information frequency may be reduced in line with the maximum sub-table size and transmission cycle and speed.

5.1.3.2 Data common to all receivers

The number of schedule information loops is 0. The SDTT is sent simultaneously with the Carrousel that transmits the download content, but not at any other time.

The SDTT is normally updated once per day, at 0:00 a.m. From time to time it is also updated on an ad-hoc basis as necessary.

5.1.5 TS packet conversion of SDTT and associated transmission regulations

As per ARIB TR-B15 Ed. 4.

5.1.6.1 Receiver software update

There are no restrictions on assignment and administration of version numbers.

5.1.6.2 Data common to all receivers

version_id uses the common version number contained in data common to all receivers which is administered by the broadcaster responsible for downloading said data. Figure 5-1 shows the version numbering system.

1-6-

ARIB TR-B15

Version 4.6-E1

A Co. logo ver1.0 ver1.0 ver1.0 ver1.1 ver1.1 ver1.1 ver1.1 ver1.1

B Co. logo

C Co. logo ver1.0 ver1.0 ver1.0 ver1.0

Reserved words ver1.0 ver1.0 ver1.0 ver1.1

Genre table ver1.0

Common data version number ver 1.0 ver1.0 ver1.0 ver1.0

Version number applies to common data in its entirety ver 1.1

ver 1.2

ver 1.3

ver 1.1 download ver 1.2 download ver 1.3 download

Common data generationn

Contents of common data download

B Co. logo ver1.1

A Co. logo ver1.1

Reserved words ver1.1

A Co. logo ver1.1

B Co. logo ver1.1

Normally only the updated portions are transmitted, although sometimes the revision history is sent instead.

Figure 5-1 Common data downloads and version numbering system

The version_id reverts to 0 after 4,095. To enable the version number to begin again at 0, version_id is split into two domains: 0 to 2,047 and 2,048 to 4,095. If the current version number is between 2,048 and 4,095 and the downloaded common data version number is between 0 and 2,047, the downloaded version number is deemed to be higher than the current version number and the receiver proceeds with the download.

5.2 Transmission of download content

Regulations on addition to the DSM-CC table Carrousel are set out in ARIB STD-B21 12.2.2, “Transmission

Scheme of the Content.”

For information on DII module Info, refer to ARIB STD-B21 Appendix 3, 3.1.4 “DII Module Info.”

Multi-section transmission is permitted for download content.

For the time being, service_id for download content transmission shall be limited to 929.

Content may be transmitted at 0.5 slots (TS rate = 0.5434375 Mbps) or two slots (TS rate = 2.17375 Mbps).

1-7-

ARIB TR-B15

Version 4.6-E1

5.2.3 Download time, period and cycle

Download content is sent as a single piece of content using multiple frames, where one frame is defined as ten seconds.

Figure 5-2 shows the download content transmission schedule. The receiver manufacturer supplies the download broadcaster with information about the desired download period, number of transmissions, and duration (in multiples of 10 seconds). The download period varies in accordance with the number of units performing downloads. The download broadcaster draws up a schedule in consultation with the receiver manufacturers. The Carrousel cycle is the maximum number of cycles (as an integer) that can be sent within the duration specified by the receiver manufacturer (in multiples of 10 seconds). After content equivalent to the maximum number of cycles has been sent, a dummy (either null packets, or adaptation fields only, or empty Carrousel packets) is inserted for the remaining time through to the end of the required duration.

Model #N

10 sec

Repeated every 24 hours

Up to 180 models

Time

High-speed transmission

(2.0Mbps)

Low-speed transmission

(0.5Mbps)

… all receivers

Model

#1

Model

#2

Model

#X all receivers

Model

#Y

Model

#Z

Model

#179

Figure 5-2

20 min.

Reference model of download content transmission schedule

(low transmission speed for data common to all receivers and models #2 and #Z, high transmission speed for all others)

5.2.3.2 Data common to all receivers

Data common to all receivers is sent at least once every 20 minutes, as shown in Figure 5-2. The common data is treated as a “Common to All Receivers” model. The business or group submits a request for the desired download period to the download broadcaster. The download period varies in accordance with the number of units performing downloads. The download broadcaster draws up a schedule in consultation with the receiver manufacturers.

The Carrousel cycle is three cycles. After content equivalent to three cycles has been sent, dummy data

(either null packets, or adaptation fields only, or empty Carrousel packets) is inserted in the remaining space through to the end of the required duration.

1-8-

ARIB TR-B15

Version 4.6-E1

5.2.4 PID and tag values assigned to download content

PID and tag values for download content are used to augment the download content at the receiver. There are nine types of PID and tag values available: one for data common to all receivers, and eight for receiver software. .

Eight types of PID and tag values are assigned to receiver software for each model in turn, in the order of transmission.

Model 1

(PID1,tag1)

Model 2

(PID2,tag2)

Model 3

(PID3,tag3)

Model 7

(PID7,tag7)

Model 8

(PID8,tag8)

Model 9

(PID1,tag1)

Model 10

(PID2,tag2)

Model 11

(PID3,tag3)

Figure 5-3 Assignment of PID and tag values (without data common to all receivers)

Model 1

(PID1,tag1)

Common

(PIDk,tagk)

Model 2

(PID2,tag2)

Model 6

(PID6,tag6)

Model 7

(PID7,tag7)

Model 8

(PID8,tag8)

Model 9

(PID1,tag1)

Model 10

(PID2,tag2)

Figure 5-4 Assignment of PID and tag values (with data common to all receivers)

Where the number of units updated is eight or less units, dummy data is inserted. Each dummy lasts 10 seconds, and consists of either null packets, or adaptation fields only, or empty Carrousel packets.

Model 1

(PID1,tag1)

Model 2

(PID2,tag2)

Dummy 3

(PID3,tag3)

Dummy 7

(PID7,tag7)

Dummy 8

(PID8,tag8)

Model 1

(PID1,tag1)

Model 2

(PID2,tag2)

Dummy 3

(PID3,tag3)

Figure 5-5 Assignment of PID and tag values for eight or less units

Where the number of units updated is not a multiple of eight, dummy data is sent continuously until a multiple of eight is reached.

Example: If the number of units is 70, two dummies (PID7 and PID8) will sent in order to bring the total to

72.

Similarly, dummy data is used in daily updates to enable assignment of PID and tag values in sequence.

5.2.5 Module and Carrousel structure

5.2.5.1 Receiver software update

There are no stipulations regarding the modules in the Carrousel.

5.2.5.2 Data common to all receivers

Normally only the modified portions of content are sent. However, sometimes the cumulative total of the modifications is sent instead, in case the receiver has not received all of the modified portions. Content is not downloaded by type, such as logo data and genre code tables; these are all together in a single Carrousel.

Genre code tables, program characteristics code tables and keyword lists each consist of one module.

Logo data has modules for six different logo types. Every module includes logo data for all logo IDs to be

1-9-

ARIB TR-B15

Version 4.6-E1 updated. Logo data is sent for all six types. Figure 5-4 shows a sample Carrousel structure for data common to all receivers.

DII

Name Descriptor module_id = 0 module_id = 1 module_id = 2 module_id = 3 module_id = 4 module_id = 5 module_id = 6 module_id = 7 module_id = 8

“GENRE”

“FEATURE”

“KEYWORD”

“LOGO-00”

“LOGO-01”

“LOGO-02”

“LOGO-03”

“LOGO-04”

“LOGO-05”

DDB

CommonTableDataModule()

CommonTableDataModule()

KeywordDataModule()

(genre code table)

(program characteristics table)

(reserved words list)

LogoDataModule() (logo data = SD4:3 small)

LogoDataModule() (logo data = SD169 small)

LogoDataModule() (logo data = HD small)

LogoDataModule()

LogoDataModule()

(logo data = SD large)

(logo data = SD 169 large)

LogoDataModule() (logo data = HD large)

(common data configured as 1 Carrousel) (logo data module for each logo type)

Figure 5-6 Sample common data Carrousel structure

5.2.6.1 Receiver software update

To improve the reliability of downloads, it is necessary to send compatibility descriptors that define the models eligible for downloads, containing the same maker_id, model_id, version_id, group_id and download_id values as those in the SDTT. Other information is not stipulated.

5.2.6.2 Data common to all receivers

To improve the reliability of downloads and transmission of module information, it is necessary to send compatibility descriptors that define the models eligible for downloads, containing the same maker_id, model_id, version_id, group_id and download_id values as those in the SDTT. The modele_info-byte descriptor may omit the type descriptor but must contain the name descriptor. The version must conform to

5.1.4.2. Table 5-2 shows the naming conventions for name descriptors, while Table 5-3 shows correspondence between name descriptors and logo data (where applicable).

Table 5-2

Download content

Genre code table

Program characteristics code table

Keywords list

Channel logo

Name descriptors and download content

Name descriptor

GENRE

FEATURE

KEYWORD

LOGO-XX

Remarks

See Table 5-4

See Table 5-5

See Table 5-6

See Tables 5-3 and 5-6

XX denotes logo_type

1-10-

Table 5-3 Name descriptors and download content for logo data

Logo type

HD large

HD small

SD4:3 large

SD4:3 small

SD16:9 large

SD16:9 small

Name descriptor

LOGO-05

LOGO-02

LOGO-03

LOGO-00

LOGO-04

LOGO-01

ARIB TR-B15

Version 4.6-E1

5.2.7.1 Receiver software update

No stipulations.

5.2.7.2 Data common to all receivers

Tables 5-4 and 5-6 show the data formats for the genre code table, program characteristics code table, keywords list and logo data.

Table 5-4

Data structure

Syntax of genre code table and program characteristics code table

Bytes

CommonTableDataModule(){

number_of_loop

table_code

level_1_name_length

name_char.

}

level_2_name_length

name_char.

}

}

}

1

1

1

1

1

1

1-11-

ARIB TR-B15

Version 4.6-E1

number_of_loop(the number of code loops): repetitions of code information loops following

table_code(code): newly specified content code

For the genre code table, it is 1 byte of data, including level 1 and 2 genre classifications. For the program characteristics code table, it is 1 byte of data, including level 1 and 2 characteristics.

level_1_name_length(the length of level 1 name): number of bytes in level 1 name following. This value is

0 when there are only level 2 additions, and the level 1 name is not encoded.

name_char.(the description of level 1 name): series of text information fields describing level 1 names.

Text encoding follows SI text string encoding rules. For more information about text encoding, refer to

SI/EPG document.

level_2_name_length(the length of level 2 name): number of bytes in level 2 name following

name_char.(the description of level 2 name): series of text information fields describing level 2 names.

Text encoding follows SI text string encoding rules.

Table 5-5

Data structure

KeywordTableDataModule(){

number_of_loop

Syntax of keywords list

Bytes

name_length

name_char.

}

}

}

number_of_loop(the number of loops): repetitions of keyword information loops following

1

1

1

name_length(the length of keyword name): number of bytes in keyword name following

name_char.(the description of keyword name): series of text information fields describing keywords. Text encoding follows SI text string encoding rules.

1-12-

ARIB TR-B15

Version 4.6-E1

Table 5-6 Syntax of logo data

Data structure

LogoDataModule(){

logo_type

number_of_loop

for(i=0; i< number_of_loop; i++){

logo_id

number_of_services

for ( j=0; j<number_of_services; j++ ) { original_network_id transport_stream_id

service_id

}

data_size for(j=0;j< data_size; j++) {

data_byte

}

}

}

logo_type(logo type): shows logo type (as per Table 4-1)

number_of_loop(the number of loops): repetitions of logo information loops following

Bytes

1

2

2

1

2

2

2

2

1

logo_id(logo ID): value which enables the receiver to recognize the logo data. The first 7 bits are reserved, and the logo_id value is assigned to the last 9 bits (TBD). The reserved bits are all ‘1’.

number_of_services(the number of service): number of services using the following logo. (This enables the same logo to be shared among multiple services.)

original_netowork_id(the specification of original network): specifies the original network using the logo data

transport_stream_id(the specification of transport stream): specifies the transport stream using the logo data

service_id(the specification of service): ID unique to the service

data_size(size of logo data): number of bytes in logo data following.

data_byte(data): actual logo data encoded in PNG format

5.3 Transmission timing of notification information and download content

5.3.1 Receiver software update

The start time for transmission of download content is specified in the SDTT as start_time. It is important that power control processes for the purpose of schedule confirmation via SDTT recapture or download content acquisition are properly completed prior to start_time, in order to prevent any portion of the first download content from being lost.

1-13-

ARIB TR-B15

Version 4.6-E1

5.3.2 Data common to all receivers

The SDTT transmission status can be used to determine if download content transmission is in progress. It is important that power control processes for the purpose of SDTT recapture or download content acquisition are properly completed prior to DII acquisition, in order to prevent any portion of the first download content from being lost.

5.4 Emergency halt in receiver update service

In the event of an emergency halt in the download, download content transmission will cease. However,

SDTT transmission may continue, so the receiver should perform a timeout.

5.5 Suspension of receiver update service

If there is no download content whatsoever, transmission of SDTT and download content is suspended. PMT transmission continues, however, which means that PMT_PID may remain unchanged in PAT.

5.6 Summertime (daylight saving time)

SDTT start_time and transmission times are based on UTC + 9 hours, irrespective of local summertime schemes.

5.7 Security

5.7.1 Receiver software update

Encryption of download content associated with receiver software updates for cipher or other purposes is receiver implementation dependent.

Security guidelines are provided in ARIB STD-B21, Appendix 3, 5.2 “Transmission Guidelines.”

5.7.2 Data common to all receivers

Nothing in relation to security.

6 Receiver guidelines for downloads

6.1 Memory

(1) The memory buffer should be capable of keeping up with the transmission speeds of notifications and download software.

(2) The memory area allocation for common data should be 10 KB for the genre code table, program characteristics code table and keyword list, plus additional memory as required for logo data. Of the six types of logo data sent, the receiver implementation determines which will be acquired. Table 6-1 shows

1-14-

ARIB TR-B15

Version 4.6-E1 the memory requirements for each logo type. For details of common data downloads, see Section 6.3

“Common Data Reception Guidelines.”

(3) Protection against potential download errors during the receiver software update process is provided by either a two-bank memory structure whereby two banks of non-volatile memory enable full restoration to pre-download status, or a “one bank +

α” structure whereby one bank is overwritten by the download and a dedicated program is permanently stationed in memory.

(4) Memory areas used to store logo data for services that are no longer required may be overwritten with logo data for newly added services.

Table 6-1 Logo data size

(300 logos, 1,000 services)

HD large

HD small

SD4:3 large

SD4:3 small

SD16:9 large

SD16:9 small

354 KB

300 KB

397 KB

267 KB

300 KB

202 KB

Basis of calculation: 300

× the number of bytes specified in Table 4-1 (Size patterns/logo types for transmitted logos) and 1,000

× the 8 byte look-up table (original_network_id, transport_stream_id, service_id, logo_id).

Hardware size and performance specifications are detailed in ARIB STD-B21, Section 12.3.2 Necessary

Capacity and Performance of Receiver Hardware.

Flash memory implementation requirements are detailed in ARIB STD-B21, Appendix 3, Section 5.1.1.3

Flash Memory Implementation.

6.2 Operation

This function accepts notifications in accordance with the operational status and arranges software download reservations.

(1) The reservation function analyses each notification as it is received to determine whether it constitutes a download of data common to all receivers or a receiver software download consistent with the receiver information. Depending on the outcome, the reservation function then reserves the download.

(2) If the notification information contains “forced download” and user consent is set to on, then the download is reserved without the user’s knowledge.

(3) If the notification information contains “optional download,” the available options are displayed together with the means of selection. The user selects the download(s) to be reserved. When the display menu

1-15-

ARIB TR-B15

Version 4.6-E1 becomes available for the selected content, the user is notified via a small icon (or equivalent) on the screen. The user then accesses the menu to display the selected content. Thus, content is not displayed without direct user intervention. This procedure is designed to cause minimal disturbance to program enjoyment.

For more information about required functions, refer to ARIB STD-B21, Section 12.3.1, Necessary

Functions.

For examples of when downloads are performed and how the outcomes are evaluated, see ARIB STD-B21,

Appendix 3, Section 5.1.4, Download Determinations and Outcomes.

This function receives download software sent via DSM-CC data Carrousel on the basis of notification information and stores it in non-volatile memory.

(1) Downloaded software is subject to validity and conformance checks, then stored in non-volatile memory in accordance with notification information.

(2) Downloads are performed in accordance with notification information. Where schedule information exists

3

, downloads may also be performed in standby mode in accordance with schedule information. If no schedule information exists

3

, the download may be performed when the power is switched off, provided that the software downloading process does not impact on program viewing (including reservation viewing). Once writing to non-volatile memory begins, receiver operations can be barred until writing is finished.

Operational scenarios are described in ARIB STD-B21, Appendix 3, Section 5.1.1, Receiver Download

Operational Scenarios.

The consent function stores the user’s consent information and allows the receiver to perform downloads by default.

For more information about required functions, refer to ARIB STD-B21, Section 12.3.1, Necessary

Functions.

6.2.4 Recovery from abnormal event function

This function restores the receiver to normal operating status following an abnormal status event during reception of download software, such as power off, suspension of processing or data error detected.

3

"Schedule information exists" means the loop count for the schedule information in SDTT is not 0, and

"No schedule information exists" means it is 0.

1-16-

ARIB TR-B15

Version 4.6-E1

(1) If abnormal status is detected during download processing, the download software data that has been written is rendered invalid and the download software is re-acquired.

(2) In the twin-bank memory structure, two areas are provided for download overwriting during receiver software updates. In the event of an abnormality, the pre-download program is executed. In the “single bank + α” memory structure, a single download overwriting area is provided together with a dedicated non-writeable program area. In the event of an abnormality, the dedicated program is executed, thus guaranteeing a minimum level of functionality.

(3) In the event of an abnormality while downloading data common to all receivers, the structure should at the very least prevent the loss of any data prior to the download.

For more information about required functions, refer to ARIB STD-B21, Section 12.3.1, Necessary

Functions.

Operational scenarios are described in ARIB STD-B21, Appendix 3, Section 5.1.1, Receiver Download

Operational Scenarios.

This function regulates the power based on notification information. It supplies power to the circuit used to receive software information when instructed by the local timer, then switches the power off again after the software has been downloaded and the download completed. It also maintains power supplies to the minimum required circuits when the main power is switched off, and switches the power off again after the software has been downloaded and the download completed. It works in the same way as power regulation for EMM capture.

For more information about required functions, refer to ARIB STD-B21, Section 12.3.1, Necessary

Functions.

6.2.6 Version number display function

This function displays current valid version information in the event that the download function fails to operate properly and the receiver manufacturer and/or broadcaster provides assistance to the user via telephone.

(1) Ideally, the version number should be protected so that it is not displayed in the course of normal user operations, and can only be accessed via a specific sequence of operations conducted at power on time.

(2) The version number should be configured in such a way that it is not readily understood by the viewer.

6.3 Common data reception guidelines

6.3.1 Cross-media standardization of genre codes, program characteristics codes and keywords

As noted in Section 4, tables for genre codes, program characteristics codes and keywords are standardized for both terrestrial and digital satellite broadcasting. However, the codes themselves may be used separately

1-17-

ARIB TR-B15

Version 4.6-E1 by different broadcast media. Codes that are used by only one transmission medium must appear as

“undefined” in other media, and cannot be used for other purposes.

6.3.2 Receiver tracking of version number of common data

Common data is downloaded via both terrestrial and digital satellite transmission routes when adding common codes used by both, in order to accommodate dedicated receiver units. If codes are added from either BS or CS digital only, the download is performed via the corresponding transmission route only. For digital satellite broadcasts, the version number applies to the common data in its entirety, including the logo, genre code table, program characteristics code table and keywords. For terrestrial broadcasts, the version number applies to common data for the genre code table, program characteristics code table and keywords list only. This means that version numbers can differ between terrestrial and digital satellite broadcasting.

Dedicated BS digital receivers are allowed to use version numbers that are applicable only to digital satellite broadcasts.

6.3.3 Downloading

Dedicated BS digital receivers use BS digital common data version numbers, and perform downloads when version updated content is delivered. Receivers should be designed to accommodate the potential for codes that are exclusive to terrestrial digital broadcasting to be accidentally used in BS digital satellite SI.

7 Operational guidelines for receiver information update services

Receiver manufacturers requiring download capability must supply download content as DII and DDB messages in section format and SDTT in section format to the download broadcasters.

The download broadcasters submit the supplied download software data to a quality check.

Uploading guidelines are set out in ARIB STD-B21, Appendix 3, Section 4 “Upload format for receiver software.”

Quality assurance for download software is described in ARIB STD-B21, Appendix 3, Section 5.2.6 “Quality assurance for download software.”

The procedure for submission of download software is described in ARIB STD-B21, Appendix 3, Section

5.2.7 “Submission of download software.”

7.1.3 Data common to all receivers

Data common to all receivers is administered by the download broadcaster.

Similarly, logo ID is managed centrally.

1-18-

ARIB TR-B15

Version 4.6-E1

Downloading of data common to all receivers is described in ARIB STD-B21, Appendix 3, Appendix A

“Download format for data common to all receivers.”

7.1.4 Creation and delivery of notification information

The download broadcaster creates and delivers notification information on the basis of on the SDTT section data from the receiver manufacturer.

Creation and delivery of notifications is described in ARIB STD-B21, Appendix 3, Section 4 Upload format for receiver software.

7.1.5 Scope of responsibility

The download broadcaster guarantees transmission of the data supplied by the receiver manufacturer. The receiver manufacturer guarantees operation of the receiver when the data is transmitted as stated.

Refer to the guidelines set out in ARIB STD-B21, Appendix 3, Section 5.2.8 “Apportionment of transmission costs.”

7.1.7 Fee-paying download services

Fee-paying download services are beyond the scope of the operational regulations.

For test purposes, receiver software updates may employ methods such as specifying the model_id and version_id of targets that are not yet on the market.

Similarly, data common to all receivers may use 0xfffd for the maker_id and model_id.

7.2.1 Definition

Engineering services are defined as services with the primary objective of delivery of download content.

7.2.2 Operation

7.2.2.1 Objective

The primary objective is the delivery of download content for receiver software updates and data common to all receivers in accordance with these operational guidelines.

7.2.2.2 Model

TS multiplexed with other services should be configured as stipulated in Sections 4 and 7.

Additional operations associated with engineering services are subject to the following:

• service_type for NIT service list descriptors is 0xA4 (engineering service).

1-19-

ARIB TR-B15

Version 4.6-E1

• SDTT Table_cycle for BIT NO. 1 loop SI transmission parameters descriptor is not used.

• data_component_id in PMT data encoding format descriptor is 0x9 (ARIB Data Download Format).

Additional_data_component_info is not sent.

• PMT always contains the nine PID and Component_tag values described in Section 5.2.4. The

Component_tag value for data common to all receivers is 0x79, and for receiver software is a sequentially allocated value between 0x71 and 0x78.

• PCR is not always sent for engineering services.

In order to provide sufficient transmission capacity with download content for future needs, one solution is to use engineering slots for independent TS transmission, in accordance with the following guidelines.

Whichever approach is adopted, the selection will be made automatically and the update performed when the power is turned off after viewing another TS service. The following statement will be displayed if the viewer directly specifies (using the service id) a service whose service type is engineering service (0xA4):

“This channel is a broadcast used to send data to the receiver.”

Where the channel is selected via upload/download, it may be skipped. Engineering services are not displayed by EPG.

7.2.2.3 Engineering slot transmission signal

Table 7-1 shows PSI and tables sent by engineering slot TS.

Table 7-1 PIS and tables sent by engineering slot TS

0x00 PAT

0x02 PMT

0x40 NIT[actual]

0xC3 SDTT

0x73 TOT

~

1)

~

1)

~

Transmission level: ~ = always sent, ○ = sent only as required

1) If there is no download content whatsoever, transmission of SDTT and download content is suspended.

Transmission of engineering service PMT continues, however, which means that PMT_PID may remain unchanged in PAT.

Since the engineering slot TS is the TS selected by the user in a non-viewing period, only the required all-channel SIs (as shown in Table 7-1) are sent, rather than all of the all-channel SIs. Transmitted PSIs are used in accordance with the PSI/SSI Operational Guidelines.

Download content is delivered using the data Carrousel, in accordance with Operational Guidelines for

Downloads.

1-20-

ARIB TR-B15

Version 4.6-E1

(2) PSI and table descriptors

Table 7-2 shows PSI and table descriptors sent via engineering slot TS.

Table 7-2 PSI and table descriptors

0

Table_id Table

×02 PMT ( 1st_loop )

Descriptor

Conditional access system

Transmission

0

×40

PMT ( 2nd_loop )

NIT[actual] (1st_loop)

Digital copy control

Emergency information

×

×

Conditional access system

Stream identifier

Layer transmission

Digital copy control

~

×

Region ×

Video decoding control

Data encoding format

Network name

Staff

CA_EMM_TS

×

~

~

○*

0

0

×C3

×73

NIT[actual] (2nd_loop)

System administration

Service list

Staff

Satellite allocation system

~

~

○*

~

~

* Multiple inclusions allowed

7.2.2.4 Engineering slot transmission guidelines

The transmission guidelines are shown below. For more detail, refer to the Operational Guidelines for

Downloads.

(1) SDTT

Where download content exists, SDTT is sent at least once every ten minutes at a transmission speed of no greater than 10 kbps.

(2) Download content

May be transmitted at the fasted possible rate in the engineering slot TS.

7.2.2.5 Engineering slot reception guidelines

Where download content acquisition and a preset timer recording are set for the same time, the timer recording takes precedence.

Where download content acquisition will interfere with the start time of a timer recording, the download is not performed.

Where the download delivery schedule is for a time after completion of a timer recording, the engineering

1-21-

ARIB TR-B15

Version 4.6-E1 slot TS is selected and the download content acquisition is performed.

Once the operation is completed, the TS or service_id prior to migration to the engineering slot is restored, except in the case of memory initialization or equivalent in the course of a download for the purpose of updating the receiver software.

1-22-

ARIB TR-B15

Version 4.6-E1

Appendix 1 Operational rules for download service

The operational rules specify the operation rules when the consigned broadcasting operator (The Association for Promotion of Digital Broadcasting hereinafter, referred to as Dpa), who performs data broadcasting

(engineering stream broadcasting) certified by Article 52-13, paragraph 2 in the broadcasting law, performs download service targeting the television receivers that have functions of receiving BS digital broadcasting and broadband CS digital broadcasting.

1. Purpose of the download service

The purpose is to contribute to the smooth operation of the entire BS digital broadcasting / broadband

CS digital broadcasting by update on data common to all receivers(genre code table, program code table, keyword table, logo data) used commonly for all the receivers through function update and addition of receiver software by broadcasting, using engineering stream broadcasting.

2. Engineering Stream Broadcasting

It consists of receiver software, download broadcasting that sends out data common to all receivers(network id 0x0004, service id 929CH) and notice broadcasting that predicts and notifies the time information of download broadcast using all TSes (SDTT: Software Download Trigger Table).

Instead of targeting viewers like the general data broadcasting, this broadcasting service targets the receivers that have BS digital broadcasting and broadband CS digital broadcasting functions.

3. Types of Download Service

Download service has the following types:

Service Type User Application

Common to all receivers “Logo”

Common to all receivers “Other than Logo”

Consigned broadcasting operators

Platform

Consigned broadcasting operators

Platform

4. Operation of download service

Update of the logo data

Update of genre code table, program code table, and reserve words

(1) Operation of download service

Per a user usage application, Dpa provides download service except for cases such as broadcasting equipment failure, maintenance and other unavoidable circumstances.

1-23-

ARIB TR-B15

Version 4.6-E1

(2) Application of download service

Users that use receiver services submit the specified “Download Application Form” within the specified date to Dpa.

Users that use the services common to all receivers attach the raw material data (such as logo data to

“Application form of Data for All Receivers”, and make an application to Dpa. Both “Logo” and “Other than Logo” of services common to all receivers are collectively controlled with the association as the window. For “Other than Logo” of services common to all receivers, users and related institutions shall determine the update content after consultation, and the representative shall make an application to Dpa.

(3) Creation of download content

Content for the individual receivers is created by the respective users. Dpa creates the content common to all receivers based on the submitted materials.

(4) Acceptance check for download content

Dpa performs acceptance check, i.e., whether the content has been created according to specifications. If the check results show that there are errors with the content, Dpa will make a request for recreation and

5. Security of download content

Encryption in view of confidentiality or other purposes of download content relating to receiver software update shall be dependent to implementation of the receiver and its manufacturer.

There are no particular considerations for security of download content relating to data common to all receivers.

6. Usage fee and payment

Users shall pay registration fees, download service usage fees and other fees to the association according to the Dpa rate schedule specified elsewhere.

7. Confidentiality

Dpa will not leak or disclose the information related to user download service usage to the third party without the prior consent from the user. In addition, users shall not leak or disclose information known through this service to the third party.

8. Download related responsibilities and test, as well as viewer support

(1) Guaranty

Dpa guarantees that receiver software submitted from the receiver manufacturers, and data common to

1-24-

ARIB TR-B15

Version 4.6-E1 all receivers submitted from the consigned broadcasting operator and platform should be correctly sent out.

Receiver manufacturers shall guarantee the receiver operations when data is correctly sent out.

Dpa accepts prior broadcasting for operation confirmation. Users can perform test for receiver software update using methods such as specifying receivers that have not been shipped to the market by model id, version id, etc.

In addition, in the case of data common to all receivers, test can be made with maker id and model id as

0xfffd.

(2) Support for download related claims and inquiries

Users handle the claims and inquiries relating to the download content, while Dpa handles inquires relating to the download service itself.

(3) Troubleshooting

Dpa is unambiguously responsible for download related broadcasting responsibilities, and Dpa first performs support for viewers. With their own expenses and responsibilities, users shall provide support for viewers for troubles of receivers or other devices arising from the download results.

9. Disclaimer

Dpa shall not be responsible for the following cases:

1. Reception trouble arising from natural disaster, rainfall attenuation and other weather reasons

2. Failure arising from devices such as receiver

3. Failure of devices such as receiver arising from content

4. Broadcasting stop due to failure or maintenance of broadcasting equipment and related equipment, and download interruption due to system switching, etc.

1-25-

ARIB TR-B15

Version 4.6-E1

<Intentionally blank.>

1-26-

Volume 2

Function Specifications for Digital Satellite

Broadcasting Receivers

ARIB TR-B15

Version 4.6-E1

Contents

1 Introduction .......................................................................................................................................2-1

4 Requirements for User Interfaces .....................................................................................................2-6

4.4 EPG ...................................................................................................................................................2-9

4.4.1 Common rules ························································································································ 2-9

4.4.2 Program list ···························································································································2-11

4.4.3 Program search····················································································································· 2-12

4.4.5 Reserved program display ···································································································· 2-12

4.5.2 Program list ·························································································································· 2-13

4.6 Video, audio, and subtitle switching ...............................................................................................2-13

4.6.1 Default ES ···························································································································· 2-13

4.7 Adaptation to various TV broadcasting methods............................................................................2-14

4.7.1 Reception of signals sent through hierarchical modulation ·················································· 2-14

4.7.2 Reception of signals sent through Emergency Warning System (EWS) ······························· 2-15

4.7.3 Reception of temporary services ·························································································· 2-15

4.7.4 Reception an event relay ·································································································· 2-17

4.7.5 Reception multi-view TV broadcasting············································································ 2-18

4.7.6 Reception switching service······················································································· 2-18

4.8 Reception of data broadcasting services .........................................................................................2-18

4.8.2 The start and termination operations of data broadcasting service processing······················ 2-19

4.9 Reception of interactive data broadcasting services .......................................................................2-19

4.10 Reception of subtitles and captions.................................................................................................2-19

2-i―

ARIB TR-B15

Version 4.6-E1

4.11.1 Reservation registration·········································································································2-19

4.13.1 Password ·······························································································································2-21

4.13.2 Parental level·························································································································2-22

4.13.3 Antenna setting ·····················································································································2-22

5.1 Tuner ...............................................................................................................................................2-26

5.5 Memory...........................................................................................................................................2-26

5.5.1 RAM ·····································································································································2-26

5.5.2 NVRAM································································································································2-27

5.6.2 EPG·······································································································································2-27

5.7 Receiver internal sound...................................................................................................................2-27

5.8 High-speed digital interfaces ..........................................................................................................2-27

5.8.2 Operation specifications for a PSI/SI table during output of partial TS·································2-27

2-ii―

ARIB TR-B15

Version 4.6-E1

5.12 Reception service at shipment.........................................................................................................2-31

5.15 Others ..............................................................................................................................................2-33

5.15.3 Reset button·························································································································· 2-34

6

5.15.7 Modem ································································································································· 2-34

Operation Specifications for PSI/SI Tables That Can Be Inserted into Partial TS Outputs ...........2-35

6.1 Output operation specifications ......................................................................................................2-35

6.1.1 Definition of tables and descriptors ······················································································ 2-35

6.1.3 Interval for resending each table (Repetition interval)·························································· 2-37

6.2 Table operation specifications.........................................................................................................2-38

6.2.1 PAT······································································································································· 2-38

6.2.2 PMT ····································································································································· 2-40

7.1 Sample processing for determining whether a partial TS can be recorded to a D-VHS.................2-61

7.2 Copy Generation Management System - Analog (CGMS-A) ........................................................2-62

7.2.1 Definition of CGMS-A········································································································· 2-62

2-iii―

ARIB TR-B15

Version 4.6-E1

of identification signal ····················································································2-64

7.3 Assurance of the uniqueness of a broadcasting program and its contents......................................2-65

8 ANNEX...........................................................................................................................................2-66

8.1 Operation specifications for an IP interface....................................................................................2-66

8.1.3 Operation rules for tuner description·····················································································2-66

2-iv―

ARIB TR-B15

Version 4.6-E1

1 Introduction

This chapter describes the function specifications for digital satellite broadcasting receivers. Digital satellite broadcasting companies that accept outsourcing must operate their businesses assuming that these specifications are the standards. The following table shows the degree of priority for each specification from the viewpoint of a digital satellite broadcasting company (Required: A, Optional: B).

These specifications do not restrict product designs of receiver manufacturers. That is, some manufacturers may refrain from implementing some specified functions, implement some functions differently, or implement functions superior to specified ones. Note, however, that this functional discrepancy may lead to an error.

Broadcasting programs in our country (Japan) are provided through various types of broadcasting services.

Various rights associated with these programs, including copyrights and neighboring rights, must be protected through a total system. Protection of rights promotes provision of high-quality programs and healthy advancement and development of broadcasting. As such, a receiver unit should ideally assure the uniqueness of a program and clearly convey what a program intends to express.

For more information about the uniqueness of a program, see the section "7.3 Assurance of the uniqueness of a broadcasting program and its contents".

Table 1-1 Degree of priority for functions of a receiver

Section titles of function specifications of a receiver Degree of priority

4 Requirements for User Interfaces

4.1 Prerequisite system

4.2 Remote controller

4.3 Time management

A

A

A

4.4 EPG

4.4.1 Common rules

4.4.2 Program list

4.4.3 Program search

A

A

B

4.4.4 Program information display

4.4.5 Reserved program display

4.5 Program selection

4.5.1 Channel selection

4.5.2 Program list

4.6 Video, audio, and subtitle switching

4.7 Adaptation to various TV broadcasting methods

4.7.1 Reception of signals sent through hierarchical modulation

4.7.2 Reception of signals sent through Emergency

Warning System (EWS)

4.7.3 Reception of temporary services

4.7.4 Reception of an event relay

4.7.5 Reception of multi-view TV broadcasting

4.7.6 Reception of CA switching service

B

B

A

A

A

A

A

B

B

B

Comments switching=B (Also applicable to manual switching)

B

2-1―

ARIB TR-B15

Version 4.6-E1

4.8 Reception of data broadcasting services

4.9 Reception of interactive data broadcasting services

4.10 Reception of subtitles and captions

4.11 Program reservation

4.12 Conditional access services

4.13 User setting function

4.13.1 Password

4.13.2 Parental level

4.13.3 Antenna setting

4.13.4 The aspect ratio of the connected TV

4.13.5 Settings for a telephone line

4.13.6 Setting for the viewer location

4.13.7 Download permission setting

4.13.8 Caption display selection

4.13.9 Personal data clear function

4.14 Error messages

5 Hardware and Software Requirements

5.1 Tuner

5.2 TS decoder

5.3 Video decoding and outputting

5.4 Audio decoding and outputting

5.5 Memory

5.5.1 RAM

5.5.2 NVRAM

5.6 Character fonts

5.6.1 Data broadcasting services

5.6.2 EPG

5.7 Receiver preinstalled sound

5.8 High-speed digital interfaces

5.9 CA module interfaces

5.10 Copy control

5.10.1 Analog video output

5.10.2 Digital audio output

5.10.3 Hi-speed digital interface output

5.10.4 Digital video output

5.10.5 Digital video and audio output

5.11 Download function

5.12 Reception service at shipment

5.13 System test

5.13.1 IC card test

A

A

A

A

A

A

A

A

B

A

A

A

A

A

A

A

B

A

A

A

A

A

*1

High priority is assigned because captions are often used for prompt reports.

B

A

A

A

A/B Manual settings=A

C/N display=B

A

*1

A

(A)

(A)

(A)

(A)

A

A

A

A

Digital audio outputting = B

See Section 5 of Part 1 of this document

If a receiver supports digital audio output, the priority A is assigned to this function.

If a receiver is equipped with a hi-speed digital interface, the priority A is assigned to this function.

If a receiver supports digital video output, the priority A is assigned to this function.

If a receiver supports digital video and audio output, the priority A is assigned to this function.

2-2―

ARIB TR-B15

Version 4.6-E1

5.13.2 Telephone line connection test

5.14 Accumulation function

5.15 Others

5.15.1 Priory for various kinds of display

5.15.2 Priority for power standby processing

5.15.3 Reset button

5.15.4 RGB analog terminal

5.15.5 Digital video terminal

5.15.6 Digital video and audio terminal

5.15.7 Modem

6 Operation specifications for PSI/SI tables that can be inserted into partial TS outputs

A

B

A

A

B

B

B

B

A

(A)

*1) If this function will be implemented in a receiver that is equipped in a means of transportation such as a car, or a compact, lightweight portable TV note)

that is designed to be carried around, the priority

B is given to the function.

*2

*1

*1

If a receiver is equipped with a hi-speed digital interface, the priority A is assigned to this function.

Any functional limitations should be explained fully in a catalog or the manual so that the user can understand the limitations. Moreover, a receiver should display a message indicating that current broadcast contents are not supported when a user attempts to access unsupported broadcast contents.

*2) If this function will be implemented to a receiver that is equipped to a means of transportation such as a car, or a compact, lightweight portable TV note)

that is designed to be carried around, the power supply may not be available at times. Therefore, the power standby processing may become too difficult to implement. A catalog or the manual should fully explain the functional limitations and corrective actions so that a user can understand the limitations and what to do to correct them.

Note) A portable TV is a receiver that is equipped with a display whose size is 14 inches or less. This receiver uses DC (direct current) as its power supply (with a help of an AC adaptor or another device).

2-3―

ARIB TR-B15

Version 4.6-E1

This section is based on the document "ARIB STD-B21 Receiver for Digital Broadcasting", and defines the requirements for user interfaces, hardware, and software.

(1) ARIB STD-B21 "Receiver for Digital Broadcasting"

(2) ARIB STD-B10 "Service Information for Digital Broadcasting System"

(3) ARIB STD-B32 "Video Coding, Audio Coding and Multiplexing Specifications for Digital

Broadcasting"

(4) ARIB STD-B24 "Data Coding and Transmission for Digital Broadcasting"

(5) ARIB STD-B25 "Conditional Access System Specifications for Digital Broadcasting"

Digital tuner

CA switching service This service displays the broadcasting company's "Guidance Channel" when an unsubscribed user selects a scramble channel.

PSI An acronym for Program Specific Information. This information is necessary for selecting a specific program, and consists of four tables: PAT, PMT, NIT, and CAT. The MPEG standard and an order from Ministry of Internal Affairs and Communications define this information.

SI

This is a device that selects a reception channel from an IF signal, demodulates the signal, selects a desired program, decode the signal, and then display the decoded baseband signal. This device is also called STB or IRD.

An acronym for Service Information. This information contains the programs sequence and simplifies program selection. An order from Ministry of Internal

Affairs and Communications defines this information, and the ARIB standard defines the contents of this information. In addition to extended information defined by the ARIB standard, this information contains PSI in the MPEG-2 format.

EPG

ES

Direct channel selection

Up and down channel selection

One-touch channel selection

Subtitles

Captions

An acronym for Electronic Program Guide. A receiver uses SI sent from broadcasting companies to construct a program guide from which a user can select a program.

An acronym for Elementary Stream. An elementary stream is essentially a collection of encrypted video, audio, or data within a PES packet. An elementary stream is transmitted from a PES packet that has the same stream

ID.

One of the methods by which a user can select a channel in a receiver. A user presses a number key on a remote controller to directly specify the service ID.

One of the methods by which a user can select a channel. A user presses the up and down cursor buttons to increase or decrease the "service_id" to select a channel.

One of the methods by which a user can select a channel. One-touch buttons are preprogrammed to correspond to particular broadcasting companies or services, and pressing a particular button directly switches the channel to the corresponding service.

One of the services that superimpose texts on the video of a TV broadcast. The superimposed texts are highly relevant to the video of the TV broadcast.

A subtitle service that does not synchronize with the main video, audio, or data.

This service is used for special reports, editorial notes of a program, and time signals.

2-4―

Hierarchical modulation

Emergency Warning

System (EWS)

Temporary service

Multi-view TV

CAS

IEEE1394

Partial TS

SIT

DIT

CGMS

Macrovision

VESA

DVI

DDWG

HDCP

HDMI

DTCP

ARIB TR-B15

Version 4.6-E1

A type of modulation that combines a large-scale modulation, such as TC8PSK, and a small-scale modulation that can be received on low C/N, such as QPSK or

BPSK.

A report on natural disasters. A receiver must monitor the start signal of EWS, and display the report once it is broadcasted.

A service that is designed to temporarily broadcast the program contents on the different channel from the normal member channel. The normal service is temporarily stopped, and then this service is used.

Multiple videos and audios are transmitted within a single service. A broadcasting company specifies the combinations of these videos and audios, and a viewer can switch between these combinations

An acronym for Conditional Access System. This system controls the viewing of a service (member channel) or an event (program). This system is vital for

TV programs that require fees, and free TV programs whose contents need to be protected.

The serial bus interface that is defined by "IEEE Std 1394-1995 IEEE Standard for a High Performance Serial Bus". This interface supports high-speed real-time data transmission.

Partial transport stream. A bit stream that is selected and extracted from MPEG transport stream. This stream may be a single transport packet or a collection of multiple packets, and is not relevant to the program.

An acronym for Selection Information Table. This table provides stream information of a partial TS and information about the service and event that are transmitted through the partial TS.

An acronym for Discontinuity Information Table. This table is inserted to the change points where the partial TS becomes discontinuous.

An acronym for Copy Generation Management System. This system protects data from copying by managing information about the generations of the data.

This generation management uses three types of copy controls: "Copy is possible without restrictions", "Copy is possible for one generation", and "Copy is prohibited".

This is a copy control technology developed by Macrovision Corporation. If a receiver is connected to a display, normal output is possible. If a receiver is connected to a recorder, normal recording becomes impossible (extremely low-quality images are output). This technology uses both false synchronization pulses and color stripes.

An acronym for Video Electronics Standards Association.

This organization defines and promotes the standards for displays and display interfaces.

An acronym for Digital Visual Interface

An interface standard defined by DDWG.

An acronym for Digital Display Working Group

This industry organization promotes standardization of digital display interfaces.

An acronym for High-bandwidth Digital Content Protection System.

This standard protects the contents of digital video signals and digital video/audio signals transmitted through DVI or HDMI

An acronym for High-Definition Multimedia Interface.

This digital interface standard is defined by HDMI founders. This standard and related licences are managed by HDMI Licensing, LLC (Limited Liability

Company).

An acronym for Digital Transmission Content Protection.

This standard controls the content transmission and recording by using authentication and encryption in a digital interface.

2-5―

ARIB TR-B15

Version 4.6-E1

Free programs whose contents need to be protected

DLNA

Bluetooth

Free programs that are transmitted safely on the broadcast signals. Highly priority is placed on the protection of their contents. These programs do not manage any information concerning viewers.

An acronym for Digital Living Network Alliance

This organization defines and promotes the implementation guidelines for home network devices.

This short-range wireless communication technology is defined by Bluetooth

SIG. This technology is widely used around the world and designed to enable wireless communication between mobile phones, laptop computers, and other potable devices.

Program Stream defined in ISO/IEC 13818-1 MPEG-2 Systems. MPEG_PS

4 Requirements for User Interfaces

A receiver unit must receive digital signals from broadcasting satellites that emit 11.7 to 12.0 GHz signals and are located at the orbit location 110 degrees of east latitude. Broadcasting services must be provided for the entire Japan region.

For more information on the standard and operation of the signals received by a receiver that follows this document's specifications, see "ARIB STD-B32 Video Coding, Audio Coding and Multiplexing

Specifications for Digital Broadcasting" and Section 7 in Part 1 of this document.

This receiver should also be capable of distinguishing signals that can be converted to a program by following the flowchart in "Figure 13-1 Identification flow of broadcasting/non-broadcasting" in "ARIB

STD-B21". This operation is possible through analysis of the system management descriptor contained in

PSI.

Main functions of a receiver should be accessible from a remote controller (hereafter abbreviated as a remote). A remote should be implemented with all buttons described in "ARIB STD-B21 4.4.16 Remote controller and channel access (1) Necessary buttons" and some additional buttons that enable a user to access the following functions. The following example shows a recommended design of a remote but does not restrict further addition of other buttons.

- A power button for turning on or off (standby) the power of a receiver

- Buttons for moving a cursor vertically and horizontally (Arrow buttons)

(These buttons may be substituted with a joystick.)

- A button for executing an action associated with the selection item where the cursor is positioned (OK button).

2-6―

ARIB TR-B15

Version 4.6-E1

- Number buttons for entering a channel number and selecting a channel (Ten key)

- Up and down buttons for switching channels

- One-touch buttons for directly selecting a channel whose service ID can be preset. *1

(For example, 12 buttons from A to L)

3) Operation of EPG and others

- A button for displaying a program list (EPG button)

- A button for displaying a system menu (Menu button)

4) Data broadcasting service

For details, see "4.3 Remote" in Section 3 of Part 1 of this document.

The following buttons are used in data broadcasting:

Data button, Arrow buttons, OK button, Ten key, Color button, Return button

Color buttons must be positioned in the following sequence from the left side: Blue, Red, Green, and

Yellow. The color of each color button must also be distinguishable with attached letters. Therefore, the letters "Blue, Red, Green, and Yellow" must be placed near appropriate buttons.

5) Others

- A button for displaying related video (Video button) *2

Buttons for switching to an audio ES and switching the language (Audio button)

- Buttons for switching subtitle availability and the language of the subtitle (Subtitle button)

*1 One-touch buttons

Manufacturers may decide to preset one-touch buttons so that their numbers correspond to the numbers in some program charts (in newspaper or magazines). This document does not specifically define any recommended appearance and design of these buttons. Instead, only a recommended example (Button

A to L) is provided. Note that users should be able to change the numbers that are set for these buttons after they purchase a receiver.

*2 Video button

A video button must be implemented with all of the following switching functions. Manufacturers can freely decide how to implement these functions.

(1) Switching between multiple TV services

This function enables a user to switch from a regular service to a concurrent service and vice versa.

Both the regular service and concurrent service are provided by the same broadcasting company and contained within the same TS. Each service has a unique service ID.

(2) Switching to a temporary service

This function enables a user to switch between a regular service to a temporary service and vice versa. Both the regular service and temporary service are concurrently provided by the same broadcasting company and contained within the same TS.

2-7―

ARIB TR-B15

Version 4.6-E1

(3) Switching between the main and sub windows in a multi-view TV

This function enables a user to switch between components of a component group that is defined by component group descriptors if the TV supports the multi-view service.

(4) Switching to another video component

This function enables a user to switch between video components of a current service if no component groups are defined, or when hierarchical modulation is used.

Example of a remote

(If a TV is connected to a digital tuner)

Example of a remote

(In case of a digital tuner build-in TV)

Power

1

5

9

EPG

Data

A

E

I

2

B

F

J

6

0

OK

Return

C

G

K

3

7

D

H

L

4

8

Menu

Channel

Video Audio Subtitles

Blue Red

Green Yellow

Power

1

5

9

EPG

Data

Multi audio

Video

Blue Red

Green Yellow

A

E

I

2

6

Air Satellite

3

7

10

0

11

Menu

Audio

Subtitles

B

F

J

OK

Return

Channel

Mute

Volume

C

G

K

4

8

12

D

H

L

Figure 4-1 Example of a remote

2-8―

ARIB TR-B15

Version 4.6-E1

A receiver should be capable of obtaining the current Japan Standard Time (JST = Coordinated Universal Time

(UTC) + 9) from TOT. However, 1-second error may occur and is acceptable.

A receiver can support daylight saving time (summer time) by adding the current time and the offset value that can be obtained from Local_Time_Offset_Descriptor of TOT.

The offset time should be displayed for programs whose schedules are affected by daylight saving time

(summer time).

(Every information item in TOT other than Local_Time_Offset_Descriptor is based on the Japan Standard

Time.)

4.4 EPG

Manufacturers can freely decide how to implement EPS functions (for example, program list display, program search, and reserved recording) and EPG user interface that utilize SI. However, this document provides the following rules and guidelines for EPG functions because EPG functions are highly useful for users and also affect the design of SI.

1) The program selection operation of a receiver must not be affected by an error in SI table transmission.

Even if SI has not been sent successfully, a user should be able to select and display a desired channel by using PSI.

2) When a user moves from a program of one media type (TV, radio, or data broadcasting) to a program of another media type, the receiver must display a sign indicating the media type.

3) If an EPG is displayed with 8-bit CLUT index colors, which are also used for data display, for its characters and figures, the EPG must use 32 receiver-dependent colors and 128 common fixed colors.

See "4.2.1 Resolutions and Restrictions on Planes That Constitute Display Windows" in Section 3 of

Part 1 of this document for more information. Manufacturers can freely allocate any colors to the 32 receiver-dependent colors.

<Reference: Allocation of colors to the 8-bit CLUT index colors>

See "4.2.1 Table 1 Resolution of a window plane" in Section 3 of Part 1 of this document.

Common fixed colors: 128 colors

Subtitles and logos can only use the common fixed colors. EPG and data broadcasting services can also use these colors.

Receiver dependent colors: 32 colors

The EPG and menus of a receiver use these colors.

Manufacturers can freely specify any colors.

Colors specified by a broadcasting company: 96 colors

2-9―

ARIB TR-B15

Version 4.6-E1

These colors are used for graphic characters in a data broadcasting service that is provided by a broadcasting company.

Broadcasting companies can freely specify any colors.

When an EPG is display on the 8-bit CLUT subtitle plane, any colors can be specified for the 128 colors other than the 128 common fixed colors. When an EPG is displayed on a plane other than the subtitle plane or character and graphic plane, the EPG can use any colors. This is also applicable when an EPG is display in a receiver that supports a superior color display function than the 8-bit CLUT.

4) The video and audio of a selected program must be continued during EPG window display that uses all-channel SI. For example, a receiver can display a shrunk video window to continually display the video of a program during EPG window display. A receiver can also display the EPG window over the video of a program by using alpha compositing to implement the same effect.

If a user displays an EPG during data service window display (excluding closed captioning) instead of video display, racing condition may arise between graphic characters of the data service and the EPG.

Therefore, it is advisable that a portion of the data service be discontinued during EPG window display as long as discontinuation does not pose incongruity.

5) The currently selected (received) channel should be appropriately located within the screen so that the channel attracts most attention when a user displays a channel list or program list that cover multiple broadcasting companies.

6) If possible, a service logo should be displayed within an EPG window. The size of a logo (the number of horizontal and vertical dots) can be changed on the basis of logo data held, but the logo design should be maintained. The ratio between the length and width and the colors of a logo should also be maintained.

Service logos can use invisible colors (alpha value = 0) and semi-invisible colors (alpha value =128) that are

• contained in the common fixed colors. If a service logo uses these colors, and this logo needs to be displayed on the EPG window, the following operation is acceptable:

Invisible colors : These colors can be processed as non-displayable colors. That is, no colors are

• drawn for the pixels for which these colors are assigned. A user would see the background OSD of the EPG for these pixels.

Semi-invisible colors : These colors can be processed as visible colors. That is, the alpha values of pixels for which semi-invisible colors are assigned (alpha value = 128) can be increased to 255.

7) If a receiver is designed to accumulate all-channel SI, the EPG window may display old information regarding programs when the current time and the reception time of all-channel SI are different.

Manufacturers should describe this phenomenon in product manuals. For example, a product manual

2-10―

ARIB TR-B15

Version 4.6-E1 may contain a statement such as "Some programs may change without prior notice. The display contents of the EPG may be different from the actual program contents or schedules."

8) If the selected service sends captions during EPG window display based on SI, that captions should be promptly displayed.

9) If the "text_char" field of the component descriptor or audio component descriptor is omitted, the default value should be inserted. The default value should be "Video" for the component descriptor or

"Audio" for the audio descriptor. Note, however, that the default value should be "Primary Audio

CR(line-feed) Secondary Audio" if the dual mono mode is selected.

1) A receiver must be capable of extracting information from SI and displaying all programs offered by all broadcasting companies to a program list. This does not apply for some programs, such as data services, that are unsupported by the receiver.

2) A receiver must display short programs on a program list so that a user can notice the existence of these programs.

3) A receiver must display long programs or programs that run beyond 24 hours on a program list. A user should be able to notice the existence of these programs regardless of which time period the user has chosen from the EPG.

4) If a user chooses to display a program list in the newspaper format, the receiver should use a format similar to the newspaper format (10 full-width characters per line).

5) The length of a program name (program title + sub title) of a long program should be within 40 characters. If the space is limited, program name display within 20 characters is also acceptable

(Names of programs that do not extend beyond 30 minutes should be displayed within 20 characters).

6) A receiver should indicate whether a program will charge any fees on the program list.

7) A receiver should display the attributes of a program. These attributes are contained within SI and include information regarding the video mode, audio mode, availability of attached data, subtitle, fee requirement, digital copy permission, and parental control.

8) A receiver should display the latest and accurate information about programs on the program list as soon as possible when program information has been updated.

9) Loop scroll should be applied for the channel scrolling of a program list.

10) Note the following points when implementing a program list that displays data broadcasting programs:

Manufacturers can freely decide how to implement a program list, and may either combine or separate a list of data broadcasting programs and a list of TV programs.

A receiver should indicate that a data attached program has a related data broadcast service on the program list.

2-11―

ARIB TR-B15

Version 4.6-E1

A receiver should indicate the existence of data programs and local contents for which CA is applied on the program list.

1) A receiver should be implemented with a program search function that enables a user to search for a program based on the program genre information provided through "content_nibble_1" (General categories) and "content_nibble_2" (Main categories) of "content_descriptor". This function should be operable even if only general category information is available.

1) Broadcasting companies determines the layouts of program detail information. Guidelines should be provided for receiver manufacturers to adapt to these layouts. Program detail information should be displayed in lines, and each line should contain 20 full-width characters.

* The above number of character consumes space equivalent to 480 dots horizontally

(a half of the total display width) when the character and graphic resolution is HD (960*540), and

24-dot fonts are used.

2) A user should be able to easily display the detail information of the currently watched program.

4.4.5 Reserved program display

1) A receiver should be implemented with a display function for a reserved program list.

The basic operation of program selection is described below. The following description does not restrict manufacturers from applying different implementation procedures for program selection.

The basic operation of channel selection involves specification of a 3-digit service ID entered with the Ten

Key. A remote should be implemented with additional one-touch buttons (for example, 12 additional buttons) for directly selecting a channel for ease of use. Users should be provided with useful user interfaces.

Manufactures should preset the values for the one-touch buttons before shipment so that the preset values are the same as the basic service IDs corresponding to the channels offered by broadcasting companies. Users should be able to change the preset values when they want to.

The operation of channel selection should be based on PSI. If a receiver detects cancellation of a program, the receiver should display a message informing the cancellation.

For more information on the definition of program cancellation, see "7.6 Program Cancellation" in Section 7 of Part 1 of this document.

2-12―

ARIB TR-B15

Version 4.6-E1

Program selection should be available from a program list that can be displayed from a currently watched program.

4.6 Video, audio, and subtitle switching

All the functions described in this section are required in a receiver unit. However, manufacturers can freely decide how to implement these functions.

When a user selects a service, and there is no specific ES that needs to be decoded first (the default ES), a receiver need to decide which ES should be decoded first from multiple ESs. For more information on how to decide the default ES, see "5.1.3 Default ES" in Section 7 of Part 1 of this document.

Multiple video ESs may be sent from a single service. A user should be able to select all ESs. When a user first moves to a channel, the default ES should be selected. A user should be able to use the video button of a remote to switch from one ES to another in a circular manner. Manufacturers can freely decide how to implement a function for decoding and displaying multiple ESs at the same time. If a manufacturer decides to implement a function for decoding multiple ESs at the same time, a receiver must provide an interface by which a user can decide whether to display a single ES or multiple ESs at the same time. If a receiver is implemented with the multi-view TV function, the receiver must switch from one ES to another as a user moves from one view to another. These ESs are grouped together by "Component_group_descriptor" and represent videos, audios, or subtitles. In addition, a receiver should not remember the mode that has been selected before a user selects an ES in the multi-view TV function.

Multiple audio ESs may be sent from a single service. A user should be able to select all ESs. When a user first moves to a channel, the default ES should be selected. A user should be able to use the audio button of a remote to switch from the main audio to the sub audio and from one ES to another ES in a circular manner. If a receiver is implemented with a menu interface in which a user can choose a desired audio, the receiver must extract information from "Audio_Component_descriptor" to display appropriate audio selection choices.

4.6.4 Subtitle ES selection

A maximum of one subtitle ES and one caption ES can be attached to a single service. A user should be able to switch from no subtitles to one of the multiple languages within the subtitle ES. The default subtitle setting should be no subtitles. A user should be able to use the subtitle button to perform the above operation in a

2-13―

ARIB TR-B15

Version 4.6-E1 circular manner. If a receiver is implemented with a menu interface in which a user can choose a desired subtitle ES, the receiver must extract information from "selector_byte" of "data_content_descriptor" to display appropriate subtitle selection choices. In addition, a user should be able to select a caption from the initial setting menu, but the sender of the caption SE predetermines whether to display the caption, and the caption is normally displayed automatically. Note that a receiver must display both the subtitle ES and caption ES at the same time if both ESs are present.

4.7 Adaptation to various TV broadcasting methods

4.7.1 Reception of signals sent through hierarchical modulation

See "ARIB STD-B21 6.3 Receiver's function of hierarchical modulation in digital satellite broadcasting" and

"7.1 Operation of hierarchical modulation" in Section 7 of Part 1 of this document.

Functions required for reception

(1) Demodulation of signals sent through hierarchical modulation

(2) Invalidation of the higher layer through monitoring of the error rate of 8PSK.

(3) A decoding function of the video and audio at the lower layer. However, a receiver does not need to be implemented with a function for concurrently outputting the decoded video and audio of the same stream type that exist between the higher layer and lower layer.

(4) Automatic switching to another stream layer after a receiver invalidates the higher layer according to the Hierarchical Transmission Descriptor within the monitored PSI.

Manufacturers can freely decide whether to automatically switch from the higher layer to the lower layer.

(5) A function for indicating that the receiver is currently receiving the lower layer signals

(Display of a message such as "Reception has been switched to the lower layer video")

Detection of layers

(1) A receiver must evaluate the error rate of 8PSK within a single carrier or other equivalent information detected during demodulation in order to determine which layer should be used. The receiver does not need to evaluate the error rates of QPSK and BPSK.

(2) A receiver must determine whether hierarchical modulation signals exist by examining the above information and the Hierarchical Transmission Descriptor in the PMT, and obtain an ESPID for each layer. The sender of a service can only use the PMT to indicate whether the current service uses the hierarchical modulation. The PMT does not contain any other information.

(3) A receiver must allow a user to use the multiple ES selection function to deliberately choose the lower layer signals.

2-14―

ARIB TR-B15

Version 4.6-E1

* Transmission of static images

A receiver must be capable of displaying a static image that has been sent as a MPEG2 I-picture through the MPEG-TS. The following conditions must be met for a static image to be sent through the

MPEG-TS:

The sequence header and end code must be attached to the I-picture.

A video control descriptor must be included in the PMT. The static image flag field of this descriptor must be "1".

4.7.2 Reception of signals sent through Emergency Warning System (EWS)

See "6.3 Emergency Warning System (EWS)" in Section 7 of Part 1 of this document.

(1) A receiver must monitor the emergency warning descriptor in the descriptor region 1 of the current channel's PMT after the start control bit of TMCC has been changed from 0 to 1.

(2) A receiver must select and display the channel represented by "service_id" if "start_end_flag" of the emergency warning descriptor is "1", and "area_code" is the same as the area code that is set in the receiver unit.

(3) A receiver must continue monitoring the PMT as long as the start control bit of TMCC stays "1".

(4) Once the emergency warning descriptor is deleted from the current channel's PMT , the reception processing of Emergency Warning System signals must be terminated. Then the receiver must recover the settings before the reception of EWS signals.

(The receiver must not memorize the channel used for EWS reception.)

If a user switches a channel during reception of Emergency Warning System signals, the reception processing of Emergency Warning System (EWS) signals should be terminated. However, if the start control bit of TMCC has been changed from 0 to 1 again, the receiver must start the reception processing of Emergency Warning System (EWS) signals.

A receiver must not start the reception processing if "start_end_flag" of the emergency warning descriptor turns to "0" because "0" represents test signal transmission.

If a receiver does not support reception of TMCC during power off (or standby), the receiver must start monitoring the emergency warning descriptor in the descriptor region 1 of the current channel's

PMT after the receiver is turned on. If the start control bit of TMCC is "1", the receiver must start the reception processing of Emergency Warning System (EWS) signals.

If a receiver supports reception of TMCC during power off (or standby), the receiver must perform the reception processing of Emergency Warning System (EWS) signals during power off (or standby).

4.7.3 Reception of temporary services

See "7.3 Temporary formation" in Section 7 of Part 1 of this document.

2-15―

ARIB TR-B15

Version 4.6-E1

(1) Determination of a temporary service

A receiver can determine whether the presented "service_id" is the ID of a temporary service by examining whether "service type" of the NIT is one of the temporary service types (Service format identifier: 0xA0, 0xA1, or 0xA2).

A service description table (SDT) is always transmitted as a temporary service (through a maximum of 2 SDTV channels for a single "broadcaster"). A receiver can determine the start of a temporary service by monitoring whether "service_id" of the temporary service has been registered into the

PAT.

(2) Notification of the start of a service

A receiver must notify a user of the start of a temporary service by either in-program captions or announcement.

(3) Switching between temporary channels

A user should be able to use either the video button, up and down buttons, or direct channel selection buttons to switch from one temporary service to another. Channels for temporary services need to be skipped if no temporary services are on air.

When a user uses the up and down buttons to switch from one temporary service channel to another, the receiver must follow the channel order described in "service_id". For example, if a user uses the up button to move from the channel 101, 102 (Temporary), 103 (Temporary), to 201, and then uses the down button to move down from 201, the use will return to 103 (Temporary).

If a user uses one of the one-touch buttons to select a channel from another TS, the receiver must extract information of the PAT. Therefore, this operation may take a few seconds during which a user cannot perform any operations.

(4) Display of an EPG

Manufacturers can decide whether to implement an EPG. It is recommended that the receiver display an EPG when the EPG information is being transmitted.

(5) Termination of a temporary service

Deletion of "service_id" of a temporary service from the PAT means the termination of the temporary service. A receiver must recover the "service_id" of a normal service that is associated with the same

TS or media type as for the temporary service. Both the temporary service and normal service must be contained in the same "broadcaster".

(6) Recording

Contents of a temporary service cannot be recorded through reserved recording unless the contents of a temporary service are unintentionally recorded because of an event relay (redirection of a TV program from one channel to another because of extension of the program duration).

2-16―

ARIB TR-B15

Version 4.6-E1

4.7.4 Reception of an event relay

See "7.5 Event relay" in Section 7 of Part 1 of this document".

(1) Service overview

A program (or an event) such as game coverage of the high school baseball in Japan starts in one service ID and continues broadcasting in another service ID. Some live programs cannot end broadcasting at the scheduled end time and continue broadcasting in another temporary service ID to deliver the remaining portion of the program. When such redirection occurs, a receiver can use the SI to notify a viewer of redirection of a program from one service to another, or appropriately record an event by changing the recording-target service.

(2) Determination of a service

A receiver can determine whether an event will be redirected to another service by examining whether

"event_group_descriptor" is assigned to the current event's EIT[p/f], and whether the "event_type" of

"event_group_descriptor" represents a relay event type. The receiver should monitor EIT[p/f] of the relay destination event that is described in "event_group_descriptor". A current event and relay destination event may belong to two different TSs. In this case, the receiver should monitor EIT[p/f other] instead.

(3) Notification to a viewer and event switching

As a rule, broadcasting companies notify a viewer of an event relay by providing captions or announcement. However, a receiver can also notify a viewer of an event relay once it detects an event in EIT[p/f] of the event relay destination. Manufacturers can decide whether to implement and how to implement notification of an event relay to a viewer in a receiver. If a manufacturer decides to implement notifications, the notification must at least provide information that the current event will be continued in another service and information regarding the time of transition. After the notification, the user should be able to change the channel to move to the relay destination service where a program

(event) will continue.

(4) Recording support

If a user has set reserved recording for an event for which an event relay is scheduled, and the recording has already started, the receiver should automatically switch to the relay destination event as soon as the currently recorded event ends in order to continue the recording of the remaining portion of the event. The continued recording should be started after the receiver confirmed that the relay destination event is assigned to EIT[p/f]. If the relay destination has not been assigned to EIT[p/f] until the current event ends, an event relay is not scheduled; therefore, the continued recording should be eliminated. If the relay destination service is a temporary service, the end of an event relay can be determined once PAT is deleted from PMT_PID. Once it happens, the receiver should stop the recording.

2-17―

ARIB TR-B15

Version 4.6-E1

4.7.5 Reception of multi-view TV broadcasting

See "7.4 Multi-view TV" in Section 7 of Part 1 of this document.

(1) Multi-view TV consists of 1 service_id and multiple ESs. Among multiple SDTVs, one is the main service and others are sub services.

(2) A user must be notified of reception of multi-view TV(MVTV) in the main channel.

The PID of the main channel that is described in PMT must be the default ES.

The relationship between the main service and sub services is specified in

"component_group_descriptor".

After an MVTV event ends, the receiver must move to the next event with the default video and audio.

(3) A user must be notified of the start of multi-view TV through captions or announcement.

A user must be able to switch the channels by using the video button (or another equivalent function) of a remote. Grouped switching of a video and audio may not be possible during a few seconds after the start of multi-view TV because the receiver may not be able to obtain "component_group_descriptor".

In this case, a video component and audio component are switched independently.

(4) The attribute of each component in MVTV must be the same. A receiver can determine whether a component is a part of MVTV by examining EIT(p/f).

(5) A digital VTR should be able to record all services. An analog VTR should be able to record the main service and do not need to be able to record all services.

(6) A function for displaying multiple SDTVs at the same time is optional.

(7) MVTV should be started with an event and terminated with an event. That is, MVTV should not be started or terminated during an event.

(8) An EPG should display whether a program uses MVTV.

See Section 5 of Part 1 of this document.

When explaining this function to a user in a manual and other places, the function name must be

"Guidance channel switching function".

4.8 Reception of data broadcasting services

4.8.1 Requirements for a receiver

A receiver must be implemented with the following functions and specifications described in "4.

Requirement functions for a basic receiver for reception of data broadcasting services" in Section 3 of Part 1 of this document.

4.2. Requirement functions

4.3. Remote

4.4. TS decoder

2-18―

ARIB TR-B15

Version 4.6-E1

4.5. Memory required in a receiver

4.8.2 The start and termination operations of data broadcasting service processing

For details on the start and termination operations of data broadcasting service processing in a receiver, see

"5.1.12 Relevant receiver operations" in Section 3 of Part 1 of this document.

4.9 Reception of interactive data broadcasting services

See the following chapters in Section 6 of Part 1 of this document for details on how to support interactive data broadcasting services reception.

Chapter 5 Communication protocol

6.4 Recommended receiver functions

8.4 Receiver functions

9.1 Operations when a receiver is turned off

4.10 Reception of subtitles and captions

See the following subsections in "7 Encoding operations for subtitles and captions" in Section 3 of Part 1 of this document.

7.4 Characters used in subtitles and captions

7.5 Control codes used for subtitles and captions

7.6 Operation of DRCS

7.7 Initial operations

7.8 Mono media used in subtitles and captions

7.9 Recommended receiver operations

Reception of captions is a vital function of a receiver because captions send special reports on natural disasters, editorial notes of a program, and a time signal.

4.11 Program reservation

This section defines the rules for view reservation and recording reservation.

4.11.1 Reservation registration

1) If the program that a user wants to reserve has multiple ESs, the user should be able to select an ES when creating reservation.

2) If the program that a user want to reserve has captions, the user should be able to choose whether to record the captions.

3) If there is a possibility that the desired program may not be viewable, the user should be notified.

4) If the desired program prohibits copying, the user should be notified.

2-19―

ARIB TR-B15

Version 4.6-E1

5) If any viewing restrictions are applied to the desired program, the user should be required to enter a password during reservation registration.

6) If the desired program requires fees (free_CA_mode is "1"), or the program is free but requires contents protection, the receiver should ask the user whether the user wants to view the program during reservation registration.

4.11.2 Confirmation of reserved programs

1) A receiver must have an user interface for check reserved programs that have been registered.

2) The user must be able to cancel reserved programs that have been registered.

4.11.3 Execution of reserved operations

1) Reserved operations must follow EIT[p/f actual] of TS that is send with the reserved program.

2) Program reservation registration must be automatically deleted after the reserved program ends.

3) Air time change of a registered reserved program

The start time of the reserved program may be delayed. Manufacturers can decide whether to delay the execution time of a reserved operation in a receiver to resolve the problem. A receiver may be implemented with two different modes by which a user can decide whether to delay the execution time of a reserved operation. The recommended maximum delay time is 3 hours because it is the standard delay time that is sufficient enough to cancel a delayed program.

If the reserved program is to be started earlier than the scheduled start time, the registered reserved operation may be canceled.

The "event_id" should remain the same even if the scheduled time has been changed (The "event_id" should be unique within a channel).

The time should be processed in minutes. For example, if a receiver displays the time, it should be rounded to the nearest minute.

Some reserved programs may be cancelled (the event_id may be deleted) due to program schedule changes.

2-20―

ARIB TR-B15

Version 4.6-E1

4.11.4 Timer reservation

A user may want to reserve a replacement program that will be aired if sports coverage is canceled because of rain. A timer reservation function may be used to realize this reservation.

4.12 Conditional access services

See "4. Required specifications for a receiver" in Selection 5 of Part 1 of this document.

The following functions are examples of conditional access services:

Viewing function of a free program that requires contents protection

Reservation function of a free program that requires contents protection

Viewing function of a program that requires fees

Reservation function of a program that requires fees

Power control (including EMM filtering specified by NIT)

Error notification (which responds to an IC card)

Automatic display message

Mail

Parental lock(age limit for viewing)

Display of IC card information

Operations when no IC cards are inserted

4.13 User setting function

A receiver must be implemented with windows in which a user can specify the following settings. All of these settings must be memorized in NVRAM.

4.13.1 Password

A password consists of 4 decimal numbers and is used when a user sets the parental level and unlocks the parental lock. At the initial setting, a user can freely set a password. If the user wants to change the existing password, the user should be required to enter the previous password. In order to resolve a situation where a user forgets the password, the receiver should be implemented with an EMM command (password clear command). The execution of this command recovers the initial settings. For more information, see 4.15.3

Password" in Section 5 of Part 1 of this document.

2-21―

ARIB TR-B15

Version 4.6-E1

4.13.2 Parental level

The age range specifiable for the parental level is 4 to 20. As a rule, the children's age is entered for the parental level. The receiver must not show any programs whose "parental_rating" values exceed the set parental level. However, once the correct password is entered, these prohibited programs must be shown. For more information, see "4.15.2 Parental level( age limit for viewing)" in Section 5 of Part 1 of this document.

4.13.3 Antenna setting

The local oscillation frequency of a converter must be 10.678GHz. The specification of the initial transmission source that is used during antenna adjustment should follow the description in Section 5.12 of Chapter 5. The receiver should display the antenna level value so that the user can easily install an antenna. For example, the antenna level value may be assigned an approximated value that is twice as large as the C/N value (dB, the

28.9MHz layer) of the incoming carrier. However, manufacturers determine the absolute value of the antenna level.

In order to accommodate middle-width antennas, the receiver should be able to display approximately 20 dB

(Antenna level: approximately 40) as the maximum C/N value.

To prepare for an unexpected accident of the satellite, the user should at least be able to manually change the frequency setting of the reception transponder, which is preset by a manufacturer before shipment.

4.13.4 The aspect ratio of the connected TV

The aspect ratio should be either 4:3 or 16:9 (wide).

For details on the operation specifications, see "6.1.2 Video output signals" in "ARIB STD-B21".

4.13.5 Settings for a telephone line

A receiver enables a user to set the dial type. A user should be able to set both the dial mode (DP10, DP20, or

PB) and optional external phone number.

For more information on the primary phone line type, code numbers for communication companies, fixed primary disconnection number, and caller ID notification, see "6.4 Recommended receiver functions" in

Section 6 of Part 1 of this document.

4.13.6 Setting for the viewer location

A receiver should enable a user to specify the following settings in order to identify the viewer location:

(1) Ward codes

A ward code corresponds to a target region descriptor.

A receiver uses this information to provide local services that are relevant to the viewer's location (for example, weather reports and election results) in the data broadcasting service.

For more information on actual values assigned to ward codes, see "ARIB STD-B10 Appendix G".

2-22―

ARIB TR-B15

Version 4.6-E1

(2) Area code

An area code supports the emergency information signals (whose implementation is specified in

Ordinance for Regulating Radio Equipment, Article 9-3-5; Ordinance for Regulating the Operations of

Radio Station, Article 138; and Ministerial Ordinance of MPT No. 405 of 1985).

This information is used for the emergency warning system (EWS).

For more information on actual values signed to area codes, see "ARIB STD-B10 Appendix D".

A receiver should be equipped with a function that automatically set an appropriate area code once the viewer sets the ward code, which is described in (1).

(3) Postal code (7 digits)

A receiver uses this information to provide local services that are relevant to the viewer's location (for example, weather reports and election results) in the data broadcasting service. This information is also used to identify the access point nearest to the viewer's location in the interactive data service.

4.13.7 Download permission setting

This setting enables a user to specify whether to permit software updates through data downloading. For more information on the downloading function, see Section 1 of Part 1 of this document. Manufacturers can decide whether "Permitted" or "Not permitted" should be set as the default setting. Note that the data common to the entire receiver should be updated through data downloading regardless of this setting.

4.13.8 Caption display selection

The caption modes include the "Display selection at reception, Display selection at a record replay" mode.

(See "7 Subtitle and caption encoding" in Section 3 of Part 1 of this document.) In this mode, captions do not automatically start when the main video, audio, or data starts. Therefore, a user should be able to specify

"Display" or "Not display" at the initial setting. The default mode should be "Display".

4.13.9 Personal data clear function

A receiver must be implemented with an initialization function by which a user can delete the personal data stored in NVRAM during program reception or user settings. This function is necessary for protection of privacy when the digital satellite broadcasting receiver is either given to another user or needs to be scrapped.

Information in the broadcasting company specific region and common region that are used during data broadcasting

For details, see "8.2 Usage of NVRAM that is shared by MM services" in Section 3 of Part 1 of this document.

Personal data related to Conditional access , such as an EMM mail

For details, see "4.3 Memory" in Section 5 of Part 1 of this document.

User setting information such as the interactive connection setting information

Personal data that a user has set in the manufacturer specific region

2-23―

ARIB TR-B15

Version 4.6-E1

The operation menu for this function should be located at a relatively deep menu layer in order to prevent a user from unintentionally deleting personal data.

4.14 Error messages

An error message must be shown on the display once an error is caused by one of the problems described in

Table 4-1.

Manufacturers can decide how to display an error message. Table 4-1 shows some example error messages that correspond to programs for suggesting a user to identify the cause of the error and take a corrective action (These examples are only recommendations).

Note that the receiver can also display the error codes shown in Table 4-1 with corresponding error messages.

For information on error messages related to IC cards, see 4.18 in Section 5 of Part 1 of this document.

Cause of an error

A user selects a non-broadcasting channel.

The reception level has been lowered because of rain or thunder.

There may be some bad contact with an antenna cable or connector.

The receiver cannot receive any signals

There may be some disconnections with an antenna cable or connector.

Some incorrect settings have been specified.

A short circuit has occurred in the internal wires of the antenna cable.

The broadcasting period has already passed.

Table 4-1 List of error messages and error codes

Example error message on the display

This channel cannot be viewed because it is a non-broadcasting channel.

The video has been switched to the lower layer.

Error code

E201

Corrective action cannot be viewed. because of rain or thunder.

Receiving no signals

Check the connection with the antenna.

(Note 1)

E202

E209

E203

The video will be automatically switched to the higher layer once the reception level returns to normal. Please wait for a while.

Check the connection of the antenna cable.

Check the connection of the antenna cable.

Check whether correct values have been specified to the antenna settings.

Check the connection of the antenna cable.

The user selects a non-existing channel.

The phone line has not been correctly connected or set.

The selected channel does not exist.

The receiver could not connect to the center.

E204

E301

Check the broadcasting period with a program guide.

Check the channels with a program guide.

Check the connection and settings of the phone line.

Make sure that the phone line is connected correctly.

2-24―

ARIB TR-B15

Version 4.6-E1

(During a replay of data broadcast)

The BML document cannot be obtained.

The receiver cannot receive any data.

E400

This receiver cannot display the data.

E401

Move from the current channel to another channel, and then return to the previous data channel again.

Move from the current channel to another channel.

(During a replay of data broadcast)

The receiver's BML engine does not support the obtain

BML's version.

(During a replay of data broadcast)

An execution error occurs during a contents replay.

The receiver cannot obtain the external reference data.

The receiver failed to display the data.

E402 Move from the current channel to another channel, and then return to the previous data channel again.

(Note 1): The example error message differs depending on the broadcast inactive statuses described in "7.6

Handling of Inactive broadcast" in Section 7 of Part 1 of this document. The following are the example error messages:

(1) Inactive-1: An example error message is "The broadcasting is inactive".

(3) Inactive-3: An example error message is "The broadcasting is inactive".

(4) No signals: An example error message is "Broadcasts cannot be received".

If it is difficult to implement multiple error messages in a receiver, the error message for the statuses (1)

Inactive-1 and (3) Inactive-3 can be also "Broadcasts cannot be received".

If the receiver is capable of identifying the causes of the statuses (2) Inactive-2 and (4) No signals, the receiver can display an additional message for a viewer (for example, "The reception condition has been worsened.") so that the viewer can easily acknowledge the cause of the status.

2-25―

ARIB TR-B15

Version 4.6-E1

5 Hardware and Software Requirements

5.1 Tuner

A turn should be equipped with 1 IF input system.

The turn should support the local frequency 10.678GHz of the satellite converter.

For information on specifications for the tuner part, see 4.4.1 to 4.4.4 of ARIB STD-B21.

For information on front-end signal processing, see 4.4.5 of ARIB STD-B21.

See "ARIB STD-B21 4.4.6 Transport processing".

If the decoder needs to support data broadcasting services, see "4.4 TS decoder" in Section 3 of Part 1 of this document.

5.3 Video decoding and outputting

See both "6.1 Video decoding process and output signals" and "Appendix-1 Method of switching the video format" of ARIB STD-B21. For information on the RGB analog terminal and digital video terminal, see both

"5.15.4 RGB analog terminal" and "5.15.5 Digital video terminal" in this section. For information on video output through a digital video and audio terminal, see "5.15.6 Digital video and audio terminal" in this section.

5.4 Audio decoding and outputting

See "6.2 Audio decoding process and output" and "Appendix-4 Down-mix processing in the AAC decoder" of ARIB STD-B21. If a receiver is implemented with additional options such as downmixing for an external semi-surround processor and downmixing for stereo sound field extension (both of which are described in

"ARIB STD-B21 6.2 Audio decoding process and output"), the receiver should display the downmixing setting status, so that a user can acknowledge which setting status is active.

If a receiver needs to be equipped with a digital audio output function, the receiver must follow the AAC extensions described by IEC 60958 and IEC 61937. If the digital output needs to be performed through the

Bluetooth interface, the receiver must acquire the Bluetooth logo permission in order to assure the compatibility with the Bluetooth standard. For more information on audio output through a digital video and audio terminal, see "5.15.6 Digital video and audio terminal" in this section.

5.5 Memory

5.5.1 RAM

If a receiver needs to support the data broadcasting services, see "4.5. Memories that a receiver must be equipped with" in Section 3 of Part 1 of this document.

The receiver must be equipped with a memory buffer that is sufficient enough for the transmission speed for reception of notification information and downloadable software.

Manufacturers can decide how big the RAM size should be for receiver-resident programs such as SI and EPG.

2-26―

ARIB TR-B15

Version 4.6-E1

5.5.2 NVRAM

For information on a memory that supports downloading of software and receiver common data, see

"6.1 Rules for a memory"in Section 1 of Part 1 of this document.

If the receiver needs to support data broadcasting, see "8.2 Operation of NVRAM that is shared by MM services" in Section 3 of Part 1 of this document.

For information on a memory that supports email reception, see "4.3 Memory" in Section 5 of Part 1 of this document.

Manufacturers can freely decide whether to implement NVRAMs other than the ones mentioned above.

The receiver must be implemented with the following character fonts for data broadcasting services, SI, and

EPG.

See "4.2.5 Fonts" and "7.6 Operation of DRCS" in Section 3 of Part 1 of this document. Font data are transmitted through 4 gradations format. Therefore, the receiver must appropriately display these fonts.

Effects of gradation are dependent on the receiver.

5.6.2 EPG

Manufacturers can decide which character fonts and sizes should be used for an EPG. For information on character sets, see "4.1 Character sets" in Section 4 of Part 1 of this document.

5.7 Receiver internal sound

See "6.3.5 Receiver internal sound" in Section 3 of Part 1 of this document.

If a receiver needs to be equipped with a high-speed digital interface, see "Chapter 9 Specifications for high-speed digital interfaces" and "Appendix-2 High-speed digital interface" in ARIB STD-B21.

5.8.1 Output limit for partial TS

When outputting a digital satellite broadcasting program, the receiver should not output a component that cannot be descrambled.

5.8.2 Operation specifications for a PSI/SI table during output of partial TS

Some rules have been established for the specifications of partial TS. Partial TS may be transmitted from a

2-27―

ARIB TR-B15

Version 4.6-E1 receiver unit via a high-speed digital interface when the receiver is connected with a MPEG stream recorder.

For details, see "6 Operation specifications for PSI/SI tables that can be inserted into partial TS outputs" in this section.

5.8.3 Control commands for IEEE 1394

See "ARIB STD-B21 9.1.5 Descriptors, commands, and tuner models".

5.8.4 Specifications for an IP interface

If a receiver needs to be equipped with an IP interface as the high-speed digital interface, see "ARIB

STD-B21 Chapter 9, 9.2 IP interface specifications" and ARIB STD-B21 Appendix-2 High-speed digital interface".

For details on operation of this interface, see 8.1 Operation specifications for an IP interface".

If the receiver is equipped with a wireless LAN, the receiver may encounter an error caused by a connection from a receiver that the user is unaware of. Therefore, an IP interface needs to be implemented with a function that can reduce the user's confusion.

For operation in the case of output with MPEG_PS, see the rules for MPEG_PS transmission described in

“8.1 Operation specifications for an IP interface” and DLNA guidelines.

See "ARIB STD-B25 Conditional Access System Specifications for Digital Broadcasting" and "4

Requirements for a receiver" in Section 5 of Part 1 of this document. Supply of IC cards must follow the supply requirements of BS Conditional Access Systems Co., Ltd.

CA interface

A receiver must be equipped with a low-speed CA interface, which is described in the above specification document.

Descrambler

A receiver must be equipped with a descrambler described in the above specification document.

Other CAS-related controls

The above specification document describes more details. The following two control functions must be equipped to a receiver in addition to controls functions for CAS-related user interfaces.

ECM/EMM reception function

5.10 Copy control

5.10.1 Analog video output

Specific copy control functions must be implemented to a receiver for each analog video output format as shown in the following table.

2-28―

ARIB TR-B15

Version 4.6-E1

A receiver must obtain the control information from "service_type" (Identification information for service format) in the service list descriptor, "copy_control_type" (Format information for copy control),

"digital_recording_control_data" (Control information for digital copying), and "APS_control_data"

(Control information for analog output copying) in the digital copy control descriptor.

(See "Digital copy control descriptor" in Section 4 of Part 1 of this document.)

Specifically, a receiver must obtain information on false synchronization pulses and color strips that are introduced by Macrovision from "APS_control_data" (Control information for analog output copying). It must obtain information on CGMS-A, which is sent as a video ID signal, from

"digital_recording_control_data" (Control information for digital copying). It must obtain information on

APS (Control information for analog output copying), which is sent as a video ID signal, from

"APS_control_data".

Analog video output **1

480i composite

480i component

480p component

720p component

1080i component

RGB analog output **4

Macrovision **2

False synchronization pluses, Color strips

False synchronization pluses

-

-

-

-

Video ID signal **3

CGMS-A

APS

CGMS-A

APS

CGMS-A

APS

CGMS-A

APS

CGMS-A

APS

-

**1) The same rule applies to analog video output whose format has been converted from the format of the received video signal in the receiver.

**2) To use the Macrovision pulses and strips, a broadcasting company must have a contract with

Macrovision. No parameters should be transmitted.

**3) A video ID signal consists of CGMS-A information, APS information, and other information. It uses the identification signals superimposed in VBI, and transmitted to a receiver. See "7.2.3 Allocation of an identification signal" in this section.

**4) For information on RGB analog output, see 5.15.4 in this section. For information on operation of

RGB analog output, See Section 6 of Part 1 of this document.

2-29―

ARIB TR-B15

Version 4.6-E1

5.10.2 Digital audio output

Manufacturers decide whether a receiver should support digital audio output. If a receiver needs to support digital audio output, it must obtain information from "service_type" (Identification information for service format) in the service list descriptor, "copy_control_type" (Format information for copy control),

"digital_recording_control_data" (Control information for digital copying) in the digital copy control descriptor to perform copy control.

A receiver must follow IEC 60958 if it uses the linier PCM to output audio. It must follow IEC 61931

AAC extension if it uses the AAC stream to output audio.

5.10.3 Hi-speed digital interface output

Manufacturers decide whether to equip high-speed digital interface to a receiver. If a receiver needs to be equipped with high-speed digital interface, the following requirements must be fulfilled:

A receiver must obtain information from service_type, copy_control_type, digital_recording_control_data and encryption_mode to perform copy control.

A receiver should appropriately control MPEG_TS output in a digital audio service, temporary audio service, data service, temporary data service, and bookmark list service. In addition, sometimes there are output restrictions in the case of output with MPEG_PS to an IP interface.

See "Digital copy control descriptor" and " Content availability descriptor" in Section 4 of Part 1 of this document.

A receiver must use DTCP to protect the copyrights of programs whose protection is specified by broadcasting companies. For details on DTCP, see the DTCP specification document.

To use DTCP with MPEG_TS to perform output for digital TV service, temporary video service, data service, temporary data service, or bookmark list data service, "DTCP_descriptor" must be inserted. In addition, to perform output with MPEG_PS to an IP interface, PCP-UR must be inserted as UR Mode =

10 and Content Type = 00.

For digital audio service and temporary sound service, to use DTCP with MPEG_TS to perform output to an IP interface, DTCP_audio_descriptor must be inserted. In addition, to perform output with

MPEG_PS to an IP interface, PCP-UR must be inserted as UR Mode=10 and Content Type=01.

See related information in Section 8 of Part 1 of this document..

If a receiver needs to output only the audio stream through a separate high-speed digital interface that follows the specifications for a serial interface, the following requirements must be fulfilled:

A receiver must follow the IEC60958-conformant format (including IEC61937-conformant format) of

IEC61883-6.

The receiver must use information in "digital_recording_control_data" of the digital copy control descriptor to set a value for "Channel_status" that is embodied in the IEC60958-conformant format of

IEC61883-6.

2-30―

ARIB TR-B15

Version 4.6-E1

The receiver must obtain information from "copy_control_type" and "digital_recording_control_data" to perform copy control.

See "Digital copy control descriptor" in Section 4 of Part 1 of this document.

The receiver must use DTCP to protect the copyrights of programs whose protection is specified by broadcasting companies.

The receiver should appropriately control MPEG_TS output in a digital audio service, temporary audio service, data service, temporary data service, and bookmark list service.

If DTCP needs to be applied, the signal must include "DTCP_descriptor". For details on DTCP, see the

DTCP specification document.

The receiver should allow MPEG_TS output of a digital audio service, temporary audio service, data service, temporary data service, or bookmark list service if the value of "copy_control_type" is 11 because it satisfies the requirements of IEC61883-4.

5.10.4 Digital video output

A receiver must be equipped with a DVI. The receiver must follow the HDCP specifications to set appropriate protection technology for contents whose copy control is specified by the digital copy control descriptor, or contents whose protection is specified by the content availability descriptor. For information on operations regarding this issue, see Section 8 of Part 1 of this document.

5.10.5 Digital video and audio output

A receiver must be equipped with an HDMI. The receiver must follow the HDCP specifications to set appropriate protection technology for contents whose copy control is specified by the digital copy control descriptor, or contents whose protection is specified by the content availability descriptor. For information on operations regarding this issue, see Section 8 of Part 1 of this document.

5.11 Download function

See "Chapter 6 Guidelines for a receiver about download reception" in Section 1 of Part 1 of this document.

5.12 Reception service at shipment

Manufacturers can decide what should be the transponder, TS, and service ID of the default service that will be received when a user sets up the receiver in the user's home.

5.13 System test

5.13.1 IC card test

See "4.20.1 IC card test" in Section 5 of Part 1 of this document.

2-31―

ARIB TR-B15

Version 4.6-E1

5.13.2 Telephone line connection test

5.13.2.1 Thelephone line connection test

This function is for line connection confirmation with the public line, and it will be launched when the user selects this function at the test menu screen.

After it is launched, the receiver detects the dial tone after offhook. If the dial tone cannot be detected for 30 seconds or longer after offhook, the line shall be disconnected unconditionally. In addition, as soon as the dial tone is detected, the line can be disconnected. The detection results of the dial tone shall be displayed on the screen, notifying the connection confirmation results.

5.13.2.2 Telephone line connection test for an interactive data broadcasting service

1) Range of telephone line connection test

At the time of receiver setting, a connection test should be performed between the receiver and a center.

* Even if a receiver receives a dial tone (a signal indicating that a dial up is possible) in a PSTN connection, it does not mean that the dial type setting (PB or DP) has been correctly set up. In an

ISDN connection, a pseudo tone may be returned from the analog port of TA. Therefore, reception of a pseudo tone does not mean that the line is correctly connected.

Figure 5-1 shows the range of line connection test.

Receiver

Modem

Public switched telephone network, etc.

Collection network

Access point

Range of telephone line connection test

Center

Figure 5-1 The range of line connection test

2) Line connection and settings

Line connection and settings must be set for a PSTN line.

(1) Connect a PSTN line to a receiver.

(2) Confirm the following initial setting have been set:

Postal code

Line type for priority usage

• dentification number for a communication company

2-32―

ARIB TR-B15

Version 4.6-E1

Cancellation number for a fixed priority connection

Caller ID notification

Optional external phone number

Dial type

3) Line connection test

(1) Connect to the center via an actual service or other services.

(2) Confirm that the connection has been established normally by referring to the screen display.

(3) If an error message is displayed, follow the description in the message to take corrective actions.

5.14 Accumulation function

Manufacturers can decide whether to implement an accumulation function to a receiver. If a receiver needs to be implemented with an accumulation function, the receiver must follow the rules specified in Section 8 of

Part 1 of this document. It is also recommended that the receiver follow the rules specified in "7.3 Assurance of the uniqueness of a broadcasting program and its contents".

5.15 Others

5.15.1 Priory for various kinds of display

Appropriate priority should be given to each display element according to the order shown below when two or more elements superimpose on each other in the same screen region.

1) Error message (See 4.14 in this document)

4) Subtitles

5.15.2 Priority for power standby processing

Appropriate priority should be given to each power standby process according to the order shown below.

2) Manufacturers can decide which of the three processes need to acquire priority: Electric currency control, EMM reception control that is controlled by the CA_EMM_TS descriptor, or downloading.

Electric currency control and EMM reception control that is controlled by the CA_EMM_TS descriptor must acquire priority if the data common to the entire receiver has already been downloaded.

As described above, a digital satellite broadcasting receiver uses the electric currency control to perform many processes during power standby. The receiver's user manual should contain some description about this system, or some other methods of notifying a user should be devised.

2-33―

ARIB TR-B15

Version 4.6-E1

5.15.3 Reset button

A receiver should be equipped with a reset button to be prepared for a failure where a receiver becomes inoperable. The reset button should be able to recover the receiver from the inoperable status.

5.15.4 RGB analog terminal

Manufacturers can decide whether to equip a VGA terminal to a receiver. If it needs to be equipped with a VGA terminal, the terminal connector must fulfill the requirements described in "4. Physical

Connections" in "Enhanced Display Data Channel Standard (Version 1)" issued by VESA. The output signal format must fulfill the requirements described in "2. VESA Video Signal Definition" in "Video

Signal Standard (Version 1, Rev. 1)" issued by VESA.

Manufacturers can decide whether to equip a DVI terminal that outputs analog signals. If a receiver needs to be equipped with a DVI terminal, the terminal connector should fulfill the requirements specified in "5. Physical Interconnect Specification" in "Digital Visual Interface DVI (Revision 1.0)" issued by DDWG. The output signal format should fulfill the requirements specified in 2.5 Analog of "2.

Architectural Requirements" in "Digital Visual Interface DVI (Revision 1.0)".

For information on the operation of RGB analog outputs, see Section 8 of Part 1 of this document.

5.15.5 Digital video terminal

Manufacturers can decide whether to equip a DVI terminal to a receiver. If a receiver needs to be equipped with a DVI terminal, the terminal connector should fulfill the requirements specified in "5.

Physical Interconnect Specification" in "Digital Visual Interface DVI (Revision 1.0)" issued by DDWG.

The output signal format should fulfill the requirements specified in "2. Architectural Requirements" in

"Digital Visual Interface DVI (Revision 1.0)".

For information on copyright protection technologies, see "5.10.4 Digital Video Output" in this section and Section 8 of Part 1 of this document.

5.15.6 Digital video and audio terminal

Manufacturers can decide whether to equip an HDMI terminal to a receiver. If a receiver needs to be equipped with an HDMI terminal, the terminal must fulfill the requirements specified in

"High-Definition Multimedia Interface Specification" issued by "HDMI Licensing, LLC".

For information on copyright protection technologies, see "5.10.5 Digital Video and Audio Output" in this section and Section 8 of Part 1 of this document.

5.15.7 Modem

See “ARIB STD-B21 Chapter 11 Specifications of bidirectional communication function”. A PSTN compatible modem (V.22bis or more, MNP4 or more) is required when it is to be equipped.

2-34―

ARIB TR-B15

Version 4.6-E1

6 Operation Specifications for PSI/SI Tables That Can Be Inserted into Partial TS Outputs

6.1.1 Definition of tables and descriptors

6.1.1.1 Types of tables and their IDs

If a receiver needs to output a digital satellite broadcasting program as a partial TS, the receiver must use the tables described in Table 6-1. For details on each table, see "ARIB STD-B10" and "ARIB STD-B21".

Table 6-1 PSI/SI tables used in digital satellite broadcasting

Table name

PAT(Program Association Table)

Function description

PMT(Program Map Table)

DIT (Discontinuity Information Table)

SIT (Selection Information Table)

This table contains IDs of TS packets through which

PMTs of a partial TS are transmitted.

This table contains IDs of TS packets through which the coded signals that constitute a broadcasting program are transmitted.

This table contains discontinuity points where a partial

TS program may have inconsistant information regarding the program array.

This table contains information on a partial TS program.

Table 6-2 shows the values assigned to PIDs of the transport stream packets that transmit sections of a partial

TS.

Table 6-2 PIDs for PSI/SI tables

PID Table

0x0000 PAT

PIDs are specified in a PAT PMT

0x001E DIT

0x001F SIT

Table 6-3 shows the values (table_id) assigned to tables that contain information about sections of a partial

TS that a receiver outputs. These values are specified in Section 4.1 of Part 1 of "ARIB STD-B10".

Table 6-3 table_id for tables table_id Table

0x00 PAT

0x02 PMT

0x7E DIT

0x7F SIT

6.1.1.2 Types of descriptors and their identifiers

Table 6-4 lists the descriptors that can be used in a partial TS. Descriptions of all descriptors are provided in

"5.2 Types of descriptors and their identifiers" in Section 4 of Part 1 of this document. Descriptors that are excluded from Table 6-4 cannot be used in a partial TS.

2-35―

ARIB TR-B15

Version 4.6-E1

Table 6-4 Descriptors that can be used in a partial TS

Descriptor name

Stuffing Descriptor

Service Descriptor

Short Event Descriptor

Extended Event Descriptor

Component Descriptor

Stream Identifier Descriptor

Content Descriptor

Parental Rate Descriptor

Hierarchical Transmission Descriptor

Digital Copy Control Descriptor

Hyper Link Descriptor

Audio Component Descriptor

Target Area Descriptor

Emergency Information Descriptor

Data Component Descriptor

Data Contents Descriptor

Video Decode Control Descriptor

Event Group Descriptor

Broadcaster Name Descriptor

Component Group Descriptor

Series Descriptor

Content Availability Descriptor

Partial Transport Stream Descriptor

Network Identification Descriptor

Partial TS Time Descriptor

Function descriptions

See Section 4 of Part 1 of this document.

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

Same as above

This descriptor provides information on the partial TS.

This descriptor provides information on network identification

This descriptor provides information on the partial TS time

Broadcast ID Descriptor This descriptor provides information on broadcast IDs that are necessary for data replays.

Tag values (descriptor_tag) that need to be assigned to all descriptors except for "Broadcast ID Descriptor" should follow the specifications described in "5.2 Types of descriptors and their identifiers" in Section 4 of

Part 1 of this document, and "9.1.7.2" in "ARIB STD-B21". The tag value "0x85" should be assigned to

"Broadcast ID Descriptor".

6.1.2 Table common items

6.1.2.1 version_number

(1) Assignment of version_number

"version_number" should be independently assigned to each table.

The PMT of a broadcasted program can be output with the same "version_number" as the PMT of a

2-36―

ARIB TR-B15

Version 4.6-E1 partial TS only if assignment of the PMT to the partial TS does not pose any problems. If a receiver rearranges the structure of the PAT, DIT, SIT, or PMT, the receiver can assign any value to the

"version_number" of each table.

(2) When to change a partial TS

If a receiver directly outputs the PMT of a broadcasted program as the PMT of a partial TS, the partial

TS should only be changed when it is broadcasted. However, if the receiver rearranges the structure of a table, the partial TS should be changed when the table information is changed. For information on how to perform a stream change that involves insertion of a DIT, see the document section on a DIT. If the stream change does not involve insertion of a DIT, a delay that is associated with a stream change should be minimized.

(3) Version change

A receiver should manage the "version_number" and can assign any value to the "version_number".

When a table is either updated or changed, the "version_number" should be incremented by 1. The

"version_number" should be correctly managed even when the PMT of a broadcasted program has not been normally updated.

The "version_number" should also be incremented by 1 when a change to a table involves insertion of a DIT.

6.1.2.2 current_next_indicator

The value "1" should be assigned to the "current_next_indicator" of all tables, and then the tables should be output. If the value "0" is assigned to the "current_next_indicator", the corresponding table should not be output. When a receiver rearranges the structure of a table, the value "1" must be assigned to the

"current_next_indicator".

6.1.2.3 running_status

The "running_status" of all SITs should be undefined (assigned with the value "0x0"), and then the SITs should be output.

The value "1" should be assigned to all the bits of each item.

6.1.3 Interval for resending each table (Repetition interval)

Table 6-5 shows the maximum intervals for resending each table within a partial TS.

2-37―

ARIB TR-B15

Version 4.6-E1

Table 6-5 Maximum intervals for outputting each table (Repetition interval)

Table_id Table Recommended maximum interval for insertion

0x00 PAT

0x02 PMT

120ms

120ms

0x7E DIT

0x7F SIT

This table should be inserted when it is necessary

3.6s

Each table should be inserted to the same position where the existing table is inserted, replacing the existing table. For example, a new PAT should replace the existing PAT that has been sent as a part of a program. A new PMT should replace the existing PMT that has been sent as a part of a program. The insertion interval for a SIT should be the same as that for the EIT[p/f] which is sent as a part of a program. The above maximum intervals actually indicate 110% of the maximum intervals specified by general rules for broadcasting because some margins may be necessary. Generally, an SIT is used as a replacement for an NIT.

However, the maximum interval for an SIT is the same as that for an EIT [p/f] that is more frequently transmitted than NIT because an SIT additionally contains service information. For details on table outputs within a partial TS, see "11.1 Section placement rules for TS packets" and "11.2 Transmission of TS packets" in Section 4 of Part 1 of this document.

6.2.1 PAT

6.2.1.1 Structure and operation of a PAT

[Purpose]

This table contains IDs of TS packets that transmit the PMTs and SITs related to the program contents that are inserted into a partial TS.

[Structure]

Table 6-6 shows the structure of a PAT.

Table 6-6 Structure of a PAT (Program Association Table)

Data structure program_association_section () {

Bit Identifier

2-38―

ARIB TR-B15

Version 4.6-E1 for (i = 0;i< N;i++) { if( program_number == "0x0000" ){

} else{

}

}

}

[Meaning of each field]

Meaning of each field is defined by Section 5.2.1 of Part 2 of "ARIB STD-B10", and Section 2.4.4 of

"ISO/IEC13818-1".

[Output operation rules]

The output interval is defined in Section 6.1.3 of this document.

Only one PAT can be output with one partial TS.

A new PAT should be output to the same location where the existing PAT has been inserted, replacing the existing PAT.

Table 6.7 describes the rules for output operation of each field.

Table_id

Table 6-7 Output operation rules for a PAT

Rules for output operation of each field

The value "0x00" should be assigned to this field. section_length transport_stream_id version_number current_next_indicator section_number last_section_number

[program_loop] program_number network_PID program_map_PID

The section length of a PAT should be assigned to this field. The maximum length of an entire section is 1024 bytes. Therefore, the maximum value for this field is 1021.

The "transport_stream_id" of the original transport stream that has contained the PAT should be assigned to this field. This field should contain the "transport_stream_id" used in the original program that constituted the partial TS.

This field should be incremented by 1 when the PAT is updated. When a partial TS starts to be outputs, any value can be assigned to this field.

The value "1" should be assigned to this field.

The value "0x00" should be assigned to this field.

The value "0x00" should be assigned to this field.

A loop should be created for the services contained in the relevant TS. No maximum loop count is specified.

The "service_id" of the relevant service should be assigned to this field. One

"program_loop" for the condition (program_number = "0x0000") must be created within a PAT. (The PID of an SIT ("0x001F") should be assigned to the next PID field.)

The PID of an SIT ("0x001F") should be assigned to this field.

The PID of the PMT of the relevant service should be assigned to this field.

2-39―

ARIB TR-B15

Version 4.6-E1

6.2.2 PMT

6.2.2.1 Structure and operation of a PMT

[Purpose]

This table contains the PIDs of TS packets that transmit coded signals that constitute a program that will be output as a partial TS.

[Structure]

Table 6-8 shows the structure of a PMT.

Table 6-8 Structure of a PMT (Program Map Table)

Data structure program_map_section () {

Bit Identifier for (i = 0;i< N;i++) { descriptor()

} for (i = 0;i< N;i++) { for (j = 0;j< M;j++) {

Descriptor()

}

}

}

[Meaning of each field]

Meaning of each field is defined by Section 5.2.3 of Part 2 of "ARIB STD-B10" and Section 2.4.4 of

"ISO/IEC13818-1".

2-40―

ARIB TR-B15

Version 4.6-E1

[Output operation rules]

The PMT must be output when a partial TS includes a stream. The PMT must be relevant to the services described in the PAT, and must be retransmitted at an interval described in Section 6.1.3.

If the structure of a partial TS service remains the same since the service was originally broadcasted, and also fulfills the requirements specified by the current standard, the PMT of the service can be directly output. If the PMT needs to be modified and then output, the new PMT should replace the existing PMT. If a PMT is sent as Multi Sections, and the PMT is not compatible with a program that needs to be output as a partial TS, the PMT must not be directly output. The PMT must be first modified to be compatible with a partial TS before being output.

If a broadcasting service is cancelled, a relevant PMT may not be output. If a partial TS consists of only this broadcasting service, only a PAT is assigned to the partial TS. The partial TS should not be output.

Table 6-9 describes the rules for output operation of each field. table_id

Table 6-9 Output operation rules for a PMT

Rules for output operation of each field

The value "0x02" should be assigned to this field section_length program_number version_number current_next_indicator section_number last_section_number

PCR_PID program_info_length

[1st (program) loop]

[2nd (ES)_loop] elementary_PID

ES_info_length

The section length of a PMT should be assigned to this field. The maximum length for an entire section is 1024 bytes. Therefore, the maximum value for this field is 1021.

The "service_id" of the relevant service should be assigned to this field. The value output during broadcast should be directly assigned to this field.

In a normal operation, this field should be incremented by 1 when the

PMT is updated. If the PMT of the original broadcasted program is inserted to the partial TS, and a system error occurs during the broadcast, the "version_number" may be incremented by more than 1.

This "version_number" can be directly output.

The value "1" should be assigned to this field.

The value "0x00" should be assigned to this field.

The value "0x00" should be assigned to this field.

The PID of the TS packet that transmits the relevant PCR packet should be assigned to this field.

The loop length of "The 1st_loop" should be assigned to this field.

The maximum loop length should not exceed the value for

"section_length".

The maximum loop count is 16. this field. (Stream type identifiers are defined in Section 4 of Part 1 of this document.)

The PID of the relevant ES or TS packet that transmits payload should be assigned to this field.

The length of the next "ES descriptor" should be assigned to this field.

2-41―

ARIB TR-B15

Version 4.6-E1

6.2.2.2 Descriptors that can be inserted into a PMT

Table 6-10 lists the descriptors that can be used in a PMT.

0x09

Table 6-10 Descriptors that can be used in a PMT

Tag Descriptor

Conditional Access System Descriptor

0xC1 Digital Copy Control Descriptoyr

0xC8 Video Decode Control Descriptor

0xFC Emergency Information Descriptor

Insertion condition

×

{

{ loop

-

1

D

2

2

D

{

D

{

*1 2

1

2

→Must be inserted to the appropriate descriptor field within a table if this descriptor has been inserted to a broadcast program, and the program component needs to be output.

{

→Can be inserted to the appropriate descriptor field within a table.

× →Cannot be inserted to any part of a table.

→Recommended to be inserted to the appropriate descriptor field within a table.

1

→Can be inserted to "1st loop"

2

→Can be inserted to "2 nd

loop"

D

→Can be inserted to both "1 st

loop" and "2 nd

loop"

6.2.2.3 Descriptors that can be inserted to the first loop (Program loop) of a PMT

For information on the structures, meaning of each field, and basic output operation rules of the following descriptors, see Section 4 of Part 1 of this document.

(1) Digital Copy Control Descriptor

See "Digital Copy Descriptor" in Section 4 of Part 1 of this document.

[Purpose]

This descriptor should be placed into a PMT when digital copy control information needs to be indicated, or the maximum transmission rate needs to be described for all target services. This descriptor should also be used when both of the actions described above need to be performed. This descriptor should be inserted to a PMT as it was when it was first transmitted from a broadcaster.

[Output operation rule]

If the relevant ES needs to be protected from digital copying, and this descriptor is originally contained in a broadcasted program, the original descriptor must be inserted into the PMT as it was when its was first transmitted.

2-42―

ARIB TR-B15

Version 4.6-E1

(2) Emergency Information Descriptor

[Purpose]

This descriptor indicates that the relevant service is either an emergency warning broadcast or a test broadcast for emergency warning signals.

[Output operation rule]

Output of this descriptor is optional. However, it is recommended that this descriptor be deleted.

(3) Target Area Descriptor

[Purpose]

This descriptor indicates the area where all services should be provided

[Output operation rule]

This descriptor is placed in a PMT during broadcast of a relevant service when the "service_type" of the service is 0xC0 (data service), and the target area of the service needs to be indicated. Output of this descriptor is optional during partial TS output.

(4) Content Availability Descriptor

[Purpose]

See "Content Availability Descriptor" in Section 4 of Part 1 of this document.

[Output operation rule]

This descriptor is placed in a PMT to specify control information for accumulation and output for all relevant services. This descriptor and Digital Copy Control Descriptor are used to manage control information.

6.2.2.4 Descriptors that can be inserted to the second loop (ES loop) of a PMT

For information on the structures, meaning of each field, and basic output operation rules of the following descriptors, see Section 4 of Part 1 of this document.

(1) Stream Identifier Descriptor

[Purpose]

This descriptor attaches a label to a target ES. This label can be used to obtain the information specified by the component descriptor in a SIT.

[Output operation rule]

If a SIT contains a component descriptor or audio component descriptor in its "service loop", Stream

Identifier Descriptor creates a link between the component descriptor's "component_tag" and the target ES.

Table 6-11 shows the output operation rules for Stream Identifier Descriptor.

2-43―

ARIB TR-B15

Version 4.6-E1

Table 6-11 Output operation rules for Stream Identifier Descriptor descriptor_tag descriptor_length

Output operation rule for each field

The value "0x52" should be assigned to this field.

The length of Stream Identifier Descriptor should be assigned to this field. to this field. This value will be linked with the component tag value of a component descriptor in a SIT.

(2) Hierarchical Transmission Descriptor

[Purpose]

This descriptor is used to indicate the relationships between layered ESs when a relevant service is transmitted as a combination of multiple hierarchical layers.

[Output operation rule]

Output of this descriptor is optional during partial TS output.

(3) Data Component Descriptor

[Purpose]

This descriptor indicates the coding method for a relevant ES.

[Output operation rule]

This descriptor is always sent when a program is broadcasted if the program contain data components (including subtitles and captions). If the data contents need to be inserted to a partial TS, and then the partial TS needs to be output, this descriptor must be inserted in a SIT.

(4) Target Area Descriptor

[Purpose]

This descriptor indicates the area where the ES should provide service.

[Output operation rules]

This descriptor is always placed in a PMT when the "stream_type" of the ES is a data broadcast service, and the target area of the ES needs to be specified. Output of this descriptor is optional during partial TS output.

If this descriptor needs to be inserted in both the 1st_loop and 2nd_loop of a PMT, the target area specified for the 2nd_loop must indicate a location that is a part of the area specified for the

1st_loop.

(5) Digital Copy Control Descriptor

See "Digital Copy Control Descriptor" in Section 4 of Part 1 of this document.

[Purpose]

This descriptor should be placed into a PMT when digital copy control information needs to be indicated, or the maximum transmission rate needs to be described for the target ES. This descriptor should also be used when both of the actions described above need to be performed. If this

2-44―

ARIB TR-B15

Version 4.6-E1 descriptor has been sent with the broadcasted program, the descriptor needs to be output without any changes.

[Output operation rule]

If the relevant ES needs to be protected from digital copying, and this descriptor is originally contained in a broadcasted program, the original descriptor must be inserted into the PMT as it was when its was first transmitted.

(6) Video Decode Control Descriptor

[Purpose]

This descriptor is used when the video decoding must be controlled at the changing point of video coding methods within the same "service_id". This descriptor also indicates whether the ES is a static frame image of an MPEG-I.

[Output operation rule]

This descriptor should be inserted to a PMT if the original broadcasted program contains this descriptor, and the actions specified by this descriptor needs to be perform in the video that constitutes a partial TS.

[Other notes]

Video Decode Control Descriptor contains the following sets of information that enable reception control.

1) Seamless video switching when the video format is changed

2) Determination of whether the ES is a static frame image of a MPEG-I.

If the same reception control needs to be performed during broadcast and replay, both of the above sets of information should be output. A receiver may use the second information set to determine whether the ES is a static image. Therefore, when a static image needs to be output as a partial TS, Video Decode Control

Descriptor must be inserted to the PMT.

6.2.3 DIT (Discontinuity Information Table)

6.2.3.1 Structure and operation of a DIT

[Purpose]

This table indicates the discontinuity points of a stream that will be output as a partial TS. If there are some discontinuity points in a partial TS for some reasons, a receiver inserts a DIT to the partial TS.

[Structure]

Table 6-12 shows the structure of a DIT, which consists of a single section. This DIT section is transmitted through a transport stream packet whose PID value is "0x001E". The table ID for a DIT is

"0x7E".

2-45―

ARIB TR-B15

Version 4.6-E1

Table 6-12 Structure of a DIT (Discontinuity Information Table)

Data structure discontinuity_information_section () {

Bit Identifier

}

[Meaning of each field]

The meaning of each field is defined by "9.1.8.2" of Chapter 9 of "ARIB STD-B21" and "7.1.1" of

"ETS 300 468".

[Output operation rules]

When a partial TS is output, a DIT must be inserted to the discontinuity points of the stream based on the system time (Specifically, the discontinuity points of PCR). If discontinuity of

"continuity_counter" occurs within a transport packet header of at least one of the packets that constitute a partial TS, a DIT must also be inserted to the points where this type of discontinuity occurs. Discontinuity of "continuity counter" means an addition or deletion of an ES. This type of discontinuity may occur in a normal broadcast stream due to some problems caused by a broadcaster.

In such case, no DIT needs to be inserted.

A receiver needs to insert a DIT to a partial TS when there are some discontinuity points in a partial

TS due to some programs caused by the receiver.

The following actions may cause discontinuity, which necessitates insertion of a DIT to a partial TS.

(1) Start or stop of partial TS output

(2) Change to a service that constitutes a stream during partial TS output. This change involves discontinuity of ES/PCR, and may be caused by channel change.

(3) Change to an ES that constitutes a stream during partial TS output. This change does not involve any changes to the output service, and may be due to any reasons (for example, addition or deletion of an

ES).

When a program switch from one stream to another, only one DIT should be inserted between the old stream and new stream. Separate streams should be inserted at the end of the old stream and should not be inserted at the beginning of the new stream.

If discontinuity of a partial TS has been caused by none of the above actions (for example, caused by change in SI information), no DIT should be inserted to the partial TS.

If a DIT needs to be inserted to a partial TS, two consecutive transporter packets with the specified format must be inserted to the partial TS. No other transport packets should be inserted between

2-46―

ARIB TR-B15

Version 4.6-E1 these two transporter packets. If a change to the stream involves insertion of a DIT, the stream information and table information before the insertion of the DIT must not exist in the stream after the insertion of the DIT. Similarly, the new stream information and table information after the insertion of the DIT must not exist in the stream before the insertion of the DIT. This kind of configuration may cause confusion.

<First packet>

The first transport packet should have the PID of "0x001E", and "adaptation field" should be inserted to this packet. The value "0" should be assigned to the "payload_unit_start_indicator" of the transport packet header. The value "10" (adaptation_field only, no payload) should be assigned to the

"adaptation_field_control". The value "1" should be assigned to the "discontinuity_indicator" of the

"adaptation field", and the value "0" should be assigned every other flag of the "adaptation field". The

"stuffing_byte" should be allocated for the remaining transport packet fields.

<Second packet>

The DIT that is specified by this specification document should be inserted to the second packet. The value "0x001E" should be assigned to the PID of the transport packet header. The value "1" should be assigned to the "payload_unit_start_indicator".

Table 6-13 shows the output operation rules for each field of a DIT. table_id

Table 6-13 Output operation rules for a DIT

Output operation rule for each field

The value "0x7E" should be assigned to this field. section_length transition_flag

The section length of the DIT should be specified. The fixed value

"0x001" should be assigned to this field.

For information on how to use the bits of this field, see "9.1.8.2" in

"ARIB STD-B21".

6.2.4 SIT (Selection Information Table)

6.2.4.1 Structure and operation of an SIT

[Purpose]

This table provides summary of SI information that is necessary for providing stream information of a partial TS and service information of the services that are included in the stream.

[Structure]

Table 6-14 shows the structure of an SIT.

2-47―

ARIB TR-B15

Version 4.6-E1

Table 6-14 Structure of an SIT (Selection Information Table)

Data structure selection_information_section () {

Bit Identifier for (i = 0;i< N;i++) { descriptor()

} for (i = 0;i< N;i++) { for (j = 0;j< M;j++) { descriptor()

}

}

}

[Meaning of each field]

The meaning of each field is defined by "9.1.8.2" in Chapter 9 of "ARIB STD-B21" and "7.1.2" of

"ETS 300 468".

[Output operation rule]

An SIT must be always output to a partial TS at the interval specified in Section 6.1.3. This SIT must provide stream information of the partial TS and service information of the services that have been inserted to the stream.

Table 6-15 shows the output operation rule for each field of an SIT. table_id

Table 6-15 Output operation rules for an SIT

Output operation rule for each field

The value "0x7F" should be assigned to this field. section_length version_number current_next_indicator section_number

The section length of the SIT should be assigned to this field. The length of the entire section is 4096 bytes. Therefore, the maximum value for this field is 4093.

In a normal operation, this field should be incremented by 1 when the

SIT is updated.

The value "1" should be assigned to this field.

The value "0x00" should be assigned to this field.

2-48―

ARIB TR-B15

Version 4.6-E1 last_section_number The value "0x00" should be assigned to this field. transmission_info_loop_length The length of the "1 st

_loop" should be assigned to this field.

The maximum loop length should not exceed the value for

"section_length". service_id The "service_id" of the relevant program should be assigned to this field. The value for "service_id" should remain the same since it was first transmitted. running_status

Service_loop_length

The value "0x0" should be assigned to this field.

The length of the "2 nd

_loop" should be assigned to this field.

The maximum loop length should not exceed the value for

"section_length".

The value "Undefined (0x0)" should be assigned to all the running statuses in an SIT.

This table provide information only on the currently output event among the services that constitute a partial TS. The table must be updated or modified when this event has been changed. If there are some changes to the SIT, the "version_number" should be incremented.

Every time table information is updated or modified, the "version_number" should be incremented by 1. If the "version_number" reaches "0x1F", the next incremented value should be "0x00". Any number can be assigned to the "version_number" when the partial TS is initially output.

If the change to the table information involves insertion of a DIT, the "version_number" should be incremented by 1. However, it is not mandatory; the value for "version_number" does not need to be consecutive.

If a partial TS time descriptor has been inserted to the first loop of an SIT, "JST_time" can be used to indicate the time when the stream is output. Every time a table that updates the value of "JST_time" is inserted to the

SIT, the "version_number" of the SIT must be incremented. However, the SIT must indicate that the other descriptors in the SIT have not been updated or modified. To do so, the value "0" must be assigned to the

"other_descriptor_status" bit of the partial transport time descriptor.

6.2.4.2 Descriptors that can be inserted to an SIT

Table 6-16 shows the descriptors that can be used to an SIT.

Table 6-16 Descriptors that can be used in an SIT

Tag Descriptor

0x4D Short Event Descriptor

0x4E Extended Event Descriptor

0xC4 Audio Component Descriptor

0xC5 Hyper Link Descriptor

0xC7 Data Contents Descriptor

Insertion condition

{

{

{

{

{

Loop

2

2

2

2

2

2

2

2

2

2-49―

ARIB TR-B15

Version 4.6-E1

0x63 Partial Transport Stream Descriptor

0xD6 Event Group Descriptor

0xD8 Broadcaster Name Descriptor

0xD9 Component Group Descriptor

0xC2 Network Identification Descriptor

0x85 Broadcast ID Descriptor

{

~

{

{

D

1

2

2

{

{

~

2

2

1

*1 D

2

~

→ Must be inserted to the appropriate descriptor field within a table

{

→ Can be inserted to the appropriate descriptor field within a table

→ Required to be inserted to the appropriate descriptor field within a table as a general rule

→ Must be inserted to the appropriate descriptor field within a table if this descriptor has been inserted to a broadcast program, and the data component needs to be output

1

→ Can be inserted to "1

st

loop"

2

→Can be inserted to "2 nd

loop"

D

→ Can be inserted to both "1 st

loop" and "2 nd

loop"

*1 : Insertion of a partial TS time descriptor to the 1st loop (transmission_info_loop) is optional. A partial TS time descriptor should record the program start time and program duration of an

EIT. As a general rule, insertion of this descriptor to the 2nd loop (service_loop) of the SIT is mandatory.

6.2.4.3 Descriptors that can be inserted to the first loop (transmission_info loop) of an SIT

(1) Partial Transport Stream Descriptor

[Purpose]

This descriptor is used to describe the stream information of a partial TS

[Structure]

Table 6-17 shows the structure of the Partial Transport Stream Descriptor.

Table 6-17 Structure of a Partial Transport Stream Descriptor

Data structure partial_transport_stream_descriptor () {

Bit Identifier

}

2-50―

ARIB TR-B15

Version 4.6-E1

[Meaning of each field]

The meaning of each field is defined in "9.1.8.3" in "ARIB STD-B21".

[Output operation rule]

This descriptor must be placed in the 1st loop of an SIT.

Table 6-18 shows the output operation rule for each field of this descriptor.

Table 6-18 Output operation rules for the Partial Transport Stream Descriptor peak_rate

Output operation rule for each field descriptor_tag The value "0x63" should be assigned to this field descriptor_length The of the descriptor should be assigned to this field.

The peak packet rate of the partial TS should be assigned to this field.

This field should specify the maximum peak packet rate of the partial

TS. This 22-bit field will be coded into a positive integer at a ratio of minimum_overall_smoothin g_rate maximum_overall_smoothin g_buffer

400 bits/second.

The minimum overall smoothing buffer leak rate among all partial transport packets should be assigned to this field. This 22-bit field will be coded into a positive integer at a ratio of 400 bits/second. The value "0x3FFFFF" (undefined) should be assigned to this field.

The maximum smoothing buffer size among all partial transport packets should be assigned to this field. This 14-bits field will be coded into a positive integer with a unit of bytes. The value "0x3FFF"

(undefined) should be assigned to this field.

(2) Network Identification Descriptor

[Purpose]

This descriptor clarifies the information regarding the network where the partial TS is originally created.

[Structure]

Table 6-19 shows the structure of the Network Identification Descriptor.

Table 6-19 Structure of the Network Identification Descriptor

Data structure network_identification_descriptor () {

Bit Identifier for (i = 0;i< N;i++) {

}

}

2-51―

ARIB TR-B15

Version 4.6-E1

[Meaning of each field]

The meaning of each field is defined by "9.1.8.3" in "ARIB STD-B21".

[Output operation rule]

This descriptor must be inserted into an SIT.

Table 6-20 shows the output operation rule for each field.

Table 6-20 Output operation rules for the Network Identification Descriptor descriptor_tag

Output operation rule for each field

The value "0xC2" should be assigned to this field. descriptor_length The of the descriptor should be assigned to this field. country_code A country code associated with the location of the distribution system where the partial TS is created should be assigned to this field. If the location is Japan, the code "0x4A504E" should be assigned to this field. media_type network_id

The media type of the distribution system where the partial TS is created should be assigned to this field. If the media type is digital satellite broadcasting, the code "0x4253" should be assigned to this field.

The network identification number of the distribution system where private_data the partial TS is created should be assigned to this field. The identification number should be obtained from the NIT.

This field should remain "unused".

(3) Partial TS Time Descriptor

[Purpose]

When this descriptor is placed in the first loop of an SIT, this descriptor manages information regarding the time when the partial TS is created.

[Structure]

Table 6-21 shows the structure of the Partial TS Time Descriptor.

Table 6-21 Structure of the Partial TS Time Descriptor

Data structure partialTS_time_descriptor () { bit Identifier if ( JST_time_flag ==1 ) {

}

}

2-52―

ARIB TR-B15

Version 4.6-E1

[Meaning of each field]

The meaning of each field is defined in "9.1.8.3" in "ARIB STD-B21".

[Output operation rule]

It is recommended that this descriptor be inserted to an SIT.

"JST_time" should be inserted at an interval of less than 10 seconds.

This descriptor should not be inserted to the 2nd loop of an SIT if this descriptor has already been inserted to the 1st loop. However, if this descriptor needs to be inserted to both loops, "JST_time" should only be inserted to the descriptor in the 1st loop and not to the descriptor in the 2nd loop.

Only the service time information should be managed.

The "other_descriptor_status" needs to be set to "0" when only the Partial TS time descriptor has been changed, and other descriptors within the SIT have not been changed.

If this descriptor is inserted to the 1st loop of an SIT, the "event_version_number",

"event_start_time", and "duration" fields become invalid.

Errors in the time inserted by "JST_time" should be within 2 seconds.

Table 6-22 shows the output operation rule for each field of this descriptor.

Table 6-22 Output operation rules for the Partial TS Time Descriptor

Output operation rule for each field event_version_number event_start_time duration

This field becomes invalid if the descriptor is inserted to the 1st loop of an

SIT.

This field becomes invalid if the descriptor is inserted to the 1st loop of an

SIT. The value "0xFFFFFFFFFF" should be assigned in such case.

This field becomes invalid if the descriptor is inserted to the 1st loop of an

SIT. The "0xFFFFFF" should be assigned in such case. offset If daylight saving time (summer time) needs to be applied to "JST_time", the offset time should be assigned to this field. The value for this field should be obtained from the "local_time_offset" of the local time offset descriptor in the

TOT. If daylight saving time (summer time) does not need to be applied, the value "0x000000" should be assigned to this field. For more information on daylight saving time, see Section 4 of Part 1 of this document. offset_flag One of the following values should be assigned to this field to indicate whether the offset time should be added to or subtracted from the

"JST_time".

"0": Offset time should be added to "JST_time".

"1": Offset time should be subtracted from "JST_time".

Other_descriptor_status One of the following values should be assigned to this field to indicate the statuses of other descriptors that are inserted to the SIT.

"0": Other descriptors have not been changed.

"1": Other descriptors have been changed.

JST_time

"1" should be assigned to this field if the next field represents "JST_time".

The time when the partial TS is output should be assigned to this field. The value for this field should be obtained from the "JST_time" field of the

TOT. When "JST_time" needs to be updated, errors should be within 2 seconds.

2-53―

ARIB TR-B15

Version 4.6-E1

6.2.4.4 Descriptors that can be inserted to the 2nd loop (service loop) of an SIT.

For information on the structures, meaning of each field, and basic output operation rules of the following descriptors, see Section 4 of Part 1 of this document.

(1) Service Descriptor

[Purpose]

This descriptor contains basic information about a service that is inserted to the partial TS. This information may include the service name and broadcasting company's name.

[Output operation rule]

Only one descriptor should be inserted for a single service.

The information about the broadcasting company's name and service name should be directly obtained from the broadcasted programs.

(2) Short Event Descriptor

[Purpose]

This descriptor contains the event name and short character string that briefly explains about the event.

[Output operation rule]

As a general rule, this descriptor should be inserted to an SIT.

One descriptor should be output for one event.

The information for this descriptor should be directly obtained from the broadcasted programs.

(3) Extended Event Descriptor

[Purpose]

This descriptor contains a character string that explains the event in detail.

[Output operation rule]

The same descriptor information transmitted with the broadcasted program should be inserted to an

SIT.

Multiple instances of this descriptor may be transmitted from a single broadcast program (Maximum of 16). No restrictions are specified for the number of instances. That is, all of the descriptor instances can be inserted to the SIT, or only a limited number of the descriptor instances can be inserted to the SIT (for example, the first two instances).

(4) Component Descriptor

[Purpose]

This descriptor contains information on the video component stream that constitutes an event.

[Output operation rule]

In a broadcasted program, one descriptor is output for each video component within an event. If a stream identifier descriptor is inserted to the PMT, this component descriptor should be inserted to the SIT, as a general rule. The component descriptor must provide information about the video

2-54―

ARIB TR-B15

Version 4.6-E1 component that is inserted to the SIT, and the information must remain the same since the information is first transmitted.

[Other notes]

The information that the component descriptor provides during broadcast may be inconsistent with the actual properties of the component because an event mode may be changed during an event. It is preferable that the component descriptor be changed at the time of partial TS creation, so that the information it provides becomes consistent. However, it is also acceptable to simply insert the unchanged component descriptor to the SIT. (In a broadcasted program, the "component_type" of the component descriptor indicates the type of the representative component of a program. When the event mode is changed during a program, the "component_type" does not change immediately. This must be taken into consideration when a partial TS needs to be output.)

(5) Parental Rate Descriptor

[Purpose]

This descriptor contains information on the age at which parental control is applied for an event.

[Output operation rule]

Only when this descriptor is inserted to an event of the broadcasted program, the same descriptor information may be inserted to the SIT.

(6) Audio Component Descriptor

[Purpose]

This descriptor contains information on the audio component stream that constitutes an event.

[Output operation rule]

In a broadcasted program, one descriptor is output for each audio component within an event. If a stream identifier descriptor is inserted to the PMT, this component descriptor should be inserted to the SIT, as a general rule. The component descriptor must provide information about the audio component that is inserted to the SIT, and the information must remain the same since the information is first transmitted.

[Other notes]

The information that the component descriptor provides during broadcast may be inconsistent with the actual properties of the component because an event mode may be changed during an event. It is preferable that the component descriptor be changed at the time of partial TS creation, so that the information it provides becomes consistent. However, it is also acceptable to simply insert the unchanged component descriptor to the SIT. (In a broadcasted program, the "component_type" of the component descriptor indicates the type of the representative component of a program. When the event mode is changed during a program, the "component_type" does not change immediately. This must be taken into consideration when a partial TS needs to be output.)

2-55―

ARIB TR-B15

Version 4.6-E1

(7) Hyper Link Descriptor

[Purpose]

This descriptor contains hyperlinks to other programs, in-program information, and other information related to the program.

[Output operation rule]

Insertion of this descriptor is optional.

(8) Data Contents Descriptor

[Purpose]

This descriptor contains information on the data component stream that constitutes an event.

[Output operation rule]

This descriptor is transmitted for a data component of an event during broadcast (optional). If this descriptor is attached to a data component, and the data component needs to be inserted to a partial

TS, the attached descriptor must be inserted to the SIT.

(9) Content Descriptor

[Purpose]

This descriptor contains information on the genre of the event.

[Output operation rule]

Insertion of this descriptor to an SIT is optional.

One content descriptor is transmitted for one broadcast program (optional). If this descriptor is transmitted with a program, the descriptor should be directly inserted to the SIT.

(10) Event Group Descriptor

[Purpose]

This descriptor contains information about related services, grouped services during SD/HD switching broadcasting, and links to a relay service.

[Output operation rule]

If this descriptor needs to be inserted to an SIT, the original information transmitted with the broadcasted program must be inserted.

(11) Broadcaster Name Descriptor

[Purpose]

This descriptor is used to describe the name of the broadcaster.

[Output operation rule]

If this descriptor needs to be inserted to an SIT, the original information transmitted with the broadcasted program must be inserted.

2-56―

ARIB TR-B15

Version 4.6-E1

(12) Component Group Descriptor

[Purpose]

This descriptor defines and indicates combinations of components within an event. This descriptor is used for Multi-view TV (MVTV) and other functions.

[Output operation rule]

If this descriptor needs to be inserted to an SIT, the original information transmitted with the broadcasted program must be inserted.

(13) Series Descriptor

[Purpose]

This descriptor is used to determine whether a program is a part of a series.

[Output operation rule]

If this descriptor needs to be inserted to an SIT, the original information transmitted with the broadcasted program must be inserted.

(14) Partial TS Time Descriptor

[Purpose]

If this descriptor is inserted to the 2nd loop of an SIT, this descriptor is used to describe the time information of an event that is inserted to the SIT.

[Structure]

For details on the structure of the Partial TS Time Descriptor, see Table 6-21.

[Meaning of each field]

The meaning of each field is defined in "9.1.8.3" in "ARIB STD-B21".

[Output operation rule]

As a general rule, this descriptor should be inserted to an SIT.

"JST_time" should be inserted at an interval of less than 10 seconds.

If one service is inserted to a partial TS, only one partial TS time descriptor should be inserted to the

SIT. If multiple services are inserted to a partial TS, only the partial TS time descriptor that is inserted to the 1 st

loop of the SIT should hold "JST_time", and the descriptor inserted to the 2 nd

loop should not hold "JST_time". The descriptor inserted to the 2 nd

loop only manages the time information of the relevant services.

The "other_descriptor_status" needs to be set to "0" when only the Partial TS time descriptor has been changed, and other descriptors within the SIT have not been changed.

Errors in the time inserted by "JST_time" should be within 2 seconds.

2-57―

ARIB TR-B15

Version 4.6-E1

Table 6-23 shows the output operation rule for each field of this descriptor.

Table 6-23 Output operation rules for the Partial TS Time Descriptor offset

Output operation rule for each field value should be assigned to this field descriptor_length The of the descriptor should be assigned to this field. event_version_number This field becomes valid if the descriptor is inserted to the 2nd loop of an SIT.

The value for this field should be incremented by 1 every time the event information in the relevant service is changed. The initial value can take any number. A change to a stream may involve addition of a DIT. If the services event_start_time before and after the DIT are continuous, the "event_version_number" should also be continuous when it is incremented.

If the descriptor is inserted to the 2nd loop of an SIT, this field indicates the start time of the relevant event. The "start_time" of the EIT should be assigned to this field. If this field needs to be invalid, the value

"0xFFFFFFFFFF" should be assigned. duration If the descriptor is inserted to the 2nd loop of an SIT, this field indicates the duration of the relevant event. The "duration" of the EIT should be assigned to this field. If this field needs to be invalid, the value "0xFFFFFF" should be assigned.

If daylight saving time (summer time) needs to be applied to

"event_start_time", the offset time should be assigned to this field. The value for this field should be obtained from the "local_time_offset" of the local time offset descriptor in the TOT. If daylight saving time (summer time) does not need to be applied, the value "0x000000" should be assigned to this field.

For more information on daylight saving time, see Section 4 of Part 1 of this document. offset_flag One of the following values should be assigned to this field to indicate whether the offset time should be added to or subtracted from the

"event_start_time" and "JST_time".

"0": Offset time should be added to the "event_start_time" and "JST_time".

"1": Offset time should be subtracted from the "event_start_time" and

"JST_time". other_descriptor_status One of the following values should be assigned to this field to indicate the statuses of other descriptors that are inserted to the SIT.

JST_time_flag

JST_time

"0": Other descriptors have not been changed.

"1": Other descriptors have been changed.

This field indicates whether the next field represents "JST_time". The value

"1" should be assigned to this field if the next field represents "JST_time".

The time when the partial TS is output should be assigned to this field. The value for this field should be obtained from the "JST_time" field of the TOT.

When "JST_time" needs to be updated, errors should be within 2 seconds.

This field should only be inserted to the partial TS time descriptor that is inserted to the 1 st

loop of the SIT.

[Other notes]

If one service is inserted to a partial TS, this descriptor should only be inserted to either one of the loops in the SIT. If the "JST_time" needs to be described, this descriptor should be inserted to the 1 st loop. If the time information of the services needs to be described, or both the "JST_time" and time information of the services need to be described, this descriptor should be inserted to the 2 nd

loop of the SIT.

2-58―

ARIB TR-B15

Version 4.6-E1

If multiple services are inserted to a partial TS, multiple partial TS time descriptors may be inserted to the 2 nd

loop of an SIT to hold the time information for each service. However, if some descriptors hold

"JST_time" and others do not hold "JST_time", the descriptors' processing may become too complicated. Therefore, in order to simplify the processing, only the 1 st

loop of the SIT should hold

"JST_time", and the 2 nd

loop should not hold "JST_time". Instead, the descriptor in the 2 nd

loop should only manage the time information of the relevant services. Note, however, that it is also acceptable that all the descriptors contain "JST_time".

(15) Broadcast ID Descriptor

[Purpose]

This descriptor contains various IDs that are necessary when a user replays the data broadcasts. These

IDs are transmitted during data broadcast.

[Structure]

Table 6-24 shows the structure of the Broadcast ID Descriptor

Table 6-24 Structure of the Broadcast ID Descriptor

Data structure broadcast_id_descriptor () { bit Identifier

}

[Meaning of each field]

The meaning of each field is defined in Section 4 of Part 1 of this document.

[Output operation rule]

This descriptor must be placed in the 2nd loop of an SIT if the data component of a program

(Component tag value: from 0x40 to 0xDF) needs to be output to a partial TS.

2-59―

ARIB TR-B15

Version 4.6-E1

Table 6-25 shows the output operation rules for each field of this descriptor.

Table 6-25 Output operation rules for the Broadcast ID Descriptor descriptor_tag

Output operation rule for each field

The value "0x85" should be assigned to this field. original_network_id The service that needs to be output to a partial TS belongs to a network. The ID of this network should be assigned to this field. transport_stream_id The service that needs to be output to a partial TS belongs to a transport stream. The

ID of this transport stream should be assigned to this field. event_id The ID of the event that needs to be output to a partial TS should be assigned to this field. broadcaster_id The service that needs to be output to a partial TS belongs to a broadcaster. The ID of this broadcaster should be assigned to this field.

[Remarks]

A multimedia data service may use "original_network_id", "transport_stream_id", "service_id", and

"event_id" in the following way to identify data-transmission modules and video/audio components arib://<original_network_id>.<transport_stream_id>.<service_id>

[;<event_id>]/component_tag

A multimedia data service may have a function for reserving a space in the receiver's NVRAM, so that the information regarding the program's broadcasting company can be saved to or loaded from this memory space. To implement this function, the multimedia data service uses "broadcaster_id" to identify the broadcasting company

The above functions of a multimedia data service must be normally operable when a user replays the data component from a partial TS, just as they are operable when the original program was received by a receiver. As such, the above-mentioned IDs should be obtainable from the partial PS. The

"service_id" can be obtained from one of the fields of the SIT. Therefore, all of the above mentioned

IDs except for this ID should be included in the Broadcast ID Descriptor.

2-60―

ARIB TR-B15

Version 4.6-E1

7.1 Sample processing for determining whether a partial TS can be recorded to a D-VHS

If a user wants to record a digital satellite broadcasting program to a D-VHS, which uses a fixed recording rate, the user should be able to know whether the program can be recorded to the desired media (a tape). The user also should be able to select the recording mode to extend the recording time and know how much is the remaining recordable time. There are several ways to determine whether the program can be recorded to a

D-VHS. One widely used technique is to obtain a value from the maximum bit rate ("maximum_bit_rate" field) in the digital copy control descriptor. This subsection introduces an example usage of the maximum bit rate.

1) Definition of the maximum bit rate

The maximum bit rate is the average of the transmission rates within one-sixtieth of one second.

2) The default value for the maximum bit rate

The maximum bit rate is specified in the "maximum_bit_rate" field of the digital copy control descriptor, and this descriptor can be placed in the PMT, SDT, and EIT. If the bit rate of each component of a program does not exceed the bit rate described in "5.2.6. Default maximum bit rates" in

Section 7 of Part 1 of this document, the digital copy control descriptor does not need to be placed in either the PMT, SDT, or EIT. If this descriptor is not inserted to any tables, the default maximum bit rate described in "5.2.6. Default maximum bit rates" must be used for each component of a program.

A digital satellite receiver obtains the maximum bit rate of each component, calculates the sum of all maximum bit rates related to the recording-target components, and determines which recording mode should be used for a D-VHS.

Once the recording mode is determined, the receiver can use the IEEE1394 commands to control the recording modes. The following is an example:

Reference: Example recording modes for a D-VHS

The following 6 recording modes are available to a D-VHS, and have different main data input rates (all recordable data are recorded). Instead of recording all programs in the HS mode, the receiver can automatically change the recording mode according to the characteristic of each program. For example, a program that uses both 1080i and normal stereo audio may be recorded in the HS mode, and a program that uses both 480i and normal stereo audio may be recorded in the STD mode.

Automatic change in the recording mode enables a user to efficiently use the D-VHS, so that the recording time is maximized.

HS mode

STD mode

28.2Mbps

14.1Mbps

LS2 mode

LS3 mode

7.0Mbps

4.7Mbps

2-61―

ARIB TR-B15

Version 4.6-E1

LS5 mode 2.8Mbps

LS7 mode 2.0Mbps

The above bit rates indicate the total bit rates that can be recorded to a recording tape. When an MPEG2 transport stream is to be recorded to a D-VHS, a header will be added. Therefore, the actual recordable bit rate for an MPEG2 transport stream is approximately 70 to 80% of the above value for each mode. For example, in the STD mode, the actual recordable bit rate for an MPEG2 transport stream is approximately 12

Mbps.

7.2 Copy Generation Management System - Analog (CGMS-A)

When a digital satellite broadcasting receiver transmits analog signals, the signals must be protected from copying with CGMS-A.

CGMS-A for 480i (525i) is defined in "JEITA(EIAJ) CPR-1204", and copyright-related information is specified in IEC 61880. CGMS-A for 480p (525p) is defined in "JEITA(EIAJ) CPR-1204-1", and copyright-related information is specified in IEC61880. CGMS-A for 720p (750p) and 1080i (1125i) is defined in "JEITA(EIAJ) CPR-1204-2", and copyright-related information is specified in IEC61880.

The definition of CGMS-A and recording method to a recording media are as follows:

CGMS-A Definition

0 , 0 The signals can be copied without CGMS on the recording media needs to remain "0 , 0"

0 , 1

1 , 0 restrictions

Undefined

Only the first generation can be copied when the signals are recorded.

CGMS on the recording media needs to be changed to "1 ,

1" when the signals are recorded.

1 , 1 The signals cannot be copied. The signals must not be recorded.

The copy generation management information should be transmitted through one line of a vertical blanking interval in the brightness signals. A reference signal (70% of the peak level of white) and 20-bit digital signal

(wave width 70% or 0%) should be placed to the valid video portion of this one line. This 20-bit digital signal should be used to carry the copy generation management information and other video-related information.

7.2.2.1 480i composite analog output

CGMS-A transmission in 480i composite analog signals must follow the specifications for the identification signal waveform that is described in the following document.

JEITA(EIAJ) CPR-1204 "Video ID signal transmission using VBI (525 line system)"

2-62―

ARIB TR-B15

Version 4.6-E1

7.2.2.2 480i component analog output

Multi lines CGMS-A should be inserted on the 20 th

line and 283 rd

line of a vertical blanking

Multi levels interval in the brightness signals.

Logic 1: 70

±10% of the peak level of white

Logic 0: +10% or -5% of the current black level

Clock frequency fsc/8=(455/16)fH=447kHz fH meaning the horizontal scan frequency

Figure 7-6 shows the transmission signal waveform. Errors in the time between the appearance of a reference signal to the subsequent bits should be less than 0.44

μs.

+700mV

70%

Ref bit1 bit2 bit3 bit20

Logic 70±10% of the peak level of white

0mV

-300mV

Logic

0: 0% +10% -5%

50%

11.2μs±0.3μs

T±50ns

22T

(49.1μs±0.44μs)

T=1/(f sc/8)=2.235μs

Figure 7-6 Identification signal waveform for a 480i component transmission

CGMS-A transmission in 480p component analog signals must follow the specifications for the identification signal waveform that is described in the following document.

JEITA(EIAJ) CPR-1204-1 "Video ID signal transmission using VBI (525p system)"

CGMS-A transmission in 720p component analog signals must follow the specifications for the identification signal waveform that is described in the following document.

JEITA(EIAJ) CPR-1204-2 "Video ID signal transmission using VBI (750p, 1125i system)"

CGMS-A transmission in 1080i component analog signals must follow the specifications for the identification signal waveform that is described in the following document.

JEITA(EIAJ) CPR-1204-2 "Video ID signal transmission using VBI (750p, 1125i system)"

2-63―

ARIB TR-B15

Version 4.6-E1

7.2.3 Allocation of an identification signal

An identification signal consists of 20 bits of information. This 20-bit data is divided into WORD0, WORD1,

WORD2, and CRCC. Each division reserves 2 bits, 4 bits, 8 bits, and 6bits, respectively.

See the following diagram for more detail. The value "0" (unused) should be assigned to a bit for which no information is specified.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Bit

Data

WORD 0 WORD 1 WORD 2 CRCC

2 bits 4 bits 8 bits 6 bits

1) WORD0 Information about the aspect ratio

WORD 0 bit1 bit2

0

0

1

0

1

0

The aspect ratio is 4:3

Description

The aspect ratio is 4:3. The signal is a letterbox signal.

The aspect ratio is 16:9

2) WORD 1 The header that describes the information stored in WORD2

WORD 1 Description of the information stored in WORD2 bit3 bit4 bit5 bit6

1 1 1

Other combinations

1 No information is stored in WORD2

Undefined

3) WORD2 (bit 7,8,9, and 10)

If WORD1 (bit 3 to 6) is "0000", the CGMS-A information should be stored in bit 7 and 8 of WORD2.

The Analog Protection System value should be stored in bit 9 and 10 of WORD2. b7 b8

0 0

0 1

1 0

1 1

CGMS-A

0 , 0

0 , 1

1 , 0

1 , 1

B9 b10 Analog Protection System value

0 0 The signal can be copied without restriction

0 1 Insertion of false synchronization pulses

1 0 Insertion of false synchronization pulses, and addition of 2-line color stripes

1 1 Insertion of false synchronization pulses, and addition of 4-line color stripes

2-64―

ARIB TR-B15

Version 4.6-E1

4) WORD2 (bit 11 to 14)

These bits are undefined. The logical value "0" should be assigned to these bits.

5) CRCC (bit 15 to 20)

A CRC (Cyclic Redundancy Check) is an error-directing code.

Polynomial G(x): G(x)=X

6

+X+1

The value "1" is preset for every bit in the following figure.

The first 14 bits of the data should be input while SW1 is closed and SW2 is connected to "a".

The remaining bits after the bit 15 (CRCC code) should be output while SW1 is opened and SW2 is connected to "b".

D D D D D

SW1

Figure 7-9 CRCC

D b SW2 a

7.3 Assurance of the uniqueness of a broadcasting program and its contents

A receiver should fulfill the following requirements in order to assure the uniqueness of a broadcasting program and its overall contents. A receiver should also fulfill the following requirements if the receiver has an accumulation function, or the receiver has a function for controlling an external recorder.

A receiver must not use the program signals or descriptors and data included in the signals to automatically cut or skip program notification or advertisement. This type of function must not be implemented to the accumulation function and automatic control function for an external recorder, either.

This function does not include skipping and a pause performed by a user.

A receiver must not intentionally insert totally unrelated program contents to the program or program contents that are being output to the screen. For example, if a receiver displays totally unrelated program contents, notifications, or advertisements with the currently displayed program, a viewer may become confused and think that the unrelated program contents are actually a part of the displayed program.

Note, however, that this type of function does not include multiple contents display that can be performed by a user. For example, two screens display and small screen display are not intended to confuse a viewer, and therefore can be implemented as a part of receiver's functions.

2-65―

ARIB TR-B15

Version 4.6-E1

8 ANNEX

A BS digital receiver shall use the PCP (Protected Content Packet), which is described in "DTCP Volume 1

Supplement E (DTCP V1SE)", instead of the packet format described in "9.2.2.2 Packet format" in Chapter 9 of "ARIB STD-B21" when it performs output with partial TS.

One PCP should contain enough amounts of data so that if a receiver receives the program contents of one

PCP, the program duration is between 0.3 second and 2 seconds. However, this rule does not apply to the

PCP that is sent right before Nc update, and the PCP that is attached to the last portion of an HTTP response.

If the duration of the entire program content is less than 0.3 second, this entire program content should be included in a single PCP. If the duration of the program content contained in an HTTP response, which is used when a receiver accesses the content to specify the range, is less than 0.3 second, the program content contained in the HTTP response should be included in a single PCP.

8.1.2 Operation of partial TS output

When a partial TS needs to be output through an IP interface, the output operation must follow the specifications described in "6.1 Output operation specifications" and "6.2 Table operation specifications" in this document. However, if program content needs to be transmitted through HTTP, no DITs should be inserted to the program at the points where the HTTP response is started and terminated. For example, when a receiver accesses the program content to specify the range, the subsequent HTTP response may become discontinuous from the previous HTTP response. In this case, a new DIT should not be inserted.

8.1.3 Operation rules for tuner description

A BS digital receiver must insert the tuner container and channel item to the data transmitted through an IP interface, following the rules specified in "9.2.3. Tuner description specifications" in "ARIB STD-B21 9.2.3".

For details on this operation, see relevant sections in "DLA Networked Device Interoperability Guidelines"

(the DLNA guidelines). The following sections describe the operation rules for the properties of the turner container and channel item in a digital satellite receiver.

8.1.3.1 General operation rule for tuner description

The properties of a turner container and channel item must not be used with no values or only blank characters inserted if the properties belong to the following name space, which is defined in "9.2.3 Tuner description specifications" in "ARIB STD-B21". xmlns:arib="urn:schemas-arib-or-jp:elements-1-0/"

The properties that do not belong to the above name space must follow the rules specified by the DLNA guidelines.

2-66―

ARIB TR-B15

Version 4.6-E1

8.1.3.2 Operation rules for the tuner container and channel item

Table 8-1 shows the operation rules for the properties of a tuner container. A BS digital receiver must implement the properties with the implementation level ~ (Required), as described in Table 8-1, as well as the requirements specified in DLAN guidelines. property name dc:title arib:objectType

Table 8-1 Operation rules for the properties of a tuner container

Implementation level property type property description

~

~ string string

This property contains the name of the broadcasting system. A digital satellite receiver should assign "Digital Satellite Broadcasting" to this field using full-width characters.

This property indicates whether the tuner container is in accordance with "9.2 IP interface specifications" of "ARIB STD-B21" and "8.1

Operation specifications of an IP interface" in this document. A digital satellite receiver should assign

"ARIB_BS" to this filed, using half-width characters.

~: Required {: Optional

The properties of "dc:" are defined by Dublin Core Metadata Initiative.

Table 8-2 shows the operation rules for the properties of a channel item. A BS digital receiver must implement the properties with the implementation level ~ (Required), as described in the Table 8-2, as well as the requirements specified in DLNA guidelines. A receiver must also follow the descriptions in Table 8-2 if the receiver needs to implement the properties with the implementation level { (Optional). arib:objectType dc:title

Table 8-2 Operation rules for the properties of a channel item property name

Implementation level property type property description

This property indicates whether the channel item is in accordance with "9.2 IP interface specifications" of "ARIB STD-B21" and "8.1

~ string Operation specifications of an IP interface" in this document. A digital satellite receiver should assign "ARIB_BS" to this filed, using half-width characters.

This property indicates the event name. As a general rule, the "event_name_char" contained in the first loop of the Short Event Descriptor should be inserted to this property. The Short

Event Descriptor is contained in the event loop

~ string updated as the original EIT is updated.

If the "event_name_char" is unknown, a receiver should insert the same event name assigned to "upnp:channelName", as described in the DLNA guidelines.

2-67―

ARIB TR-B15

Version 4.6-E1 upnp:genre upnp:channelName upnp:channelNr

This property indicates the genre to which the event indicated by the "dc:title" belongs. As a general rule, a converted character string that corresponds to the value of the

"content_nibble_level_1" (general category) in the Content Descriptor should be assigned to this property. The conversion must be in accordance with the general category table in

~ string "Appendix A" of Section 4. The Content

Descriptor is contained the event loop of the

EIT. Multiple genres can be assigned to

"upnp:genre". If the "content_nibble_level_1" is either "0xC", "0xD", or "0xE", the character string "Undefined" should be assigned to this property. If the "content_nibble_level_1" is unknown, the character string "Unknown" should be assigned to this property.

This property indicates the service name

(member channel name). As a general rule, the

"char" contained in the second loop of the

Service Descriptor should be assigned to this

~ string in the service loop of the SDT.

If the "char" is unknown, the previously set member channel name should be assigned to this property.

This property indicates the channel number.

The channel number can be defined by the following formula: upnp:channelNr = "One-touch channel selection number"

×10000+"3-digit number"

×10

[One-touch channel selection number]

The value assigned for a service (member channel) in the receiver should be used for this number. If no one-touch channel selection number is assigned to the service, the value

~ integer

[3-digit number]

As a general rule, the "service_id" of the

Service List Descriptor should be used for this number. The Service List Descriptor is contained in the second loop (TS loop) of the

NIT. For example, if the "service_id" is

"101"(0x0065), the 3-digit number should be

"101".

If no information can be obtained from the

NIT, the previously set 3-digit number should be used.

2-68―

upnp: scheduledStartTime upnp: scheduledEndTime dc:description

ARIB TR-B15

Version 4.6-E1

This property indicates the start time of an event. As a general rule, the converted form of the "start_time" that represents the start time of the event should be assigned to this property. The "start_time" must be converted from the format "MJD+BCD" to the following format specified in the DLNA guidelines. The latter format is the same format for the

"dc:date". The "start_time" is contained in the event loop of the EIT.

If the TOT does not exist, the following format

{ string should be applied:

CCYY-MM-DDTHH:MM:SS

If the summer time offset value is set in the

TOT due to the introduction of summer time, the time offset (

±HH:MM) should be attached to the above format, as shown below.

CCYY-MM-DDTHH:MM:SS+09:00

→ Non-summer time

CCYY-MM-DDTHH:MM:SS+10:00

→ Summer time (1 hour)

If the "start_time" has not been specified, this property should not be implemented.

This property indicates the end time of an event. As a general rule, the converted end time should be assigned to this property. The end time must be calculated from the

"start_time" and "duration", which represents the duration of the event, that are contained in the event loop of the EIT. Then the end time must be converted from the "BCD" format to the following format specified in the DLNA guidelines. The latter format is the same format for the "dc:date".

If the TOT does not exist, the following format

CCYY-MM-DDTHH:MM:SS

If the summer time offset value is set in the

TOT due to the introduction of summer time, the time offset (

±HH:MM) should be attached to the above format, as shown below.

CCYY-MM-DDTHH:MM:SS+09:00

→Non-summer time

CCYY-MM-DDTHH:MM:SS+10:00

→Summer time (1 hour)

If the "start_time" or "duration" has not be specified, and the end time cannot be calculated, the "upnp:scheduledEndTime" property should not be implemented.

This property represents a program description. As a general rule, the "text_char" contained in the second loop of the Short

Event Descriptor that is contained in the event loop of EIT should be assigned to this field.

2-69―

ARIB TR-B15

Version 4.6-E1 arib: longDescription [email protected] upnp:rating upnp:icon upnp: [email protected]:resolution

This property represents the detailed description of an event. As a general rule, information about the item name should be obtained from the "item_description_char" field of the Extended Event Descriptor contained in the event loop of the EIT.

Information about the event description should be obtained from the "item_char" filed of the same descriptor. Multiple instances of this property can be set for a channel item, and each property instance must correspond to each Extended Event Descriptor. The order of

{ string these property instances must be in accordance with the "descriptor_number", and the ascending order is preferred. If multiple item descriptions are assigned to one item name, these item descriptions need to be combined together to form a single

"arib:longDescription". The item name should be written on the first 24 bytes of this property, and the item description should be written on the remaining bytes after the 24 th

byte. If the length of the item name is less than 24 bytes, the space characters should be inserted to the remaining bytes until the 24 th

byte.

This property represents the resolution of the output contents. The resolution must consist of both the number of horizontal pixels and the

{ pattern string number of vertical pixels. The entry must be made with half-width characters, and the format is shown below.

(The number of horizontal pixels)x(The number of vertical pixels)

Example)1920x1080

This property represents the parental rating. As a general rule, a converted form of the "rating" field of the Parental Rate Descriptor should be assigned to this property. The "rating" must be

{ string example, if the value of rating is "10", "0x10" should be inserted. This property only shows how high the parental rate is, and is not necessarily used for other purposes.

{ URI

{ pattern string of the service (member channel).

This property represents the size of the logo of the service (member channel).

The format for this property must be the same for the "[email protected]" property. The size of a logo must be one of the size patterns shown in "Table 4-1 Size patterns of transmitted logos" in "4 (3) Logo data update" in Part 1 of this document. The number of horizontal dots and vertical dots must also be taken from the table mentioned above.

(The number of horizontal dots) x(The number of vertical dots)

Example)64x36

2-70―

arib: videoComponentType arib: audioComponentType arib: audioComponentType

@qualityIndicator arib: copyControlInfo

{

{

{

{

ARIB TR-B15

Version 4.6-E1 unsigned integer unsigned integer unsigned integer

CSV string

This property represents the type of the video component. As a general rule, a converted form of the "component_type" value of the

Component Descriptor contained in the EIT should be assigned to this property. The

"component_type" must be converted to a decimal number.

If one "service_id" contains multiple video

ESs, multiple instances of this property can be set for a channel item. The property instance that corresponds to the default ES must be placed first.

This property represents the type of the audio component. As a general rule, a converted form of the "component_type" value of the Audio

Component Descriptor contained in the EIT should be assigned to this property. The

"component_type" must be converted to a decimal number.

If one "service_id" contains multiple audio

ESs, multiple instances of this property can be set for a channel item. The property instance that corresponds to the default ES must be placed first.

This property represents the quality mode of the audio component. As a general rule, a converted form of the "quality_indicator" value of the Audio Component Descriptor contained in the EIT should be assigned to this property. The "quality_indicator" must be converted to a decimal number.

This property represents information about recording control and output control of a program. As a general rule, 4 different sets of information should be combined and assigned to this property: The "encryption_mode" of the

Content Descriptor, the

"digital_recording_control_data",

"APS_control_data" of the Digital Copy Control

Descriptor, and the bit that indicates whether output is possible. Each set of information must be delimited by commas, and should be represented as a character string.

The bit that indicates whether output is possible should be either "1" or "0". The value

"1" indicates that output is prohibited, and the value "0" indicates that output is permitted.

This property only shows how much copy control has been set, and is not necessarily used for other purposes.

2-71―

ARIB TR-B15

Version 4.6-E1 arib: dataProgramInfo arib: [email protected] arib: multiViewInfo arib: captionInfo

Arib: multiESInfo arib: caProgramInfo

This property indicates whether any data contents exist in a program. As a general rule, the value "1" should be assigned to this property if both of the following conditions are met:

- The "data_component_id" of the Data

Contents Descriptor is "0007".

{ boolean - The "component_tag" of the subtitle ES (a value from 0x40 to 0x7F) is assigned to the

"entery_component" of the Data Contents

Descriptor.

If the existence of data contents is confirmed by other methods, the value "1" should be assigned. Otherwise, the value "0" should be assigned.

This property indicates whether the data contents synchronize with the program. As a general rule, if the value "1" is assigned to

"associated_contents_flag" in the selector area of the Data Contents Descriptor, the value "1" should be assigned to this property. Otherwise, the value "0" should be assigned.

This property indicates whether Multi View

TV (MVTV) is being used. As a general rule, if the "component_group_type" of the

{ boolean Component Group Descriptor in the EIT is

"000", the value "1" should be assigned to this property. Otherwise, the value "0" should be assigned to this property.

This property indicates whether subtitles or captions are being used. As a general rule, the value "1" should be assigned to this property if the "data_component_id" is "0008", or a subtitle ES exists within a program.

{ boolean one "service_id" contains multiple subtitle

ESs, multiple instances of this property can be set for a channel item. The property instance that corresponds to the default ES must be placed first.

This property indicates whether multiple video

ESs or audio ESs are present in a program. As a general rule, if multiple Component are placed in the EIT, the value "1" should be assigned to this property. If only one descriptor is placed in the EIT, the value "0" should be assigned.

This property indicates whether the program is free or requires fees. As a general rule, if the

"free_CA_mode" of the EIT is "1", the should be assigned to this property. If the

"free_CA_mode" is "0", the program is free, and the value "0" should be assigned to this property.

2-72―

ARIB TR-B15

Version 4.6-E1 arib: caProgramInfo

@available

This property indicates whether the viewer has subscribed to the program.

If the "arib:caProgramInfo" is "1" (meaning

"fee-requiring program"), this property indicates whether the viewer has subscribed to

{ boolean

If the "arib:caProgramInfo" is "0" (meaning

"free program"), this attribute does not exist. If the viewer has subscribed to the default ESs, the value "1" should be assigned to this property.

~: Required {: Optional

The properties of "upnp:" are defined by "UPnP Forum".

2-73―

ARIB TR-B15

Version 4.6-E1

8.1.3.3 Properties that should be assigned to the accumulated contents

If a receiver has the accumulation function, and outputs the accumulated contents through an IP interface in accordance with "8.1 Operation specifications for an IP interface", the accumulated contents should have the properties described in Table 8-3. A BS digital receiver must implement the properties with the implementation level ~ (Required), as described in Table 8-3, as well as the requirements specidied in

DLNA guidelines. A receiver must also follow the descriptions in Table 8-3 if the receiver needs to implement the properties with the implementation level { (Optional).

Table 8-3 Properties that should be assigned to the accumulated contents property name arib:objectType

Implementation level property type property description

This property indicates whether the properties of the accumulated contents are in accordance with the specifications

~ string described in "8.1 Operation specifications for an IP interface". A digital satellite receiver should assign "ARIB_BS" to this property, using half-width characters.

This property represents the event name. As a general rule, the "event_name_char" contained in the first loop of the Short

Event Descriptor should be assigned to dc:title contained in the event loop of the EIT.

If the "event_name_char" is unknown, a receiver should insert the same event name assigned to "upnp:channelName", as described in the DLNA guidelines.

This property indicates the genre to which the event indicated by the "dc:title" belongs.

As a general rule, a converted character string that corresponds to the value of the

"content_nibble_level_1" (general category) in the Content Descriptor should be assigned to this property. The conversion must be in accordance with the general upnp:genre upnp:channelName

4. The Content Descriptor is contained the event loop of the EIT. Multiple genres can be assigned to "upnp:genre". If the

"content_nibble_level_1" is either "0xC",

"0xD", or "0xE", the character string

"Undefined" should be assigned to this property. If the "content_nibble_level_1" is unknown, the character string "Unknown" should be assigned to this property.

This property indicates the service name

(member channel name). As a general rule, the "char" contained in the second loop of the Service Descriptor should be assigned

~ string contained in the service loop of the SDT.

If the "char" is unknown, the previously set member channel name should be assigned to this property.

2-74―

upnp:channelNr dc:date [email protected] upnp:scheduledStartTime

ARIB TR-B15

Version 4.6-E1

This property indicates the channel number. The channel number can be defined by the following formula: upnp:channelNr = "One-touch channel selection number"

×10000+"3-digit number"

×10

[One-touch channel selection number]

The value assigned for a service (member channel) in the receiver should be used for this number. If no one-touch channel selection number is assigned to the this number.

[3-digit number]

As a general rule, the "service_id" of the

Service List Descriptor should be used for this number. The Service List Descriptor is contained in the second loop (TS loop) of the NIT. For example, if the "service_id" is "101"(0x0065), the 3-digit number should be "101".

If no information can be obtained from the

NIT, the previously set 3-digit number should be used.

This property represents the time when a receiver started to accumulate the contents. The format for this property must be the same for the channel item. For example, if a receiver started to accumulate the program contents at 7 am on Jun. 17, 2005, the formatted value for this property should be

"2005-06-17T07:00:00".

~*1 string accumulation for the contents.

This property indicates the start time of an event. As a general rule, the converted form of the "start_time" that represents the start time of the event should be assigned to this property. The "start_time" must be converted from the format "MJD+BCD" to the following format specified in the

DLNA guidelines. The latter format is the same format for "dc:date". The

{ string

"start_time" is contained in the event loop of the EIT.

If the TOT does not exist, the following format should be applied:

CCYY-MM-DDTHH:MM:SS

If the summer time offset value is set in the TOT due to the introduction of summer time, the time offset (

±HH:MM) should be attached to the above format, as shown below.

CCYY-MM-DDTHH:MM:SS+09:00

-> Non-summer time

CCYY-MM-DDTHH:MM:SS+10:00

-> Summer time (1 hour)

If the "start_time" has not been specified, this property should not be implemented.

2-75―

ARIB TR-B15

Version 4.6-E1 upnp:scheduledEndTime dc:description arib:longDescription

{ string

This property indicates the end time of an event. As a general rule, the converted end time should be assigned to this property.

The end time must be calculated from the

"start_time" and "duration", which represents the duration of the event, that are contained in the event loop of the EIT.

Then the end time must be converted from the "BCD" format to the following format specified in the DLNA guidelines. The latter format is the same format for the

"dc:date".

If the TOT does not exist, the following format should be applied:

CCYY-MM-DDTHH:MM:SS

If the summer time offset value is set in the TOT due to the introduction of summer time, the time offset (

±HH:MM) should be attached to the above format, as shown below.

CCYY-MM-DDTHH:MM:SS+09:00

→ Non-summer time

CCYY-MM-DDTHH:MM:SS+10:00

→ Summer time (1 hour)

If the "start_time" or "duration" has not be specified, and the end time cannot be calculated, the "upnp:scheduledEndTime" property should not be implemented.

This property represents a program description. As a general rule, the of the Short Event Descriptor that is contained in the event loop of EIT should be assigned to this field.

This property represents the detailed description of an event. As a general rule, information about the item name should be obtained from the

"item_description_char" field of the

Extended Event Descriptor contained in the event loop of the EIT. Information about the event description should be obtained from the "item_char" filed of the same descriptor. Multiple instances of this property can be set in the accumulated contents, and each property instance must correspond to each Extended Event instances must be in accordance with the

"description_number", and the ascending order is preferred. If multiple item descriptions are assigned to one item name, these item descriptions need to be combined together to form a single

"arib:longDescription". The item name should be written on the first 24 bytes of this property, and the item description should be written on the remaining bytes th

byte. If the length of the item after the 24 name is less than 24 bytes, the space characters should be inserted to the remaining bytes until the 24 th

byte.

2-76―

[email protected] upnp:rating upnp:icon upnp:[email protected]:resolution arib:videoComponentType arib:audioComponentType arib:audioComponentType

@qualityIndicator

ARIB TR-B15

Version 4.6-E1

{ pattern string

This property represents the resolution of the output contents. The resolution must consist of both the number of horizontal pixels and the number of vertical pixels.

The entry must be made with half-width characters, and the format is shown below.

(The number of horizontal pixels)x(The number of vertical pixels)

Example)1920x1080

This property represents the parental rating. As a general rule, a converted form of the "rating" field of the Parental Rate

Descriptor should be assigned to this property. The "rating" must be converted

{ string example, if the value of rating is "10",

"0X10" should be inserted. This property only shows how high the parental rate is, and is not necessarily used for other purposes.

{

{

{

{ pattern string unsigned integer unsigned integer unsigned integer

This property represents the size of the logo of the service (member channel).

The format for this property must be the same for the "[email protected]" property.

(The number of horizontal dots) x(The number of vertical dots)

Example)64x36

This property represents the type of the video component. As a general rule, a converted form of the "component_type" value of the Component Descriptor contained in the EIT should be assigned to this property. The "component_type" must be converted to a decimal number.

If one "service_id" contains multiple video

ESs, multiple instances of this property can be set for the accumulated contents.

The property instance that corresponds to the default ES must be placed first.

This property represents the type of the audio component. As a general rule, a converted form of the "component_type" value of the Audio Component Descriptor contained in the EIT should be assigned to this property. The "component_type" must be converted to a decimal number.

If one "service_id" contains multiple audio

ESs, multiple instances of this property can be set for the accumulated contents.

The property instance that corresponds to the default ES must be placed first.

This property represents the quality mode of the audio component. As a general rule, a converted form of the

"quality_indicator" value of the Audio

Component Descriptor contained in the

EIT should be assigned to this property.

The "quality_indicator" must be converted to a decimal number.

2-77―

ARIB TR-B15

Version 4.6-E1 arib:copyControlInfo arib:dataProgramInfo arib:[email protected] arib:multiViewInfo

This property represents information about recording control and output control of a program. As a general rule, 5 different sets of information should be combined and assigned to this property: The

"encryption_mode" of the Content

Descriptor, the

"digital_recording_control_data",

"APS_control_data" of the Digital Copy

Control Descriptor, the bit that indicates whether output is possible, and the bit that indicates whether the control mode is

"copy_no_more". Each set of information must be delimited by commas, and should be represented as a character string.

The bit that indicates whether output is possible should be either "1" or "0". The value "1" indicates that output is prohibited, and the value "0" indicates that output is permitted.

The bit that indicates the control mode is

"copy_no_more" should be either "1" or

"0". The value "1" indicates that the control mode is "copy_no_more", and the value "0" indicates that the control mode is not "copy_no_more".

This property only shows how much copy control has been set, and is not necessarily used for other purposes.

This property indicates whether any data contents exist in a program. As a general rule, the value "1" should be assigned to this property if both of the following conditions are met:

- The "data_component_id" of the Data

Contents Descriptor is "0007".

{ boolean - The "component_tag" of the subtitle ES

(a value from 0x40 to 0x7F) is assigned to the "entery_component" of the Data

Contents Descriptor.

If the existence of data contents is confirmed by other methods, the value "1" should be assigned. Otherwise, the value

"0" should be assigned.

This property indicates whether the data contents synchronize with the program. As a general rule, if the value "1" is assigned to both the "arib:dataProgramInfo" and

{ boolean "associated_contents_flag" in the selector area of the Data Contents Descriptor, the value "1" should be assigned to this property. Otherwise, the value "0" should be assigned.

This property indicates whether Multi

View TV (MVTV) is being used. As a general rule, if the

Component Group Descriptor in the EIT is

"000", the value "1" should be assigned to this property. Otherwise, the value "0" should be assigned to this property.

2-78―

ARIB TR-B15

Version 4.6-E1

This property indicates whether subtitles or captions are being used. As a general rule, the value "1" should be assigned to this property if the "data_component_id" is "0008", or a subtitle ES exists within a arib:captionInfo arib:multiESInfo be assigned. If one "service_id" contains multiple subtitle ESs, multiple instances of this property can be set for the accumulated contents. The property instance that corresponds to the default ES must be placed first.

This property indicates whether multiple video ESs or audio ESs are present in a program. As a general rule, if multiple

Component Descriptors or Audio

{ boolean

EIT, the value "1" should be assigned to this property. If only one descriptor is placed in the EIT, the value "0" should be assigned.

This property indicates whether the program is free or requires fees. As a general rule, if the "free_CA_mode" of the arib:caProgramInfo arib:[email protected] able the value "1" should be assigned to this property. If the "free_CA_mode" is "0", the program is free, and the value "0" should be assigned to this property.

This property indicates whether the viewer has subscribed to the program .If the

"arib:caProgramInfo" is "1" (meaning

"fee-requiring program"), this property indicates whether the viewer has

{ boolean

If the "arib:caProgramInfo" is "0"

(meaning "free program"), this attribute does not exist. If the viewer has subscribed to the default ESs, the value "1" should be assigned to this property.

~: Required {: Optional

*1 If the duration is unknown because the accumulation is being performed, or the item does not have the "res" property, this attribute does not need to be implemented.

and

If a digital satellite receiver needs to output a stream from its DMS (Digital Media Server) through HTTP, the receiver must specify the content selection by using "protocolInfo" and recommended MIME-Types.

"protocolInfo" is defined in the "Media Management" section of the DLNA guidelines, and the recommended

MIME-Types are described in "DTCP V1SE". The content selection must be specified as follows:

"protocolInfo" consists of the following 4 fields:

<protocol>':'<network>':'<contentFormat>':'<additionalInfo>

First field <protocol>: The protocol through which the content is output

Second field <network>: The entry to this field depends on the output protocol. If the ouput protocol

2-79―

ARIB TR-B15

Version 4.6-E1 is HTTP, an asterisk ("*") should be assinged for this field.

Third field <contentFormat>: The entry to this field depends on the output protocol. If the output protocol is HTTP, the format of the content should be assigned to this field.

Fourth field <additionalInfo>: Additional information is assigned here.

For example, if the stream output protocol is HTTP, and a TS-formatted MPEG content with a time stamp, which is in accordance with "8.1.1 Packet format", needs to be transmitted under protection of DTCP-TP, it is represented using the following "protocolInfo". http-get:*:application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTFORMAT="vid eo/vnd.dlna.mpeg-tts": DLNA.ORG_PN=DTCP_MPEG_TS_JP_T;DLNA.ORG_

FLAGS=01110000000000000000000000000000;ARIB.OR.JP_PN=MPEG_TTS_CP

The following values need to be inserted to each field of "protocolInfo". The rules for "protocolInfo" are defined in the "Media Management" section of the DLNA guidelines.

First field: "http-get" should be inserted. This entry represents the output protocol HTTP.

Second field: An asterisk ("*") should be inserted to this field.

Third field: An MIME-Type should be inserted. The details are described later.

Fourth field: See "ARIB.OR.JP_PN=MPEG_TTS_CP".

In the case of output using partial TS, both ARIB.OR.JP_PN and DLNA.ORG_PN can be described. Here, when describing the stream format protected by DTCP-IP in DLNA.ORG_PN, the format specified in

Volume 3: Link Protection Guideline of DLNA guidelines must be used. In addition, other parameters such as the ones defined by the DLNA guidelines and the ones defined by receiver manufacturers can be inserted to the fourth field. If multiple parameters need to be inserted, the insertion rule defined by the DLNA guidelines must be followed.

For the third field, the MIME type that is recommended by "DTCP V1SE" should be assigned to the

MIME-Type section of content transmitted under protection of DTCP-IP. The MIME type that supports a

TS-formatted stream with a time stamp should be assigned to the CONTENTFORMAT section. The latter

MIME type is defined in the "MPEG-2 MIME-Type Definition" section of the DLNA guidelines. The third field may be written as follows: application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTFORMAT=

"video/vnd.dlna.mpeg-tts"

In the above example,

(host) represents the address of the host that performs AKE (Authentication Key Exchange).

(port) represents the port of the host that performs AKE.

2-80―

ARIB TR-B15

Version 4.6-E1

"DTCP1HOST=(host)" and "DTCP1PORT=(port)" can be omitted from the third field. However, if the

DTCP-IP protection is necessary for the entire content or a part of the content, these two entries must be inserted.

The MIME type of the content that is transmitted as the payload of a PCP should be assigned to the

"CONTENTFORMAT" section of the third field. If a TS-formatted stream with a time stamp needs to be transmitted, "video/vnd.dlna-mpeg-tts" should be assigned to the "CONTENTFORMAT" section. The above type of stream is defined in "8.1.4 Transmission of MPEG video / audio in a time-stamped TS format" in Vol.

2 of "ARIB STD-B24". If "protocolInfo" is used for the "Out" parameter of CMS:GetprotocolInfo(), the third field does not need to include "DTCP1HOST=(host)" and "DTCP1PORT=(port)" because the address and port of the host that performs AKE may differ among different contents.

If "protocolInfo" is used as an attribute of the "res" ("[email protected]"), the double quotation marks enclosing "video/vnd.dlna-mpeg-tts" overlap with the ones enclosing the entire "protocolInfo". This leads to an error in XML. Therefore, the double quotation marks enclosing the entire "protocolInfo" should be replaced with single quotation marks, or the ones enclosing "video/vnd.dlna-mpeg-tts" should be replaced with "&quot;". Therefore, "[email protected]" should be described as follows: protocolInfo='http-get:*:application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTF

ORMAT="video/vnd.dlna.mpeg-tts":ARIB.OR.JP_PN=MPEG_TTS_CP' or protocolInfo="http-get:*:application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTFOR

MAT=&quot;video/vnd.dlna.mpeg-tts&quot;:ARIB.OR.JP_PN=MPEG_TTS_CP"

Below is an example for CDS (ContentDirectory service) item when partial TS is transmitted.

<item id=”ID1” restricted=”1” parented=”0”>

<dc:title>Title</dc:title>

<upnp:class>object.item.videoItem</upnp:class>

<upnp:genre>Genre</upnp:genre>

<upnp:channelName>Channnel Name</upnp:channelName>

<upnp:channelNr>10000</upnp:channelNr>

<dc:date>2008-09-18T18:00:00</dc:date>

<res protocolInfo=”http-get:*:application/x-dtcp1;DTCP1HOST=192.168.0.1;

DTCP1PORT=30000;CONTENTFORMAT=&quot;video/vnd.dlna.mpeg-tts&quot;:

DLNA.ORG_PN=DTCP_MPEG_TS_JP_T;DLNA.ORG_FLAGS=01110000000000

000000000000000000;ARIB.OR.JP_PN=MPEG_TTS_CP”>URL1</res>

<arib:objectType>ARIB_BS</arib:objectType>

</item>

In addition, below are other examples when partial TS may be transmitted under no protection of DTCP-IP

2-81―

ARIB TR-B15

Version 4.6-E1

(no encryption).

<item id=”ID1” restricted=”1” parented=”0”>

<dc:title>Title</dc:title>

<upnp:class>object.item.videoItem</upnp:class>

<upnp:genre>Genre</upnp:genre>

<upnp:channelName>Channnel Namer</upnp:channelName>

<upnp:channelNr>10000</upnp:channelNr>

<dc:date>2008-09-18T18:00:00</dc:date>

<res protocolInfo=”http-get:*:application/X-arib-cp;CONTENTFORMAT=&quot; video/vnd.dlna.mpeg-tts&quot;: ARIB.OR.JP_PN=MPEG_TTS_CP”>URL1</res>

<res protocolInfo=”http-get:*:video/vnd.dlna.mpeg-tts:DLNA.ORG_PN=

MPEG_TS_JP_T;DLNA.ORG_FLAGS=01100000000000000000000000000000”>

URL1</res>

<arib:objectType>ARIB_BS</arib:objectType>

</item>

8.1.4.2 The URL to the content that is protected by DTCP-IP

The URL to the content protected by DTCP-IP should be assigned to the "res" value of the tuner description in a digital satellite receiver. This URL does not need to use the URI format recommended by "DTCP V1SE".

8.1.4.3 The Content-Type header field of an HTTP header

When HTTP request or HTTP response is performed for a content that is protected by DTCP-IP, the

Content-Type header inserted to the HTTP header must include the address and port of the host that performs

AKE. This rule is defined in "DTCP V1SE". The MIME types that should be used for this Content-Type header are the same as the MIME types that are used in "8.1.4.1".

Therefore, in the case of output with partial TS, it is written as follows:

Content-Type:application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTFORMAT=

"video/vnd.dlna.mpeg-tts"

In addition, in the case of output with MPEG_PS, it is written as follows:

Content-Type:application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTFORMA

T=“video/mpeg“

8.1.4.4 Access to a content to specify a range

If a digital satellite receiver is designed to access a program content to specify a range through

"TimeSeekRange.dlna.org", the receiver must follow the rules specified in the DLNA guidelines.

If a receiver is designed to access a program content through "Range.dtcp.com", which is defined in "DTCP

2-82―

ARIB TR-B15

Version 4.6-E1

V1SE", the receiver must follow the following rules:

If a BS digital receiver is designed to access a specified range through "Range.dtcp.com", if there is description of ARIB.ORG_JP_PN in the fourth field of [email protected] in the content that can be supported,

"ARIB.OR.JP_OP=1" must be inserted. If the content cannot be supported, the "ARIB.OR.JP_OP" parameter should not be inserted.

If there is description of DLNA.ORG_PN, cleartextbyteseek-full or lop-cleartextbytes flag of

DLNA.ORG_FLAGS must be set according to the specifications in DLNA guidelines.

However, when both ARIB.ORG_JP_PN and DLNA.ORG_PN are described, ARIB.OR.JP_OP may not be inserted due to restrictions on [email protected]’s length.

The format of "Range.dtcp.com" is as follows:

Range.dtcp.com = "Range.dtcp.com" ":" range-specifier range-specifier = byte-range-specifier byte-range-specifier = bytes-unit "=" byte-range-set bytes-unit = "bytes" byte-range-set = byte-range-spec byte-range-spec = first-byte-pos "-" [last-byte-pos] first-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT

The "first-byte-pos" indicates the location of the first byte of the pre-encryption content, and the

"last-byte-pos" indicates the location of the last byte of the pre-encryption content.

A sample description of "Range.dtcp.com" is shown below.

Range.dtcp.com: bytes=1539686400-

Range.dtcp.com: bytes=1539686400-1541710655

If the requested range from "Range.dtcp.com" is less than the size of a TS-formatted packet with a time sample (one packet = 192 bytes), the requested range must be expanded so that it matches the size of one

192-byte packet, and a response to the request must be performed. The expansion operation should be performed as follows.

If the start position of the requested range is different from the beginning position of a

TS-formatted packet with a time stamp, the start position of the response range must be extended to the beginning position of the TS-formatted packet with a starting position of the requested time.

If the end position of the requested range is different from the end position of a

TS-formatted packet with a time stamp, the end position of the response range must be extended to the end position of the TS-formatted packet with a starting position of the requested time.

For content other than TS format with a time stamp, the response range in response to the range specifying request of Range.dtcp.com must be in accordance with Volume 3 in DLNA guidelines.

A response to a request from "Range.dtcp.com" involves the HTTP response codes. Table 8-4 shows some

2-83―

ARIB TR-B15

Version 4.6-E1 conditions pertaining to a "Range.dtcp.com"requrest, and corresponding HTTP response codes.

Table 8-4 HTTP response codes corresponding to a "Range.dtcp.com" request

When a receiver normally responds to the

"Range.dtcp.com" request:

When the requested range from "Range.dtcp.com" is invalid: (For example, the start position of the requested range exceeds the end position of the content.)

When the request from "Range.dtcp.com" is grammatically incorrect:

When the receiver does not support the

"Range.dtcp.com" request to the content:

200 (OK)

("206 (Partial Content)" should not be used.)

416 (Requested Range Not

Satisfiable)

400 (Bad Request)

406 (Not Acceptable)

When a receiver responds to a request from "Range.dtcp.com" with the response code "200 (OK)", the

"Content-Range.dtcp.com" header fields must be inserted to the HTTP response header. The

"Content-Range.dtcp.com" is described in "DTCP V1SE".

The format of the "Content-Range.dtcp.com" is as follows:

Content-Range.dtcp.com = "Content-Range.dtcp.com" ":"

• content-range-spec content-range-spec = byte-content-range-spec

• byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/"

( instance-length | "*" ) bytes-unit = "bytes" byte-range-resp-spec = first-byte-pos "-" last-byte-pos

• first-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT

• instance-length = 1*DIGIT

The "first-byte-pos" indicates the location of the first byte of the pre-encryption content, and the

"last-byte-pos" indicates the location of the last byte of the pre-encryption content.

The "instance-length" indicates the size of the entire pre-encryption content. If the entire size is too difficult to calculate, an asterisk ("*") may be used.

A sample description of "Content-Range.dtcp.com" is shown below:

Content-Range.dtcp.com: bytes

1539686400-1541710655/9238118400

When a TS-formatted content with a time stamp is accessed through "Range.dtcp.com", the requested range should match the size of the TS-formatted packet with a time stamp (one packet = 192 bytes).

2-84―

ARIB TR-B15

Version 4.6-E1

8.1.4.5 Conversion rules for the expanded characters used in tuner description

The character codes used in the tuner description in a digital satellite receiver must follow the rules specified in "9.2.3 Tuner description specifications" in "ARIB STD-B21". However, the additional 8-bit symbols defined by "7.1" of Part 2 of Vol.1 of "ARIB STD-B24" must follow the specifications shown in Table 7-19 of Part 2 of Vol. 1 of "ARIB STD-B24". (Blank sheet)

2-85―

ARIB TR-B15

Version 4.6-E1

< Intentionally blank.>

2-86―

Volume 3

BS Digital Satellite Broadcasting Operational

Guidelines for Datacasting

ARIB TR-B15

Version 4.6-E1

Contents

1 Introduction ..............................................................................................................................................3-1

1.1 BS standard level ..............................................................................................................................3-1

1.2 BS Level 2.........................................................................................................................................3-1

2 Related Documents ..................................................................................................................................3-1

3 Definition of Terms ..................................................................................................................................3-2

4 Basic Receiver Unit Functionality for Reception of Data Broadcasts.....................................................3-5

4.1 Receiver configuration......................................................................................................................3-5

4.1.1 Hardware configuration·········································································································· 3-5

4.1.2 Receiver reference model ······································································································· 3-6

4.2 Presentation functions .......................................................................................................................3-7

4.2.1 Resolution of planes in display screen and associated restrictions·········································· 3-8

4.2.2 Eligible plane combinations and associated restrictions ······················································· 3-10

4.2.3 Mono-media encoding and presentation planes ···································································· 3-13

4.2.4 Audio reproduction function ································································································ 3-19

4.2.5 Fonts····································································································································· 3-20

4.3 Remote control................................................................................................................................3-21

4.3.1 Datacasting keys··················································································································· 3-21

4.3.2 Key mask ····························································································································· 3-21

4.4 TS decoder ......................................................................................................................................3-22

4.5 Memory requirements .....................................................................................................................3-22

4.5.1 RAM ···································································································································· 3-22

4.5.2 NVRAM······························································································································· 3-23

4.6 Modem ............................................................................................................................................3-23

5 Data Transmission Specification Usage.................................................................................................3-24

5.1 SI/PSI ..............................................................................................................................................3-24

5.1.1 Types of datacasting services ······························································································· 3-24

5.1.1.1 Data programs versus television programs ......................................................................3-24

5.1.1.2 Types of datacasting service programs ............................................................................3-24

5.1.1.3 Datacasting services and other program types.................................................................3-25

5.1.1.4 service_type for datacasting program channels ...............................................................3-26

5.1.2 Content structure and components usage in datacasting services ········································· 3-26

5.1.2.1 Content versus local content ............................................................................................3-26

5.1.2.2 Local content and ES .......................................................................................................3-27

3-i―

ARIB TR-B15

Version 4.6-E1

5.1.2.3 Component tags usage .....................................................................................................3-27

5.1.2.4 Entry component identifier ..............................................................................................3-28

5.1.2.5 ES constraints ..................................................................................................................3-28

5.1.2.6 Section datacasting rules..................................................................................................3-28

5.1.2.7 Default maximum bit rate for datacasting programs .......................................................3-28

5.1.2.8 Audio and video components in datacasting services .....................................................3-29

5.1.3 Series reservation of datacasting services··············································································3-30

5.1.4 PMT specific to datacasting service usage ············································································3-30

5.1.5 PMT data encoding method descriptors usage·······································································3-30

5.1.6 PMT region descriptor usage·································································································3-32

5.1.7 p/f EIT data content descriptors usage···················································································3-32

5.1.8 schedule EIT data content descriptor usage···········································································3-35

5.1.9 p/f EIT hyperlink descriptor usage ························································································3-35

5.1.10 schedule EIT hyperlink descriptors usage ·············································································3-35

5.1.11 EIT unique to datacasting service usage················································································3-35

5.1.12 Associated receiver operations ······························································································3-35

5.1.12.1 Datacasting engine startup ...............................................................................................3-35

5.1.12.2 Receiver operation at start of datacasting program .........................................................3-36

5.1.12.3 Receiver operations at PMT update.................................................................................3-37

5.1.12.4 Data button.......................................................................................................................3-38

5.1.12.5 Resolution and aspect control of datacasting programs ..................................................3-40

5.1.12.6 Receiver operation at station selection ............................................................................3-40

5.1.12.7 Datacasting program reservation operations (Guidelines) ..............................................3-40

5.1.12.8 Partial transport stream input/output ...............................................................................3-41

5.1.12.9 Preferred EPG display format..........................................................................................3-41

5.2 Independent PES transmission specification usage ........................................................................3-42

5.3 Data carousel and event message transmission specification.........................................................3-42

5.3.1 Data carousel transmission operation ····················································································3-42

5.3.1.1 Introduction of data events and local content ..................................................................3-42

5.3.1.2 Data events usage.............................................................................................................3-42

5.3.1.3 Local content activation and termination ........................................................................3-43

5.3.1.4 Introduction of return to entry flag ..................................................................................3-43

5.3.1.5 Local content and data content descriptors......................................................................3-43

5.3.1.6 Empty carousels usage.....................................................................................................3-45

5.3.1.7 Basic receiver operations during datacasting program display .......................................3-45

3-ii―

ARIB TR-B15

Version 4.6-E1

5.3.2 DownloadInfoIndication (DII) message usage ····································································· 3-46

5.3.3 DownloadDataBlock (DDB) message usage ········································································ 3-48

5.3.4 Event messages usage ·········································································································· 3-49

5.3.4.1 Purpose of event messages...............................................................................................3-49

5.3.4.2 Transmission of event messages ......................................................................................3-49

5.3.4.3 Transmission of general-purpose event messages ...........................................................3-49

5.3.4.4 Transmission of NPT reference messages .......................................................................3-50

5.3.4.5 Event message processing by the receiver.......................................................................3-51

5.3.4.6 Usage of DSMCC_section() ............................................................................................3-53

5.3.4.7 Usage of general-purpose event message descriptors......................................................3-54

5.3.4.8 Usage of NPT reference descriptors ................................................................................3-54

5.3.5 IIT usage ······························································································································ 3-54

5.3.6 Associated receiver operations ····························································································· 3-54

5.3.6.1 CM usage .........................................................................................................................3-54

5.3.6.2 Expire descriptors (DII) and receiver operations.............................................................3-54

5.3.6.3 Filtering resources for datacasting reception ...................................................................3-55

5.4 Datacasting service fee structures ...................................................................................................3-55

5.4.1 Fee structures ······················································································································· 3-55

5.4.2 Receiver requirements·········································································································· 3-55

5.5 Low-layer transmission of datacasting services..............................................................................3-55

5.6 Multi-view operation and datacasting services...............................................................................3-56

5.7 Provisional channels and datacasting services................................................................................3-57

5.8 Interactive transmission protocols in datacasting services .............................................................3-57

6 Operating Mono-media Encoding..........................................................................................................3-58

6.1 Video encoding................................................................................................................................3-58

6.1.1 MPEG-1 Video····················································································································· 3-58

6.1.1.1 Constraints on encoding parameters ................................................................................3-58

6.1.1.2 Playback in synchronization with sound (MPEG-2 AAC) ..............................................3-58

6.1.1.3 Other limitations ..............................................................................................................3-58

6.1.2 MPEG-2 Video····················································································································· 3-58

6.1.2.1 Constraints on encoding parameters ................................................................................3-59

6.1.2.2 Other limitations ..............................................................................................................3-59

6.1.3 MPEG-4 Video····················································································································· 3-59

6.2 Still picture and bitmap pattern encoding .......................................................................................3-60

6.2.1 MPEG-2 I frames ················································································································· 3-60

3-iii―

ARIB TR-B15

Version 4.6-E1

6.2.1.1 Constraints on encoding parameters................................................................................3-60

6.2.1.2 Other limitations ..............................................................................................................3-61

6.2.2 JPEG ·····································································································································3-61

6.2.2.1 Encoding parameters........................................................................................................3-61

6.2.2.2 Scaling .............................................................................................................................3-61

6.2.2.3 Other limitations ..............................................................................................................3-61

6.2.2.4 Markers and marker segments to be used........................................................................3-61

6.2.3 PNG ······································································································································3-62

6.2.3.1 Encoding parameters........................................................................................................3-62

6.2.3.2 Chunks to be used for PNG .............................................................................................3-62

6.2.3.3 Other limitations ..............................................................................................................3-62

6.2.4 MNG ·····································································································································3-62

6.2.4.1 Chunks to be used for MNG ............................................................................................3-62

6.2.4.2 Constraints on MNG usage..............................................................................................3-63

6.3 Audio encoding...............................................................................................................................3-64

6.3.1 MPEG-2 AAC ·······················································································································3-64

6.3.1.1 Encoding parameters........................................................................................................3-64

6.3.1.2 Transporting MPEG-2 AAC ............................................................................................3-64

6.3.1.3 Limitations in data-carousel distribution .........................................................................3-64

6.3.1.4 ACC audio file data format..............................................................................................3-64

6.3.2 AIFF-C··································································································································3-64

6.3.2.1 Encoding parameters........................................................................................................3-64

6.3.2.2 Maximum data size..........................................................................................................3-65

6.3.2.3 Other limitations ..............................................................................................................3-65

6.3.3 MPEG-4 Audio ·····················································································································3-65

6.3.4 Additional sound ···················································································································3-65

6.3.5 Receiver's preinstalled sounds·······························································································3-65

6.3.6 Sound synthesis on the receiver·····························································································3-65

6.3.6.1 Mix balance......................................................................................................................3-65

6.3.6.2 Encoding methods that make simultaneous playback of sounds possible.......................3-66

6.4 Character encoding .........................................................................................................................3-67

6.4.1 8-unit code (including EUC-JP) ····························································································3-67

6.4.1.1 Constraints on the character code function......................................................................3-67

6.4.1.2 Character set used in data broadcasts ..............................................................................3-72

6.4.1.3 Character code initialization operation............................................................................3-73

3-iv―

ARIB TR-B15

Version 4.6-E1

6.4.2 International encoding character code ·················································································· 3-73

6.5 Descriptor command picture encoding ...........................................................................................3-73

6.5.1 Geometric····························································································································· 3-73

7 Operating Subtitles and Superimposed Text Encoding..........................................................................3-74

7.1 Scope and definition of services .....................................................................................................3-74

7.2 Scheduling and transmission operations .........................................................................................3-74

7.2.1 Constraints on scheduling and transmission ········································································· 3-74

7.2.2 PES transmission specification used for subtitles ································································· 3-75

7.2.3 PES transmission specification used for superimposed text ················································· 3-76

7.2.4 Using data groups················································································································· 3-77

7.2.5 Using caption management data··························································································· 3-78

7.2.5.1 Caption management data used for subtitles ...................................................................3-78

7.2.5.2 Caption management data used for superimposed text ...................................................3-78

7.2.6 Using caption text data ········································································································· 3-79

7.2.7 Using data units···················································································································· 3-79

7.2.8 Using PSI/SI························································································································· 3-79

7.2.8.1 Using component tags......................................................................................................3-79

7.2.8.2 Using PMT.......................................................................................................................3-80

7.2.8.3 Stream format identification ............................................................................................3-80

7.2.8.4 Using descriptors .............................................................................................................3-80

7.2.8.5 Data encoding method descriptor ....................................................................................3-80

7.2.8.6 Target area descriptor.......................................................................................................3-80

7.2.8.7 Data contents descriptor...................................................................................................3-80

7.3 Video resolution and subtitles and superimposed text display formats ..........................................3-81

7.3.1 Display formats ···················································································································· 3-81

7.3.2 Display area·························································································································· 3-81

7.3.3 Initial action position············································································································ 3-82

7.4 Characters used in subtitles and superimposed text........................................................................3-82

7.4.1 Character code······················································································································ 3-82

7.4.2 Character font······················································································································· 3-82

7.4.3 Font size ······························································································································· 3-83

7.4.4 Display block ······················································································································· 3-84

7.4.5 Non-spacing characters ········································································································ 3-95

7.5 Control codes used in subtitles and superimposed text ..................................................................3-96

7.5.1 Control codes ······················································································································· 3-96

3-v―

ARIB TR-B15

Version 4.6-E1

7.5.2 Using flashing ·····················································································································3-101

7.5.2.1 Limitations .....................................................................................................................3-101

7.5.3 Raster color control ·············································································································3-101

7.5.4 Using boxing ·······················································································································3-101

7.5.5 Using underlining················································································································3-102

7.5.6 Using boundary highlighting·······························································································3-102

7.5.7 Using scrolling ····················································································································3-102

7.5.7.1 Control codes .................................................................................................................3-103

7.5.7.2 Scrolling speed...............................................................................................................3-103

7.5.8 Display function priority ·····································································································3-103

7.6 Using DRCS..................................................................................................................................3-103

7.7 Using initialization........................................................................................................................3-104

7.7.1 Initialization through caption management ·········································································3-104

7.7.2 Initialization through caption text························································································3-104

7.7.3 Initialization through a text data unit···················································································3-104

7.7.4 Initialization through character control code ·······································································3-104

7.8 Mono-media used in subtitles and superimposed text ..................................................................3-104

7.8.1 Using geometric ··················································································································3-104

7.8.2 Using bitmap data ···············································································································3-104

7.8.3 Using warning sounds ·········································································································3-104

7.8.4 Using additional sounds ······································································································3-104

7.9 Preferred receiver's action.............................................................................................................3-105

7.9.1 Start and end of subtitling display ·······················································································3-105

7.9.2 Start and end of superimposed text display ·········································································3-105

7.9.3 Setting items on the receiver ·······························································································3-105

8 Operating Multimedia Encoding..........................................................................................................3-107

8.1 Introduction...................................................................................................................................3-107

8.2 Using NVRAM commonly used for MM services .......................................................................3-107

8.2.1 Identifying the broadcaster common area············································································3-107

8.2.2 Identifying the broadcaster specific area ·············································································3-108

8.2.3 Using information on the right to access the area reserved for BS digital broadcasters, for wide band CS digital broadcasters ··············································································3-108

8.2.4 Use of the viewer's place of residence information from MM services ·······························3-111

8.3 Using remote control keys from MM services ............................................................................. 3-111

8.3.1 Possible values for used-key-list attributes··········································································3-111

3-vi―

ARIB TR-B15

Version 4.6-E1

8.3.2 Correspondence between remote control keys, key codes, and access keys ························3-112

8.3.3 Guidelines for content that uses selection by color keys······················································3-112

8.4 Use of BML versions ....................................................................................................................3-112

8.5 Using lockModuleOnMemory(),SetCachePriority() ....................................................................3-112

8.6 Transporting DRCS pattern data...................................................................................................3-113

8.7 Using name spaces ........................................................................................................................3-113

8.8 Using BML element extension modules (interrupt event)............................................................3-114

8.9 Using procedural scripting languages ...........................................................................................3-114

8.10 Use of getPrefixNumber().............................................................................................................3-114

8.11 Using encrypted communication in the interactive communication feature ................................3-115

9 Operations of Data Broadcasting Services Based on Storage Functionality .......................................3-116

9.1 Operations related to storable program.........................................................................................3-116

9.2 Operation related to linked pre-stored data programs...................................................................3-116

9.2.1 Controlling the viewing of linked pre-stored data programs················································3-116

9.2.2 service_type of channels that operate linked pre-stored data programs ·······························3-116

9.2.3 Schedule patterns of linked pre-stored data programs and operation restrictions ················3-116

9.2.4 Use of the PMT's data encoding method descriptor in linked pre-stored data programs······3-117

9.2.4.1 Use of auto_start_flag in linked pre-stored data programs............................................3-117

9.2.5 Use of the PMT's target area descriptor in linked pre-stored data programs ························3-117

9.2.6 Use of the PMT's digital copy control descriptor in linked pre-stored data programs··········3-118

9.2.7 Use of the p/f EIT's data content descriptor in linked pre-stored data programs··················3-118

9.2.8 Use of the p/f EIT's hyperlink descriptors in linked pre-stored data programs ····················3-118

9.2.8.1 Types of hyperlink to be used ........................................................................................3-118

9.2.8.2 Hyperlink descriptor operation rules .............................................................................3-119

9.2.8.3 Program types and transmission of hyperlink descriptors .............................................3-119

9.2.8.4 Operation when multiple hyperlink descriptors are put.................................................3-119

9.2.9 Use of DII related to storage of linked pre-stored data programs ········································3-119

9.2.10 Use of carousels related to storage of linked pre-stored data programs ······························ 3-120

9.2.11 Use of the multimedia encoding method related to linked pre-stored data programs·········· 3-120

9.2.11.1 Operations related to name spaces.................................................................................3-120

9.2.12 Use of event messages related to storage of linked pre-stored data programs····················· 3-120

9.2.13 Guidelines on the receiver's actions related to linked pre-stored data programs at channel selection ····························································································································· 3-121

9.2.13.1 Launching the data broadcasting engine........................................................................3-122

3-vii―

ARIB TR-B15

Version 4.6-E1

9.2.13.2 Receiver's action related to linked pre-stored data programs when a data broadcasting program starts ...........................................................................................3-122

9.2.14 Processing for programmed storage of a linked pre-stored data program ····························3-123

9.2.14.1 Processing for programmed storage (guidelines) ..........................................................3-123

9.2.14.2 How to calculate the size of content ..............................................................................3-123

9.2.14.3 Autodetect of a stored program .....................................................................................3-123

9.2.14.4 Television program viewing reservation........................................................................3-123

9.2.15 Storage operation processing related to linked pre-stored data programs ····························3-123

9.2.15.1 Information to be stored when storage is performed .....................................................3-123

9.2.15.2 General rules on processing when storage is performed ...............................................3-124

9.2.15.3 Content updates when a linked pre-stored data program is broadcast multiple times ..3-124

9.2.16 Preferable EPG display related to storage of linked pre-stored data programs ····················3-125

9.3 Operations related to independent pre-stored data program.........................................................3-125

9.3.1 Controlling the viewing of independent pre-stored data program········································3-125

9.3.2 service_type of channels that operate independent pre-stored data program ·······················3-125

9.3.3 Schedule patterns of independent pre-stored data program and operation restrictions·········3-125

9.3.4 Use of the PMT's data encoding method descriptor in independent pre-stored data program·······························································································································3-126

9.3.5 Use of the PMT's target area descriptor in independent pre-stored data program ················3-126

9.3.6 Use of the PMT's digital copy control descriptor in independent pre-stored data program··3-126

9.3.7 Use of the p/f EIT's data content descriptor in independent pre-stored data program··········3-126

9.3.8 Use of DII related to storage of independent pre-stored data program ································3-126

9.3.9 Use of carousels related to storage of independent pre-stored data program ·······················3-126

9.3.10 Use of the multimedia encoding method related to independent pre-stored data program···3-126

9.3.11 Use of event messages related to storage of independent pre-stored data program··············3-126

9.3.12 idelines on the receiver's actions related to independent pre-stored data program at channel selection ·················································································································3-126

9.3.12.1 Receiver's actions related to independent pre-stored data program when a data broadcasting program starts ...........................................................................................3-127

9.3.13 Processing for programmed storage of an independent pre-stored data program·················3-127

9.3.13.1 Processing for programmed storage ..............................................................................3-127

9.3.13.2 How to calculate the size of content ..............................................................................3-127

9.3.14 Guidelines on storage operation processing related to independent pre-stored data program ·3-127

9.3.14.1 Information to be stored when storage is performed .....................................................3-127

9.3.14.2 General rules on processing when storage is performed ...............................................3-127

3-viii―

ARIB TR-B15

Version 4.6-E1

9.3.15 Preferable EPG display related to independent pre-stored data program ···························· 3-128

9.4 Extension of BML procedural scripting language related to linked pre-stored/independent pre-stored data programs...............................................................................................................3-128

9.4.1 Programmed-storage-related function ················································································ 3-128

10 Specifications for Terrestrial, BS, and Wide Band CS Common-Use Digital Receivers.................3-132

10.1 Introduction ...................................................................................................................................3-132

10.2 Concept of operation levels and BML versions............................................................................3-132

10.3 Functions demanded of terrestrial and satellite common-use receivers .......................................3-133

10.3.1 RAM ·································································································································· 3-133

10.3.2 NVRAM····························································································································· 3-133

10.3.3 Actions different from the actions of conventional-type receivers······································ 3-134

10.3.4 Identification of media received ························································································· 3-135

10.4 Transmission .................................................................................................................................3-135

10.4.1 Use of DownloadInfoIndication (DII) messages ································································ 3-135

10.4.2 Event messages that do not depend on data event IDs························································ 3-135

10.4.3 NPT reference message ······································································································ 3-135

10.4.4 Route certificate transmission ···························································································· 3-135

10.5 Guidelines on use of content.........................................................................................................3-136

10.5.1 Identification of terrestrial and satellite common-use receivers·········································· 3-136

10.5.2 BML3.0 content placement ································································································ 3-136

10.5.3 Operation coverage of new functions ················································································· 3-136

10.5.4 Operation coverage of browser pseudo-objects ·································································· 3-138

10.5.5 Notes on operation by mixing different BML versions together········································· 3-143

10.5.6 Communication content······································································································ 3-143

10.5.6.1 BML version ..................................................................................................................3-143

10.5.6.2 Security ..........................................................................................................................3-143

10.5.6.3 Browser specific display ................................................................................................3-143

10.5.6.4 Route certificate transmission........................................................................................3-143

10.5.6.5 Print-related function .....................................................................................................3-144

10.5.7 Using name spaces ············································································································· 3-144

10.5.7.1 Identification of the area shared among terrestrial digital television broadcasters .......3-144

10.5.7.2 Identification of the area reserved for affiliates of terrestrial digital television broadcasters....................................................................................................................3-144

10.5.7.3 Identification of the area reserved for BS digital broadcasters, commonly used in both broadcasting and communication ..........................................................................3-144

3-ix―

ARIB TR-B15

Version 4.6-E1

10.5.7.4 Identification of the registered outgoing call storage area ............................................3-144

10.5.7.5 Identification at automatic channel selection by epgTune( ) or epgTuneToComponent( ) ...............................................................................................3-144

10.5.7.6 Broadcasting stream and mono-media referenced from communication content .........3-144

10.5.8 Selecting services of other media ························································································3-144

10.5.9 Programmed recording and viewing reservation for other media ········································3-145

10.6 Operation of new functionality for captioning .............................................................................3-145

10.6.1 Captioning rollup mode·······································································································3-145

10.6.2 Out-screen display function·································································································3-145

10.7 Print function ................................................................................................................................3-145

10.7.1 Extended API group ············································································································3-145

10.7.2 Print data format··················································································································3-146

10.7.3 Supplementary items regarding API for print-related functions ··········································3-146

10.7.4 Presentation by the receiver ································································································3-146

Appendix 1 CLUT Common Fixed Colors ...............................................................................................3-147

Appendix 2 Module Compression Format................................................................................................3-149

Appendix 3 Notes on Access to NVRAM.................................................................................................3-150

Appendix 4 Guidelines on Information Operation on Data Broadcasting NVRAM................................3-150

Appendix 5 Use of NVRAM when the ID of the previous broadcaster is assigned.................................3-153

3-x―

ARIB TR-B15

Version 4.6-E1

1 Introduction

BS digital broadcasting based datacasting services are provided in accordance with ministerial ordinances and notifications from the Ministry of Internal Affairs and Committees as well as standards and specifications released by the Association of Radio Industries and Businesses (abbreviated hereafter to ARIB) including

"Data Encoding and Transmission Specifications for Digital Broadcasting" (ARIB STD-B24) and "Service

Information for Digital Broadcasting System" (ARIB STD-B10). The current document, "BS Digital Satellite

Broadcasting Operational Guidelines for Datacasting", is designed to complement these standards by providing more detailed operational guidelines.

The aim of the Operational Guidelines is to provide flexibility in datacast programming by individual commissioning broadcasters as well as expandability to allow for future growth in datacasting services. The signal transmission and reception specifications contained in these Operational Guidelines are designed to ensure the integrity of datacasting services via BS digital broadcasting.

Basic transmission specifications for datacast programming provided by BS digital commissioning broadcasters shall be as per these Operational Guidelines.

BS digital broadcast receivers are required to be able to receive signal transmitted in accordance with the

Operational Guidelines, and to be capable of operating without malfunction in the presence of other forms of signal.

1.2 BS Level 2

Due to the advent of combined BS/CS receivers, the Operational Guidelines now provide "BS Level 2" specifications designed to replicate additional CS functionality within BS. BS Level 2 is designed to ensure ongoing operational compatibility without requiring any modifications or changes to existing receivers or BS operations.

BS Level 2 is described in Part 2, Section 3.

This Section pertains to datacasting via BS digital broadcasting in accordance with the fog documents:

(1) ARIB STD-B21 "Receiver for BS Digital Broadcasting"

(2) ARIB STD-B10 "Service Information for Digital Broadcasting System"

(3) ARIB STD-B20 "BS Transmission and Operational Conditions in Digital Broadcasting"

(4) ARIB STD-B24 "Data Encoding and Transmission Specifications for Digital Broadcasting"

(5) ARIB STD-B25 "Conditional Access System Specifications for Digital Broadcasting"

3-1―

ARIB TR-B15

Version 4.6-E1

The following terms are used in this document.

16:9

4:3

8PSK

Display aspect ratio with 16 units length versus 9 units height.

Display aspect ratio with 4 units length versus 3 units height.

8 phase-shift keying modulation format, whereby eight transmitted values are aligned with eight phase changes. Normally implemented as trellis coded eight-phase (TC8PSK).

8-bit character encoding Encoding format that boosts text transmission efficiency by reducing text code

ARIB switching overheads compared to 7-bit encoding.

The Association of Radio Industries and Businesses is a domestic industry-based

CLUT

DAVIC

DRCS

ES association which produces standard specifications and technical documents in conjunction with broadcasters, manufacturers and telecommunications carriers.

Color Look Up Table a table used to convert index values for color information into actual physical values.

Digital Audio-Visual Council — designs standardized formats for the transmission and reception of digital information in MPEG format.

Dynamically Redefinable Character Sets a text encoding format for text broadcasting and datacasting that enables external and user-defined characters to be transmitted as patterns.

Elementary Stream made up of encoded images, sound and independent data

EUC-JP

ISO

I frame

MNG

MPEG-1

MPEG-2

PES

PID

PNG

TS carried in PES packets. The ES is transmitted in the form of PES packets with the same stream ID.

Japanese character codes encoded in accordance with ISO 2022.

International Organization for Standardization.

Intra Frame a frame made up of compressed data joined within the frame.

Multiple-image Network Graphics file format for animation graphics, also known as "MING". Multiple PNG images can be displayed in order in a repeating sequence.

A compression format for video and audio data developed by the international standards agency Moving Pictures Expert Group-1 (ISO/IEC 11172).

A compression format for video and audio data developed by the international standards agency Moving Pictures Expert Group-2 (ISO/IEC 13818).

Packetized Elementary Stream video, audio and independent text data packetized into variable length packets.

Packet Identifier 13-bit stream identifier information that indicates the specific stream attribute.

Portable Network Graphics graphic file format developed as the successor to GIF, also known as "PING". Enables compression without quality degradation. File format consists of an eight-byte signature followed by a series of chunks.

Transport Stream as stipulated in the MPEG system specifications (ISO/IEC

13818-1). In BS digital broadcasting, each transponder contains multiple TS that are distinguished by the TMCC signal.

V.22bis

Event

Modulation system for full duplex telephone modems at up to 2,400 bps given in

ITU-T recommendation.

Program. Event as per ARIB STD-B10.

Common fixed colors Colors defined for common use in logo displays and color palettes in receiver units.

Broadcaster-defined colors

Receiver-dependent colors

Pixel expansion

Colors that individual broadcasters are permitted to define in combination with

CLUT index values.

Colors that can be defined for individual receivers in combination with CLUT index values.

A single pixel is expanded vertically and horizontally to cover four pixels.

3-2―

ARIB TR-B15

Version 4.6-E1

Level 1 (2, 3, 4) Kanji characters

Data carousel

Standard character codes for Japanese Kanji characters, as specified in JIS X0208 and elsewhere.

A digital broadcasting download format defined in ISO/IEC 13818-6 that delivers data in a repeating pattern.

Transport Stream

Upstream channel

Refer to TS.

Channel used to connect a receiver to a central device via a modem or equivalent.

Partial transport stream The bit stream which results when transport packets unrelated to the selected program(s) are removed from the MPEG transport packets.

Font

Font size

Basic procedures

(Code Independent

Mode)

Typeface, size etc of a character set.

Same as design limits.

Basic data transmission control procedures between host and terminals, including procedures designed to minimize data transmission errors.

Multi-section

Data-enriched television program

Television program

Two or more sections embedded within a TS packet for transmission.

A television program where the video and audio content is complemented by data broadcast as part of the event. May also contain hyperlink descriptors designating linked data programs. Programs that are primarily audio in content are also considered to be television program for the purpose of this definition.

Ordinary video and audio programming content without additional data. May contain hyperlink descriptors designating linked data programs.

Independent data program

Datacast programs that mainly consist of multimedia data. These programs do not contain hyperlinks to any television programs or data-enriched television programs.

Linked data program A program in which the multimedia data is stored at a different time to a data-enriched program or program designed for viewing in conjunction with the data. This feature is optional in the basic receiver unit.

Other data programs Other data programs envisaged in the future which do not fall into the above categories.

Associated datacasting A general term for datacasting services in which the data portion of data-enriched television programs and linked data programs is designed for viewing in conjunction with the image portion.

Image portion of data-enriched television program

The non-data portion of a data-enriched television program.

Data portion

Video recording

The data portion of a data-enriched television program.

Recording of broadcast services onto media such as D-VHS or HDD in the form of a transport stream or partial transport stream. This feature is optional in the basic receiver unit. (In the case of analogue recording, "Analogue Recording" must be stipulated.)

A reservation for viewing a specific program event based on SI information. Program viewing reservation

Program recording reservation

Store

Viewing in real time

A reservation for recording a specific program event based on SI information.

Storing a data file onto RAM, NVRAM, HDD or equivalent.

Viewing content as it is obtained from the data carousel.

Viewing stored data Viewing content after it has been stored as a data carousel modules.

Independent viewing Viewing stored content only without specifying video and audio streams referenced from the content simultaneously.

Data event The period over which a BML document or group of BML documents for a given component is being transmitted. Data events are different to SI events. Data events are switched with every update of data_event_id in DII sent in the component.

Local content The data carousel sent in the data event for a given component.

3-3―

ARIB TR-B15

Version 4.6-E1

Content

Entry component, entry carousel

Startup module

Startup document

A general abstraction for the collection of local content that is sent over the period of a given component event, which is identified by the EIT data content descriptor.

A component with a component tag value of 0x40 in PMT 2 nd

loop is called an entry component. The data carousel sent via this component is called the entry carousel.

A module with moduleId = 0.

The first BML document in the data carousel to be reproduced by default.

Located in the startup module.

Data broadcasting engine

Data event message

Receiver software that obtains and interprets multimedia data (BML documents) and renders it on the display screen.

Interrupt event generated by the data broadcasting engine against the BML document currently being displayed in response to changes in transmitted data signal such as data event switching.

Identification of the stream format as per ISO/IEC 13818-1. Stream format identification

Data carousel

Image PES

Low-layer service

Chunk

Data carousel transmission specification as stipulated in ARIB STD-B24, Section

3.

Data structure used for transmission of video data encoded as per ISO/IEC

13818-1.

A layer broadcast that can be received at low C/N times.

Name given to information block in PNG and MNG file formats.

Audio PES Data structure used for transmission of audio data encoded as per ISO/IEC

13818-1.

News flash subtitling Fast subtitling service for television broadcasts, commonly used for news flashes.

Superimposed text

Temporary channel

Multi-view

Subtitling service where the text is not synchronized with the main video, audio and/or data content, commonly used for ongoing updates and raw news.

Services provided on temporary SDTV channels on surplus bandwidth created by reducing bit rates without compromising existing editing services, commonly used for news flashes.

Splitting HDTV bandwidth into several (up to three) SDTV that can be used to watch different but related content simultaneously (e.g. during a golf broadcast, the main channel might be the conventional broadcast, with the 17 th

hole as Sub 1 and the 18 th

hole as Sub 2).

3-4―

ARIB TR-B15

Version 4.6-E1

4 Basic Receiver Unit Functionality for Reception of Data Broadcasts

This chapter describes the required functionality of the basic receiver unit for reception of data broadcasts.

The basic receiver unit conforms to Class A as shown in the two sample receiver configurations given in

ARIB STD-B24 "Data Encoding and Transmission Specifications for Digital Broadcasting", Section 1, Part 1,

Description. In this document, the basic receiver unit is defined in terms of the various sections of the hardware configuration and the internal resources associated with the reference decoder.

Figure 4-1 shows the hardware configuration for the basic receiver unit.

Digital broadcast signal input into the receiver is converted to a transport stream by the tuner and 8PSK demodulation. The transport stream decoding process then splits the demodulated transport stream into video, audio and other data. The video steam is sent to the vide decoder and the audio stream to the audio decoder.

This enables the basic receiver unit to reproduce ordinary video and audio content.

During data broadcast reception, the data is temporarily sent to the main memory or non-volatile memory for

CPU processing. This arrangement enables data to be sent from the main memory to the video and audio decoders for simultaneous reproduction during text/diagrams display as well as ordinary video and audio reproduction. Upstream circuits can also be used to add interactive elements to conventional television viewing. These hardware operations require the following functional specifications:

1

Types of data compatible with transport decoder

2

Replaying streamed and stored audio data

3 Replaying streamed and stored video data

4

Displaying video and still picture, graphics and text

5

Modem-based interactive communication

6 Maximum data size for continuous recording

7

Maximum data size for system information such as fonts

8

Memory size for data acquisition and decoding

9

Guidelines for remote control operation

TS decoder functionality is described in 1; display functionality is described in 2, 3, 4 and 7; modem functionality is described in 5; memory capacity is described in 6, 7 and 8; and remote control functionality is described in 9.

3-5―

ARIB TR-B15

Version 4.6-E1

Remote control k

Non-stored data flow

TS decoding

Audio output

Audio decoding

RF

I/O

Tuner h

NVRAM

(Flash)

8PSK demodulation c i

ROM

(Font.etc) j

RAM

(main memory)

Video decoding d e

CPU

Figure 4-1 Hardware configuration for basic receiver unit

Display processing f

Video output g

System bus

Modem

The receiver reference model indicates the resources within the receiver and sets out the reception limits of the basic receiver unit with respect to data broadcasts. Figure 4-2 shows the receiver reference model.

The reference model is essentially the decoder model shown in DAVIC 1.4 Part 9 modified in accordance with the specifications in the Operational Guidelines. Unless stated otherwise, the definitions used here conform to DAVIC definitions.

The MPEG-2 TS is split into individual ES units using a PID filter. Next, the video and audio elementary streams sent by PES travel are stored in the main buffer Bn via the TBn transport buffer. The elementary stream for MM content sent by the data carousel is subject to PID filtering and then Section filtering, then stored in Bcontents (via TBn).

In this way, the received MM content data is activated via an end user operation. The MM engine reads

Bcontents data and executes MM content using Bwork as execution memory in accordance with the activation command. Meanwhile, mono-media content sent by the data carousel is transferred from Bcontents to the respective decoders, while streamed mono-media content is transferred from Bn to the respective decoders. Audio mono-media content is decoded and then presented via the speaker. Video mono-media content is decoded into video, still picture, text/diagrams and subtitles, then temporarily buffered in respective plane display memory areas, then recombined and presented on the monitor. Model plane combinations are shown in the following figure. Thus, still picture and video are converted to effective pixels by area. The text/diagrams plane is imposed, with a transmission coefficient, on the combined still picture and video, then the text/diagrams plane is imposed on the result, with the same transmission coefficient, to produce the final presentation screen.

3-6―

ARIB TR-B15

Version 4.6-E1

BProNV

MM engine

Interpreter

BMMexec

BSCRexec

Bwork

MPEG-2

TS

TBn

TBn

Bcontents NV

Bsys

TBn

TBn

Bn

MBn EBn

TBn

Bcontents

Bn

X f r

B

A

System

Decoder

MPEG-2

/ linear

Audio

Decoder

MPEG-1,2

Video

Decoder

Still picture decoder

Text / diagrams decoder

Bo

"Display memory video plane "

"Display memory still picture plane "

"Control memory switched video / still picture plane "

"Display memory text/diagrams plane"

CLUT

Display memory subtitles plane

CLUT

1-α1

1-α2

α1

α2

TBn

Bn

Bcontents

BcontentsNV

XfrBA

BMMexec

Bwork

BproNV

Other buffers

Figure 4-2 Basic receiver unit reference model

Transport buffer for elementary stream n.

Main buffer for elementary stream n in decoder.

Buffer for multimedia content data sent via data carousel. Where a module has been compressed (with DII Compression Type descriptor) for transmission, both compressed and expanded data will be buffered.

Storage buffer for multimedia content data sent via data carousel. (*) Optional in basic receiver unit.

Buffer used to transfer audio content in file format to the audio decoder.

Multimedia code execution memory.

Multimedia content execution memory combining BMMexec and BSCRexec.

Non-volatile memory used to store information on individual receiver users and unique broadcaster information.

For details on the definition, refer to ISO/IEC13818-1 and DAVIC 1.4

Specifications Part 9.

Presentation functions for the basic receiver unit are as described in Section 1, Part 1 of ARIB STD-B24,

"Data Encoding and Transmission Specifications for Digital Broadcasting".

3-7―

ARIB TR-B15

Version 4.6-E1

4.2.1 Resolution of planes in display screen and associated restrictions

Table 4-1 shows the required resolution of each plane in the display screen.

Table 4-1 Plane resolutions

Item

Video plane

Still picture plane

Text/diagrams plane

Subtitle plane

Switched video/still picture plane

Resolution

Requirement

1920x1080x16, YCbCr(4:2:2), 16:9

720x 480x16, YCbCr(4:2:2), 16:9

720x 480x16, YCbCr(4:2:2), 4:3

Resolution

Resolution

1920x1080x16, YCbCr(4:2:2), 16:9

720x 480x16, YCbCr(4:2:2), 16:9

720x 480x16, YCbCr(4:2:2), 4:3

960x 540x8, 16:9

(*) Display size = 1920x1080 (2 x horizontal/vertical pixel expansion)

720x 480x8, 16:9

720x 480x8, 4:3

CLUT

Receiver-dependent colors: 32

Broadcaster-defined colors: 96

Presentation

CLUT 8-bit index value converted to YCbCr(4:2:2) and 4-bit

α values (*0)

Resolution

CLUT number: 1

Common fixed colors: 128 (refer to Appendix 1)

960x 540x8, 16:9

(*) Display size = 1920x1080 (2 x horizontal/vertical pixel expansion)

720x 480x8, 16:9

CLUT

720x 480x8, 4:3

CLUT number: 1

Common fixed colors: 128 (refer to Appendix 1)

Receiver-dependent colors: 32

Presentation

CLUT 8-bit index value converted to YCbCr(4:2:2) and 4-bit

α values (*0)

Resolution 960x 540x1, 16:9

(*) Size = 1920x1080 (2 x horizontal/vertical pixel expansion)

360x 240x1, 16:9

(*) Size = 720x480 (2 x horizontal/vertical pixel expansion)

360x 240x1, 4:3

(*) Size = 720x480 (2 x horizontal/vertical pixel expansion)

(*0) where the

α value definition sets an 8-bit color map in CLUT, the upper 4 bits of the color map are mapped to the 4 bits in CLUT.

When combining the text/diagrams and subtitles planes together, a degree of non-linearity is permitted in

α mixing, in order to allow some freedom in the structure of the mixing path.

However, this means that the presentation results must reflect changes in

α, which has 16 gradations.

3-8―

ARIB TR-B15

Version 4.6-E1

Table 4-2 shows restrictions associated with each plane in areas such as mono-media code that can be presented and size and position of mono-media content.

Table 4-2 Restrictions in display plane

Item

Video plane

Still picture plane

Text/diagrams plane

Eligible mono-media code

Requirement

MPEG-2

(*) Only one video can be presented at a time, irrespective of encoding method

Position

MPEG-1

(*) Only one video can be presented at a time, irrespective of encoding method

From plane even pixel numbers to odd pixel numbers for both x and y coordinates (*1)

Even pixel numbers for both x and y coordinates Size

Layering

Eligible mono-media code

Position

No layering of video

JPEG

From plane even pixel numbers to odd pixel numbers for both x and y coordinates

Size Even pixel numbers for both x and y coordinates

Layering Unrestricted

Eligible mono-media code

8-bit character code. (*) including EUC-JP.

PNG

MNG

Position

Size

From any pixel to any other pixel, for both x and y coordinates

Any number of pixels for both x and y coordinates

Subtitles plane Eligible mono-media code

Position

Size

8-bit character code

Bitmap data

From any pixel to any other pixel, for both x and y coordinates

Any number of pixels for both x and y coordinates

Switched video/still picture plane

Display switching effect

Switching position although this may occur on occasion. For more details, refer to 7.9.

From any pixel in both x and y coordinates

Size Any number of pixels for both x and y coordinates

Display switching is receiver dependent.

(*1) Pixel is defined as per ARIB STD-B24.

(*2) Applications that require minimal (or no) changes in the layering order of still picture, text and diagrams or redrawing after movement are recommended. Redrawing should not cause failure of the receiver display. Restrictions on layering of still picture generated in combination with video are described in 4.2.2.

3-9―

ARIB TR-B15

Version 4.6-E1

4.2.2 Eligible plane combinations and associated restrictions

As shown in the reference model, the presentation screen is a combination of the various planes. Table 4-3 shows the rules for combining planes.

Item

Resolution

Area for switched still picture/video plane

Table 4-3 Eligible plane combinations and restrictions

Requirements

Video, still picture planes, text/diagrams planes, and subtitle planes can only be combined when they are at the same resolution and same aspect ratio. Note however that 960x540 for the text/diagrams and subtitles planes are treated as

1920x1080. (*3)(*4)

In the switched still picture/video plane, the 1/2x1/2 resolution of the switched still picture/video planes is treated as the same resolution as the switched plane.(*5)

A rectangle area must be designated for either video or still picture.(*6)

Maximum number of areas for video and still picture

Where the rectangular area is for video, the maximum number of areas is 1.

Where all rectangular areas are still picture, the maximum number of areas is

4.(*7)

(*3) Where the video aspect suddenly changes, for instance due to interruption by an emergency broadcast, the combined television broadcast and datacast display is maintained, even if this is different to datacast resolution. The display operation in this situation is receiver dependent. For more information about operational guidelines for receivers, refer to Chapter 5, Data

Transmission Specification Usage.

(*4) Datacasting resolution refers to combinations with text/diagrams, subtitles, and video and still picture planes that can be used simultaneously with datacasts. It is defined as shown below.

3-10―

ARIB TR-B15

Version 4.6-E1

960x540

(16:9)

*1

Datacasting resolution

720x480

(16:9)

720x480

(4:3)

Text/diagram plane resolution

Subtitle plane resolution

Video plane resolution

Still picture plane resolution

960x540

(16:9)

720x480

(16:9)

720x480

(4:3)

960x540

(16:9)

720x480

(16:9)

720x480

(4:3)

1920x1080

(16:9)

720x480

(16:9)

720x480

(4:3)

1920x1080

(16:9)

720x480

(16:9)

720x480

(4:3)

{

{

{

{

{

{

{

{

{

{

{

{

*1 Text/diagram plane at datacasting resolution 960x540 (16:9) is expanded by x 2 in the vertical and horizontal directions for layering with video and still picture.

The following table shows the datacasting resolution that can be combined with compressed video in low-level video format (352x240 (16:9,4:3)).

Low-level video format

352x240

(16:9)

352x240

(4:3)

Datacasting resolution

960x540

(16:9)

720x480

(16:9)

720x480

(4:3)

{

{

3-11―

ARIB TR-B15

Version 4.6-E1

The datacasting resolution that can be combined with 720p video is 960x540 (16:9).

In line with amendments to ARIB STD-B21, investigations will be conducted where necessary with the establishment of a new MPEG resolution.

(*5) Both video and still picture are YCbCr (4:2:2) at full resolution and valid switching units are 2 pixels. Thus, for the purpose of still picture/video switching in the switched still picture/video plane at 1/2x1/2 resolution of video and still picture planes.

(*6) (*7) There are two visual patterns for displaying combinations of video and still picture planes.

In the first pattern, the video is positioned on top of the still picture as shown in Figure 4-3.

The rectangular area is the video area, and the number of areas that can be set is 1.

In the second pattern, the still picture is positioned on top of the video for the entire screen display as shown in Figure 4-4. The rectangular area is the still picture area, and the maximum number of areas is 4. Where multiple still picture areas are specified, the still picture can be layered as shown in examples 1 and 2 in Figure 4-5; however in this case, the area is not rectangular as required in the regulations, and therefore cannot be implemented. In examples 3 and 4, the areas are not rectangular but they are acceptable because the boundaries of the rectangular areas are considered to be in contact.

Still picture

…Full screen

Moving picture

…Rectangular area

Figure 4-3 Example 1: Moving picture and still picture combinations

Moving picture

Still picture

Still picture

…Full screen

…Rectangular area

Still picture

Still picture

Figure 4-4 Example 2: Moving picture and still picture combinations

3-12―

Moving picture

Still picture 1

Still picture 2

Still picture 3

Still picture 4

ARIB TR-B15

Version 4.6-E1

…Full screen

…Rectangular area

Figure 4-5 Example 3: Moving picture and still picture combinations

4.2.3 Mono-media encoding and presentation planes

Table 4-4 provides an overview of the constraints on mono-media encoding in the planes listed above. It is expected that broadcasters will not transmit mono-media encoding that is not listed here or mono-media that has not been encoded in accordance with the regulations. Details of the encoding systems are given in

Chapter 6.

3-13―

ARIB TR-B15

Version 4.6-E1

JPEG

PNG

Table 4-4 Restraints on mono-media encoding for display planes

Encoding method

MPEG-2

(*8)

MPEG-1

Transmission specification

Image size

Details

Video PES (*9); streaming type identifier = 0x02

1920x1080 (16:9), 1440x1080 (16:9)

1280x720(16:9),

720x480 (16:9), 544x480 (16:9),

480x480 (16:9), 352x240 (16:9),

720x480 (4:3), 544x480 (4:3),

Transmission specification

480x480 (4:3), 352x240 (4:3)

(*10)

Scaling 256/128,192/128,160/128,128/128,96/128,80/128,64/128,48

/128,32/128(*11)

Video PES (*9); streaming type identifier =0x01

Image size

Other

352x240(4:3, 16:9), 176x120(4:3, 16:9) (*10)

Scaling 256/128,192/128,160/128,128/128,96/128,80/128,64/128,48

/128,32/128(*11)

Only for display on 720x480 (4:3, 16:9) SD resolution video plane

Transmission specification

Data carousel; streaming type identifier = 0x0D

Image size Horizontal/vertical any size from 16 pixels to full size

Scaling 128/128(*12)

Other

Transmission specification

Assumes 4:2:0 resolution. 4:2:2 input must not cause failure in receiver display.

MM encoding Data carousel; streaming type identifier = 0x0D

MNG

Image size

Scaling 128/128 streaming type identifier = 0x06

Horizontal/vertical any size from 2 pixels to full size

Transmission specification

Data carousel; streaming type identifier = 0x0D

Image size Horizontal/vertical any size from 2 pixels to full size

Scaling 128/128

Transmission specification

Independent PES; streaming type identifier = 0x06

Data carousel; streaming type identifier = 0x0D

8-bit character encoding

(*) includes EUC-JP

(*8) It is also possible to transmit the intraframe only and generate a pseudo still picture display, in which case the constraints are as per video encoding. Accordingly, simultaneous decoding of other video (MPEG 1 and 2) is not possible. A video decoding control descriptor (refer to Section 4) is required for intraframe transmission.

(*9) Streamed packets sized in accordance with MPEG-2 TS multiplexed PES packets.

(*10) In this document, the physical pixels in individual planes have been defined as resolutions. Where the mono-media screen size is different, the following principles apply to mapping to the plane.

3-14―

ARIB TR-B15

Version 4.6-E1

MPEG resolution is defined in terms of the Vertical size, Horizontal size and Aspect ratio contained in the

Sequence Header of MPEG encoded data. The MPEG resolution of video data that can be displayed in the respective video plane resolutions is described below.

MPEG video

HD video data

MPEG resolution

1920x1080 (16:9)

1440x1080 (16:9)

Video plane resolution

1920x1080

(16:9)

720x480

(16:9)

720x480

(4:3)

{

{

×

×

×

×

1280x720 (16:9) {

× ×

SD video data

MPEG2 video

MPEG1 video

720x480 (16:9)

544x480 (16:9)

480x480 (16:9)

352x240 (16:9)

720x480 (4:3)

544x480 (4:3)

480x480 (4:3)

352x240 (4:3)

352x240 (16:9)

176x120 (16:9)

352x240 (4:3)

176x120 (4:3)

×

×

×

×

×

×

×

×

×

×

×

×

{

{

{

{

×

×

×

×

{

{

×

×

×

×

×

×

{

({= yes,

×= no)

(*11) The scaling factor is defined as follows by the combination of the MPEG resolution and plane.

{

{

{

×

×

{

{

Scaling ratio = 128/128 (100%) for video data display is defined as follows:

1) Video data quantized at the relevant MPEG resolution

2) Quantized video data displayed on video plane at the following aspect ratio:

- Vertical pixels = vertical pixels for video data

- Horizontal pixels = vertical pixels x aspect ratio of video data

Note:

Video data at 352x240 MPEG resolution is given side panels on the left and right of width 4 pixels. Thus the video plane display has a total of 360 pixels in the horizontal direction. Video data at 176x120 MPEG resolution is given side panels on the left and right of width 2 pixels to make 180 horizontal pixels on the video plane display. When side panels are added by the receiver in this way, the display format is receiver dependent. It is recommended that the side panels are hidden for multimedia content using other planes.

3-15―

ARIB TR-B15

Version 4.6-E1

- Video data at 1280x720(16:9) is mapped to a video plane with resolution 1920x1080(16:9) (i.e.

1080 pixels in the vertical direction and 1920 in the horizontal direction), with a scaling ratio of

128/128.

About video data presentation with scaling ratio n/128 {n|256,192,160,128,96,80,64,48,32}:

1) Calculate the aspect ratio for 128/128 scaling as described above.

2) Use the respective n/128 pixel numbers for the respective aspect ratios as the display area for displaying in the video plane. In the event of non-even pixel numbers in either direction, the numbers are rounded off from the largest pixel number (lower right) for both directions. (For details on pixel numbers, refer to ARIB STD-B24.)

Scaling ratio constraints

Scaling ratios above 128/128 apply only to video data with 352x240 or 176x120 MPEG resolution.

(Example 1) Scaling of HD video data

Video data and MPEG resolution

16:9

Display in video plane for datacasting resolution of

960x540 (16:9)

(scaling ratio=128/128)

Display in video plane for datacasting resolution of 960x540

(16:9)

(scaling ratio=64/128)

1920x1080

1440x1080

1280x720

1920x1080

960x540

1920x1080

1920x1080

Mapped to 1080 in the vertical direction and 1440 ->1920 in the horizontal direction to maintain

16:9 aspect in the video plane.

1920x1080

Mapped to 1920x1080(16:9) plane.

960x540

1920x1080

960x540

1920x1080

3-16―

ARIB TR-B15

Version 4.6-E1

(Example 2) Scaling of SD video data (16:9)

Display in video plane for datacasting resolution of 720x480

(16:9) (scaling ratio=128/128)

16:9

Video data and MPEG resolution

Display in video plane for datacasting resolution of

720x480 (16:9) (scaling ratio=64/128)

720x480

360x240

720x480

720x480

544x480

480x480

720x480

Mapped to 480 in the vertical direction and

{544,480,352}->720 in the horizontal direction.

360x240

720x480

352x240

176x120

360x240

720x480

4-pixel side panels added to the left and right ends to produce

360x240 display area.

180x120

720x480

2-pixel side panels added to the left and right ends to produce

180x120 display area.

180x120

720x480

90x60

720x480

(*) Data transmission uses origin position for video display of the top left-hand corner of the plane.

3-17―

ARIB TR-B15

Version 4.6-E1

(Example 3) Scaling of SD video data (4:3)

Video data and MPEG resolution

4:3

Display in video plane for datacasting resolution of

720x480 (4:3)

(scaling ratio=128/128)

Display in video plane for datacasting resolution of

720x480 (4:3)

(scaling ratio=64/128)

720x480 720x480

360x240

720x480

544x480

480x480

352x240

720x480

Mapped to 480 in the vertical direction and

{544,480,352}->720 in the horizontal direction.

360x240

720x480

4-pixel side panels added to the left and right ends to produce

360x240 display area.

360x240

180x120

720x480

176x120

180x120

720x480

2-pixel side panels added to the left and right ends to produce

180x120 display.

90x60

720x480

(*12) 256/128 scaling is used only for images sent in 960x540 resolution and expanded by 2 pixels in both directions at the receiver end to produce 1920x1080 size.

3-18―

ARIB TR-B15

Version 4.6-E1

Table 4-5 lists specifications pertaining to audio reproduction. It is expected that broadcasters will not transmit mono-media encoding that is not listed here or mono-media that has not been encoded in accordance with the regulations. Details of the encoding systems are given in Chapter 6.

Table 4-5 Audio reproduction function

Encoding method

AAC-LC

AIFF-C

Subtitles warning sound

Details

Transmission specification Audio PES; streaming type identifier = 0x0F

Data carousel; streaming type identifier = 0x0D

Sampling frequency 48KHz, 32KHz (*13)

Maximum continuous file size 256KB

Other (*13)(*14)

Transmission specification Data carousel; streaming type identifier = 0x0D

Sampling frequency 12KHz(*) 1/4 of main audio

Maximum continuous file size 96KB

Other (*13)(*14)

Transmission specification Preinstalled sound (*15)

Sampling frequency 12KHz

Maximum continuous file size 48KB

(*13) Chapter 6, Operating Mono-media Encoding, describes constraints such as simultaneous decoding of video encoded and other audio encoded data.

(*14) During repeated playback of decoded file format data transmitted in the data carousel, periods without audio are permitted between repetitions.

(*15) Total ROM size for preinstalled sounds = 480KB.

3-19―

ARIB TR-B15

Version 4.6-E1

4.2.5 Fonts

Fonts are restricted to a size consistent with the required on-board ROM size of the receiver to prevent interference with normal operation. Table 4-6 shows font specifications.

Table 4-6 Fonts

Item Details

Font typefaces Typefaces: 3 (Maru-Gothic, Futo Maru-Gothic and Kaku-Gothic)

(*) Shared for 960x540 and 720x480

No proportional fonts

Character types

Kanji characters (types 1 and 2), hiragana characters, katakana characters, alphameric characters, symbols etc (*16)

Font size

(pixels)

User-defined characters allowed

Maru-Gothic

Futo Maru-Gothic

16, 20, 24, 30, 36

30

(*16) For details on character types, refer to 6.4.1.2.

(*17) Character embellishment (such boundary highlighting) is to be achieved via software processing. The means of implementation (such as loading of dedicated fonts) is receiver dependent.

3-20―

ARIB TR-B15

Version 4.6-E1

Table 4-7 lists the remote control keys used in datacasting together with content creation guidelines. To avoid confusion, no button should have several different meanings assigned to it. Where a button has more than one meaning, the operation of the button should be described to the end user within the relevant content.

Table 4-7 Remote control keys used in datacasting

Keys

↑, ↓, ←, →

(Up/Down and Left/Right keys)

0 - 9

(numeric keys)

Enter

Back

Guidelines

Moves in the direction of the arrow.

Numeric input.

Data

Blue, red, green and yellow

(color keys)

Executes the operation.

Undoes the operation.

Backspace in user input text. (or Delete All)

Stop calls in both directions.

(*) When a connection is in progress, the operation command is at the receiver (ideally, a message that the connection will be broken should be displayed in the content when the Back key is pressed); after the connection, it is in the content.

(*) BML document may be used for Back. Note that previous location may not exist.

Toggles show/hide multimedia datacasting.

Selects operation/execute.

(*) Buttons are arranged Blue, Red, Green then Yellow from left to right on the remote control unit. The names of the colors should also be printed on the buttons for easy identification.

Multimedia content can mask keys as per ARIB STD-B24. Station selector keys (one-touch selector button, channel up/down keys and video key) are not masked by content except during online communication.

3-21―

ARIB TR-B15

Version 4.6-E1

Table 4-8 lists transport decoder requirements.

Table 4-8 Transport decoder

Item

Number of TS that can be received simultaneously

Number of filters required

1

PID

Requirements

32(*18)

(*18) Designed for receivers with 32 PID filters and 32 Section filters that are capable of receiving and displaying datacasting content (including SI/PSI reception) at the same time.

Both minimum and recommended memory requirements are stipulated for the basic receiver unit, in order to promote receiver usage. The minimum specifications enable the receiver to receive and display all forms of datacasting content without failure. The recommended specifications enable a practical response to future services that were envisaged in 2000.

Memory deployment in receivers and associated definitions can be found in 4.1.2 Receiver reference model.

4.5.1 RAM

Receiver units contain various forms of memory, as illustrated in the reference model. This section describes

Bcontents and XfrBA, which are envisaged as RAM-based memory. Table 4-9 shows the RAM sizes. For details, refer to 4.1.2 Receiver reference model.

Table 4-9 RAM

Item Memory specifications

Bcontents

Minimum

At least 2MB

XfrBA 256KB

Recommended

At least 8MB

Buffer sizes for subtitles and superimposed text are described in Chapter 7.

3-22―

ARIB TR-B15

Version 4.6-E1

4.5.2 NVRAM

The main types of non-volatile receiver memory used for datacasting are BproNV (for individual user information and broadcaster-specific information) and BcontentsNV (for MM content), as shown in the reference model. BproNV is described in 8.2.1 and 8.2.2. The broadcaster specific area (broadcaster specific information) can read and write only from MM content (including stored MM content) that has been obtained from broadcasts by the receiver. The user cannot read or write to the broadcaster specific area by using other receiver functions or connecting an external device to the receiver. In order to satisfy these constraints, the broadcaster specific area should ideally be located in an internal memory device such as NVRAM. Since the storage function is optional for BcontentsNV, implementation and the capacity are receiver dependent.

For details, refer to 4.1.2 Receiver reference model.

NVRAM in the receiver uses devices which have a limited number of writes. If the write limit is exceeded these devices can fail, reducing the usable life span of the receiver unit. For this reason, the system design should avoid excessive writing to NVRAM. Appendix 3 gives more information on this issue.

4.6 Modem

Table 4-10 lists modem requirements.

Protocol

Item

Transmission rate

Table 4-10 Modem requirements

Requirements

BASIC mode procedure (Code Independent Mode)

V22bis (2400bps)

3-23―

ARIB TR-B15

Version 4.6-E1

This chapter describes newly defined items, updates and operational constraints pertaining primarily to

XML-based multimedia encoding method transmission systems, based on the provisions of the documents listed below. Except where otherwise specified, datacasting services are defined as multimedia datacasting services encoded via XML-based multimedia encoding method. Any area not covered in this chapter shall be subject to the provisions of the following documents.

ARIB STD-B10 "Service Information for Digital Broadcasting System"

ARIB STD-B24 "Data Encoding and Transmission Specifications for Digital Broadcasting"

Chapter 9 of this document describes data programs requiring the storage function, which is optional on the basic receiver unit. Given that the current chapter describes the basic receiver unit, any information concerning storage is denoted by the „ symbol.

5.1 SI/PSI

5.1.1.1 Data programs versus television programs

Data programs are distinguished from television programs as follows:

Television program: A program where the first component of the PMT 2 nd

loop does not contain a

Data program: data encoding method descriptor (in this chapter, this also includes radio programs)

A program where the first component of the PMT 2 nd

loop contains a data encoding method descriptor

Television programs are classified into those with additional data ("data-enriched television programs") and those without ("standard television programs"). In this document, television program means a standard television program.

Data programs are classified into those designed for viewing in isolation ("independent data programs") and those designed for viewing in conjunction with standard or data-enriched television programs ("linked data programs").

Table 5-1 describes the different types of datacasting service programs.

3-24―

ARIB TR-B15

Version 4.6-E1

Table 5-1 Types of datacasting service programs

Program type

Data-enriched television program

Independent data program

„ Linked pre-stored data program

„ Independent pre-stored data program

Definition

A television program with a data encoding method descriptor located in a component other than the head of the PMT 2 nd

loop.

„ May use hyperlink to link to a pre-stored data program.

A program that is transmitted by a data service (service_type=0xC0) and contains a data encoding method descriptor in the head component of the

PMT 2 nd

loop.

A data program which is broadcast as a service_type=0xA8 service and which contains hyperlinks to standard or data-enriched television programs via hyper_linkage_type=0x81 (combined_posterior_stream). Hyperlinks must be provided in both directions, with the corresponding pre-stored data program specified in the hyper_linkage_type=0x80(combined_prior_data) hyperlink in the television program. Refer to Chapter 9.

(Optional for basic receiver unit)

A data program which is broadcast as a service_type=0xA8 service but which does not contain a hyper_linkage_type=0x81(combined_posterior_stream) hyperlink descriptor in the corresponding data program EIT. Refer to Chapter

9.

(Optional for basic receiver unit)

„ The service type (0xC0 or 0xA8) of the broadcast service is used to distinguish between an independent data program and a linked or independent pre-stored data program.

Data programs by viewing type

Data programs are either viewed in real time, or stored for subsequent viewing. Programs that cannot be viewed in real time have a very long data carousel cycle. This effectively prevents viewing by acquiring modules from the data carousel in each cycle. The status of the program with respect to real-time viewing is notified via the ondemand_retrieval_flag in the PMT data encoding method descriptor and the EIT data content descriptor.

Where a data program is designed to be stored for later viewing in conjunction with a television program, the commissioning broadcaster may forbid viewing of the data program independently of the television program. The status of the program with respect to independent viewing is notified via the independent_flag in the PMT data encoding method descriptor and the EIT data content descriptor.

„ Types of data program storage

Some types of content in data programs may be stored while other types may not. The same applies to additional data in data-enriched television programs. The status of the content with respect to storage is notified via the file_storage_flag in the PMT data encoding method descriptor and the EIT data content descriptor.

This flag is ignored in basic receiver units with no storage function.

Refer to PMT data encoding method descriptor (5.1.5) and EIT data content descriptor (5.1.7).

3-25―

ARIB TR-B15

Version 4.6-E1

5.1.1.4 service_type for datacasting program channels

There are three forms of service_type for services broadcast by different data programs as shown below:

1) Data-enriched television programs are broadcast on service_type=0x01 or 0x02

(television or radio services) channels

2) Independent data programs are broadcast on service_type=0xC0 channels

3) „ Pre-stored linked and independent data programs are broadcast on service_type=0xA8 dedicated channels

These channels are ignored on a basic receiver unit with no storage function.

5.1.2 Content structure and components usage in datacasting services

5.1.2.1 Content versus local content

Table 5-2 explains the distinction between content and local content, while Figure 5-1 shows the relationship between local content and events.

Table 5-2 Content versus local content

Content

Local content

Definition

Collection of local content transmitted for a given component over a given event period. Indicated in the data content descriptor.

Application

Not designated for content.

Collection of BML documents transmitted for a given data

May switch between successive pieces of local content within a single component in order. event of a given component..

„ Where the transmission period for local content is the same as the event period (ES1 in

Figure 5-1), the EIT data content descriptors have 1:1 correspondence. For other forms of local content, EIT data content descriptors are not 1:1. Chapter 9 provides definitions of correspondence between event periods and local content.

3-26―

ARIB TR-B15

Version 4.6-E1

ES1

ES2

ES3

ES4

Local content

(1:1 correspondence in data content descriptors)

Local content Local content Local content

Data event

Local content

Event

Local content

Local content

Local content

Time

Figure 5-1 Local content and events

5.1.2.2 Local content and ES

Each piece of local content is transmitted on a separate data carousel (ES). Local content may be used to reference video/audio ES and/or event message ES. The streaming type identifier for components used to transmit data carousels and event messages is always 0x0D.

5.1.2.3 Component tags usage

Table 5-3 shows tags for components used in datacasting services, including subtitles and superimposed text.

Note that this excludes video and audio components used in television and radio services.

Table 5-3 Usage of component tags in datacasting

Component type

Subtitles (default)

Subtitles (other)

Superimposed text (default)

Superimposed text (other)

Entry component (default)

Entry component (other)

All other components (data carousel, event message, AV stream referenced from datacasting only*)

Component tag value

0x30

0x31 - 0x37

0x38

0x39 - 0x3F

0x40

0x41 - 0x4F

0x50 - 0x7F

* A video and audio stream which is not selected in the EPG (or equivalent) receiver menu and can only be played from datacasting content.

3-27―

ARIB TR-B15

Version 4.6-E1

The default component in datacasting programs is always the component with a tag value of 0x40. The entry component that sends the startup document at station selection is identified by this tag, not by entry_point_flag in the data encoding method descriptor. The entry component sends the entry module (moduleId=0), and the entry module must contain a startup document.

Multi-view programs sometimes have entry components for each sub-channel. Entry components are identified as follows:

The main channel (component group 0) entry component always has a tag value of 0x40.

Sub-channels other than the main channel (component group other than 0) have entry component tag values in the range 0x41 - 0x4F. The entry component for a given sub-channel may not be used as the non-entry component for another sub-channel in other words, a sub-channel may not have more than one component with a tag value in the range 0x40 - 0x4F.

Thus, sub-channel entry components have the lowest tag values among data components in the corresponding component group.

Entry components in hierarchical transmission are identified as follows:

Either the main and sub entry components or the corresponding components in the hierarchical transmission identifier are selected in accordance with the hierarchy during transmission.

In light of constraints on receiver hardware resources, the maximum number of ES per service (per PMT) is

12ES. (For example, one video, two audio, one subtitles and one for superimposed text brings the total to seven for multimedia data components.)

For multi-view operation, this constraint applies to each component group defined in the component group descriptor. In hierarchical transmission, this constraint applies to the components in each layer (used at high level and low level).

5.1.2.6 Section datacasting rules

Multi-section transmission (two or more sections per TS packet) is not permitted in data carousel and event message transmission.

Bit rates for transmission of section data in data carousels and event messages are subject to the following limits:

- No more than five TS packets may be sent in succession in a single PID.

- The components (maximum 4 PIDs, refer to 5.3.6.3) that are received at the same time as the content have a total bit rate of up to 4Mbps, including DII, DDB and event messages.

- In addition, the maximum bit rate per sub-table is 2Mbps (8KB

±100% per 32 milliseconds).

- If the transmission exceeds these limits, the section reception may become less efficient or may be interrupted altogether, depending on the receiver.

5.1.2.7 Default maximum bit rate for datacasting programs

Refer to Section 7.

3-28―

ARIB TR-B15

Version 4.6-E1

5.1.2.8 Audio and video components in datacasting services

For the purpose of clarity, audio and video streams in a PMT are classified as follows.

Television audio and video: audio and video streams as defined in Section 7, which can be played by EPG (or equivalent) and switched using the audio/video buttons. The component_tag values are 0x00 - 0x0F for video and 0x10 - 0x2F for audio. When an event containing the stream is selected, the audio and video is played by

EPG (or equivalent). Television audio and video is sometimes used in independent data programs.

Datacasting audio and video: audio and video streams which are viewed/played exclusively from datacasting content, with component_tag values in the range 0x50 - 0x7F. These are not played using EPG (or equivalent), and switching using audio/video buttons (or equivalent) is not featured.

Data-enriched and independent television programs can view AV streams either by specifying the component_tag value directly (hereafter "direct tag specification") or by specifying -1 for component_tag and viewing the stream selected by EPG (hereafter "default specification").

The default specification method is normally used to view television audio and video components from datacasting content, as per the models presented in ARIB STD-B24 Section 2, Description 2, "Audio

Playback Control". However, direct tag specification is also permitted in the following cases to prevent potential conflicts between the datacasting content specification and a television audio/video switching operation using the remote control keys or other receiver function.

1. Where the event contains only one television video component, it can be viewed via direct tag specification.

2. Where the event contains only one television audio component which is not dual mono, it can be accessed via direct tag specification.

The following operational restrictions apply in relation to the above.

1. Default specification only at activation of startup documents for data-enriched television programs and independent data programs featuring television audio and video. This is to prevent the datacasting engine from switching audio/video that is already being played by the EPG (or equivalent) at the commencement of presentation of the startup document.

2. Viewing television audio and video from datacasting content in a multi-view program is by default specification only, since television audio/video contains multiple components. video when playing an audio/video selected via direct tag specification. For dual mono television audio, only default specification may be used. The selection status of the dual mono television audio in this case is receiver dependent. Where necessary, the channel ID is also specified.

3-29―

ARIB TR-B15

Version 4.6-E1

Related receiver operations are described below:

1. The receiver uses EPG (or equivalent) to play audio and video at station selection from independent data programs containing television audio and video, in the same way as data-enriched television programs.

2. Where only one television audio selection is available, the receiver will not perform audio switching when the audio button is pressed. The same applies to television video.

3. When the datacasting engine finishes, the default television audio and video is played. If the datacasting content does not switch the audio and video by direct tag specification (default specification only), the audio and video component being played at this time will continue.

5.1.3 Series reservation of datacasting services

For details of the series reservation from multimedia content, refer to 8.9.

5.1.4 PMT specific to datacasting service usage

For details of the receiver operations at station selection and PMT updating, refer to 5.1.12.3 and

5.1.12.6.

There are only three types of components that can be stated in PMT without having an ES:

Subtitle components

Superimposed text components

Components used to transmit only event messages

5.1.5 PMT data encoding method descriptors usage

Data encoding method descriptors are used only in these components:

Components used to transmit subtitles and/or superimposed text

For more information about data encoding method descriptors used in subtitle and superimposed text components, refer to Chapter 7 on subtitles and superimposed text

Components used to transmit data carousels

Data encoding method descriptors are not used in any other components.

Table 5-4 lists data encoding method descriptors.

3-30―

ARIB TR-B15

Version 4.6-E1 use_xml default_version_flag independent_flag style_for_tv_flag bml_major_version, bml_minor_version ondemand_retrieval_fla g file_storable_flag

Table 5-4 Usage of data encoding method descriptors

Flag data_component_id 0x0007 additional_data_component_info(additional_arib_bxml_info())

Details transmission_format 00 (format for data carousel transmission and event message transmission). entry_point_flag auto_start_flag

Always 1 only in components with component_tag=0x40.

(When a datacasting program is selected, components with component_tag=0x40 transmit the module containing the first document to be activated.) 0 for other components.

At station selection, the receiver obtains and presents the startup document for the data carousel transmitted by the component with component_tag=0x40.

Used. Viewed by the receiver only at station selection. When auto_start_flag=0, the viewer must press the data button to activate the datacasting engine for a datacasting program. When auto_start_flag=1, the receiver activates the datacasting engine immediately. For independent data programs, auto_start_flag is always 1. document_resolution Indicates the BML content resolution and aspect ratio. Uses the following three parameters only:

0011: 960

×540

0100: 720

×480(16:9)

0101: 720

×480(4:3)

For details of the datacasting program resolution and aspect ratio control, refer to 5.1.12.5.

Value is 0 (XML using application-dependent tags not sent). bml_major_version / bml_minor_version can be omitted when this flag is 1

(using default value for version number). This will be interpreted as bml_major_version=1, bml_minor_version=0 (receivable in the basic receiver unit configuration).

As per the specifications. Value is 1 if the content transmitted in the event can be viewed independently, or 0 otherwise. A basic receiver unit without storage function does not need to reference this flag.

As per the specifications. When this flag is 0 (style is not formatted for television; content cannot be laid out on television receiver), the basic receiver unit will conclude that it cannot be displayed.

As per the specifications.

Where these fields are provided and bml_major_version = 1, the basic receiver unit will deduce that it can be viewed.

As per the specifications. Flag value is 1 when the content transmitted with the component can be viewed in real time, or 0 otherwise.

Always 1 for data-enriched television program entry component.

In a basic receiver unit with no storage function, a flag value of 1 means viewable and any other value means it is not viewable.

Indicates whether the content is storable.

A flag value of 0 indicates that the content is not storable.

Such as local content that can change during an event or content that the commissioning broadcaster does not want stored. A basic receiver unit without storage function does not need to reference this flag. additional_arib_carousel_info() data_event_id Not used in PMT. Value is fixed at 0xF(1111).

3-31―

ARIB TR-B15

Version 4.6-E1

5.1.6 PMT region descriptor usage

The region descriptor is sometimes used for multimedia datacasting services and superimposed text, but not in subtitles.

Where a multimedia datacasting service is subject to regional restrictions, region descriptors are applied to all the multimedia data components of the relevant event(s). Region restrictions are not applied to individual multimedia data components.

Where a multimedia datacasting service is subject to regional restrictions, the same region descriptor is applied to all components of the service.

Where superimposed text is subject to regional restrictions, region descriptors are used in the relevant

• components.

Thus, region descriptors are not used in the 1 st

loop.

Region description formats is 0x01 (BS digital prefecture specification) only.

Where region descriptors exist, the receiver operation is as follows:

Ideally, if the components of the multimedia datacasting service to be displayed region have region descriptors that do not include the receiver's region information, the datacasting service for the relevant event should not commence. In this case the receiver notifies the viewer of a multimedia datacasting service outside the designated region.

Where superimposed text components have region descriptors that do not include the receiver's region information, the superimposed text is not displayed. There is no need to inform the viewer.

In all cases, if region information has not been set for the receiver, viewing restrictions do not apply.

In addition, 5.1.12.9 describes the EPG display when region descriptors exist.

5.1.7 p/f EIT data content descriptors usage

For details of the data content descriptors for subtitles and superimposed text, refer to Chapter 7.

There may be more than one data content descriptor per event.

Some multimedia datacasting service events have no data content descriptors.

Not all broadcast content has data content descriptors.

The maximum number of data content descriptors in an event is 32.

Table 5-5 describes p/f EIT data content descriptors, while Figure 5-2 shows the content and ES structure.

Field entry_component num_of_component_ref component_ref

Table 5-5 Usage of data content descriptors

Details

Specifies the component containing the startup module for the relevant local content.

Not referenced, since the receiver has no use for num_of_component_ref for the schedule EIT.

States the components used to transmit carousels other than the entry carousel, the relevant audio and video streams, and the component used to transmit the event message. p/f EIT is treated as containing the confirmed value. The receiver does not

3-32―

ARIB TR-B15

Version 4.6-E1

Field Details

ISO_639_language_code text_length need to reference this field in the schedule EIT for a video viewing or recording reservation. The p/f EIT value is used for execution.

„ Chapter 9 details the operation for a storage reservation.

Fixed at jpn (Japanese).

Maximum value is 80 (bytes). A minimum of 40 bytes is displayed by the receiver as the content title.

States the title of the content displayed on EPG. text_char arib_bxml_info() transmission_format document_resolution

00 (data carousel and/or event message transmission specification). auto_start_flag EIT is not used. Value is always 0.

Indicates the content resolution and aspect ratio. Uses the following three parameters only:

0011: 960

×540

0100: 720

×480(16:9)

0101: 720

×480(4:3)

For details of the datacasting program resolution and aspect ratio control, refer to 5.1.12.5. use_xml default_version_flag

Value is 0 (XML using application-dependent tags not sent). bml_major_version / bml_minor_version can be omitted when this flag is 1

(using default value for version number). This will be interpreted as bml_major_version=1, bml_minor_version=0 (receivable in the basic receiver unit configuration). independent_flag content_id_flag associated_contents_flag style_for_tv_flag update_flag

ISO_639_language_code content_id content_version

As per the specifications. Value is 1 if the content transmitted in the event can be viewed independently, or 0 otherwise. A basic receiver unit without storage function does not need to reference this flag.

As per the specifications. If the descriptor contains content_id and content_version, the flag value is 1; otherwise it is 0.

As per the specifications. When the receiver displays notification on the EPG

(or equivalent) of datacasting in conjunction with a television program, it is performed only for events with data content descriptors with 1 specified for this flag.

As per the specifications. When this flag is 0 (style is not formatted for television; content cannot be laid out on television receiver), the basic receiver unit will conclude that it cannot be displayed. update_flag is not used. Always 0.

As per the specifications. bml_major_version, bml_minor_version ondemand_retrieval_flag

As per the specifications. content_version is used. Note that content_version does not change during an event.

As per the specifications.

Where these field are included and bml_major_version = 1, the basic receiver unit concludes that it is viewable.

As per the specifications. A flag value of 1 indicates that the content sent in the current component can be viewed in real time; otherwise, the flag value is 0.

The flag value is always 1 for the entry component of a data-enriched television program.

In a basic receiver unit with no storage function, a flag value of 1 means viewable and any other value means it is not viewable.

3-33―

ARIB TR-B15

Version 4.6-E1

Field file_storable_flag arib_carousel_info() num_of_carousels component_tag component_size_flag default_transaction_id_ flag default_timeoutDII_flag default_leak_rate_flag component_size timeout_value_DII leak_rate

Details

Indicates whether the content is storable.

A flag value of 0 indicates that the content is not storable.

Such as local content that can change during an event or content that the commissioning broadcaster does not want stored. A basic receiver unit without storage function does not need to reference this flag.

When num_of_carousels=0, this means that all subsequent carousel information is undefined and p/f EIT will contain confirmed information

(num_of_carousels is not 0). This value is not referenced for viewing and recording reservations.

„ Where num_of_carousels=0 is used in schedule EIT, storage reservation is not permitted.

As per the specifications. Where content is selected from EPG (or equivalent), the startup document is obtained/presented from the component specified in this tag value.

As per the specifications. Where the component_size field is not used (for instance, due to lack of confirmation), the value is 0.

Flag value is 0 (transaction_id not encoded). Thus, transaction_id is not used in this descriptor, and any DII with transaction identifier may be obtained.

As per the specifications. In certain cases, the flag value is 0 and the timeout_value_DII field is not used.

Flag value is 0 (leak_rate field not used). 5.1.2.6 provides more information about the data carousel transmission rate without using leak_rate.

As per the specifications; where employed, the confirmed value is used.

Normally the confirmed value does not changed. Modifications that involve an increase in the value are not recognized. If usage is not confirmed, it may be omitted.

„ In this case, storage reservation operations are not permitted.

Where omitted, or if 0xFFFFFFFF (no timeout value recommended) is specified, it is assumed to be 5,000 milliseconds.

The commissioning broadcaster may choose to transmit DII at fixed cycles and use a fixed value for timeout_value_DII irrespective of the carousel length.

(Not used. For details of transmission rates of section data, refer to 5.1.2.6.)

3-34―

ARIB TR-B15

Version 4.6-E1

Data content descriptor entry_componentco mponent_ref1 component_ref2

Data ES

Audio ES1 referenced from data ES

Video ES1 referenced from data ES

Figure 5-2 Content and ES structure

5.1.8 schedule EIT data content descriptor usage

In schedule EIT, num_of_component_ref may contain unconfirmed values, so it is not referenced by the receiver.

In schedule EIT, num_of_carousel=0 may occur.

Component information to be used at storage execution is as per p/f EIT.

5.1.9 p/f EIT hyperlink descriptor usage

The basic receiver unit does not need to interpret hyperlink descriptors.

„ Receivers compatible with pre-stored linked data programs can interpret hyper_linkage_type=0x80(combined_prior_data) and 0x81(combined_posterior_stream) hyperlink descriptors as described in Chapter 9.

5.1.10 schedule EIT hyperlink descriptors usage

Refer to the next section in this document.

5.1.11 EIT unique to datacasting service usage

The data content descriptor contains information required for content selection and reservation. Note that not all programs providing datacasting services have data content descriptors.

Component information in data content descriptors is fixed for the duration of the event.

For details of different EITs sent for all SI and specific SI, refer to Section 4.

5.1.12 Associated receiver operations

5.1.12.1 Datacasting engine startup

When a datacasting program is selected, if auto_start_flag (can be specified for data-enriched television programs only) of the data encoding method descriptor in the PMT entry component

(component_tag=0x40) is 0, the datacasting engine is not activated immediately. Instead, the datacasting engine startup process commences when the viewer presses the data button. If auto_start_flag is 1, the

3-35―

ARIB TR-B15

Version 4.6-E1 datacasting engine is activated immediately without waiting for a button operation. The next section explains the procedure through to activation.

„ Chapter 9 describes receiver operations on receivers compatible with pre-stored linked data programs where such programs have been stored.

5.1.12.2 Receiver operation at start of datacasting program

Data transmission operation prerequisites

• data_event_id in the PMT data encoding method descriptor is fixed at (0xF) and is not used.

A component with component_tag=0x40 is an entry component; the data carousel sent in an entry component is called an entry carousel.

The entry component always exists, and PID does not change.

There is one entry component per event.

Basic receiver operations at channel selection (Guidelines)

1. Where ECM is specified in the PMT 1 st

loop, the corresponding process is performed. The following processing is conducted only when the program can be viewed by confirmation of the contract status.

2. Where the PMT 2 nd

loop contains television audio and video (television video: component_tag=0x00 –

0x0F, television audio: component_tag=0x10 – 0x2F), these are replayed.

3. The entry component (the component with component_tag=0x40) is identified from among the components in the PMT 2 nd

loop.

4. A data_component_id value of 0x0007 in the data encoding method descriptor for the entry component is taken to indicate a datacasting program using XML-based multimedia encoding method, and the following process is performed. If the receiver is not compatible with the data encoding system used, the datacasting service will not commence.

5. If the value of auto_start_flag in the entry component data encoding method descriptor is 1, the following process commences immediately. If the value is 0, the process commences when the viewer presses the data button.

6. The decisions involved in steps 7 through 10 below are used to determine whether to activate the datacasting engine.

7. The BML / B-XML version number specified in the data encoding method descriptor of the entry component is used to determine whether to display the data. Content is viewable if bml_major_version/bml_minor_version is omitted or if bml_major_version is 1, and not viewable otherwise. If the content is deemed to be not viewable, the datacasting service is not displayed.

8. Where the content is deemed to be not viewable based on the on-demand viewing permission information in the data encoding method descriptor of the entry component, the datacasting service is not displayed.

9. Where a receiver that is compatible with region designation in multimedia datacasting services deems

3-36―

ARIB TR-B15

Version 4.6-E1 that the region designated in the region descriptor of the entry component is outside the region information for the receiver, the datacasting service is not displayed and the viewer is notified via a suitable message. The wording and display format of the message is receiver dependent.

10. Where the 2 nd

loop ECM is specified in the entry component and charging is by flat fee with no contract, the datacasting service is not displayed.

11. Where the datacasting service is deemed to be suitable for display based on steps 7 through 10, the datacasting engine is activated and the entry component startup document is obtained and displayed.

12. After the datacasting engine has started up, if the entry component is found to be an empty carousel, the following operation is required. (For details of empty carousels, refer to 5.3.1.6.)

- If auto_start_flag=0, the engine startup process halts at the point where the entry carousel is found to be an empty carousel and the receiver waits for the viewer to press the data button (refer to step

5 above).

- If auto_start_flag=1, the receiver continues to monitor data event switching for the entry component, and obtains and displays the startup document at the point where data event switching occurs and the startup module appears.

Receiver operation for multi-view program component group (sub-channel) switching (Guidelines)

1. Component group switching does not change the datacasting display the document being displayed before switching is retained.

Receiver operation for content selection from EPG with viewing or viewing reservation (Guidelines)

1. EPG (or equivalent) presents the viewer with content candidates on the basis of the EIT data content descriptor. The on-demand viewing permission information in the data content descriptor is used to determine whether the datacasting program can be viewed on the receiver. If it cannot be viewed, a message to this effect is displayed, and the program is not made available for selection.

2. For a program currently being broadcast, viewing begins with the component specified in entry_component for the content selected by the viewer as the starting component. Thus, the receiver assesses the BML version, on-demand viewing permission information, region designation and restricted reception status for the component to determine whether it is viewable. If it is, the receiver obtains and displays the startup document.

3. To begin viewing a reserved program, the two steps described above are executed from the start time of the program.

5.1.12.3 Receiver operations at PMT update

Receiver operation when PMT update occurs while viewing a datacasting program:

Loss of component while viewing

3-37―

ARIB TR-B15

Version 4.6-E1

→ Currently displayed document is discarded, and the startup document for the entry carousel (or the entry carousel for the component group, when viewing a non-zero component group in a multi-view program) is displayed.

Select station

PMT update

Entry component

:

Component being viewed

Other component

Lost

Component switching

Figure 5-3 Loss of component due to PMT update while viewing

Loss of entry component

→ Since it is no longer a datacasting program, the datacasting engine shuts down.

There is no need to track updates to the data encoding method descriptor (such as auto_start_flag).

5.1.12.4 Data button

The data button on the remote control has two uses as described below.

Activate datacasting engine

Used by the viewer to begin the datacasting service for a data-enriched television program without automatic startup (auto_start_flag=0 in the data encoding method descriptor for the entry component).

When such a program is selected, the receiver waits for the user to press the data button before activating the datacasting engine.

Content control after datacasting engine starts up

Once the datacasting engine is activated, a press of the data button is processed by the datacasting engine. It can be obtained as an interrupt event (with type attribute "DataButtonPressed") as required for the BML document. The processing response when the data button is pressed is described in the form of multimedia content. Note that the data button is normally used as an display on/off toggle for the datacasting service associated with the television program being viewed, which represents a content production restriction.

For these reasons, it is not feasible to use the data button to force quit the datacasting engine. This could be achieved by a receiver dependent means, such as a different receiver function or a button on the remote control.

The following uses for the data button are envisaged.

3-38―

ARIB TR-B15

Version 4.6-E1

(Example 1)

To begin displaying datacasting service content after the viewer pushes the data button (instead of having content displayed automatically immediately after station selection)

1. Set the value of auto_start_flag in the entry component data encoding method descriptor to 0.

2. The datacasting engine is not activated immediately when a data-enriched television program is selected.

3. The receiver activates the datacasting engine when the data button is pressed. The startup document is obtained and displayed when the datacasting engine starts up.

4. The startup document is used to display multimedia content menus and other information, and to begin the datacasting service.

5. A press of the data button during a datacasting service is relayed to the multimedia content. Content control then is used to either delete all text and diagrams or switch to icon display (or equivalent).

6. If another press of the data button is detected, content control reverts to the datacasting service display prior to deletion.

(Example 2)

To display content directly after selecting a datacasting service

1. Set the value of auto_start_flag in the entry component data encoding method descriptor to 1.

2. The datacasting engine is activated when a datacasting program is selected, and the startup document is obtained and displayed.

3. The startup document is used to display multimedia content menus and other information, and to begin the datacasting service.

4. Subsequent processing is as per step 5 onwards in Example 1 above.

(Example 3)

To activate the datacasting engine immediately after station selection without displaying the datacasting service content on the screen

1. Set the value of auto_start_flag in the entry component data encoding method descriptor to 1.

2. The datacasting engine is activated when a datacasting program is selected, and the startup document is obtained and displayed.

3. In the default status of the startup document, full-size television audio and video is presented, and the receiver waits for the data button to be pressed.

4. When the data button is pressed, content control displays multimedia content menu and other information, and starts displaying the datacasting service.

5. Subsequent processing is as per step 5 onwards in Example 1 above.

3-39―

ARIB TR-B15

Version 4.6-E1

5.1.12.5 Resolution and aspect control of datacasting programs

The receiver sets the resolution and aspect control based on the information provided by document_resolution in the BML document, as opposed to document_resolution in the PMT data encoding method descriptor or the EIT data content descriptor. In datacasting programs involving video, the aspect ratio of the video is normally the same as the aspect ratio stipulated in document_resolution. In the event of a discrepancy (for instance, in a news flash video), the combined display of the video and the datacasting service should continue as before. However the display format is receiver dependent.

5.1.12.6 Receiver operation at station selection

Table 5-6 lists receiver operations at station selection.

The datacasting program is deemed viewable based on the BML version, region designation and restricted reception status.

„ Chapter 9 provides more information about receiver operations on receivers compatible with pre-stored linked data programs.

Selection method

Remote control channel selection

Selection from EPG

(current broadcast program)

Viewing reservation

Table 5-6 Receiver operations at station selection

Selection Receiver operation operation

Data-enriched television program selected

Independent data program selected

If auto_start_flag=1, the receiver starts displaying the startup document for the entry component of the relevant event. If auto_start_flag=0, the receiver waits for the data button to be pressed before displaying the startup document.

The selected independent data program is activated.

The program is not activated if the PMT on-demand viewing permission information precludes real-time viewing. A notification message is displayed for the prescribed period.

Program selection by specifying content

The specified content is activated.

When displaying the content title, a minimum of 40 bytes must be shown.

The content is not selected if the EIT on-demand viewing permission information precludes real-time viewing, and a notification message to this effect is displayed.

As for channel selection

5.1.12.7 Datacasting program reservation operations (Guidelines)

Setting a viewing reservation

As with ordinary programs that do not involve datacasting services, the event viewing start time and other details are reserved. Where the schedule EIT at the reservation time contains a data content descriptor, the following functionality can be provided to the viewer.

This setting ensures that the selected content is displayed first when the reservation is executed, rather than the PMT entry component.

3-40―

ARIB TR-B15

Version 4.6-E1

Video recording reservation

The required event bit rates for recording media mode selection and bandwidth allocation are determined as described in 5.1.2.7. All other considerations are as per a viewing reservation.

Execution of viewing or recording reservation

The datacasting display and video recording based on PMT commence at the start time of the reserved event. If content is not specified in the viewing reservation then the entry component startup document is displayed; if content has been specified, then the startup document for the specified content is displayed.

5.1.12.8 Partial transport stream input/output

Where the receiver outputs data components (those with component tag value in the range 0x40 - 0x7F) to the partial transport stream, these must be matched to the descriptors listed in Table 5-7 below. (As per the provisions of Section 2.)

Name

Table 5-7 Descriptors output to partial TS

Data encoding method descriptor

Data content descriptor

Broadcast ID descriptor

Hyperlink descriptor

Table described

PMT 2

SIT 2 nd

SIT 2 nd nd

loop

loop

SIT 2 nd

loop

loop

Required/optional

Required

Required

Required

Optional

When playing multimedia content with the partial transport stream as the input source, operations for functions that require the use of SI information which is not included in the partial transport stream shall be receiver dependent. For example, the broadcasting-use extended functions described below.

- EPG functions: station select (epgTune), reservation (epgReserve, epgRecReserve)

- Operation control functions: check whether broadcast is in progress or not (isBeingBroadcast)

5.1.12.9 Preferred EPG display format

The data program display may be combined with the radio and television listings, or a dedicated data program EPG may be provided. The choice of implementation is receiver dependent.

Table 5-8 shows the preferred EPG display format for datacasting services.

„ Chapter 9 describes the EPG display format for receivers compatible with pre-stored linked and independent data programs.

3-41―

ARIB TR-B15

Version 4.6-E1

Display indicating presence of associated datacasting service

EPG display when region designation applies to the program

CA data program/local content display

Table 5-8 Preferred EPG display format

Data-enriched program display

Based on associated_contents_flag in the EIT data content descriptor, the program table or station selection display indicates the presence of additional data associated with the television program.

EPG display not required. Region information should be displayed in an obvious location such as the title.

Indicates that program or local content is fee-paying.

When already purchased, this should be indicated in the display.

5.2 Independent PES transmission specification usage

Chapter 7 describes the broadcasting format for subtitles and superimposed text.

Independent PES broadcasting is not used for other components.

Up to 256 modules can be transmitted per data carousel.

The module structure of a data carousel may change during the course of an event (i.e., the number of modules may fluctuate). In this case, the DII version is updated.

The interval between transmission of modules in the data carousel may vary depending on the type of module.

The concept of a data event with no direct chronological relationship with the event is used as a means of allowing content switching at any time, both within and between programs. The content display is switched with each new data event. Content transmitted within a single data event is known as local content (refer to Figure 5-5).

Data events are identified from data_event_id in DII.

5.3.1.2 Data events usage

• data_event_id is updated when the local content switches. This means that data_event_id will be different after a local content switch, and may not necessarily increase by 1. (Refer to Figure 5-4.)

• data_event_id is not always updated when ES stops (i.e., when the component description from PMT is lost). ES starting signifies that new local content has commenced. There is no need for the receiver to store data_event_id prior to ES stopping. (Refer to Figure 5-4.)

A separate data_event_id is administered and updated for each component. The data_event_id value cannot be 15(0xF).

3-42―

ARIB TR-B15

Version 4.6-E1

(data_event_id) loc. content loc. content loc. content Paused loc. content

1

Figure 5-4 Local content and data_event_id

5.3.1.3 Local content activation and termination

An update in DII data_event_id is taken to indicate that local content has switched. The document currently being displayed is discarded, and a new local content startup document is obtained and displayed. (Refer to 5.3.1.7.)

Activation and termination of local content is normally performed in conjunction with data_event_id update in the DII of the carousel currently being viewed.

In certain situations it may be necessary to forcibly shift control to the entry local content in synch with local content switching for the entry component, irrespective of the type of local content being viewed.

To this end, a flag (return to entry flag: return_to_entry_flag) is provided in order to notify the entry carousel DII private information area. The receiver monitors this flag, irrespective of the type of component local content on display.

The return to entry flag is not used in DII for data carousels transmitted in components other than the entry component.

5.3.1.5 Local content and data content descriptors

„ If there is no local content switching for the duration of the event and the local content transmission period is the same as the event period (as per the definition provided in Chapter 9), the data content descriptor and the local content have one-to-one correspondence.

If multiple local content are transmitted during the event period, the data content descriptor provides information about the multiple local content as a whole.

3-43―

Data ES

(entry_ component)

Data event 1

DII data_event_id=1

DII

Event

Content

Data event 2

Local content 2 data_event_id=2

Data event 3

Local content 3

DII data_event_id=3

Time

Carousel 1

Carousel 2 Carousel 3 Carousel 4

DII data_event_id=1

DII_version=0

DII data_event_id=1

DII_version=1

DII data_event_id=1

DII_version=2

DII data_event_id=1

DII_version=3

Any module

moduleId=100 moduleVersion=0

Any module

moduleId =100 moduleVersion=1

Any module

moduleId=100 moduleVersion=2

Any module

moduleId=100 moduleVersion=3

・ If any module in the DII is updated (including module version update or change in the number of modules), the DII version will be updated.

・ An event break is not always accompanied by a data event break.

・ Where the transmission period of the local content is the same as the event period, the associated data content descriptor has one-to-one correspondence.

Figure 5-5 Data event and local content structure

- 3-44-

ARIB TR-B15

Version 4.6-E1

5.3.1.6 Empty carousels usage

An empty carousel is a data carousel with no DDB, where the numberOfModules field consists entirely of

DII with zeroes.

Empty carousels are used to switch between send/stop for component data without changing the ES description in the PMT, for instance, when a given component is required only for a particular period in an event.

Switching between empty and non-empty carousels also switches the data_event_id.

The rules for DII minimum transmission intervals (refer to 5.3.2) apply equally to empty carousels when they are transmitted.

DII version upgrades are not generated during transmission of an empty carousel.

At station selection (with auto_start_flag=1) and when an empty carousel is detected during data event switching, no error is generated but instead DII updating is monitored, and display of the startup document begins when the startup document first appears. For a data-enriched television program with auto_start_flag=0, if the entry component is an empty carousel at the point when the user presses the data button to activate the datacasting engine, the activation process is suspended and the device waits for the data button to be pressed again.

If the carousel containing the document currently being viewed during multimedia content display changes to an empty carousel, a data event message ("DataEventChanged" interrupt event, identified via status=1) indicating the "change to an empty carousel" is generated for the BML document. This operation is the same irrespective the value of auto_start_flag and whether or not it is an entry component.

Where an empty carousel is referenced but not in connection with station selection or data event switching for instance, via execution of a link between BML documents this results in an error equivalent to that which is generated when an ordinary carousel does not contain a reference module.

5.3.1.7 Basic receiver operations during datacasting program display

The receiver continuously monitors the carousel DIIs of the following two components:

1. Component DII containing the module being viewed

2. Entry component DII.

The entry component DII is monitored in order to determine the timing for a forced return to the entry carousel in conjunction with local content switching for the entry component.

Receiver response to data event switching on the component being viewed

The datacasting engine generates the "DataEventChanged" data event message for the document currently on display. It then discards the document, and obtains and displays a startup document contained in the module with moduleId=0. If data event switching results in an empty carousel, then after the document currently on display has been discarded the relevant component DII update is monitored, and if the empty carousel is removed by subsequent data event switching, a startup document is obtained and displayed. All synchronous and asynchronous interrupt events that occur after "DataEventChanged" are discarded, except for unload interrupt events. Where the epgTune/launchDocument/reloadActiveDocument function is employed within the "DataEventChanged" event handler, the startup document is not obtained and the processing is in accordance with the function specification.

― 3-45―

ARIB TR-B15

Version 4.6-E1

If data_event_id of the entry component being monitored is updated while viewing any data component, the following processing occurs:

- If return_to_entry_flag=1 in entry component DII: returns to the entry component. The module currently on display is discarded and the startup document contained in the module with moduleId=0 in entry carousel is obtained and displayed (refer to Figure 5-6).

- If return_to_entry_flag=0 in entry component DII: current document remains on display (refer to

Figure 5-6).

- In both cases, if the entry component document is being viewed, then the receiver operation is as described in "Receiver response to data event switching on the component being viewed" above.

EC data event switching

Return = 0

Entry component EC

Return = 1

: Component currently displayed

Other components

Component switching via content control

Component switching via return to entry flag

Figure 5-6 Entry component data_event_id updating and the return to entry flag

5.3.2 DownloadInfoIndication (DII) message usage

DIIs for the current viewing carousel and the entry carousel must be received in order to display multimedia content.

Figure 5-5 shows the structure of the DII in relation to local content/data event.

Due to the limited processing power of the receiver, the constant minimum transmission interval for all component DIIs (except during carousel switching) is 100 millisecond.

DSMCC_section transmits DII as per the specifications.

No more than one DII message (i.e., one DSMCC_section sending DII) is permitted. Thus, dsmccAdaptationHeader() is not used.

Module information stored in the DII message is assumed to be stored in ascending order based on moduleId (note that moduleId may not be a continuous series).

Table 5-9 describes userNetworkMessage() usage.

Field dsmccMessageHeader() protocolDiscriminator dsmccType messageId

Table 5-9 Usage of DII:userNetworkMessage()

Usage

As per the specifications.

As per the specifications.

As per the specifications.

Remarks

0x11

0x03

0x1002

- 3-46-

Field transaction_id

Usage

As per the specifications.

Transaction Number (the lower 30bits in transaction_id) normally increments by 1 in the following cases:

Data event switching occurs

One or more of the modules in the carousel is updated

The number of modules in the carousel changes (including a change involving numberOfModules=0)

ARIB TR-B15

Version 4.6-E1

Remarks

A change in transaction_id does not necessarily cause contents_id in the EIT data content descriptor to be updated. downloadId blockSize windowSize ackPeriod tCDownloadWindow tCDownloadScenario compatibilityDescriptor()

As per the specifications. Updated after each data event switching. bit31-28 data_event_id bit27-0 all 1

Used for switching with local content identifier and for matching event messages to local content.

Fixed at 4066.

As per the specifications.

As per the specifications.

As per the specifications.

Used. Describes the module in the carousel that has the longest transmission cycle.

As per the specifications when contents inserted but not used. data_event_id is used to switch data events, and also to prevent reception of incorrect event messages for chronologically adjacent local content.

4066

0

0

0

The timeout setting based on this value is receiver dependent.

CompatibilityDescriptorL ength=2

DescriptorCount=0 numberOfModules moduleId, moduleVersion moduleSize

Maximum 256 modules sent per data carousel. numberOfModules=0 may be used to indicate an empty carousel. For details of empty carousel, refer to 5.3.1.6.

As per the specifications.

Maximum module size is 1MB. For details, refer to 5.3.3.

Contains descriptors listed below. Module information area

Private data area The DII sent in the entry component of the event (tag value = 0x40) may contain arib_bxml_private_data_descriptor() as per the specifications. DIIs sent in other components do not contain this descriptor.

Where (1) the entry carousel data event switches and (2) the descriptor exists and

(3) return_to_entry_flag is 1, the receiver will discard the document currently being viewed and display the startup document for the entry carousel.

Refer to 5.3.1.4.

Descriptors stored in the module information area

Type descriptor Required for direct mapping of one resource to one module. Not required for modules where resources are stored in entity format.

Descriptor_tag

0xF0 descriptor_length

1

― 3-47―

ARIB TR-B15

Version 4.6-E1

Field

Name descriptor

Info descriptor

Module_Link descriptor

CRC descriptor

Estimated download time descriptor

Expire descriptor

ActivationTime descriptor

CompressionType descriptor

Usage

Not used.

Not used.

Not used.

Not used.

Occasionally used. Specifies the maximum transmission cycle of the corresponding module (where used).

Used.

Receiver operations when this descriptor is specified are detailed in 5.3.6.2.

Not used.

Module may be compressed for transmission. If so, this descriptor will be included; otherwise, it is not used.

For details of module compression, refer to

5.3.3.

Use of compression_type.

0: modules compressed in zlib format.

Not used.

Remarks

Implementation is optional on a basic receiver unit.

Control descriptor In order to accommodate older receivers, this descriptor is not used for non BML1.0 content.

5.3.3 DownloadDataBlock (DDB) message usage

DSMCC_section sending DDB message is as per the specifications.

Modules used to transmit DDB messages can be up to 1MB in size. Strictly speaking, the module can have up to 256 DSMCC_section sending DDB. (The maximum module size is 4066x256=1040896 bytes.)

Modules may be compressed for transmission in zlib format, in which case the corresponding DII module information area contains the CompressionType descriptor, and compression_type = 0. Appendix 2 provides more details on compression formats.

The sum of the original module size and the compressed module size (where compression is used) must not exceed the maximum module size stated above.

Table 5-10 shows DDB(downloadDataMessage())usage.

Field dsmcType messageId downloadId

Table 5-10 Usage of DDB:downloadDataMessage()

Usage dsmccDownloadDataHeader() protocolDiscriminator As per the specifications.

As per the specifications.

As per the specifications.

As per the specifications.

Remarks

0x11

0x03

0x1003

Stores same value as DII downloaded.

0 dsmccAdaptationHeader() is not used. moduleId moduleVersion blockNumber

No rules regarding moduleId value.

Used.

As per the specifications.

There is no guarantee that updating will increase the value by 1.

Value determined by

ModuleSize/blockSize.

- 3-48-

ARIB TR-B15

Version 4.6-E1

5.3.4 Event messages usage

5.3.4.1 Purpose of event messages

An event message containing a general-purpose event message descriptor (hereafter "general-purpose event message") can be used to generate an asynchronous or time-designated multimedia content interrupt event and send the data associated with the event.

If NPT is used to designate the time in a general-purpose event message, or if NPT is used in the multimedia content, an event message containing an NPT reference descriptor (hereafter "NPT reference message") is used to notify the receiver of the respective functions of NPT and STC.

Purpose of NPT

- Used to designate time in a way that does not need to be modified or re-compiled in the event of a program time shift caused by, for instance, a baseball game running overtime or a news flash. (Not compatible with relative time from program start or MJD)

- Used in the same way in the event of a change in CM duration during a repeat broadcast. (Not compatible with relative time from program start or MJD)

- When timing accuracy of 0.1 second is required, for instance, in quiz programs. (This level of accuracy not provided in relative time from program start or MJD)

- When time axis is required for stored content. (Not compatible with relative time from program start or MJD)

5.3.4.2 Transmission of event messages

A general-purpose event message may be transmitted via the component that transmits the local content that uses the message, or by another component.

NPT reference messages may be sent by multiple components for a single event.

NPT reference messages are not sent in the same component as a data carousel.

The event_section_flag in the PMT data encoding descriptor and EIT data content descriptor is not used.

The value is always 1.

DSMCC_section that transmits event messages contains either a general-purpose event message descriptor or an NPT reference descriptor but not both.

• last_section_number in DSMCC_section that transmits event messages is always 0. Thus, a sub-table that transmits one event message always does so in 1 section.

5.3.4.3 Transmission of general-purpose event messages

From the BML document, it is possible to use either a general-purpose event message transmitted in the same component as the local content that transmits the document or a general-purpose event message transmitted in a different component. Thus, only one type of general-purpose event message

• component_tag can be specified per BML document.

Identification from event_msg_group_id is not used. event_msg_group_id is always 0x000.

• private_data_byte is used.

To prevent reception of incorrect general-purpose event messages between chronologically adjacent local content, the data_event_id in the general-purpose event message has the same value as the data_event_id in the relevant local content. This applies also when the general-purpose event message is transmitted via a different component to the corresponding one with the local content.

― 3-49―

ARIB TR-B15

Version 4.6-E1

Each DSMCC_section can have up to 8 general-purpose event message descriptors.

If message_id is set to 255, or if message_id is omitted and the setting is for any message_id, a specific message_id (0 – 254) cannot be designated at the same time, and message_version must be either omitted

(or set to 255).

Where message_id is shown, the maximum number of general-purpose event messages that can be subscribed to at the same time is 8.

The same sub-table may be sent more than once for a general-purpose event message to prevent accidental omission. There are no rules or requirements regarding the number of transmissions or the intervals between transmissions.

To prevent accidental omissions, the update interval for DSMCC_section that transmit general-purpose event messages within the same ES should be no less than 100ms. This represents the recommended value for the interval between the first DSMCC_section for any version and the DSMCC_section for the next updated version. It has no bearing on the transmission interval between DSMCC_section for adjacent (but different) versions at the point of updating.

When sending an NPT designated general-purpose event message, the ignition time cannot be prior to the transmission time for the STCmax reference message (described below). NTP designated general-purpose event messages are not sent during the period from transmission of the STCmax reference message through to transmission of the first NPT reference message after STC0 circulation.

5.3.4.4 Transmission of NPT reference messages

The table_id_extension in the DSMCC_section in an NPT reference message is fixed at 0xFFFF

(event_msg_group_id=0xFFF, data_event_id=0xF). event_msg_group_id=0xFFF is used only for NPT reference messages.

The transmission interval for NPT reference messages is 1 second, as per the specifications. The constant minimum update interval for NPT reference messages is 5 seconds.

NPT step changes are notified via an NPT reference message sent up to 2 seconds prior.

Up to 2 seconds before the STC does 0 circuits, the receiver is informed that NPT is undefined by means of an NPT reference message with STC_Reference=0x1FFFFFFFF and

NPT_Reference=<NPT-value-at-STC0-circuit> (hereafter STCmax reference message). The undefined state is released by sending an NPT reference message other than the STCmax reference message immediately after the STC0 circuit. The STCmax reference message is required for datacasting transmission at STC0 circuit and transmission of content that uses NPT functions in a data event (local content) at STC0 circuit.

In the event of STC discontinuity (including STC 0 circuit), an NPT reference message for the new STC should be sent as soon as possible.

There is no need to set the NPT value to circulate or be discontinuous during a data event.

Where NPT is used within multimedia content (for interrupt event ignition or getNPT), NPT reference message monitoring is explicitly stated in the multimedia content. (The type attribute is described in the form of an "NPTReferred" interrupt event.)

Figure 5-7 shows how NPT reference messages are transmitted.

- 3-50-

NPT

2

NPT reference message

NPTr=NPT

1

STCr=STC

1

Scale=1/1

NPTr=NPT

2

STCr=STC

2

Scale=0/1

Transmitted at one-second intervals during this period.

Update intervals are 5 seconds or more.

NPTr=NPT

2

STCr=STC

3

Scale=1/1

ARIB TR-B15

Version 4.6-E1

NPT

NPT

1

STC

1

Event start

A

NPT reference message

At least 2 sec

B

STC

2

C

At least 2 sec

D

NPT reference message

STC

3

E

Figure 5-7 Transmission of NPT reference messages

5.3.4.5 Event message processing by the receiver

1. General-purpose event messages

STC

Where the BML document contains an interrupt event with "EventMEssageFired" type attribute,

DSMCC_section that sends general-purpose messages is subject to filtering in accordance with the following conditions:

- component_tag specified in es_ref attribute

- event_msg_group_id=0x000

- data_event_id for currently displayed local content

If es_ref is omitted, it is interpreted as a component of the currently displayed local content.

When DSMCC_section is first obtained, or when a version upgrade for DSMCC_section is detected, a multimedia encoding system interrupt event is generated based on the event_msg_id for the general-purpose event message descriptors in the relevant DSMCC_section and the

• message_id/message_version specified in the BML document.

Time modes

The following time modes are used to specify the ignition time: 0x00 (immediate ignition) and 0x02 (NPT time).

The receiver generates a multimedia content interrupt event as soon as possible after the ignition time specified in the general-purpose event message (for time mode 0x00, the event message reception time).

The immediate ignition and NPT setting should both be around 100 milliseconds.

― 3-51―

ARIB TR-B15

Version 4.6-E1

If there are several general-purpose event messages with time mode 0 (immediate ignition), ignition is performed in the order in which the messages were received, with no restrictions on the processing timing.

The receiver can queue up to 8 general-purposes event messages awaiting ignition.

Where the acquisition target is several general-purpose event messages with immediate ignition specified transmitted in the same DSMCC_section, ignition is performed in the order of the descriptors in

DSMCC_section.

Where the designated NPT time has already expired at the time of reception, it is treated as immediate ignition.

The subscribe validity period in a general-purpose event message is the period stated in the document that specifies the subscribe.

Where the BML document contains an interrupt event with "NPTReferred" type attribute, DSMCC_section that sends NPT reference messages is subject to filtering in accordance with the following conditions:

- component_tag specified in es_ref attribute

- event_msg_group_id=0xFFF

- data_event_id=0xF

This interrupt event is generated only when the NPT reference message is first acquired. Interrupt events are not generated in response to subsequent version upgrades of the DSMCC_section that sends NPT reference messages.

The receiver treats the NPT value as being undefined if an STCmax reference message is received. When an NPT reference message other than an STCmax reference message is received, the NPT undefined status is released. If no STCmax reference message is sent, processing does not need to take account of STC discontinuity (including STC 0 circuits).

- If subscribing to NPT-specified TimerFired interrupt events at the point when the NPT status becomes undefined (i.e., when the STCmax reference message is received), interrupt events with status=-1

(error) are immediately generated for all.

- Similarly, if a new NPT-specified TimerFired interrupt event is subscribed while NPT is undefined, an interrupt event with status=-1 is immediately generated.

- If getNPT is executed while NPT is undefined, NaN is returned.

In the case of event message ignition or interrupt event ignition with specified NPT time, it is not necessary to take NPT step change and STC discontinuity into consideration. Thus, implementation can be by timer processing or equivalent.

The NPT value returned by getNPT corresponds to the NPT step change.

The receiver stores NPT_Reference(NPTr), STC_Reference(STCr) and scale for the last NPT reference message obtained. These are stored together as a set. When the NPT value is required, the NPT value at that point in time (NPTc) is calculated via the following algorithm, based on this information and the STC value obtained at that point in time (STCc).

- 3-52-

ARIB TR-B15

Version 4.6-E1

Algorithm used to calculate the NPT value if STCc

≥ STCr then if Scale = 1/1 then

NPTc := NPTr + (STCc – STCr) else // Scale = 0/1

// Corresponds to sections A and E in Figure 5-7 else // STCc < STCr if Scale = 1/1 then else // Scale = 0/1

NPTc := NPTr – (STCr – STCc) // Corresponds to section B in Figure 5-7 end if

If NPT related processing occurs in the period after the document is presented but before the first NPT reference message can be obtained (i.e., before the first "NPTReferred" interrupt event), the receiver operation shall be as follows:

- When a general-purpose event message specifying ignition at the NPT time is received: The message is ignored and monitoring of general-purpose event messages continues.

- NPT time specified interrupt event setting (bevent):

Interrupt event setting is not performed.

- GetNPT:

Returns error value.

The subscribe validity period in an NPT reference message is the period stated in the document that specifies the subscribe.

5.3.4.6 Usage of DSMCC_section()

Table 5-11 Usage of DSMCC_section() that sends event messages

Field table_id section_syntax_indicator private_indicator dsmcc_section_length data_event_id event_msg_group_id version_number

Usage

As per the specifications.

As per the specifications.

As per the specifications.

As per the specifications.

General-purpose event messages: same value as data_event_id for corresponding local content.

NPT reference messages: 0xF

General-purpose event messages: 0x0000

NPT reference messages: 0xFFF

+1 continuity guaranteed for the same sub-table identified by table_id, data_event_id and event_msg_group_id combination.

Remarks

0x3D

1

0

― 3-53―

ARIB TR-B15

Version 4.6-E1

5.3.4.7 Usage of general-purpose event message descriptors

time_mode

Table 5-12 Usage of general-purpose event message descriptors

Field event_msg_group_id

Usage

Same value as event_msg_group_id in DSMCC_section

(always 0x000).

Uses the following modes:

0x00: event ignited immediately upon reception

0x02: event ignited in accordance with NPT time data event_msg_id

(message_id, message_version) private_data_byte

As per the specifications.

As per the specifications.

5.3.4.8 Usage of NPT reference descriptors

Field postDiscontinuityIndicator dsm_contentID scaleNumerator/scaleDenomina tor

Table 5-13 Usage of NPT reference descriptors

Usage

Only 0 is used.

Not used (always 0).

Only "0/1" and "1/1" are used.

Remarks

Maximum

255 bytes

Remarks

Still picture transmission on video PES (a still picture carousel, used for interactive replay) is not used, so IIT is not used.

If a CM occurs during a datacasting program event, a datacasting service different to the main program may be performed (in which case the context prior to the CM may be reproduced after returning to the main program) or the datacasting service may be temporarily suspended.

There are no specific agreements on datacasting transmission operation support for these. Instead, this is implemented via content control using functions such as local content switching, event messages and information writing to NVRAM.

5.3.6.2 Expire descriptors (DII) and receiver operations

„ An Expire descriptor in the DII module information area indicates that the module has a designated validity period. The validity period specified in the descriptor can be used by a receiver with storage function when storing the module. Thus, the module must be stored in accordance with the validity period specified in the descriptor, which must be accessible.

„ Stored module receiver operation

Where the stored module is referenced and found to have a specified validity period, this is compared to the current time. If the validity period has expired, an error is returned for the reference. The module should ideally be deleted from the storage media at this point.

- 3-54-

ARIB TR-B15

Version 4.6-E1

5.3.6.3 Filtering resources for datacasting reception

Table 5-14 shows the maximum filtering resources that the receiver can use for datacasting reception (other than

SI/PSI reception). Note that these figures may be exceeded in certain receivers depending on the implementation philosophy.

Transmission operation prerequisites:

1. DII monitoring for both the carousel currently on display and the entry carousel (return to entry flag: refer to 5.3.1.4).

2. Module and resource referencing only for modules transmitted by the same component as that of the document currently on display except for module acquisition for document switching (refer to 8.7).

3. A general-purpose event message could potentially be transmitted in a component different to of the carousel currently on display. However, there is only one type of filtering sub-table for monitoring of general-purpose event messages. Thus, the required filtering resources are maximum PID filtering x 1 and section filtering x 1. The same applies to NPT reference messages (refer to 5.3.4).

Total

Table 5-14 Maximum filtering resources used to receive datacasting services

Purpose

(1) DII monitoring of carousel currently on display

(2) Return to flag (entry carousel DII) monitoring

(3) Module acquisition, lock in memory

(lockModuleOnMemory) or cache

(4) General-purpose event message monitoring

(5) NPT reference message monitoring

PID filtering Section filtering Remarks

1 1

1 1

0 1 component as (1)

1 1 simultaneously

1 1 simultaneously

4 5

5.4 Datacasting service fee structures

As per Section 5.

Subtitles/superimposed text are not charged for independently of the default ES group.

Station selection, component selection and program reservation from multimedia content may involve processes such as contract confirmation, service charging and viewing restrictions confirmation. These are performed by the receiver rather than the content.

5.5 Low-layer transmission of datacasting services

Data (including subtitles and superimposed text) can be transmitted at a low layer. That is, data can be transmitted only at a higher layer, at a lower layer, or via a combination of low and high layers.

Where low-layer data references television audio and/or video, the data employs a modulation system which is either the same as that of the television audio/video, or at a lower layer.

― 3-55―

ARIB TR-B15

Version 4.6-E1

Low-layer data that references low-layer video is treated as datacasting resolution content for low-layer video.

The layer transmission descriptor conforms to television audio layer transmission as described in Section 7.

When both high and low layer data components are transmitted, the description may be an n:1 structure, with multiple high layer components referencing one low-layer component.

Low-layer components of a multi-view program do not belong to any component group. Thus the receiver can switch to a lower-layer component during viewing of any sub-channel in the event of layer switching, provided that the referencing structure is described in the layer transmission descriptor.

Component switching by the receiver in response to layer switching is normally based on the referencing structure stated in the layer transmission descriptor, and the relevant startup document is displayed. It is also possible to have an implementation where the previously viewed high layer component or document is displayed when reverting from a low to a high layer. The relevant operations are receiver dependent, including error processing if the component or document does not exist after reversion.

Component switching with reference to the layer transmission descriptor is performed in the following cases. Whether or not BML documents for other components are referenced from the original BML document is receiver dependent.

(1) To identify the entry component (including DII monitored component) at station selection (including epgTune()).

(2) To activate content from EPG in accordance with the data content descriptor.

(3) To switch the viewing layer during content viewing.

(4) To perform an ES transition when the local ES is lost.

5.6 Multi-view operation and datacasting services

Data-enriched television programs can be transmitted when multi-view is on. Note that the same datacasting service applies to all component groups.

Combinations of audio, video and data are described using the component groups descriptor.

All component groups must contain the same datacasting components (the components used to transmit the data carousel or event message). Thus, when multi-view is on, all datacasting components must be present in all component groups.

Component group switching does not affect the datacasting display the document on display continues to be displayed after switching.

The maximum number of ES stipulated in 5.1.2.5 applies to each individual component group.

Low layer data, like television audio and video, does not belong to a component group.

The return to entry flag may be used during multi-view (refer to 5.3.1.7).

In some cases, the value of component_tag may be restricted to "-1" when referencing an AV stream from a

BML document in a multi-view program (refer to 5.1.2.8).

- 3-56-

ARIB TR-B15

Version 4.6-E1

5.7 Provisional channels and datacasting services

Provisional channels can broadcast data-enriched television programs.

Datacasting services provided on provisional channels in accordance with the requirements for data-enriched television programs.

As per Section 6.

― 3-57―

ARIB TR-B15

Version 4.6-E1

6.1.1.1 Constraints on encoding parameters

Table 6-1 Constraints on MPEG-1 Video encoding parameters

Constraints on Sequence Header vertical_size horizontal_size pel_aspect_ratio picture_rate

Other parameters

240 352

6, 12 4 constrained parameters' conditions

120 176

Meanings of MPEG-1 Video encoding parameters' code numbers in Table 6-1

pel_aspect_ratio 6= 16:9 display (525lines), 12= 4:3 display (525lines)

picture_rate 4 = 30/1.001 Hz

6.1.1.2 Playback in synchronization with sound (MPEG-2 AAC)

Synchronized playback of MPEG-1, which is transported through an image PES, and MPEG-2 AAC, which is transported through a PES, shall be made possible.

MPEG-1 Video shall be transported through an image PES (stream format identification 0x01).

Shall be compliant with the specifications of Section 7, 4.1 "Video" MPEG-2 Video.

- 3-58-

ARIB TR-B15

Version 4.6-E1

6.1.2.1 Constraints on encoding parameters

Table 6-2 Constraints on MPEG-2 Video encoding parameters

Constraints on encoding parameters

Constraints on Sequence Header

Constraints on Sequence extension

Constraints on Sequence display extension vertical_ size_value

1080 horizontal_ size_ value

1440,

1920 aspect_ ratio_ information frame_ rate_ code progressive_ sequence

3 4 0 colour_ primaries transfer_ characteristics matrix_ coefficients

720 1280 3 7

480 720 3 7 1

480

480,

544,720

240 352

2, 3 4

1

0

1

Other parameters

Value specified for

[email protected]

Value specified for

1 1 1

Value specified for

[email protected]

Value specified for

[email protected]

Meanings of MPEG-2 Video encoding parameters' code numbers in Table 6-2 aspect_ratio_information 1= Square pixel, 2= 4:3 display, 3= 16:9 display frame_rate_code progressive_sequence colour_primaries

4 = 30/1.001 Hz,

0= Interlaced scanning,

7 = 60/1.001 Hz

1= Progressive scanning

1= Value specified in Rec.ITU-R BT.709(BT.1361) matrix_coefficients 1= Value specified in Rec.ITU-R BT.709(BT.1361)

MPEG-2 Video shall be transported through an image PES (stream format identification 0x02).

The scalings, 256/128, 192/128, and 160/128, shall apply to [email protected] only.

Encoding methods using MPEG-4 Video shall be optional.

― 3-59―

ARIB TR-B15

Version 4.6-E1

6.2 Still picture and bitmap pattern encoding

6.2.1 MPEG-2 I frames

6.2.1.1 Constraints on encoding parameters

vertical_ size_value

Table 6-3 Constraints on MPEG-2 I frame

Constraints on Sequence Header

Constraints on

Sequence extension

Constraints on Sequence display extension horizontal_ size_value aspect_ ratio_ information frame_(

Note2) rate_code progressive_ sequence low_ delay colour_ primaries transfer_ characteristics matrix_ coefficients

1080

(Note 1)

1920

480 720

3

2, 3

4

4

(Note 3)

0

(Note 3)

Other

(Note 5) parameters

Value specified for

[email protected]

Value

1 1 1

[email protected]

Value specified for

[email protected]

Meanings of MPEG-2 I frame encoding parameters' code numbers in Table 6-3 aspect_ratio_information frame_rate_code progressive_sequence low_delay colour_primaries

Transfer_characteristics matrix_coefficients

1= Square pixel,

4 = 30/1.001 Hz,

0= Interlaced scanning,

2= 4:3 display, 3= 16:9 display

7 = 60/1.001 Hz

1= Progressive scanning

1= Does not include B-pictures

1 = Rec.ITU-R BT.709(BT.1361)

1 = Rec.ITU-R BT.709(BT.1361)

1 = Rec.ITU-R BT.709(BT.1361)

(Note 1) In MPEG-2 Encoding (ITU-T H.262), 1,088 lines are actually encoded. In fact, data of 1,088 video lines is encoded by adding blank data of 8 video lines (dummy data) under the active lines using the encoder. Out of the 1,088 video lines, the decoder outputs 1,080 from the top, i.e. 1,080 active lines excluding dummy data, as video signals.

(Note 2) The decode and display timing shall be controlled by a timestamp value in the PES header, and the vbv_delay value shall be 0xFFFF.

(Note 3) When progressive_frame=0 (a timing difference exists between 2 fields in a frame due to interlaced scanning), the display of a field's frozen image is preferable, and when progressive_frame=1 (the timings of 2 fields are the same), the display of a frame's frozen image is preferable.

(Note 4) When low_delay=1, the decode and display timestamp values shall be the same (DTS=PTS). Only

PTS timestamps shall be added to still picture I frames.

(Note 5) When sequence_display_extension is not transported, values for color_primaries, transfer_characteristics, and matrix_coefficients shall be processed as equivalent to "1" on the receive side. For values such as vbv_buffer_size_value, ones that are specified by ISO/IEC 13818-2 for each level of Main Profile shall be adopted. However, regarding the bit_rate_value, its maximum value for each level shall be adopted, such as 4Mbps for [email protected], 15Mbps for [email protected], and the maximum transportable rate in BS digital broadcasting for [email protected] and [email protected]

- 3-60-

ARIB TR-B15

Version 4.6-E1

Scaling shall not be performed.

MPEG-I shall be transported through an image PES (stream format identification 0x02).

MPEG-I and moving pictures (MPEG-1, MPEG-2) shall not be presented simultaneously.

6.2.2 JPEG

Shall be compliant with the BaseLine method, ISO/IEC 10918-1(ITU-T T.81). ARIB STD-B24 Section 1, Part 1,

7.2 "Colorimetry" shall be applied to JPEG colorimetry.

Encoding sequence: The interleave method shall be applied.

Not loss-free baseline method.

Sampling factor: Shall be YCBCR=4:2:0. Even when receiving data in 4:2:2 format, however, sampling shall not fail. Note that JPEG in 4:2:0 refers to JPEG data in which the values for SOF0 marker information (H1,V1),

(H2,V2), and (H3,V3) are (2, 2), (1, 1), and (1, 1) respectively, and also note that JPEG in 4:2:2 refers to only

JPEG data in which the values (H1,V1), (H2,V2), and (H3,V3) are (2, 1), (1, 1), and (1, 1) respectively.

6.2.2.2 Scaling

Only 128/128 shall be applied to scaling.

Note that 256/128 is used for scaling only when pictures with a resolution of 960x540 are transported and then presented as 1920x1080 pictures on the receiver side by doubling horizontal and vertical pixels.

The screen size to be presented shall be the still picture plane's full-screen size or smaller.

Progressive mode shall not be used.

6.2.2.4 Markers and marker segments to be used

Table 6-4 shows markers and marker segments to be used for JPEG.

Table 6-4 Markers/marker segments to be used for JPEG

Marker

SOI

DQT

DRI

SOFn

DHT

Start of image

Remarks

Define quantization table

Define restart interval

Start of frame

Only SOF0(FFC0) to be decoded.

Define Huffman table

SOS

RSTm

Start of scanning

End of restart interval

EOI End of image

COM Comments

APPn

DNL

Marker for application use

Special size specified

Processing by the receiver

Normal processing

Normal processing

Normal processing (Note 1)

Normal processing

Normal processing

Normal processing

Normal processing (Note 1)

Normal processing

Ignored

Ignored

(Note 1) How to handle DRI and RSTm errors shall depend on the receiver.

― 3-61―

ARIB TR-B15

Version 4.6-E1

Because only the markers from SOI to DNL mentioned above appear in the baseline method, other markers shall be treated as errors.

6.2.3 PNG

Shall be compliant with the specifications in ARIB STD-B24, Section 1, Part 2, 5.3. colortype=3 bitdepth=1, 2, 4, 8

When bitdepth 1, 2, or 4 is used, colors to be specified for a CLUT shall be limited to color indexes (fixed colors) 0-1, 0-3, or 0-15 respectively.

Image compression type=0 (zlib)

6.2.3.2 Chunks to be used for PNG

Table 6-5 shows chunks to be used for PNG. If a chunk other than those listed in Table 6-5 is used, the receiver shall ignore it.

Table 6.5 Chunks to be used for PNG

Chunk name

IHDR

IDAT

Usage details

Color depth

Color type

Compression method

Filtering method

Interlace method

Filter method

IEND

1, 2, 4, 8

3 (specified in the palette) only

0 (deflate/inflate 32KB or less) only

0 only

0 (not interlaced) only

0 (not filtered) only

PLTE shall not be used.

To specify a color pallet, a CLUT shall be referenced instead of using PLTE in PNG chunks.

The data-storage type shall be non-interlace type.

The pattern size to be presented shall be the text/diagrams plane's full-screen size or smaller.

6.2.4 MNG

Shall be compliant with the specifications in ARIB STD-B24, Section 1, Part 2, 5.4.

6.2.4.1 Chunks to be used for MNG

Table 6-6 shows chunks to be used for MNG. If a chunk other than those listed in Table 6-6 is used, the receiver shall ignore it.

- 3-62-

ARIB TR-B15

Version 4.6-E1

Table 6.6 Chunks to be used for MNG

Chunk name Usage details

MHDR Mandatory

MEND Mandatory

IHDR,PNG chunks,IEND Compliant with the PNG usage specifications

TERM

FRAM

DEFI

Compliant with ARIB STD-B24

Compliant with ARIB STD-B24

Compliant with ARIB STD-B24

6.2.4.2 Constraints on MNG usage

(1) Total data size

256KB

Note that the MNG file total data size refers to a total amount of data when different MNGs are exploded.

Also note that the data amount of each MNG shall be a value of number of horizontal pixels x number of vertical pixels x bitdepth x number of PNG images.

(2) Total number of PNG images

64 images.

Note that the total number of PNG images refers to the number of all PNG images held by an MNG.

(3) Value specified for the update interval of PNG files

Minimum: 200 milliseconds

Maximum: 5,000 milliseconds

Specified in units of: 100 milliseconds

(4) Repeat

To set endless loop, 0x7fffffff shall be specified as the repeat count.

To specify a limited number of repeats, a value of an update interval of PNG files x number of PNG images x repeat count shall not exceed 120 seconds.

(5) Display size

Maximum data size of all PNG files in a single screen: 256KB

Note that the total display area per second shall not exceed 256KB.

(6) Others

Playing (when the streamStatus attribute=play), the display position of an MNG cannot be changed.

The PNG object size in an MNG shall be unchangeable.

A fully transparent color's position on a CLUT shall be fixed.

In the basic receiver unit, even if there is delay in the updates of PNG files that should be executed simultaneously with execution of other drawing operations, PNG images shall not be skipped but displayed in sequence.

When the top frame specifies framing mode 0, MNG shall be treated as in framing mode 1, which is the default setting, regardless of the number of cycles.

― 3-63―

ARIB TR-B15

Version 4.6-E1

Shall be compliant with the specifications in Section 7, 4.2 "Sound".

Table 6-7 MPEG-2 AAC encoding parameters

Sampling frequency

48kHz, 32kHz

Bit length

16 bit

Sound encoded by using MPEG-2 AAC shall be transported through an audio PES (stream format identification

0x0F) and data carousel (stream format identification 0x0D).

For the file format when sound is transported through a data carousel, refer to 6.3.1.4.

6.3.1.3 Limitations in data-carousel distribution

The file size shall be 256KB or less.

The sampling frequency shall be 48KHz.

Sound and MPEG-2Video and/or MPEG-I cannot play simultaneously.

6.3.1.4 ACC audio file data format

Shall be in MPEG-2 AAC Elementary Stream format.

As shown in Figure 6-1, an audio frame composed of an ADTS header and audio data associated with it shall be treated as one unit, and the ACC audio file data format shall be composed of one or more than one such units.

(One audio frame is equal to 1024 samples as a unit in PCM; it is approximately 21.3 milliseconds at a sampling rate of 48KHz.)

ADTS AAC

Header Audio frame Data

Audio frame

ADTS

Header

AAC

Audaio frame Data

Figure 6-1 ACC audio file data format

6.3.2 AIFF-C

Table 6-8 AIFF-C encoding parameters

Sampling frequency Bit length

- 3-64-

ARIB TR-B15

Version 4.6-E1

The maximum data size shall be 96KB or less.

Sound encoded by using AIFF-C shall be transported through a data carousel (stream format identification

0x0D).

The basic receiver unit does not need to support Private_chunks (chunks other than Format_Version_Chunk,

Extended_Common_Chunk, and Sound_Data_Chunk).

The number of channels shall be one.

There is no need to support repeat playback. (Playback of the seamed stream is not possible.)

Encoding methods by using MPEG-4 shall be optional.

Additional sound shall not be used.

The encoding method for the receiver's preinstalled sounds shall be AIFF-C and compliant with the specifications in 6.3.2.1. However, depending on the receiver's implementation, it is possible to adopt another functionally equivalent encoding method. The assignment of preinstalled sounds shall be as shown in Table 6-9.

Table 6-9 Assignment of the receiver's preinstalled sounds

0: News flash chime 1 1: News flash chime 2 2: News flash chime 3 3: News flash chime 4

4: News flash chime 5

8: Button 4

12: Button 8

5: Button 1

9: Button 5

13: Alert

6: Button 2

10: Button 6

14:

7: Button 3

11: Button 7

15:

Numbers in the above table mean sound_ids when specified by using multimedia encoding, and they mean preinstalled sounds when specified by using the extended control code PRA in 8-unit codes.

The receiver's capacity used for preinstalled sounds shall be 480KB.

6.3.6 Sound synthesis on the receiver

It is preferable that the receiver shall perform mixing on sounds that are distributed through different encoding methods, at a 1:1 volume ratio.

― 3-65―

ARIB TR-B15

Version 4.6-E1

6.3.6.2 Encoding methods that make simultaneous playback of sounds possible

Simultaneous playback of multiple sounds shall be permitted only for the combinations marked with { in Table

6-10. Text in the brackets ( ) shows a sound that should play first if simultaneous playback is not possible. The following shows the conditions for preferred playback. Note that "AIFF-C file (news flash)" or "News flash subtitling sound" in the following refers to preinstalled sound to be played for superimposed text for which auto display is specified.

If a news flash subtitling sound overlaps other sounds, the former shall play first. (The news flash subtitling sound shall play continuously.)

If the playback of an AIFF-C sound is specified more than once, in principle, the one specified later shall be executed first.

If an MPEG-2 AAC file and AIFF-C sound are instructed at the same time, the MPEG-2 AAC file shall play first.

Table 6-10 Encoding methods that make simultaneous playback of sounds possible

AAC-LC stream

(Main)

AAC-LC file

(Stored)

AIFF-C file

(Stored)

AIFF-C file

(Preinstalled sound)

AIFF-C file

(News flash)

AAC-LC stream (Main)

AAC-LC file (Stored)

×

×

(AAC stream first)

×

(Specified later first)

{ (1)(2)(3)

×

(AAC frist)

{

(1)(2)(3)

×

(AAC frist)

{

(1)(2)(3)

×

(News flash first)

AIFF-C file (Stored)

AIFF-C file (Preinstalled sound)

×

(Specified later first)

×

(Specified later first)

×

(Specified later first)

×

(News flash first)

×

(News flash first)

AIFF-C file (News flash)

×

(Specified later first)

(1) While an MPEG-2 AAC sound PES and AIFF-C sound are being synthesized together and outputted, if the MPEG-2 AAC sound PES disappears, the playback of the AIFF-C sound will not be guaranteed.

(2) While an AIFF-C sound is playing (not being synthesized), it is not possible to synthesize it with an

MPEG-2 AAC sound PES.

(3) If the sampling frequency of the MPEG-2AAC-LC (AAC-LC stream Main), which is transported through an audio PES, is 32kHz, simultaneous playback is not possible. The MPEG-2AAC_LC, which is transported through an audio PES, shall play first.

- 3-66-

ARIB TR-B15

Version 4.6-E1

6.4.1 8-unit code (including EUC-JP)

6.4.1.1 Constraints on the character code function

Table 6-11 shows whether the character code function can be used when codes are used as mono-media referenced from multimedia code. For whether or not the character code function can be used for subtitles and superimposed text, refer to 7.5 "Control code used for subtitles and superimposed text".

― 3-67―

ARIB TR-B15

Version 4.6-E1

Table 6-11 Whether or not the character code function can be used

1. C0 control set

C0 control code

Control function

Use in multimedia code

NUL Blank

{

BEL Bell

×

APB

APF

APD

APU

APR

Action position backward

Action position forward

Action line forward

Action line backward

Action position carriage return

{

{

{

{

{

PAPF

Predetermined action position forward

{

APS Action position setting

CS Clear

{

×

CAN Cancel

×

ESC Escape

{

LS1 Locking

{

LS0 Locking

{

SS2 Single shift 2

{

SS3 Single shift 3

{

RS

US

{: Usable : Usable with conditions

×: Not usable

2. C1 control set

Record separator (data header identification sign)

Unit separator (data unit identification sign)

×

×

Limitations and supplemental remarks

C1 control code

BKF

Control function

Use in multimedia code

{

Limitations and supplemental remarks

Specifies 0 to the color map lower address for the foreground.

RDF

GRF

YLF

BLF

MGF

CNF

WHF

Black foreground and color map lower address setting

Red foreground and color map lower address setting

Green foreground and color map lower address setting

Yellow foreground and color map lower address setting

Blue foreground and color map lower address setting

Magenta foreground and color map lower address setting

Cyan foreground and color map lower address setting

White foreground and color map lower address setting

{

{

{

{

{

{

{

Specifies 1 to the color map lower address for the foreground.

Specifies 2 to the color map lower address for the foreground.

Specifies 3 to the color map lower address for the foreground.

Specifies 4 to the color map lower address for the foreground.

Specifies 5 to the color map lower address for the foreground.

Specifies 6 to the color map lower address for the foreground.

Specifies 7 to the color map lower address for the foreground.

- 3-68-

C1 control code

CDC

WMM

Control function

Conceal display control

Write mode modification

Use in multimedia code

{

{

{

×

×

ARIB TR-B15

Version 4.6-E1

Limitations and supplemental remarks

Possible to use 128 common fixed colors across receivers and 96 colors specified by broadcasters.

To specify a color using COL, specify a CLUT's index value

(0-223) using a palette number for the upper 4 bits and using CMLA for the lower 4 bits respectively.

Example1: When palette number=0 and CMLA=0, a

CLUT's index value=0.

Example2: When palette number=10 and CMLA=5, which means 0xA5, a CLUT's index value=165.

Only POL 04/0 (normal polarity) and POL 04/1 (inverted polarity 1) are used. The processing when the normal polarity changes to the inverted polarity shall be: foreground color -> background color, color halftone 1 -> color halftone 2, color halftone 2 -> color halftone 1, foreground color

-> background color.

Shall not be specified for DRCS.

Shall not be specified for DRCS.

Possible to use only double height, double width, and double height, width.

×

×

×

Shall not use the function to specify macros for control codes; shall use default macros only.

{

Only underlines is used.

For underline usage, refer to 7.5.5.

STL

SPL

Start lining and separating mosaic characters

Stop lining and separating mosaic characters

{

CSI

Control sequence introducer

{

{: Usable : Usable with conditions

×: Not usable

Only underlines is used.

For box usage, refer to 7.5.4.

― 3-69―

ARIB TR-B15

Version 4.6-E1

3. Extended control code set (CSI)

Character

CCC

ACPS

Control function

Color composition control

RCS Raster color control

Use in multimedia code

×

Limitations and supplemental remarks

Instruction possible only after initialization of the display screen and before appearance of characters with display action or appearance of control code. Only 1-code parameter is used; parameters that can be specified for P11..P1i shall be only 7 (960x540, horizontal writing) and 8 (960x540, vertical writing) for a 960x540 text/diagrams plane resolution, and only 9

(720x480, horizontal writing) and 10

(720x480, vertical writing) for a 720x480 text/diagrams plane resolution.

{

×

Instruction possible only after initialization of the display screen and before appearance of characters with display action or appearance of control code. Any of the common fixed colors across receivers and colors specified by broadcasters (index values 0-223) can be specified for the color.

For raster color control usage, refer to 7.5.3.

Note that an area on which raster color control is performed shall be a rectangle specified by the CSS style in BML's object properties.

SDF

SDP

SSM

PLD

PLU

SHS

SVS

Action position coordinate setting

System data format

(display dot pattern setting)

Display position setting

Character dot pattern setting

Partially line forward

Partially line backward

Character spacing setting

Line spacing setting

×

×

×

×

{

{

Possible to specify only 16x16, 20x20,

24x24,30x30, and 36x36 dots.

(Note 1)

×

×

The colored areas shall be full-display areas only.

SRC Raster color setting

×

TCC

Changeover control

×

CFS

Character font setting

Possible to set only 3 fonts specified in

Chapter 4 (1. Maru-Gothic (P1:03/01), 2.

Kaku-Gothic (P1:03/02), and 3. Futo

Maru-Gothic (P1:03/03)).

(Note 1)

- 3-70-

ARIB TR-B15

Version 4.6-E1

Character Control function

Use in multimedia code

Limitations and supplemental remarks

ORN

Character ornaments setting

Possible to use only without ornaments and with boundry highlighting.

For boundry highlighting usage, refer to

7.5.6.

MDF

PRA

XCS

Character style setting

Preinstalled sound playback

Define external character substitute code string

×

×

×

{: Usable : Usable with conditions

×: Not usable

(Note 1) Possible to set only a combination of a character font specified in Chapter 4 and font size.

― 3-71―

ARIB TR-B15

Version 4.6-E1

6.4.1.2 Character set used in data broadcasts

Table 6.12 Character set used in data broadcasts

Character set

Alphanumeric set specified in ARIB

STD-B24 (single-byte code)

Hiragana set specified in ARIB

STD-B24 (single-byte code)

Katakana set specified in ARIB

STD-B24 (single-byte code)

Kanji set specified in ARIB STD-B24

(double-byte code, rows 1-94)*7

DRCS set specified in ARIB

STD-B24 (single-byte code)

DRCS set specified in ARIB

STD-B24 (double-byte code)

Macro set specified in ARIB

STD-B24 (single-byte code)

JIS compatible kanji single-plane set specified in ARIB STD-B24

JIS compatible kanji double-plane set specified in ARIB STD-B24

Supplemental symbol set specified in

ARIB STD-B24

BML document

*1

{

×

×

{

×

*4

×

×

×

×

8-unit code for external reference from a BML document *2

{

{

{

{

×

*5

{*6

×

×

×

Subtitles and superimposed

*1 EUC-JP is used as specified in ARIB STD-B24, Section 2, Appendix 2, 4.1 Character encoding. text *3

{

{

{

{

{

{

{*6

×

×

×

*2 Use a code structure, extension method, call control, control over code instructions, and end code for each code set in accordance with the specifications in ARIB STD-B24, Section 1, Part 2, section 7.1. However, character sets such as single-plane and double-plane JIS compatible kanji, supplemental symbols, and

DRCS shall be excluded. For the specifications of display formats, etc., refer to Table 7-14.

*3 Use a code structure, extension method, call control, control over code instructions, and end code for each code set in accordance with the specifications in ARIB STD-B24, Section 1, Part 2, section 7.1. However, character sets such as single-plane and double-plane JIS compatible kanji, and supplemental symbols shall be excluded. For the specifications for display formats, etc., refer to Table 7-14.

*4 The rows 87 - 88 of the kanji set are used as DRCS areas in accordance with the specifications in ARIB

STD-B24, Section 2, Appendix 2, 4.1 Character encoding.

*5 Used as specified in ARIB STD-B24, Section 2, Appendix 2, 4.1 Character encoding. For 8-unit character code referenced by a BML document internally and externally, the rows 87 - 88 in the kanji set shall be shared as DRCS areas.

*6 Only default macros is used.

*7 Row 90 and row 91 shall not be used.

- 3-72-

ARIB TR-B15

Version 4.6-E1

6.4.1.3 Character code initialization operation

For objects contained in a BML document that reference 8-unit code, character code initialization, object-by-object, shall be performed when their presentation starts.

The initial value shall be horizontal writing and the resolution shall be the same as the resolution of the BML document. Initialization related to code instructions and code calls and initialization related to action and status instructions shall be performed as specified in ARIB STD-B24, Section 1, Part 3, Chapter 8 Initialization. Note that the initial values for font size, character spacing, and line spacing shall be set in accordance with Table 7-15.

The initial values for character font, front-color halftone, and back-color halftone shall be set as Maru-Gothic, index value=15, and index value=30 respectively. The initial value for raster color shall be set as transparent

(index value=8).

6.4.2 International encoding character code

Not used.

6.5 Descriptor command picture encoding

6.5.1 Geometric

Not used.

― 3-73―

ARIB TR-B15

Version 4.6-E1

7 Operating Subtitles and Superimposed Text Encoding

7.1 Scope and definition of services

BS digital broadcasting provides the following two services related to subtitles and superimposed text:

Subtitles : Caption service synchronized with the main video, audio, and data service (e.g. translation subtitles)

Superimposed text : Caption service not synchronized with the main video, audio, and data service (e.g. news flash, program schedule notice, time signal, etc)

7.2 Scheduling and transmission operations

7.2.1 Constraints on scheduling and transmission

(1) Transmission specification

Subtitles and superimposed text shall be transported through the independent PES method (stream format identification 0x06).

(2) Scheduling

Subtitles and superimposed text shall be transmitted via separate ESs. Because they are transmitted based on the same PMT as the main service, caption data shall not be pre-distributed in the same program or before a program starts.

(3) Number of ESs

The number of ESs for subtitles and superimposed text that can be simultaneously transmitted to the same layer shall be one ES each, i.e. two ESs in total.

(4) ESs in multi-view mode

ESs in multi-view mode shall be a maximum of one ES for subtitles and a maximum of one ES for superimposed text, per component group.

The subtitling ES and superimposed text ES appearing in the component group whose component_group_id=0 (the default component group that plays when a service is selected) shall be made as the default subtitling ES and superimposed text ES respectively. Do not fix the use of the subtitling and superimposed text ESs that appear in a component group whose component_group_id is not 0 but do not appear in the component group whose component_group_id is 0.

(5) ESs for temporary channels

ESs for temporary channels shall be a maximum of one ES for subtitles and a maximum of one ES for superimposed text, per provisional channel.

(6) Multi-language transmission

It shall be made possible to transmit a maximum of two languages per ES at the same time, and language identification shall be performed by caption management data in ES.

(7) Bitmap data

Bitmap data can be used in superimposed text.

(8) Available display modes

For subtitles, available display modes shall be "Auto display when receiving and selective display when recording/playing" and "Selective display when receiving and selective display when recording/playing" only. For superimposed text, available display modes shall be "Auto display when receiving and auto display when recording/playing", "Auto display when receiving and selective display when

- 3-74-

ARIB TR-B15

Version 4.6-E1 recording/playing", and "Selective display when receiving and selective display when recording/playing" only. For transmission of multiple languages, the display mode for them shall be the same. For transmission contrary to the above, the receiver's operation shall depend on its implementation, but in principle, auto display mode takes precedence.

(9) Using warning sounds and additional sounds

Regarding warning sounds for subtitles and superimposed text, only the receiver's preinstalled sounds can be used. Additional sounds shall not be used for subtitles or superimposed text.

(10) Specifying target areas

To specify a target area, control shall be performed by using the target area descriptor in PMT. Note that subtitles shall not be used by specifying their target area independently. Whereas, superimposed text can be used by specifying its target area independently. In such a case, superimposed text targeted at different areas shall be transmitted by using different time intervals.

(11) Data contents descriptor

Because superimposed text has nothing to do with events, EIT's data contents descriptor shall not be added. For subtitles, one descriptor shall be added per ES. If their parameters do not correspond to the settings for PMT's data encoding descriptor and caption management data, regarding the parameters such as display mode, number of languages, and language code, the receiver shall operate based on the settings for PMT's data encoding descriptor and caption management data

(12) Caption management data transmission frequency

Because caption management data contains information required to display subtitles and superimposed text, it is not possible to display caption text before reception of that data. Considering the moment of channel selection, caption management data shall be therefore transmitted at the following time intervals for normal transmission of subtitles and superimposed text.

Maximum transmission frequency : once per 0.3 seconds

Minimum transmission frequency : once per 5.0 seconds

Note that transmission may be interrupted due to commercial messages.

7.2.2 PES transmission specification used for subtitles

The synchronous PES transmission specification shall be applied, so that timing synchronization can be realized by using PTS. Table 7-1 shows parameters to be set for PES packets.

Setting parameters: Refer to Table 7-1.

Maximum number of ESs to be simultaneously transmitted to the same layer: 1

Maximum number of languages per ES: 2

PES unit: 1 data group

Maximum PES size: 32KB

Minimum time interval of PES packet transmission: 100 milliseconds

Maximum ES rate: 256Kbps

Reception buffer: 64KB or more (for both one language and two languages)

Other than the above, 16KB is required for DRCS; refer to 7.6.

― 3-75―

ARIB TR-B15

Version 4.6-E1

Table 7-1 PES packet setting parameters for subtitles

Field Usage data_identifier 0x80 private_stream_id 0xFF

PES_data_packet_header_length Shows the field length of PES_data_private_data_byte.

Normally, 0x00 shall be entered. *2

PES_data_private_data_byte This field can be skipped. *2

*1 Usage by entering 0 into this value, without specifying the PES packet length, shall be prohibited.

*2 When using PES_data_private_data_byte, be sure to specify the correct length of

PES_data_private_data_byte to PES_data_packet_header_length.

For PES packet transmission, the following limitations shall be imposed.

There should be proper correspondence between PES packets in order of transmission and PTS stamps in

• order of time.

At the PTS time of a #n PES packet, the total amount of information in the PES packets whose

• transmission starts after transmission of the #n packet shall not exceed the reception buffer size (64KB).

PES packet transmission shall be complete within Td after PTS time. Where Td is a time period between

• completion of reception and completion of presentation, and it shall be 0.5 seconds approximately.

For the time interval at which a caption text data group's PES packets are transmitted, a time interval between the PTS time of a #n PES packet and the PTS time of a #n-1 PES packet, in order of transmission, shall be greater than the Td of #n data.

When the total delay T of video satisfies the following conditions, transmission in synchronization with video can be possible on the transmit side.

T > L

×8 / R + Td

Where L is a maximum PES packet length and R is an ES bit rate.

The receiver's action when the data size exceeds the reception buffer size depends on the implementation of the receiver.

7.2.3 PES transmission specification used for superimposed text

The asynchronous PES transmission specification shall be applied. Table 7-2 shows parameters to be set for

PES packets.

Setting parameters: Refer to Table 7-2.

Maximum number of ESs to be simultaneously transmitted to the same layer: 1

Maximum number of languages per ES: 2

PES unit: 1 data group

Maximum PES size: 32KB

Minimum time interval of PES packet transmission: 100 milliseconds

Maximum ES rate: 256Kbps

Reception buffer: 64KB or more (for both one language and two languages)

Other than the above, 16KB is required for DRCS; refer to 7.6.

- 3-76-

ARIB TR-B15

Version 4.6-E1

Table 7-2 PES packet setting parameters for superimposed text

Field Usage

PES_packet_length

(private_stream_2)

Byte size in the subsequent PES packets. *1 data_identifier 0x81 private_stream_id 0xFF

PES_data_packet_header_length

Shows the field length of PES_data_private_data_byte.

Normally, 0x00 shall be entered. *2

PES_data_private_data_byte

This field can be skipped. *2

Asynchronized_PES_data_byte

Stores the data of a caption data group.

*1 Usage by entering 0 into this value, without specifying the PES packet length, shall be prohibited.

*2 When using PES_data_private_data_byte, be sure to specify the correct length of

PES_data_private_data_byte to PES_data_packet_header_length.

For PES packet transmission, the following limitations shall be imposed.

Use of bitmap data units shall become possible only when TMD is free.

For the time interval at which a caption text data group's PES packets are transmitted, a time interval between a #n PES packet and a #n+1 PES packet, in order of transmission, shall be greater than the Td of

#n data. Where Td is a time period between completion of reception and completion of presentation, and it shall be approximately 0.5 seconds for text only, and approximately 3 seconds for bitmap data of 32KB.

At the time of #n PES packet transmission completion time + Td time, the total amount of information in the PES packets whose transmission starts after transmission of the #n packet shall not exceed the reception buffer size (64KB).

The receiver's action when the data size exceeds the reception buffer size depends on the implementation of the receiver.

7.2.4 Using data groups

Following caption management data updates, data_group_id shall be transmitted with its data group being switched from Group A to B and Group B to A. Note that if caption management data is not transmitted for 3 minutes or more, either ID, Group A or B, may be transmitted regardless of the previous ID. data_group_version shall not be used. For caption management data with the ID of Group A , the receiver processes caption text (text, bitmap data, and DRCS) for Group A only, while for caption management data with the ID of Group B, the receiver processes caption text for Group B only.

When caption management data of the same ID as the current already-received caption management data holds is received, it shall be treated as resent data, so that initialization will not be performed by using that data. When caption management data of the same ID as the current already-received management data holds is received multiple times, caption text received each time shall be treated as new text.

Table 7-3 Data group parameters

Field Usage data_group_id data_group_size

As per the specifications. data_group_version

Not used. data_group_link_number

0x00 last_data_group_link_number

0x00

As per the specifications. However, 1 PES packet shall not exceed

32KB in size. data_group_data_byte

CRC_16

Stores data group data (caption management data and caption text data).

Performs error detection through CRC16. When an error is detected, the receiver discards the relevant data group.

― 3-77―

ARIB TR-B15

Version 4.6-E1

7.2.5 Using caption management data

It is possible to put multiple data units of the same or different data unit parameters into the same caption management data. When multiple data units exist in the same caption management data, they shall be processed in order of appearance.

Note that data allowed to be written into text shall be limited to the control codes, SWF, SDF, SDP, SSM, SHS, and SVS, not the character code set requiring screen display.

7.2.5.1 Caption management data used for subtitles

Caption management data shall be transmitted at least once every three minutes. If caption management data has not been received for three minutes or more, the receiver shall perform the initialization that executes at the time of channel selection. Table 7-4 shows parameters that can be specified to caption management data used for subtitles.

Table 7-4 Caption management data parameters for subtitles

Field

TMD num_languages language_tag

DMF

Usage

'00' (free)

1 - 2

0 - 1

'0010' (auto display when receiving and selective display when recording/playing)

'1010' (selective display when receiving and selective display when recording/playing)

ISO_639_language_code

Language code to be used.

Format

'1000' (960x540 horizontal writing)

'1001' (960x540 vertical writing)

'1010' (720x480 horizontal writing)

'1011' (720x480 vertical writing)

TCS

'00' (8-unit code) data_unit_loop_length

As per the specifications. However, 1 PES packet shall not exceed

32KB in size. data_unit

Stores a data unit (text and DRCS).

7.2.5.2 Caption management data used for superimposed text

Considering time signal superimposed text, it shall be made possible to set real time as well as free for TMD for the purpose of time synchronization through STM. If caption management data has not been received for three minutes or more, the receiver shall perform the initialization that executes at the time of channel selection. Table

7-5 shows parameters that can be specified for caption management data used for superimposed text.

Table 7-5 Caption management data parameters for superimposed text

Field

TMD

Num_languages language_tag

DMF

Usage

'00' (free)

'01' (real time)

Free and real time cannot exist at the time of presentation.

1 - 2

0 - 1

'0000' (auto display when receiving and auto display when recording/playing)

'0010' (auto display when receiving and selective display when recording/playing)

'1010' (selective display when receiving and selective display when recording/playing)

- 3-78-

ARIB TR-B15

Version 4.6-E1

ISO_639_language_code

Language code to be used. format

'1000' (960x540 horizontal writing)

'1001' (960x540 vertical writing)

'1010' (720x480 horizontal writing)

'1011' (720x480 vertical writing)

'00' (8-unit code)

TCS data_unit_loop_length

As per the specifications. However, 1 PES packet shall not exceed data_unit

32KB in size.

Stores a data unit (text and DRCS).

7.2.6 Using caption text data

It is possible to put multiple data units of the same or different data unit parameters into the same caption text data. When multiple data units exist in the same caption text data, they shall be processed in order of appearance.

Table 7-6 shows parameters that can be set for caption text data

Table 7-6 Caption text data parameters

Field

TMD

STM

Usage

'00' (free)

'01' (real time): Superimposed text only

However, set the same value as caption management data holds, in the same program.

As per the specifications. Shall be enabled only when the

PMT's data encoding descriptor timing='10' (time synchronization). data_unit_loop_length

As per the specifications. However, 1 PES packet shall not data_unit exceed 32KB in size.

Stores a data unit (text, DRCS, and bitmap data).

7.2.7 Using data units

Table 7-7 shows parameters that can be set for data units.

Table 7-7 Data unit parameters

Field Usage unit_separator

Shall be 0x1F as specified. data_unit_parameter

0x20 (text)

0x35 (bitmap data) data_unit_size data_unit_data_byte

0x30 (single-byte DRCS)

0x31 (double-byte DRCS)

As per the specifications. However, 1 PES packet shall not exceed 32KB in size.

Stores data unit data.

7.2.8.1 Using component tags

A component_tag value ranging from 0x30 to 0x37 shall be set for subtitle ES, and a component_tag value ranging from 0x38 to 0x3F shall be set for superimposed text ES. However, the default component_tag value for subtitle ES shall be set as 0x30, and the default component_tag value for superimposed text ES shall be set as 0x38.

― 3-79―

ARIB TR-B15

Version 4.6-E1

For PMT updates, in principle, ES information shall be added or deleted at the time of start/end of subtitles and superimposed text; however, it shall be also made possible to use PMT with ES information always being published.

7.2.8.3 Stream format identification

stream_type for subtitles and superimposed text shall be 0x06 (independent PES_packet).

Table 7-8 shows the usage of PMT and EIT descriptors for subtitles and superimposed text.

Table 7-8 PMT and EIT descriptor usage

Descriptor

Stream identification descriptor

Data encoding method descriptor

Target area descriptor

PMT

Mandatory

Mandatory

Mandatory when specifying a target area

EIT

Data contents descriptor

− pf-EIT: Mandatory sch-EIT: Optional

(shall not be written for superimposed text.)

7.2.8.5 Data encoding method descriptor

The data encoding method descriptor data_component_id shall be 0x0008 for both subtitles and superimposed text. Table 7-9 shows parameters to be set for additional information identification.

Table 7-9 Setting parameters for additional information identification in the data encoding method descriptor

Field Usage

DMF '0011'

Timing Subtitles : '01' (program synchronization)

Superimposed text : '00' (no synchronization) or '10' (time synchronization)

7.2.8.6 Target area descriptor

Shall be compliant with Chapter 5 Data Transmission Specification Usage, or PMT region descriptor.

7.2.8.7 Data contents descriptor

Table 7-10 and 7-11 show parameters that can be set for the data contents descriptor and its selector area. Note that if there is inconsistency between these setting parameters and the data encoding method descriptor and caption management data in PMT, the data encoding method descriptor and caption management data shall take precedence.

- 3-80-

ARIB TR-B15

Version 4.6-E1

Table 7-10 Data contents descriptor setting parameters for subtitles

Field data_component_id 0x0008 entry_component num_of_component_ref component_ref

Usage component_tag value of the relevant subtitle ES.

Shall be specified as 0.

Not required because num_of_component_ref=0.

ISO_639_language_code text_length text_char

Fixed as jpn (Japanese).

The upper limit shall be 16(byte).

The details of caption text to be displayed on EPG shall be written.

Table 7-11 Data contents descriptor's selector area setting parameters for subtitles

Field

Num_languages

DMF

ISO_639_language_code

Usage

Same as the value in caption management data.

Same as the value in the data encoding method descriptor.

Same as the value in caption management data.

7.3 Video resolution and subtitles and superimposed text display formats

Available display formats shall be 960

×540 and 720×480, and horizontal and vertical writing for each.

Combinations of the video plane's resolution and a subtitles and superimposed text display format shall be as shown in Table 7-12, each being in horizontal or vertical writing. A display format for 720x480 shall be the same regardless of an aspect ratio for video; for display considering an aspect ratio, correction shall be made on the transmit side.

Table 7.12 Video resolution and display format combinations

Video plane resolution

1920

×1080 960×540

720

×480 720×480

Subtitles and superimposed text display format

The above shall apply to data broadcasting programs.

The display area refers to an area particularized by vertical and horizontal pixels the control code SDF specifies and by the coordinates the control code SDP specifies from the upper left corner of the caption plane (refer to

Figure 7-1). The origin (0,0) of coordinates in the display area shall be the upper left corner of "Caption plane" regardless of whether the format is based on vertical or horizontal writing.

For subtitles and superimposed text, it shall be made possible to set one display area each at the same time. In addition, the display area is valid for bitmap data too. Priorities among the values for the display area shall be:

(1) Values specified by SDF and SDP in the text of caption text data

(2) Values specified by SDF and SDP in the text of updated caption management data

(3) Initial values based on the display format specified by the header of updated caption management data

In the above case, the initial values for the display area (display dot pattern) shall be as shown in Table 7-13.

Note that the values for font size, character spacing, and line spacing shall be set as shown in Table 7-15.

― 3-81―

ARIB TR-B15

Version 4.6-E1

Specified by SDP

Specified by SDF

Caption plane

Display area

Figure 7-1 Caption plane and display area

Table 7-13 Display area and display position initial values

Display format Display area

960

×540 960×540

720

×480 720×480

7.3.3 Initial action position

Display position

0, 0

0, 0

The initial action position shall be the first position of the first line based on the font size in the initial state. The first position of the first line shall be the upper left corner of the display area in horizontal writing, and the upper right corner of the display area in vertical writing. And the action direction shall be to the right in horizontal writing and down in vertical writing.

Action direction

Display block

Display block

Action direction

(a) In horizontal writing (b) In vertical writing

Figure 7-2 Initial action position and action direction

7.4 Characters used in subtitles and superimposed text

The character encoding method used for subtitles and superimposed text shall be 8-unit code. For code sets used, refer to Chapter 6 Mono-media.

Maru-Gothic is preferable as a character font used in subtitles and superimposed text.

- 3-82-

ARIB TR-B15

Version 4.6-E1

Five font sizes shall be made available that can be displayed in subtitles and superimposed text: 16 dots, 20 dots,

24 dots, 30 dots, and 36 dots. For the font size for transmission, specify any of the above.

In addition, standard, medium, and small can be used for each size. The following shows the definitions of standard, medium, and small.

Standard : Characters whose size is specified by the control code SSM.

Medium : Half-width characters in relation to standard characters.

Small : Half-size (width and height) characters in relation to standard characters.

Table 7-14 shows limitations on character display.

Table 7-14 Range of code sets usable according to the specifications for the display format and font size

92 (1 - 4)

(5 - 12)

(13 - 15)

(16 - 25)

(26 - 31)

(32 - 41)

(42 - 47)

(48 - 52)

(53 - 54)

(55 - 91)

93 (1 - 45)

(48 - 91)

94 (1 - 93)

― 3-83―

{ {

{

{

ARIB TR-B15

Version 4.6-E1

(1) When vertical writing is selected for the display format, the receiver shall display the following using font shapes different from those in horizontal writing.

Row 1: cells 2, 3, 17, 18, 28 - 30, 33 - 37, 42 - 59, and 65.

Row 4: cells 1, 3, 5, 7, 9, 35, 67, 69, 71, and 78.

Row 5: cells 1, 3, 5, 7, 9, 35, 67, 69, 71, 78, 85, and 86.

Row 92: cells 48, 49, 50, and 51.

Note that in Katakana and Hiragana sets, it is necessary to respond to the following codes.

Katakana: 2/1, 2/3, 2/5, 2/7, 2/9, 4/3, 6/3, 6/5, 6/7, 6/14, 7/5, 7/6, and 7/9 - 7/13.

Hiragana: 2/1, 2/3, 2/5, 2/7, 2/9, 4/3, 6/3, 6/5, 6/7, 6/14, and 7/9 - 7/13.

(2) Characters in row 1, cells 13 - 18, and row 2, cell 94 shall be non-spacing (refer to 7.4.5) characters.

The display block is defined as follows:

Word direction display block size = character spacing/2 + font size + character spacing/2

Line direction display block size = line spacing/2 + font size + line spacing/2

* If character spacing (line spacing) is an odd number value, a value for the character spacing/2 (line spacing/2) before the font in relation to the word direction (line direction) shall be rounded down, and a value for the character spacing/2 (line spacing/2) after the font in relation to the word direction (line direction) shall be rounded up. The relationships among display block, font size, character spacing, and line spacing are illustrated in Figure 7-3 - Figure 7-8 for horizontal writing, and in Figure 7-9 - Figure 7-14 for vertical writing. If character spacing (line spacing) is not a multiple of 4, a value for character spacing/4

(line spacing/4) shall be rounded down.

- 3-84-

ARIB TR-B15

Version 4.6-E1

Line direction display block size

Action position reference point

Character spacing/2

Word direction display block size

Line spacing/2

Font size

Font size

Line spacing/2

Character spacing/2

Figure 7-3 Relationships among display block, font size (standard), character spacing, and line spacing in horizontal writing

Line direction display block size

Action position reference point

Word direction

Character spacing/4 display block size

Font size/2

Line spacing/2

Font size

Line spacing/2

Character spacing/4

Figure 7-4 Relationships among display block, font size (medium), character spacing, and line spacing in horizontal writing

― 3-85―

ARIB TR-B15

Version 4.6-E1

Line direction display block size

Action position reference point

Word direction

Character spacing/4 display block size

Font size/2

Line spacing/4

Font size/2

Line spacing/4

Character spacing/4

Figure 7-5 Relationships among display block, font size (small), character spacing, and line spacing in horizontal writing

Action position reference point

Character spacing/2

Word direction display block size

Font size

Line spacing/2X3

Font sizeX2

Line spacing/2

Character spacing/2

Figure 7-6 Relationships among display block, font size (double-height), character spacing, and line spacing in horizontal writing

- 3-86-

ARIB TR-B15

Version 4.6-E1

Word direction display block size

Line spacing/2

Line direction display block size

Font size

Line spacing/2

Action position reference point

Character spacing

Font sizeX2 Character spacing

Figure 7-7 Relationships among display block, font size (double-width), character spacing, and line spacing in horizontal writing

― 3-87―

ARIB TR-B15

Version 4.6-E1

Line direction display block size

Word direction display block size

Line spacing/2X3

Font sizeX2

Line spacing/2

Action position reference point

Character spacing

Font sizeX2 Character spacing

Figure 7-8 Relationships among display block, font size (double height, width), character spacing, and line spacing in horizontal writing

- 3-88-

ARIB TR-B15

Version 4.6-E1

Action position reference point

Word direction display block size

Line direction display block size

Line spacing/2

Character spacing/2

Font size

Font size

Character spacing/2

Line spacing/2

Figure 7-9 Relationships among display block, font size (standard), character spacing, and line spacing in vertical writing

Action position reference point

Word direction display block size

Line direction display block size

Line spacing/2

Font size

Character spacing/4

Font size/2

Character spacing/4

Line spacing/2

Figure 7-10 Relationships among display block, font size (medium), character spacing, and line spacing in vertical writing

― 3-89―

ARIB TR-B15

Version 4.6-E1

Action position reference point

Word direction display block size

Line direction

Line spacing/4 display block size

Font size/2

Character spacing/4

Font size/2

Character spacing/4

Line spacing/4

Figure 7-11 Relationships among display block, font size (small), character spacing, and line spacing in vertical writing

- 3-90-

ARIB TR-B15

Version 4.6-E1

Action position reference point

Line direction display block size

Character spacing

Word direction display block size

Font sizeX2

Character spacing

Line spacing/2 Font size Line spacing/2

Figure 7-12 Relationships among display block, font size (double-height), character spacing, and line spacing in vertical writing

― 3-91―

ARIB TR-B15

Version 4.6-E1

Action position reference point

Line direction display block size

Character spacing/2

Word direction display block size

Font size

Character spacing/2

Line spacing Font sizeX2 Line spacing

Figure 7-13 Relationships among display block, font size (double-width), character spacing, and line spacing in vertical writing

- 3-92-

ARIB TR-B15

Version 4.6-E1

Action position reference point

Line direction display block size

Character spacing

Word direction display block size

Font sizeX2

Character spacing

Line spacing Font sizeX2 Line spacing

Figure 7-14 Relationships among display block, font size (double height, width), character spacing, and line spacing in vertical writing

― 3-93―

ARIB TR-B15

Version 4.6-E1

Table 7-15 shows the initial values for font size, character spacing, and line spacing.

Table 7-15 Initial values for font size, character spacing, and line spacing

Font size

Character spacing

Line spacing

Display block (W x H)

960

×540

720

×480

Horizontal Vertical Horizontal Vertical

36 36 36 36

4

24

40x60

12

24

60x48

4

16

40x52

8

24

60x44

Note that bordering characters (row 8) shall be displayed over the entire display block only when values for character spacing and line spacing in horizontal writing in Table 7-16 are selected. (The function to display borderings over the entire display block if values for character spacing and line spacing other than listed in

Table 7-16 are set shall be optional.)

Table 7-16 Display block where bordering characters

*1

, boxes, and underlines can be displayed correctly

960

Horizontal

960

×540

×540

Vertical

720

Horizontal

720

×480

×480

Vertical

Font size

24

30

36

16

20

24

30

36

16

20

24

30

36

16

20

24

30

36

16

20

Character spacing Line spacing

0, 1, 2

0, 1, 2

0, 1, 3

0, 2, 3

0, 2, 4

0, 3, 5

0, 3, 7

0, 4, 8

0, 5, 10

0, 6, 12

0, 1, 2

0, 1, 2

0, 1, 3

0, 2, 3

0, 2, 4

0, 2, 4

0, 2, 4

0, 3, 5

0, 3, 7

0, 4, 8

0, 5, 11

0, 7, 13

0, 8, 16

0, 10, 20

0, 12, 24

0, 5, 11

0, 7, 13

0, 8, 16

0, 10, 20

0, 12, 24

0, 4, 7

0, 4, 9

0, 5, 11

0, 7, 13

0, 8, 16

0, 5, 11

0, 7, 13

0, 8, 16

0, 10, 20

0, 12, 24

*1 Note that bordering characters shall apply in horizontal writing only.

(Reference) The above values for character spacing and line spacing are obtained from the following formulas.

Character spacing ratio = initial character spacing value/initial font size

Character spacing value 1 = character spacing ratio

× font size

Character spacing value 2 = (character spacing ratio/2)

× font size

Line spacing ratio = initial line spacing value/initial font size

Line spacing value 1 = line spacing ratio

× font size

Line spacing value 2 = (line spacing ratio/2)

× font size

The action position reference point for the display block shall be the lower left corner of the display block in horizontal writing, and the center at the top of the display block in vertical writing. However, in vertical writing,

- 3-94-

ARIB TR-B15

Version 4.6-E1 if the line direction display block size is an even number value, the action position reference point in the line direction is shifted one dot in that move direction. (For example, if the line direction block display size = 68 dots, the action position reference point in the line direction becomes the 35th dot.)

The details of the action position shall be as follows:

(1) The action position shall not move even when the display block is resized.

(2) After a character is displayed, the action position shall automatically advance. Note that the above is not applicable to non-spacing characters.

(3) When the display block extends beyond the edge of the display area, characters shall be displayed after a new line starts. In such a case, the action position shall move, as much as the line direction display block size, in the line direction in relation to a character at the line break.

A non-spacing character shall be displayed by being merged into a character the subsequent code specifies or merged into a space. The following shall be characters into which a non-spacing character is merged or code, such as a space, that can be used between codes.

Blank: NULL

Extended control: control codes for instructions and calls

Special functions: SP and DEL (usable as end)

Character code set: Spacing characters and external characters (usable as end),

― 3-95―

ARIB TR-B15

Version 4.6-E1

7.5 Control codes used in subtitles and superimposed text

Control codes used in subtitles shall be compliant with ARIB STD-B24, Section 1, Part 2, 7.1.2. However, the limitations described in Tables 7-17, 7-18, and 7-19 shall be imposed on their usage.

Table 7-17 C0 control set

C0 control code

Control function Use Limitations and supplemental remarks

APB

APF

APD

APU

APR

PAPF

APS

Action position backward

Action position Forward

Action line forward

Action line backward

Action position carriage return

Predetermined action position forward

Action position setting

{

{

{

{

{

{

{ screen

CAN Cancel

SS2

SS3

RS

US shift

{ shift

{

Single shift 2

Single shift 3

{

{

Record separator (data

× header identification sign)

Unit separator (data unit identification sign)

{

Used only for identification of a data unit, and not used in an 8-unit code string.

{: Usable : Usable with conditions

×: Not usable

- 3-96-

ARIB TR-B15

Version 4.6-E1

Table 7-18 C1 control set

C1 control code

BKF

RDF

GRF

YLF

BLF

MGF

CNF

WHF

Control function

Black foreground and color map lower address setting

Red foreground and color map lower address setting

Green foreground and color map lower address setting

Yellow foreground and color map lower address setting

Blue foreground and color map lower address setting

Magenta foreground and color map lower address setting

Cyan foreground and color map lower address setting

White foreground and color map lower address setting

Use

{

{

{

{

{

{

{

{

Limitations and supplemental remarks

Specifies 0 to the color map lower address for the foreground.

Specifies 1 to the color map lower address for the foreground.

Specifies 2 to the color map lower address for the foreground.

Specifies 3 to the color map lower address for the foreground.

Specifies 4 to the color map lower address for the foreground.

Specifies 5 to the color map lower address for the foreground.

Specifies 6 to the color map lower address for the foreground.

Specifies 7 to the color map lower address for the foreground.

SSZ Small

MSZ Medium

NSZ Normal

{

{

{

Only 128 common fixed colors across receivers can be used.

To specify a common fixed color across receivers using COL, specify a CLUT's index value (refer to Appendix 1) using a palette number for the upper 4 bits and using CMLA for the lower 4 bits respectively.

Example1: When palette number=0 and

CMLA=0, CLUT's index value=0.

Example2: When palette number=4 and

CMLA=5, which means 0x45, a CLUT's index value=69.

Only POL 04/0 (normal polarity) and POL 04/1

(inverted polarity 1) are used. The processing when the normal polarity changes to the inverted polarity shall be: foreground color -> background color, color halftone 1 -> color halftone 2, color halftone 2 -> color halftone 1, foreground color -> background color.

Shall not be specified for standard- or medium- size DRCS.

Shall not be specified for standard- or small-size

DRCS.

Shall not be specified for medium- or small-size

DRCS.

Possible to use only double height, double width, and double height, width.

― 3-97―

ARIB TR-B15

Version 4.6-E1

C1 control code

Control function Use Limitations and supplemental remarks

As standard, 1 second shall be set for the flashing frequency and 1:1 shall be set for the flash

ON/OFF time ratio.

For flashing usage, refer to 7.5.2.

CDC

WMM

Conceal display control

Write mode modification

×

×

×

STL

SPL

Start lining and separating mosaic characters

Stop lining and separating mosaic characters

{

CSI

Control sequence introducer

{

{: Usable : Usable with conditions

×: Not usable

Possible to use "awaiting processing" only.

The function to specify macros for control codes shall not be used; possible to use default macros only.

Characters with the parameter P1 set to "0" shall not be used in scrolling strings.

Only underlines is used.

For underline usage, refer to 7.5.5.

Only underlines is used.

For box usage, refer to 7.5.4.

- 3-98-

ARIB TR-B15

Version 4.6-E1

Table 7-19 Extended control code set (CSI)

Character Control function Use Limitations and supplemental remarks

Instruction possible only after initialization of the display screen and before appearance of characters with bitmap display and display action or appearance of control code. Only 1-code parameter is used; parameters that can be specified for P11..P1i shall be only 7

(960x540, horizontal writing) and 8 (960x540, vertical writing) for a 960x540 caption plane resolution, and only 9 (720x480, horizontal writing) and 10 (720x480, vertical writing) for a 720x480 caption plane resolution.

Note that if this control code is instructed, it takes precedence over the format specified in caption management data.

CCC

Color composition control

×

RCS

Raster color control

{

Instruction possible only after initialization of the display screen and before appearance of characters with bitmap display and display action or appearance of control code.

For color variations, in addition to colors from 0 (black) to 15 (half bright white) defined in ARIB STD-B24, possible to specify one from 16 to 127 of the common, fixed colors. For raster color control usage, refer to

7.5.3.

ACPS

Action position

{ coordinate setting

SDF

SDP

System data format (display dot pattern setting)

Display position setting

{

{

Instruction possible only after initialization of the display screen and before appearance of characters with bitmap display and display action or appearance of control code.

Instruction possible only after initialization of the display screen and before appearance of characters with bitmap display and display action or appearance of control code.

SSM

Character dot pattern setting

PLD

Partially line forward

×

PLU

Partially line backward

×

SHS

Character spacing setting

{

SVS

Line spacing setting

{

GSM Character

×

Possible to specify only 16x16, 20x20, 24x24, 30x30, and 36x36 dots.

GAA Colored

× The colored areas shall be full-display areas only.

SRC

Raster color setting

×

TCC

Changeover control

×

CFS

Character font setting

×

ORN

Character ornaments setting

Possible to use only without ornaments and with boundry highlighting.

For boundry highlighting usage, refer to 7.5.6.

― 3-99―

ARIB TR-B15

Version 4.6-E1

Character Control function

MDF

PRA

XCS

Character style setting

Preinstalled sound playback

Define external character substitute code string

Use

×

{

×

Limitations and supplemental remarks

Possible to use the single-line word direction scroll

(with rollout, without rollout) only, and for one location, one line only.

Note that there are limitations on control code combinations. (Refer to 7.5.7)

{: Usable : Usable with conditions

×: Not usable

- 3-100-

ARIB TR-B15

Version 4.6-E1

Flashing for 8-bit unit code strings shall be performed as follows: at intervals of approximately one second, text shall flash with the foreground color (including a halftone color for a 4-step gradation font) and background color changing on and off at intervals of 0.5 seconds each, or bitmap data shall flash with the flashing color

(which is specified by the FLC header defined in ARIB STD-B24, Bitmap Pattern Code Encoding) and raster color (if not specified, a transparent color) changing on and off at intervals of 0.5 seconds each. The timing of starting flashing shall be when flashing-specified text is first drawn, or when a bitmap pattern is drawn after flashing colors are specified by bitmap data's FLC header. The relevant text or pixels finish flashing when initialization is performed for the caption management at the time of updating, or when display screen erasure is instructed by CS.

7.5.2.1 Limitations

For the number of flashing colors, besides 128 common, fixed colors for non-flashing text and bitmap data, it shall be made possible to specify a total of 24 colors (halftone colors for a 4-step gradation font included) together for 8-unit code string flashing, and to specify a total of 16 colors together for bitmap data flashing.

From the 128 common, fixed colors, it is possible to freely specify a total of 24 colors (24 colors for text) together for subtitles, and a total of 40 colors (24 colors for text + 16 colors for bitmap data) together for superimposed text.

Only positive-phase flashing is used.

It is prohibited to specify flashing and boundary highlighting together.

It is prohibited to specify flashing and scrolling together.

7.5.3 Raster color control

Boxing shall be performed on the entire display area. An area on which raster color control is performed shall be a rectangle specified by SDF (which specifies display dots) and by SDP (which specifies a display position).

To specify raster color control, a CLUT's index value (refer to Appendix 1) shall be specified in P11..P1i by using RCS (raster color control).

Boxing controls addition of a frame composed of four outer sides in the display block. The box line thickness shall be 1 dot. A box is correctly drawn over the entire display block only in a display block specified in Table 7-16.

(The function to display a box over the entire display block even if character spacing or line spacing is changed freely shall be optional.) When boxing is specified in the word direction or line direction, if a free character or line space of 1 dot or more does not exist in the corresponding direction (word or line), it is not guaranteed that a box can be drawn correctly. Note that the boxing gradation depends on the implementation of the receiver. (The implementation of 4-step box gradation into the receiver is not mandatory.)

― 3-101―

ARIB TR-B15

Version 4.6-E1

An underline shall be drawn with a single-dot thickness on an outer side in the display block. And it shall be added to a side of the next line when in horizontal writing, while it shall be added to a side of the previous line when in vertical writing. An underline is correctly drawn over the entire display block only in a display block specified in Table 7-16. (The function to display an underline over the entire display block even if character spacing or line spacing is changed freely shall be optional.) If a value of less than 2 dots is specified for line spacing, it is not guaranteed that an underline can be drawn correctly. Note that the underlining gradation depends on the implementation of the receiver, including implementation of one-dot thickness underlining for

720x480. (The implementation of 4-step underlining gradation into the receiver is not mandatory.)

7.5.6 Using boundary highlighting

To use boundary highlighting, a value of 2 dots or more shall be specified for character spacing and line spacing respectively. If a value of less than 2 dots is specified for both character and line spacing, it is not guaranteed that boundary highlighting can be displayed correctly. Note that because no halftone is specified, the boundary highlighting gradation depends on the implementation of the receiver. (The implementation of 4-step boundary highlighting gradation into the receiver is not mandatory.)

It shall be prohibited to instruct SCR multiple times in the same text. For scrolling, data shall be transported as a different data unit (text) where a single-line display area is specified by SDF.

The receiver's action when scrolling is specified is as follows:

Scrolling is performed in a rectangle specified by SDF and SDP, text not being drawn beyond that rectangle.

It is considered that a virtual area with a single-character space (specified size) exists to the right of the first line in the display area, and when scrolling (SCR) is specified, the action position shall be set to that virtual write area again.

Characters written in the display area before scrolling shall be erased after scrolling is specified.

Text shall be displayed from its first character, from the right end of the display area.

Scrolling shall start by writing a character to the virtual write area.

When without rollout, scrolling stops after display of the last character.

When with rollout, scrolling continues until all the characters disappear on the screen.

When data to be next displayed is received during scrolling, the end of scrolling shall be awaited.

If character spacing and line spacing values that have been specified for a range from the start of scrolling instruction to the end of scrolling exceed any of the maximum values defined in Table 7-16, scrolling display shall depend on the implementation of the receiver.

Virtual write area

Display area

- 3-102-

ARIB TR-B15

Version 4.6-E1

The following control codes shall not be used from the start of scrolling instruction to the end of scrolling.

Style setting

Size setting

Action position change

Display effects

Time control

Raster color setting

SWF, SDF, and SDP

SZX and SSM

APB, APR, APF, PAPF, APU, APD, APS, ACPS, SHS, and SVS

FLC, STL, SPL, and HLC

TIME

RCS

Note that APB, APR, APF, PAPF, APU, APD, APS, ACPS, FLC, STL, SPL, HLC, and RCS specified before scrolling instruction shall be canceled when scrolling is instructed.

After scrolling (SCR) is specified, the receiver starts scrolling as soon as possible, but there may be delay between when scrolling is specified and when scrolling starts. We recommend a rate of 3 characters/second or less for the scrolling speed. The unit of the dot that moves to one time shall depend on the implementation of the receiver.

7.5.8 Display function priority

Regarding display functions through control codes, display is performed in the following priority:

3 Underlining

4 Boxing

6 Color setting and flashing

Note) Order in the same priority shall be unfixed.

As specified in ARIB STD-B24, Section 1, Part 2, 7.1.1.5, single-byte and double-byte DRCS sets shall be called.

DRCS patterns shall be encoded using pattern transmission only, not using geometric. And 0 shall be specified for fontID (font identification). If any value other than 0 is specified, the receiver interprets it as 0. The buffer secured for DRCS in the receiver shall be 16KB for subtitle DRCS and 16KB for superimposed text DRCS. It shall be made possible to simultaneously use a maximum of 188 DRCS characters for subtitles and superimposed text each.

(If patternData of multiple sizes are arranged into a 1CharacterCode, each piece of data shall be counted as 1.) patternData shall transmit design frame 4-step graduation data.

Table 7-20 DRCS pattern setting parameters

Field

NumberOfCode

As per the specifications.

CharacterCode

As per the specifications.

NumberOfFont

As per the specifications. fontId

Usage

Only 0 can be specified. (A value other than 0 shall be interpreted as 0.) mode depth

Only 0001 can be specified.

Only 2 can be specified. width

As per the specifications. *1 height

As per the specifications. *1 patternData

As per the specifications.

*1 Specify a size defined in 7.4.3 Font size.

― 3-103―

ARIB TR-B15

Version 4.6-E1

The receiver shall behave according to the timing and items of initialization defined as follows, as well as the details described in ARIB STD-B24, Section 1, Part 3, Chapter 8 Initialization. When channel selection is performed, all the items to be initialized relating to captioning shall be initialized.

7.7.1 Initialization through caption management

When the data group of the received caption management data changes from Group A to Group B, or from

Group B to Group A, the receiver shall perform initialization for the caption management at the time of updating defined in ARIB STD-B24. At the above time, the display area and display position shall be set to values in Table 7-13. In addition, the values for font size, character spacing, and line spacing shall be set to values in Table 7-15.

7.7.2 Initialization through caption text

The receiver shall perform initialization defined in ARIB STD-B24 when receiving the same caption text data as that of the data group set and language being processed for presentation.

7.7.3 Initialization through a text data unit

When receiving the same caption text data as that of the data group set and language being processed for presentation, if a text data unit is contained in that caption text data, the receiver shall perform initialization defined in ARIB STD-B24. Note that the default values for initialization shall be as follows: index value=15 for the foreground halftone color, and index value=30 for the background halftone color.

7.7.4 Initialization through character control code

The receiver shall perform initialization defined in ARIB STD-B24 immediately before it starts processing screen erasure (CS) and format setting (SWF). Note that the default values for initialization shall be as follows: index value=15 for the foreground halftone color, and index value=30 for the background halftone color.

7.8 Mono-media used in subtitles and superimposed text

Geometric shall not be used in subtitles or superimposed text.

7.8.2 Using bitmap data

Bitmap data can be used in superimposed text. However, usable colors shall be 128 fixed colors that are common across receivers.

7.8.3 Using warning sounds

Possible to use warning sounds for both subtitles and superimposed text. They shall be limited to preinstalled sounds only.

7.8.4 Using additional sounds

Shall not be used in subtitles or superimposed text.

- 3-104-

ARIB TR-B15

Version 4.6-E1

7.9 Preferred receiver's action

Number of events that can be simultaneously displayed for subtitles and superimposed text shall be one for

• subtitles and one for superimposed text, i.e. 2 in total.

Presentation of subtitles and presentation of superimposed text shall be controlled independently on the

• receiver.

In principle, the display areas for subtitles and superimposed text shall not overlap each other. However, if

• overlapping occurs, superimposed text shall take precedence and shall be displayed over subtitles.

In subtitles and superimposed text each, if bitmap data and text, or bitmap data and other bitmap data

• overlap each other, data or text appearing later shall take precedence.

In data broadcasting programs, subtitles and superimposed text shall be displayed with the display size and

• display position adjusted in relation to the full screen area.

Based on whether or not caption management data is received, the receiver shall judge whether or not caption data is transmitted. For display of a mark notifying the viewer of caption text reception or display and erasure of caption text, operation shall be performed based on the relevant data. Considering interruption of transmission of the relevant data, such as interruption due to commercial messages, it is preferable to start timeout processing if caption management data is not received for 3 minutes or more. Display control, such as EIT data, working in conjunction with other data shall depend on the receiver.

7.9.1 Start and end of subtitling display

The receiver's action at the start and end of subtitling display shall be as shown in Table 7-21. Note that the start means "starting the subtitling display specified for subtitle text" and that the end means "erasing the subtitles".

Table 7-21 Use of DMF in caption management data

DMF

Auto display at reception

Start

When reception is complete, the relevant subtitles shall be displayed immediately.

Erasure not permitted before completion of reception.

Nothing shall be done.

End

When reception is finished, the relevant subtitles shall be erased immediately.

No auto display at reception

Selective display at reception

When reception is complete, it is preferable to present some information indicating the existence of subtitles and superimposed text.

Display or erasure permitted according to the viewer's choice.

Note that usage when recording/playing shall follow the one for reception.

Nothing shall be done.

When reception is finished, if the relevant subtitles are displayed, they shall be erased immediately.

If they are not displayed, nothing shall be done.

7.9.2 Start and end of superimposed text display

Shall be the same as the start and end of subtitling display

7.9.3 Setting items on the receiver

The receiver shall display subtitles and superimposed text of the language last selected. For example, while viewing some program, if subtitling in the second language is selected, display in the second language shall be made at the time another program with subtitles starts.

The receiver shall display the first language by factory default.

― 3-105―

ARIB TR-B15

Version 4.6-E1

A receiver to which language code, such as Japanese and English, can be set shall display subtitles and superimposed text in the language that has been set.

If subtitles and superimposed text in the language or language code set to the receiver are not transmitted, the receiver shall display subtitles and superimposed text in the first language.

- 3-106-

ARIB TR-B15

Version 4.6-E1

8.1 Introduction

For the use of multimedia encoding, in principle, follow ARIB STD-B24, Section 2 "XML-based Multimedia

Encoding Method":

"Appendix 1 Usage Guidelines"

"Appendix 2 Usage Guidelines for Operation of Basic Services"

This chapter defines items not defined in the above documentation.

8.2 Using NVRAM commonly used for MM services

As NVRAM space allocated for the use of storage of persistent information, the broadcaster common area and broadcaster specific area, shown in Table 8-1, shall be provided. The details of data stored into the broadcaster-shared and broadcaster specific areas shall depend on contents defined across broadcasters or contents individually defined by broadcasters.

Table 8-1 NVRAM used for the broadcaster-shared and broadcaster specific areas

Type

Broadcaster common area

Broadcaster specific area

Area that can be shared for use by all broadcasters.

Area occupied by individual broadcasters

Meaning NVRAM size

1KB

(64-byte fixed-length block *16)

• 1KB per broadcaster

(64-byte fixed-length block *16)

• Number of broadcasters: 64

Devices to which writing can be done only a limited number of times are used for NVRAM mounted on the receiver. Writing more than the specified number of times to such devices can cause failure and result in the shortening of the receiver's life. So, it is preferable that enough consideration shall be given to prevention of excessive writing to NVRAM. The details about the above shall be described in Appendix 3.

If the ID used by the previous broadcaster is assigned to the local broadcaster ID (broadcaster_id), a new broadcaster should completely erase the relevant part of the broadcaster specific NVRAM area before use. For the above, refer to Appendix 5.

8.2.1 Identifying the broadcaster common area

To read/write information from/to the broadcaster common area from MM services, readPersistentArray()/writePersistentArray() shall execute by interpreting one fixed-length block as one file.

Reading/writing information from/to the broadcaster common area from MM services shall execute in units of fixed-length blocks. The URI shown below is used for identification of fixed-length blocks. nvram://common/<block-number>

<block-number>: 0 - 15

Regarding the use of the broadcaster common area for both-way communication, refer to Section 6.

― 3-107―

ARIB TR-B15

Version 4.6-E1

8.2.2 Identifying the broadcaster specific area

As with the broadcaster common area, operation for the broadcaster specific area shall be performed in units of fixed-length blocks. To read/write information from/to the broadcaster specific area from MM services, the URI shown below is used for identification of blocks. nvram://-/<block-number>

- : Broadcaster ID of a broadcaster to provide MM services

(broadcaster_id)

If a procedure function for the broadcaster specific area (readPersistentArray(), or writePersistentArray()) executes by specifying names in a way different from the above, NVRAM reading/writing shall not execute, but readPersistentArray() shall respond with null (failure) as a return value, and writePersistentArray() shall respond with NaN (failure) as a return value. The above means that it is not possible to reference another broadcaster's part of the broadcaster specific area.

8.2.3 Using information on the right to access the area reserved for BS digital broadcasters,

for wide band CS digital broadcasters

In BS digital broadcasting, a broadcaster can set access right information for its own part of the broadcaster specific area to permit access to that part from services executed by other broadcasters. Reading/writing information from/to the BS-broadcaster specific area by other broadcasters shall be performed based on the above access right information. The BS-broadcaster specific area shall not include an area used for writing information on the right to access blocks. X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() shall execute to set access right information. To permit access to the BS-broadcaster specific area from services executed by other broadcasters, a BS broadcaster shall at least write, in its local content,

X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() in the GlobalCode or onload in a document, such as a startup document, that never fails to execute, and then create a BML document to ensure execution of the relevant function. Access right information shall be set, block-by-block, based on the fixed-length blocks in the broadcaster specific area. z X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider(): Sets information of an access right to the local part of the broadcaster specific NVRAM area for other broadcasters.

Syntax:

Number X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider( input String blockNumber, input Array permissionData

)

Arguments: blockNumber permissionData

Block number of the NVRAM area to which the right of access is set

Access right information

Return value:

1:

NaN:

Success

Unsuccessful

Description:

Sets the access right specified in permissionData to a block that has been specified by blockNumber for the local part of the broadcaster specific area. A block number (0-15) for the

- 3-108-

ARIB TR-B15

Version 4.6-E1 local part of the broadcaster specific NVRAM area shall be written to blockNumber. To specify multiple blocks, the setting should be made per block multiple times. For the array specified as permissionData, refer to Table 8-2.

If X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() has never been executed for some part of the BS-broadcaster specific area, the state of that part shall be such that access permission for other broadcasters has never been granted. In other words, the above state is equal to the state of execution with a valid Update value set to the first element and -1 set to the second and third elements each in the permissionData of

X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider().

Table 8-2 Array format for access right information setting permissionData description

First element

Update (date access right information was updated)

"YYYYMMDDHHMM"

(12-byte decimal number string)

Second element

Network ID (original_network_id expressed in a hexadecimal number string in the format of "xxxx").

Possible to set only the network ID ("0006" or "0007") of a wide band

CS digital broadcaster described in ARIB TR-B15, Part 2, Section 7.

Note that if the string "-1" is set to both 2nd and 3rd elements, the right to access the part of the NVRAM area with the relevant blockNumber for other broadcasters shall be set to "not accessible".

Third element

Broadcaster ID (broadcaster__id expressed in a hexadecimal number string in the format of "xx").

Possible to set only the broadcaster IDs of wide band CS digital broadcasters described in ARIB TR-B15, Part 2, Section 7.

Note that if the string "-1" is set to both 2nd and 3rd elements, the right to access the part of the NVRAM area with the relevant blockNumber for other broadcasters shall be set to "not accessible".

Fourth element

Service ID (service_id expressed in a hexadecimal number string in the format of "xxxx").

Possible to set only the service ID of wide band CS digital broadcasters described in ARIB TR-B15, Part 2, Section 7.

Note that if the 4th element is omitted, the right to access the part of the

NVRAM area with the relevant blockNumber for all the services of all the broadcasters specified in the 3rd element shall be set to "accessible".

Array of access right information

The date the access right in X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() (which sets access right information) changed shall be set to Update. If the date set to Update passed the date of access right information update held in the receiver, the access right information shall be judged as updated.

However, if a not-yet-passed date is set to Update, the date set shall be judged as an invalid one and the access right information set in X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() shall be regarded as invalid. X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() shall be executable only when a valid date is set to Update in it.

- Valid date that can be set to Update

A date that passed the date of access right information update held by the receiver. And, a date that has not passed the date X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() was executed.

Example:

― 3-109―

ARIB TR-B15

Version 4.6-E1

Valid date: a ≤ x < b

Invalid date: x < a, x ≥ b x: Date to be set to Update a: Date of update held by the receiver b: Date X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider() was executed a b

Invalid date

(Cannot be set to Update)

Valid date

(Can be set to Update)

Invalid date

Time

(Cannot be set to Update)

Actions of broadcasting-use extended functions for the BS-broadcaster specific area

The broadcasting-use extended functions (writePersitentArray()/readPersitentArray(),

X_BPA_writePersitentArrayForAnotherProviderWithAccessCheck()/X_BPA_readPersitentArrayForAnotherP roviderWithAccessCheck()) can operate in the conditions shown in Table 8-3.

X_BPA_writePersitentArrayWithAccessCheck()/X_BPA_readPersitentArrayWithAccessCheck() execute according to access right information held by the receiver. Reading/writing shall be permitted only when access right information which is held by the receiver and which specifies wide band CS digital broadcasters allowed to access the relevant part of the BS-digital-broadcaster specific area matches a set of original_network_id and broadcaster_id for the broadcasters of services transmitting content that requests such access.

Table 8-3 Actions of broadcasting-use extended functions for

Access from local content

Access from another station content the BS-broadcaster specific area

Broadcasting-use extended function writePersitentArray() readPersitentArray()

X_BPA_writePersitentArrayForAnotherP roviderWithAccessCheck()

X_BPA_readPersitentArrayForAnotherPr oviderWithAccessCheck() writePersitentArray() readPersitentArray()

X_BPA_writePersitentArrayForAnotherP roviderWithAccessCheck()

X_BPA_readPersitentArrayForAnotherPr oviderWithAccessCheck()

Access permitted or denied

{

(Accessible regardless of the access right for other broadcasters set in

X_BPA_setAccsesInfoOfPersistentArray

ForAnotherProvider())

×

×

{ (Accessible only by wide band CS digital broadcasters given access permission)

- 3-110-

ARIB TR-B15

Version 4.6-E1

8.2.4 Use of the viewer's place of residence information from MM services

The following URI is used to read/write from/to the "viewer's place of residence information" (which is expected to be stored into NVRAM by the initial setting function on the receiver) from MM services. nvram://receiverinfo/<regiontype>

Table 8-4 shows strings that can be set as <regiontype>. For details of the viewer's place of residence information, refer to Section 2.

<regiontype> regioncode zipcode

Table 8-4 Types of the viewer's place of residence information

Type target area descriptor (bit position in the prefecture setting bitmap (ARIB

STD-B10 Appendix G, Table G-2))

Area code that supports emergency information signals (the Ordinance for Regulating Radio Equipment,

Clause 9, Section 3, No. 5, The

Ordinance for Regulating the

Operations of Radio Stations, Clause

138, and MPT Bulettin's 60 No. 405)

Postal code (7 digits)

Read/Write from MM services

Only Read possible as a numeric value.

Only Read possible as a numeric value.

Read/Write possible as a fixed-length string with a length of 7.

(Example: 5001234)

Field type

U:1B

U:2B

(For the lower 12 bits.

0 for all the upper 4 bits.)

S:7B

If values for the broadcaster-shared and broadcaster specific areas are not set, an empty string (0 when reading as a numeric value) shall be returned. In addition, when the viewer's place of residence information is not set, 255 shall be returned for regiontype of prefecture, 0 shall be returned for regiontpe of regioncode, and an empty string shall be returned for regiontype of zipcode.

8.3 Using remote control keys from MM services

8.3.1 Possible values for used-key-list attributes

The following table shows correspondence between remote control keys and <key-group> values that can be set to

"used-key-list" of style attributes, which control exclusive operations between the BML browser and the channel selection function to be processed by remote control keys.

Table 8.5 Possible key-group values

<key-group>

Basic data-button numeric-tuning other-tuning

Meaning

Arrow keys (

↑, ↓, →, ←), Enter key, Back key

Color keys (blue, red, green, yellow)

Channel selection numeric keys (0 to 9, 10, 11, 12, etc)

Channel-selection-related keys (one-touch select button, channel up/down key, video key)

Control over the "Data" button through used-key-list attributes shall be prohibited; if the "Data" button is pressed while the BML browser is active, processing should be handled by the BML browser.

If a key with a channel selection function other than the ones shown above exists, whether or not it is to be included in other-tuning shall depend on the receiver.

― 3-111―

ARIB TR-B15

Version 4.6-E1

8.3.2 Correspondence between remote control keys, key codes, and access keys

Table 8-6 shows a mapping of remote control keys that can be used by MM services and key codes and characters to be set as access keys.

Table 8-6 List of correspondence between remote control keys, key codes, and access keys

Remote control key

0 - 9, 10, 11, 12

Key code Access key character

1 N/A

2 N/A

3 N/A

4 N/A

5-17 N/A

"Data"

Color key (blue)

Color key (red)

Color key (green)

Color key (yellow)

Channel-selection-related keys belonging to other-tuning

20

21

22

23

N/A

'B'

'R'

'G'

24 'Y'

150- N/A

When the "Data" button is pressed, only a DataButtonPressed interruption event shall occur; a keydown or

• keyup interruption event shall not occur.

Channel selection numeric keys other than 0 to 9, or channel-selection-related keys shall not be used for purposes other than detection of channel selection operation in content using online network transmission.

In addition, key codes to be assigned to channel-selection-related keys shall depend on the receiver.

8.3.3 Guidelines for content that uses selection by color keys

To create content that has only color keys as a selection method, some indicator other than color such as a character shall be made available for identification of a color key the viewer should select.

8.4 Use of BML versions

Versions of BML documentation used in this operation shall be as shown below, and they shall be fixed as the default versions.

Table 8-7 BML document version

Type Value bml_major_version 1 bml_minor_version 0

The receiver shall always secure 1MB free space to obtain modules from carousels; if 1MB memory space

• cannot be secured when lockModuleOnMemory() executes, this function shall not process module locking.

Even if the versions of modules locked on memory are updated, the receiver shall not automatically re-obtain such modules. Procedures for detecting modules, releasing the lock, and re-locking modules on memory shall be written in a BML document.

- 3-112-

ARIB TR-B15

Version 4.6-E1

8.6 Transporting DRCS pattern data

• loadDRCS() shall used to set DRCS pattern data used both in BML documentation and in 8-unit code to be referenced externally.

DRCS patterns with multiple fonts and multiple sizes may be transmitted against 1 CharacerCode.

The maximum size of DRCS pattern data used in BML documentation simultaneously shall be 64KB.

The relationship between fontIDs specified in DRCS pattern data and fonts shall be as shown in Table 8-8.

And fontID=0 shall not be used.

Table 8-8 DRCS fontID-font correspondence fontID Font

1 Maru-Gothic

2 Kaku-Gothic

8.7 Using name spaces

Reference to another service shall be made possible only by using the following broadcasting-use extended functions: epgTune, epgIsReserved, epgReserve, epgCancelReservation, epgRecIsReserved,epgRecReserve, epgRecCancelReservation

For services other than data broadcasting services based on storage functionality, all descriptions in BML documentation shall use abbreviations (refer to ARIB STD-B24, Section 2, 9.2), with the exception of reference to other services mentioned above, and arguments directed to broadcasting-use functions whose arguments specify events.

Except for arguments directed to broadcasting-use functions whose arguments specify events, event_id is always omitted. Module update monitoring (ModuleUpdated), locking of modules on memory

(lockModuleOnMemory), cache (setCachePriority), and referencing of resources such as mono-media from BML documentation shall target only modules to be transported by the same components as the currently presented document contains.

A value that can be specified to the href attribute of the anchor element in launchDocument() shall be only a BML document to be transmitted via a component contained in the same service as the currently presented document provides. However, for pre-stored supported receivers, refer to 9.2.11.1.

The number of resources that content can obtain and retain in the content memory on the receiver simultaneously shall be limited to 384. To realize the above limitations, it is preferable to restrict the total number of resources (which have unique name spaces each) within a single-data-event period to 384 or less. However, if it is ensured at the time of content creation that the above limitations, on the receiver, can be realized, it is possible that the total number of resources within a single-data-event period be 384 or more.

Contrary to the above limitations, if locking of more resources than the above is instructed by lockModuleOnMemory(), the receiver may not do so.

Note that the resources here refer to the following two types:

- Resources directly mapped on modules

― 3-113―

ARIB TR-B15

Version 4.6-E1

- Resources stored into modules in the format of an HTTP/1.1 entity

8.8 Using BML element extension modules (interrupt event)

It shall be made possible to enable a maximum of 16 ModuleUpdated interrupt events at the same time.

It shall be made possible to enable a maximum of 8 TimerFired interrupt events at the same time. Timer shall immediately fire if times specified in TimerFired for Absolute time at playback, Time at reception, or

NPT time are discovered to be ones that already passed at the point of interpreting a BML document.

8.9 Using procedural scripting languages

Time handled by ECMA Script's Date object shall be JST(UTC + 9 hours), time to which summer time offset time is not added. If a local time reflecting summer time offset is needed for display of the present time, that local time shall be obtained such that a time offset value is added, by using addDate(), to the time that has been obtained by content with the Date() function.

To obtain cardID as a receiver-specific identifier by using the broadcasting-use extended function getIRDID(), CA_system_id shall be specified for type as specified in ARIB STD-B24. A return value shall be a string expressed in hexadecimal notation ("0x" not put at its top). The function shall not be used that obtains receiverID as hardware and obtains MakerID and ModelID used for downloading.

Support for the series-recording-reservation-related API (broadcasting-use extended functions seriesReserve(), seriesRecReserve(), etc.) shall be optional for the basic receiver unit. Whether or not receivers support the above API shall be identified by calling getBrowserSupport("BSP", "EPGFunction",

"seriesReservation"), and only the receivers that returns 1 to that call can use that API.

<series_scope_ref> used for identification of series shall be

<network_id>/<broadcater_id>/<media_type>. Where,

<network_id> Network ID (4 digits in hexadecimal notation)

<broadcaster_id> Broadcaster ID (2 digits in hexadecimal notation)

<media type> Media type

2 Audio media type

3 Data media type

For IDs specified in hexadecimal numbers, "0x" shall not be put at the beginning of a number string, and

"h" shall not be put at the end of a number string.

8.10 Use of getPrefixNumber()

• getPrefixNumber(), which was added in ARIB STD-B24 Ver3.0, shall be applicable to receivers sold after publication of the version 2.2 revision of this document, and shall be applicable to all receivers sold as new models from one year after that revision. It shall use the following Array:

Array[2] (Settings for the number of a caller ID notification)

Array[3] (Settings for the preferred fixed-connection release number)

Array[4] (Settings for the telecommunication carrier identification number)

A return value shall be limited to a number or " " (empty string) only.

- 3-114-

ARIB TR-B15

Version 4.6-E1

From the viewpoint of protection of private information, a return value shall not be transmitted as information.

[Notes on compatibility]

For the use of this function, it is assumed that the following three revisions, which have been defined after the version 2.2 of this document, shall be all reflected in target receivers.

2) The number addition function in Section 6, 6.4.2 implemented as "A Specification".

3) Process for network setting identification (bProvider argument in connect()) implemented in accordance with Section 6, 6.3.1 Telephone number transmission conditions.

This function shall be applicable to receivers sold after publication of the version 2.2 revision of this document, and shall be applicable to all receivers sold as new models from one year after that revision.

However, considering receivers sold before the above, it is mandatory to check whether or not receivers support this function by using getBrowserSupport() prior to use. If the above cannot be confirmed, this function shall not be executed.

For receivers sold before the version 2.1 of this document, some receivers support the number addition function, while others do not support it. In the former, even when "off" is set to the network setting identification, if the caller ID notification (186/184) is set, number addition will be performed as a receiver function. In the above case, if prefix playback is performed in content, a call cannot be sent correctly due to overlapping of prefixes. Much attention shall be paid to this point at the time of content creation.

8.11 Using encrypted communication in the interactive communication feature

The functions for encrypted communication in the interactive communication feature

(startCASEncryption(), endCASEncryption(), transmitWithCASEncryption()) shall not be used.

― 3-115―

ARIB TR-B15

Version 4.6-E1

9 Operations of Data Broadcasting Services Based on Storage Functionality

9.1 Operations related to storable program

A component or content can be stored if 1 is specified to file_storable_flag in its PMT's data encoding method descriptor or its EIT's data content descriptor. "Linked pre-stored data programs" and "Independent pre-stored data program" will be defined in the following as well as specifications for operations related to their storage, but that will not restrict storage operations of other data broadcasting programs.

Note that the basic receiver unit shall support all described in this chapter as an option.

Definitions

Linked pre-stored data programs

Independent data programs interactively linked to television programs or data-enriched television programs, through hyperlink descriptors with the hyper_linkage_type specified as 0x80(combined_prior_data) and

0x81(combined_posterior_stream). They shall be broadcast in services with the service_type specified as

0xA8. They are assumed to be broadcast before the event times of television programs or data-enriched television programs and assumed to be viewed after being stored. Like independent data broadcasting services, after storage, these programs may be viewable as independent programs.

Independent pre-stored data program

Of programs to be broadcast with the service_type specified as 0xA8, programs other than linked pre-stored data programs. They are based on storage and, like independent data broadcasting services, viewable as independent programs after storage.

9.2 Operation related to linked pre-stored data programs

9.2.1 Controlling the viewing of linked pre-stored data programs

For the operation of linked pre-stored data programs, real-time viewing shall be prohibited in the PMT/EIT's on-demand viewing permission information (ondemand_retrieval_flag).

9.2.2 service_type of channels that operate linked pre-stored data programs

Linked pre-stored data programs shall be broadcast in services with the service_type set to 0xA8.

9.2.3 Schedule patterns of linked pre-stored data programs and operation restrictions

Linked pre-stored data programs shall be linked interactively to television programs or data-enriched television programs through the EIT's hyperlink descriptors. For details on how to use hyperlink descriptors, refer to 9.2.8.

Linked pre-stored data programs hyperlinked to a single television program or data-enriched television program may be broadcast multiple times.

- 3-116-

Restrictions on the operation of linked pre-stored data programs

Table 9-1 shows restrictions on the operation of linked pre-stored data programs

Table 9-1 Restrictions on the operation of linked pre-stored data programs

ARIB TR-B15

Version 4.6-E1

Limitations Description

Broadcast time constraints For linked pre-stored data broadcasting programs and video programs associated with them via hyperlinks, their broadcast times shall not overlap each other.

Constraints when programs are broadcast multiple times

If multiple linked pre-stored data programs are sent for the same television program or data-enriched television program, the content_id of content contained in each event shall be the same across events.

Constraints on program structure

Linked pre-stored data programs shall be composed of data only, not transmitting video/audio streams.

9.2.4 Use of the PMT's data encoding method descriptor in linked pre-stored data programs

Regarding storage, linked pre-stored data broadcasting programs shall be stored together with information of the PMT's data encoding method descriptor, and the stored information shown below is used for playback of data broadcasting programs that have been stored.

Table 9-2 Use of the PMT's data encoding method descriptor in linked pre-stored data programs

Field auto_start_flag ondemand_retrieval_flag independent_flag

Usage

Either 0 or 1 is used. For the interpretation of auto_start_flag, refer to 9.2.4.1.

Always 0. (Real-time viewing shall be prohibited.)

If this value is 0, and if playback with the video and sound of a linked television program or data-enriched television program is not possible, it shall be judged that viewing the relevant linked pre-stored data program is not possible.

9.2.4.1 Use of auto_start_flag in linked pre-stored data programs

To view programs with hyperlinks set to linked pre-stored data programs, receivers that support linked pre-stored data programs shall interpret the auto_start_flag of the PMT's entry component as follows:

1) For the viewing of a television program or data-enriched television program for which a linked pre-stored data program is stored, data content in that linked pre-stored data program stored shall be presented based on the auto_start_flag of the entry component in the linked pre-stored data program.

2) If a linked pre-stored data program linked to a data-enriched television program is not stored, data content in the data-enriched television program shall be presented based on the auto_start_flag of the entry component in the data-enriched television program.

9.2.5 Use of the PMT's target area descriptor in linked pre-stored data programs

The target area descriptor shall not be used in linked pre-stored data programs

― 3-117―

ARIB TR-B15

Version 4.6-E1

9.2.6 Use of the PMT's digital copy control descriptor in linked pre-stored data programs

Content to be transported through a digital copy prohibited component shall be made viewable after storage too.

However, digital output of the relevant component from the receiver shall be restricted by the setting of the relevant descriptor.

9.2.7 Use of the p/f EIT's data content descriptor in linked pre-stored data programs

Information of components to be used before storage operation shall be based on the present EIT.

Data content descriptors shall be put for all content that shall be pre-stored and for all other content that shall be referenced by the component_ref of the content pre-stored.

A value for the component_size of a data content descriptor shall be a total size of modules to be transported in the relevant content.

It shall be ensured that content_id is put for content to be pre-stored.

• file_storable_flag is always 1.

9.2.8 Use of the p/f EIT's hyperlink descriptors in linked pre-stored data programs

Receivers that support linked pre-stored data programs shall interpret the hyperlink descriptors specified as follows:

9.2.8.1 Types of hyperlink to be used

For linked pre-stored data programs, combined_prior_data(0x80) and combined_posterior_stream(0x81) shall be newly defined as hyper_linkage_type for operation.

Table 9-3 Types of hyperlink to be used

Hyper_linkage_type combined_prior_data(0x80) combined_posterior_stream(0x81)

Details of use

Used for specifying hyperlink from a television program or data-enriched television program to a linked pre-stored data program.

For Selector_bye, write an event of a link destination linked pre-stored data program.

Specify only link_to_event(0x02) for the link destination type

(link_destination_type).

Used for specifying hyperlink from a linked pre-stored data program to a television program or data-enriched television program.

For Selector_byte, write an event of a link destination television program or data-enriched television program.

Specify only link_to_event(0x02) for the link destination type

(link_destination_type).

- 3-118-

ARIB TR-B15

Version 4.6-E1

9.2.8.2 Hyperlink descriptor operation rules

Use of hyperlinks with the hyper_linkage_type specified as combined_prior_data(0x80) or combined_posterior_stream(0x81).

1) Hyperlinks shall be set both ways between television program or data-enriched television program and linked pre-stored data program.

2) For transmission of multiple linked pre-stored data programs for the same television program or data-enriched television program, multiple hyperlink descriptors shall be put for the EIT of that television program or data-enriched television program.

3) Linkage may be specified from a linked pre-stored data program to multiple television programs or data-enriched television programs that provide different services at the same start time, for the same duration. In such a case, multiple hyperlink descriptors shall be put for the EIT of that linked pre-stored data program.

4) Times of link source events and link destination events shall not layering each other.

5) Hyperlinks across TSs may be used.

9.2.8.3 Program types and transmission of hyperlink descriptors

Table 9-4 Program types and transmission of hyperlink descriptors

Program types

Television program

Data-enriched television program

Linked pre-stored data programs

Transmission details

May send a hyperlink descriptor (hyper_linkage_type=0x80). (If a linked pre-stored data program exists.)

May send a hyperlink descriptor (hyper_linkage_type=0x80). (If a linked pre-stored data program exists.)

Always sends a hyperlink descriptor (hyper_linkage_type=0x81).

9.2.8.4 Operation when multiple hyperlink descriptors are put

The following describes operation when multiple hyperlink descriptors (hyper_linkage_type=0x80), from a television program or data-enriched television program to a linked pre-stored data program, are put.

1) Multiple hyperlink descriptors with the same hyper_linkage_type can be put for a single event.

2) Maximum number of hyperlink descriptors in a single event

Total number of hyperlink descriptors in a single event shall be maximum 16.

3) Rule on order of appearance for multiple hyperlink descriptors

Hyperlink descriptors with the same hyper_linkage_type shall be inserted in order of event start time.

4) Storage when multiple hyperlink descriptors are inserted

For selection criteria of programs to be stored among multiple linked pre-stored data programs, refer to

9.2.14.3.

9.2.9 Use of DII related to storage of linked pre-stored data programs

In principle, DII version updates shall not occur during an event in linked pre-stored data programs. So, basically, transaction_id does not change during an event.

― 3-119―

ARIB TR-B15

Version 4.6-E1

9.2.10 Use of carousels related to storage of linked pre-stored data programs

In principle, module updates shall not occur during an event in linked pre-stored data programs. Once all

• modules have been completely stored, the receiver can finish storage operation.

In an event to be stored, basically, its event period and the start and end times of local content to be transported (data event) shall be "consistent ". A data event whose start and end times are consistent with the event period refers to a data event operated by the transmit side under the following conditions, and only when the following conditions are met, 1 shall be assigned to the file_storable_flag of its data content descriptor and data encoding method descriptor each.

1. The first DII of storage target local content shall be transmitted within 10 seconds after the start time of an event. However, a data event with an empty carousel may be transmitted within 5 seconds after the start time of an event (refer to the next section); in such a case, a data event to be stored shall be transmitted immediately after the data event with an empty carousel.

2. In principle, transmission of DII for local content to be stored shall be completed before the end time of the relevant event. In case transmission needs to extend beyond the end time of the relevant event, it shall be completed within a maximum of one second.

An empty carousel may be transmitted for prevention of improper storage operation at break points between events. In such a case, the transmission period of an empty carousel shall be a maximum of 5 seconds after the start time of an event.

9.2.11 Use of the multimedia encoding method related to linked pre-stored data programs

9.2.11.1 Operations related to name spaces

During playback of a linked pre-stored data program stored, the es_ref setting - a shortened form of setting

(component setting not specifying event_id) in EventMessageFired interrupt events - shall be interpreted as a component of a television program or data-enriched television program. Other component settings shall

• be interpreted as data carousels of the relevant linked pre-stored data program in storage.

In linked pre-stored data programs, AV streams shall be transmitted with the default setting (-1) only.

Stored modules (resources) shall be saved so that they become accessible via the name space indicated in

ARIB STD-B24, Section 2, 9.2.12, i.e. arib://original_network_id.transport_stream_id.service_id;content_id

/component_tag/moduleId[/resourceName].

For reference to modules that are on the air or that are stored from BML documents contained in stored modules, regardless of specifications in 8.7, modules that have been transported by other services and stored shall be made referable too.

9.2.12 Use of event messages related to storage of linked pre-stored data programs

Event messages or NPT shall not be transmitted in linked pre-stored data programs.

A linked pre-stored data program may reference a general-purpose event message and NPT reference message transported on a linked television program or data-enriched television program.

Although it is just a television program, a television program linked to a linked pre-stored data program may transmit event messages.

If an event message is transported on a television program or data-enriched television program for which a

- 3-120-

ARIB TR-B15

Version 4.6-E1 linked pre-stored data program is stored, the data broadcasting engine should receive when needed the stream that transports the relevant message.

9.2.12.1 Operating an event message transmission specification in television programs or data-enriched television programs for which a linked pre-stored data program exists

Because data content does not exist in a television program, data content descriptors shall not be stored in its EIT. (To be strictly treated as an ordinary television program.)

For components to transport event messages in the relevant television program, they shall be operated in the same way as in data programs. (Components with stream_type=0x0D)

When playing a stored linked pre-stored data program, the data broadcasting engine shall receive event messages according to the settings of a BML document. In such a case, e_ref shall not be omitted in the

BML document, and components shall be specified explicitly.

9.2.13 Guidelines on the receiver's actions related to linked pre-stored data programs at channel selection

Table 9-5 Receiver's actions related to linked pre-stored data programs at channel selection

Selection method Selection operation

Channel selection

Selecting a on the remote control data-enriched television program

Operation when the Data button on the remote control is pressed

Selecting a television program

Selecting a linked pre-stored data program

When viewing a data-enriched television program and when data content is inactive

When viewing a television program and when data content is inactive

Receiver's action

When a linked pre-stored data program is stored:

If 1 is set to auto_start_flag in the data encoding method descriptor of a linked pre-stored data program, launches the data broadcasting engine and starts presenting a startup document in the entry component of the relevant linked pre-stored data program. If the setting is 0, does not launch the data broadcasting engine and waits until the Data button is pressed by the viewer.

When a linked pre-stored data program is not stored:

If 1 is set to auto_start_flag in the data encoding method descriptor of a data-enriched television program, launches the data broadcasting engine and starts presenting a startup document in the entry component of the relevant event. If the setting is 0, does not launch the data broadcasting engine and waits until the Data button is pressed by the viewer.

When a linked pre-stored data program is stored:

If 1 is set to auto_start_flag in a linked pre-stored data program, launches the data broadcasting engine and starts presenting a startup document in the entry component of the relevant linked data program. If the setting is

0, does not launch the data broadcasting engine and waits until the Data button is pressed by the viewer.

Does not play data because for linked pre-stored data programs, real-time viewing is prohibited in the PMT's on-demand viewing permission information. Displays a message for a certain time interval.

When a linked pre-stored data program is not stored:

Starts presenting a startup document in the entry component of a data-enriched television program.

When a linked pre-stored data program is stored:

Starts presenting a startup document in the entry component of the relevant linked pre-stored data program.

When a linked pre-stored data program is not stored:

No action.

When a linked pre-stored data program is stored:

― 3-121―

ARIB TR-B15

Version 4.6-E1

Selection from

EPG (selection from stored program list

(tentative name))

Directly selecting content in a linked pre-stored data program

Starts presenting a startup document in the entry component of the relevant linked pre-stored data program.

Launches the content selected.

Even when independent viewing of the relevant content is prohibited in the PMT and the related video/sound is not stored, if a linked television program/data-enriched television program is on the air, it is preferable that the relevant television program/data-enriched television program will be selected and the relevant content will be then launched with the video and sound of such a program.

9.2.13.1 Launching the data broadcasting engine

In any of the following conditions, if auto_start_flag=1 for the relevant linked pre-stored data program, the data broadcasting engine shall automatically start.

When a selection is made for a television program or data-enriched television program for which a linked pre-stored data program linked to it is stored.

When the television program event changes to a new one while continuously viewing the same channel and when a linked pre-stored data program for that new television program event is stored.

Note that during presentation of data content in a linked pre-stored data program, if the television program event changes to a television program event that no linked pre-stored data program is linked to or stored for, the presentation shall continue. In this case, because data content can be terminated only by channel selection, it is preferable that the data content in a linked pre-stored data program has the function to reselect a channel by using the channel selection process directed at the local service (epgTune()).

9.2.13.2 Receiver's action related to linked pre-stored data programs when a data broadcasting program starts

This section presents guidelines on reception operation at the start of a data broadcasting program including a stored linked pre-stored data program.

Receiver's basic actions (guidelines) at channel selection

The following shall be added to the receiver's basic actions (guidelines) at channel selection specified in 9.2.13:

1. When a television program or data-enriched television program is selected, the existence of data broadcasting programs stored is checked. If a linked pre-stored data program linked to the selected program is stored, the receiver shall execute a judgment process with respect to the launch of data broadcasting for the relevant linked data program. If the above condition is not met, as usual, the receiver shall execute a judgment process with respect to the launch of data broadcasting for the program selected.

2. For judgment on the launch of the data broadcasting engine, judgment based on independent_flag shall be added.

Presentation of data broadcasting services shall not be performed, if independent viewing permission information specified by a data encoding method descriptor in the entry component is set to independent viewing prohibited, or if stored data and video and sound are not played together (if playback is not in progress with a television program/data-enriched television program that is linked to a linked pre-stored data program).

Note that monitoring of return to entry flags is not necessary during presentation of data content in a linked pre-stored data program.

- 3-122-

ARIB TR-B15

Version 4.6-E1

9.2.14 Processing for programmed storage of a linked pre-stored data program

9.2.14.1 Processing for programmed storage (guidelines)

1) Programmed storage shall be performed from an EPG and data broadcasting engine. For details on the extended API for programmed storage, refer to 9.4.

2) Storage shall be performed in units of events and in units of contents.

3) For components to be stored, programmed storage shall be performed on all the components referenced by component_ref in a data content descriptor.

4) Programmed storage of events shall be permitted only when all the contents have the file_storable_flag set to 1.

9.2.14.2 How to calculate the size of content

The size of content shall be judged by a total of component_size values of content referenced by entry_component and component_ref in the data content descriptor.

9.2.14.3 Autodetect of a stored program

If multiple linked pre-stored data programs are linked to a television program or data-enriched television program to be reserved (if there are multiple hyperlink descriptors with the hyperlink type set as combined_prior_data), how to select a stored program shall depend on the receiver. However, selection based on the following criteria is preferable.

1) Based on the content size calculated, of all the events judged as storable on the receiver, an event with the greatest size shall be selected. If there are multiple events with the same size, which is the greatest, one of them shall be selected.

2) Of all the hyperlink descriptors to be put in the EIT of a television program or data-enriched television program, a one to be written first shall take precedence.

By using the above criteria, an attempt shall be made to store any one of events. Processing when a storage attempt fails shall depend on implementation, but it is preferable to try again as much as possible. In addition, whether or not the version of content has been updated shall be checked, and if an update is found, preferably, the event shall be stored again.

9.2.14.4 Television program viewing reservation

For viewing reservation of a television program or data-enriched television program for which a linked pre-stored data program is specified by the hyperlink type combined_prior_data, preferably, programmed storage of the relevant linked pre-stored data program shall be automatically performed.

If multiple linked pre-stored data programs are linked to a television program or data-enriched television program, one of them shall be selected automatically in accordance with 9.2.14.3.

9.2.15 Storage operation processing related to linked pre-stored data programs

9.2.15.1 Information to be stored when storage is performed

The following shows information to be stored into media when a linked pre-stored data program is stored.

― 3-123―

ARIB TR-B15

Version 4.6-E1

Table 9-6 Information to be stored when a linked pre-stored data program is stored

BIT

PMT

DII

EIT

• broadcaster_id

• auto_start_flag independent_flag

Digital copy control descriptor

Module information descriptors (Type, Expire,

CompressionType, Control)

Content name content_id

Attributes of a television program/data-enriched television program information to be hyperlinked (service_id, event_id, start_time, duration, etc.)

Remarks

Required for access to the NVRAM broadcaster specific area.

Modules

Attributes of the hyperlink destination are stored to make it easy to judge the existence of related data at the start of a television program. If multiple television programs/data-enriched television programs are linked, their information needs to be held all.

Components that configure the relevant content (written in component_tag).

Components written in the p/f EIT's component_ref.

9.2.15.2 General rules on processing when storage is performed

1) All modules that exist in the contents of a linked pre-stored data program shall be stored just once. Even if operation to update carousels is performed in the middle of processing, the receiver shall only need to keep one of such modules in storage.

2) Carousels shall only need to be stored in sequence, component by component.

A linked pre-stored data program shall be broadcast long enough to allow all carousels to be stored in sequence, component by component.

3) The following is an example of the receiver's storage start operation based on the operation of carousel transmission specified in 9.2.10.

- Acquisition of DII of the entry component shall start 2 seconds after the start time of an event.

- If DII first obtained turns out to be DII with an empty carousel, data event changeover shall be awaited. Storage operation shall start when DII with a carousel that is not empty can be obtained.

- If DII with a carousel that is not empty cannot be obtained after waiting 10 seconds, a timeout error shall occur.

9.2.15.3 Content updates when a linked pre-stored data program is broadcast multiple times

1) Processing when content is updated in another event after storage (the version of content with the same ID is updated) has been performed

An update is performed when the latest storage fails, so it is preferable to keep data of the previous version in storage and enable the previous version if storage fails.

Whether or not the version is updated shall be judged by content_version of arib_bxml_infor in the data content descriptor.

When an update is successful, the previous version in storage can be deleted.

2) Processing when storage of a reserved linked pre-stored data program fails

- 3-124-

ARIB TR-B15

Version 4.6-E1

It is preferable to set automatic reservation for another linked pre-stored data program that is linked from the same television program or data-enriched television program.

The receiver shall not store content of the same version again.

It is not necessary for the receiver to be able to automatically store content of a new version.

9.2.16 Preferable EPG display related to storage of linked pre-stored data programs

Table 9-7 shows the requirements for preferable EPG display related to linked pre-stored data programs.

Table 9-7 Preferable EPG display related to linked pre-stored data programs

Display indicating presence of associated datacasting

Display indicating presence of stored data

Display of a television program or data-enriched television program for which linkage exists.

(Hyper_linkage_type =0x80)

Display when a linked pre-stored data program already stored exists for a television program or

Indicates the existence of a television program to which a linked pre-stored data program is linked, and the existence of a data program that is linked to a data-enriched television program. data-enriched television program Displays the relevant program's title in the pane

Display when a linked pre-stored data program is already stored

Indicates in the pane for television programs or data-enriched television programs that a data program already stored exists. assigned to already stored data programs.

Only when independent viewing for the relevant linked pre-stored data program is permitted, displays that program's title in the pane assigned to already stored linked pre-stored data programs.

9.3 Operations related to independent pre-stored data program

9.3.1 Controlling the viewing of independent pre-stored data program

For independent pre-stored data program, two types of program are used: programs viewable in real time, and programs for which real-time viewing is prohibited.

9.3.2 service_type of channels that operate independent pre-stored data program

Independent pre-stored data program shall be broadcast in services with the service_type set to 0xA8.

9.3.3 Schedule patterns of independent pre-stored data program and operation restrictions

Hyperlink descriptors shall not be put into the EIT of an independent pre-stored data program.

Table 9-8 shows restrictions on the operation of independent pre-stored data program

Table 9-8 Restrictions on the operation of independent pre-stored data program

Limitations

Constraints on program structure

Description

Independent pre-stored data program shall be composed of data only, not transmitting video/audio streams.

― 3-125―

ARIB TR-B15

Version 4.6-E1

9.3.4 Use of the PMT's data encoding method descriptor in independent pre-stored data program

Regarding storage, independent pre-stored data broadcasting programs shall be stored together with information of the PMT's data encoding method descriptor, and the stored information shown below is used for playback of data broadcasting programs that have been stored.

Table 9-9 Use of the PMT's data encoding method descriptor in

Field auto_start_flag independent pre-stored data program

Usage

Always 1 like independent-type data programs. ondemand_retrieval_flag Either 0 or 1 is used. (There are programs for which real-time viewing is permitted and programs for which it is prohibited.)

9.3.5 Use of the PMT's target area descriptor in independent pre-stored data program

The target area descriptor shall not be used in independent pre-stored data program.

9.3.6 Use of the PMT's digital copy control descriptor in independent pre-stored data program

Shall be the same as linked pre-stored data programs. Refer to 9.2.6.

9.3.7 Use of the p/f EIT's data content descriptor in independent pre-stored data program

Shall be the same as linked pre-stored data programs. Refer to 9.2.7.

9.3.8 Use of DII related to storage of independent pre-stored data program

Like linked pre-stored data programs, DII version updates shall not occur during an event in independent pre-stored data program. So, basically, transaction_id does not change during an event.

9.3.9 Use of carousels related to storage of independent pre-stored data program

Shall be the same as linked pre-stored data programs. Refer to 9.2.10.

9.3.10 Use of the multimedia encoding method related to independent pre-stored data program

For name spaces to save stored modules (resources), the procedure for linked pre-stored data programs shall apply. Refer to 9.2.11.1.

9.3.11 Use of event messages related to storage of independent pre-stored data program

Event messages or NPT shall not be transmitted in independent pre-stored data program.

General-purpose event messages and NPT reference messages are not to be referenced from data content in an independent pre-stored data program.

9.3.12 idelines on the receiver's actions related to independent pre-stored data program at channel selection

- 3-126-

Table 9-10 Receiver's actions related to independent pre-stored data

ARIB TR-B15

Version 4.6-E1

Selection method

Channel selection on the remote control

Selection from EPG

(selection from stored program list

(tentative name)) program at channel selection

Selection operation

Selecting an independent pre-stored data program

Directly selecting content in an independent pre-stored data program

Receiver's action

Does not launch the data broadcasting engine if real-time viewing is specified as prohibited in the ondemand_retrieval_flag of the PMT for an independent pre-stored data program.

Launches the content selected.

9.3.12.1 Receiver's actions related to independent pre-stored data program when a data broadcasting program starts

Shall be the same as specifications related to linked pre-stored data programs. Refer to 9.2.13.2.

9.3.13 Processing for programmed storage of an independent pre-stored data program

9.3.13.1 Processing for programmed storage

Shall be the same as specifications related to linked pre-stored data programs. Refer to 9.2.14.1.

9.3.13.2 How to calculate the size of content

Shall be the same as specifications related to linked pre-stored data programs. Refer to 9.2.14.2.

9.3.14 Guidelines on storage operation processing related to independent pre-stored data program

9.3.14.1 Information to be stored when storage is performed

The following shows information to be stored into media when an independent pre-stored data program is stored.

Table 9-11 Information to be stored when an independent pre-stored data program is stored

Remarks

BIT broadcaster_id Required for access to the

NVRAM broadcaster specific area.

PMT independent_flag

DII

Digital copy control descriptor

Module information descriptors (Type, Expire,

CompressionType, Control) content_id

Modules Components that configure the relevant content (written in component_tag)

Components written in the p/f EIT's component_ref.

9.3.14.2 General rules on processing when storage is performed

Shall be the same as specifications related to linked pre-stored data programs. Refer to 9.2.15.2.

― 3-127―

ARIB TR-B15

Version 4.6-E1

9.3.15 Preferable EPG display related to independent pre-stored data program

Table 5-12 shows the requirements for preferable EPG display related to independent pre-stored data program.

Table 9-12 Preferable EPG display related to independent pre-stored data program

Display indicating presence of stored data

Display when an independent pre-stored data program is already stored

Displays the title of the relevant independent pre-stored data program in the pane assigned to already stored data programs.

9.4 Extension of BML procedural scripting language related to linked pre-stored/independent pre-stored data programs

Receivers supporting linked pre-stored data programs shall return 1 in response to getBrowserSupport("BSP", "PreStorage", "combined_prior_data").

Receivers supporting independent pre-stored data program shall return 1 in response to getBrowserSupport("BSP", "PreStorage", "basic").

Receivers to support either linked pre-stored data programs or independent pre-stored data program shall support the programmed-storage-related API in the procedural scripting language that will be specified in the following section as a broadcaster-extended API. z

X_BSP_preStorageIsReserved(): Checks whether or not storage of the specified program has been reserved with an event.

Syntax:

Number X_BSP_preStoageIsReserved( input String event_ref ,input Date startTime)

Arguments:

event_ref startTime

Return value:

Specifies an event

Start time of an event

1:

0:

NaN:

Storage already programmed

Unsuccessful

Description:

Checks whether or not with an event storage reservation is operative for the program which is scheduled to start at the time specified by startTime and which is specified by event_ref, and responds with a return value. How to write event_ref shall follow the specifications for name spaces in ARIB STD-B24, Section 2, Chapter 9.

- 3-128-

ARIB TR-B15

Version 4.6-E1 z

X_BSP_preStorageReserve(): Reserves storage of the specified program, with an event.

Syntax:

Number X_BSP_preStorageReserve( input String event_ref ,input Date startTime)

Arguments:

event_ref startTime

Return value:

Specifies an event

Start time of an event

1:

NaN:

Description:

Success

Unsuccessful

Reserves with an event storage of the program which is scheduled to start at the time specified by startTime and which is specified by event_ref, and responds with a return value regarding success or failure. How to write event_ref shall follow the specifications for name spaces in ARIB

STD-B24, Section 2, Chapter 9. z

X_BSP_preStorageCancelReservation(): Cancels with an event programmed storage of the specified program.

Syntax:

Number X_BSP_preStorageCancelReservation( input String event_ref)

Arguments:

event_ref

Return value:

Specifies an event

1:

NaN:

Description:

Success

Unsuccessful

Cancels with an event programmed storage of the program specified by event_ref and responds with a return value regarding success or failure. How to write event_ref shall follow the specifications for name spaces in ARIB STD-B24, Section 2, Chapter 9. z

X_BSP_preStorageIsReservedByContent(): Checks whether or not storage of the specified content has been reserved.

Syntax:

Number X_BSP_preStoageIsReservedByContent( input String event_ref,

Number content_id, input Date startTime

)

― 3-129―

ARIB TR-B15

Version 4.6-E1

Arguments:

event_ref Specifies an event startTime

Return value:

1:

0:

NaN:

Description:

Start time of an event

Storage already programmed

Unsuccessful

Checks whether or not storage reservation is operative for the content specified by the content ID

(content_id) to be transported in the program which is scheduled to start at the time specified by startTime and which is specified by event_ref, and responds with a return value. How to write event_ref shall follow the specifications for name spaces in ARIB STD-B24, Section 2, Chapter 9. z

X_BSP_preStorageReserveByContent(): Reserves storage of the specified content.

Syntax:

Number X_BSP_preStorageReserveByContent( input String event_ref,

Number content_id, input Date startTime)

Arguments:

event_ref Specifies an event startTime

Return value:

1:

NaN:

Description:

Start time of an event

Success

Unsuccessful

Reserves storage of the content specified by the content ID (content_id) to be transported in the program which is scheduled to start at the time specified by startTime and which is specified by event_ref, and responds with a return value regarding success or failure. How to write event_ref shall follow the specifications for name spaces in ARIB STD-B24, Section 2, Chapter 9. z

X_BSP_preStorageCancelReservation(): Cancels programmed storage of the specified content.

Syntax:

Number X_BSP_preStorageCancelReservationByContent( input String event_ref,

Number content_id)

- 3-130-

ARIB TR-B15

Version 4.6-E1

Arguments:

event_ref Specifies an event

Return value:

1:

NaN:

Description:

Success

Unsuccessful

Cancels programmed storage of the content specified by the content ID (content_id) to be transported in the program specified by event_ref, and responds with a return value regarding success or failure. How to write event_ref shall follow the specifications for name spaces in ARIB

STD-B24, Section 2, Chapter 9.

― 3-131―

ARIB TR-B15

Version 4.6-E1

10 Specifications for Terrestrial, BS, and Wide Band CS Common-Use Digital Receivers

10.1 Introduction

Considering data broadcasting operation in terrestrial digital television broadcasting, this chapter defines "BS

Level 3", in which application of data broadcasting functionality is extended to BS digital broadcasting. BS Level

3 shall basically apply to terrestrial, BS, and wide band CS common-use digital receivers (hereafter terrestrial and satellite common-use receivers) defined in TR-B14, Section 3, Part 5. In addition, this chapter also clarifies the detailed specifications for the BS reception function of terrestrial and satellite common-use receivers.

10.2 Concept of operation levels and BML versions

Table 10-1 shows operation levels and presentable BML versions in BS digital broadcasting.

Table 10-1 BS operation levels and BML versions

Operation level

Level 1

Level 2

Level 3

Target receiver

BS only receivers

BS and wide band

CS common-u se digital receivers

Terrestrial,

BS, and wide band

CS common-u se digital receivers

{

BML1.0

{

• Content that is shared with

Level 1 and that can use the broadcasting-use extended functions defined in CS broadcasting after checking their implementation.

{

• Content that is shared with

Level 1 and 2 and that can use the broadcasting-use extended functions defined in terrestrial broadcasting after checking their implementation.

BML2.0

×

×

×

×

×

BML3.0

{ (Refer to 10.5.1)

• Content that is reserved for Level 3 and that can use the broadcasting-use extended

• functions or new functionality defined in terrestrial broadcasting in the same conditions as in terrestrial broadcasting.

The above content should be put such that it will not be presented in receivers for Level 2 or lower.

BML1.0 content is intended to be shared among Level 1 to 3 assuming that it can be received with no problem by conventional-type receivers, and contents covering receivers of all types shall be put in it. Use of functions whose implementation depends on the receiver shall be permitted on condition that they are executed after checking their implementation by using getBrowserSupport(), so that the viewer will not feel uncomfortable when viewing content.

In BML3.0, however, content to be broadcast in BS digital broadcasting is written by using new functionality in terrestrial broadcasting and is reserved for terrestrial and satellite common-use; it is not presentable (compatibility unguranteed) in conventional-type BS digital receivers. The above content shall be isolated before its presentation, within the BML1.0 range such as the menu window, and shall be put so that it will not be presented in conventional-type receivers. In BML3.0 content, assuming that checking has been made before use, the essential functions in terrestrial digital broadcasting can be used without confirmation of their implementation, while optional functions in it can be used based on confirmation of their implementation.

- 3-132-

ARIB TR-B15

Version 4.6-E1

10.3 Functions demanded of terrestrial and satellite common-use receivers

Terrestrial and satellite common-use receivers shall be provided at least with the functions described in TR-B14 and TR-B15, Section 2 with respect to media they can receive.

10.3.1 RAM

The Gregorian calendar shall be shared by all receivable media. The Gregorian value shall be retained during presentation of communication content not supporting the Gregorian calendar too. Also, it is preferable that the

Gregorian value is retained during presentation of other media not supporting the Gregorian calendar.

If the receiver has to stop retaining the Gregorian value during presentation of other media, it shall initialize the

Gregorian value the first time it attempts to present media supporting the Gregorian calendar after that presentation.

10.3.2 NVRAM

The bookmark area, registered outgoing call area, and general-purpose route certificate area shall be commonly shared among media. For the NVRAM area spaces for media, the settings for capacity and access from other media permitted or prohibited are as follows:

RW: Both reading and writing permitted.

×:

Both reading and writing prohibited.

(*) Functions that have been defined after the start of operation. They shall be made optional, and both reading and writing shall be permitted only when permitted by access right information set by a BS broadcaster's service. For details, refer to 8.2.3.

Media

Wide band CS

Terrestrial

Table 10-2 Terrestrial and satellite common-use receiver's NVRAM and access from other media permitted or prohibited

Area name Access from BS

×

Access from wide band CS

Broadcaster specific area

Broadcaster specific, broadcasting and communication common area

Broadcaster common area

Broadcaster specific area

Broadcaster specific, broadcasting and communication common area

Broadcaster common area

Broadcaster specific area

Affiliate-specific area

R

×

RW

×

×

×

RW

(Access permitted to BS broadcasters defined as affiliates by the extended broadcaster descriptor in terrestrial broadcasting.)

×

RW

RW

RW

×

×

×

Access from terrestrial

R

×

×

×

×

RW

RW

RW

― 3-133―

ARIB TR-B15

Version 4.6-E1

Media

Common

Area name Access from BS

Broadcaster specific, broadcasting and communication common area

General-purpose route certificate area

Registered outgoing call area

Bookmark area

×

RW (BML3.0 only)

RW (Level 3 only)

RW (Level 2 and 3 only)

Access from wide band CS

×

RW (BML3.0 only)

RW

RW

Access from terrestrial

RW

RW

RW

RW

The following is the size of the broadcaster specific, broadcasting and communication common area for BS broadcasting to be newly added in terrestrial and satellite common-use receivers.

Space for 20 broadcasters, 2KB (64 bytes *32 blocks) per broadcaster.

If the ID used by the previous broadcaster is assigned to the local broadcaster ID (broadcaster_id), a new broadcaster should completely erase the relevant part of the broadcaster specific NVRAM area or broadcaster specific, broadcasting and communication common area before use. For the above, refer to Appendix 5.

10.3.3 Actions different from the actions of conventional-type receivers

Unless otherwise specified, for presentation both in BML1.0 and BML3.0, terrestrial and satellite common-use receivers shall behave as specified in TR-B14.

There are some differences in action between terrestrial and satellite common-use receivers and conventional-type BS receivers. Table 10-3 shows the functions that operate differently.

Table 10-3 Differences in action between terrestrial and satellite common-use receivers and conventional-type BS receivers

Function Conventional-type receivers

Not specified

Terrestrial and satellite common-use receivers

Video resolution

References in

TR-B14, Section 3,

Part 2/ Remarks

1.2.2, Appendix 10 Display resolution when the invisible attribute of the body element is set to invisible

Presentation from the stage of data event changeover to the stage of interpretation of the next document

Action while viewing or when the entry component's PID changes

Action in response to the change of auto_start_flag

Discards the previous document immediately.

However, nothing is described about a display resolution after discarding the document.

(Many receivers are implemented such that the resolution of the previous content continues for display resolution.)

Not specified

No need to refer to the value of auto_start_flag, except when selecting a channel

The display resolution of the previous content shall continue after data event changeover and unloading of the content until presentation of the next document.

Action equivalent to channel re-selection

When the value changes from 0 to 1, if the data broadcasting engine is not active, it is preferable to execute operations in 6 and after of "Receiver's basic actions at channel selection" described in 5.1.12.2.

5.12.1, Appendix 10

2.1.10.3

2.1.10.3

- 3-134-

Function Conventional-type receivers

Terrestrial and satellite common-use receivers

ARIB TR-B15

Version 4.6-E1

References in

TR-B14, Section 3,

Part 2/ Remarks

2.3.1.7 DII to be monitored DII of components, including modules being viewed, and DII of the entry component

In addition to the components on the left, the following shall be monitored:

1. DII of the component to transport modules specified by lockModuleOnMemory

Ex() (tag values 0x40, 0x50, and 0x60)

2. DII of the component to transport modules that subscribe ModuleLocked or ModuleUpdated interrupt events

2ES Components of event messages to be monitored

(number of ESs that can be subscribed simultaneously)

1ES 2.3.4.3

2ES can be subscribed in BML3.0 only.

10.3.4 Identification of media received

A BML version declares the functional scope of the browser to be used in content, but it has nothing to do with the range of access permission of NVRAM because that range depends on the type of media being received.

BML3.0 content may also contain descriptions specific to BS broadcasting, such as access to the BS-specific

NVRAM, and that should be noted in the implementation of the receiver.

10.4 Transmission

10.4.1 Use of DownloadInfoIndication (DII) messages

In BS Level 3, while both content of BML1.0 and content of 3.0 exist as specified in 10.5.2 BML3.0 content placement, DII's Control descriptors shall not be put. The version shall be obtained from version information in a BML document.

10.4.2 Event messages that do not depend on data event IDs

In BS Level 3, event messages with event_msg_group_id=1 can be transmitted for reference from BML3.0 content. For details, refer to TR-B14, Section 3, Part 2, 2.3.4.3.

10.4.3 NPT reference message

As with BS Level 1, in BS Level 3, if STC circles back to 0 during transmission of a NPT reference message, the receiver shall be surely notified through the STCmax reference message that NPT will become unstable. For details, refer to section 5.3.4.4.

10.4.4 Route certificate transmission

In BS Level 3, broadcasters providing interactive services through TLS or SSL shall always transmit route certificates by using the module_id=0xFFFF module in the entry component of a data broadcasting service. For details, refer to TR-B14, Section 3, Part 2, 2.3.1.8.

― 3-135―

ARIB TR-B15

Version 4.6-E1

10.5 Guidelines on use of content

In BS Level 3, content using the functionality defined in terrestrial digital broadcasting can be used in BS digital broadcasting too. The following shows the guidelines.

10.5.1 Identification of terrestrial and satellite common-use receivers

For BML1.0 content, its BML3.0 support can be identified by specifying BML version for functionname and "3.0" for additionalinfo respectively in getBrowserSupport(). To specify a name space for other media, whether or not the receiver supports the target media shall be checked through isSupportedMedia(). Identification of a receiver as a terrestrial and satellite common-use one shall not be made by judgment on whether or not it supports BML3.0.

Checking of BML3.0 support and identification as a terrestrial and satellite receiver shall be performed separately.

10.5.2 BML3.0 content placement

At least a startup document in the entry component and a startup document in the component directly launched from an EPG shall be written in BML1.0, because content to be received immediately after channel selection shall be receivable by all receivers.

• bml_version contained in a PMT and EIT shall be specified as 1.0.

BML documents launched by other media through epgTuneToComponent() shall be written in BML1.0.

Bookmarks for BML3.0 content should not be registered into receivers not supporting BML3.0.

10.5.3 Operation coverage of new functions

Table 10-4 shows coverage of terrestrial digital receivers functions in BML1.0 and 3.0.

The meanings of descriptions in the "Use" field are as follows:

{ (*) Usable as an option

- 3-136-

ARIB TR-B15

Version 4.6-E1

Table 10-4 Operation coverage of new functions in terrestrial and satellite common-use receivers

Function

Content where tildes "~" are use to describe its local

ES

BML1.0

Use

Content where HD data is added to video other than

HD and MPEG2-I

Content where the range of colors set by a broadcaster for PNG and MNG is extended to 207,

Content that uses 112/128 scaling for HD or SD video

Content that causes partial JPEG to remain −

Clipping of an X coordinate of video −

− from index 17 to 223

MNG with an update frequency of 100ms or more and less than 200ms

Content assuming a resident character input application

Content that uses the Kana-Kanji conversion function

BML3.0

Use

{

{

{

{

{

{

{

{

{ (*)

{

References in TR-B14, Section 3, Part

2/Remarks

Version B24 1.1 or later

1.2.3, Appendix 4

1.2.3, Appendix 4

5.11

1.2.1, Appendix 3

1.2.1

3.2.3.2

1.6

1.6.3,

5.9.6.2 Use after function check through the receiver application identification function

1.4.1 Content assuming the availability of 2MByte or more for BContents

Content assuming the upper limit of 768 for the number of resources within BContents

AAC-LC sound with 32kHz sampling

Content assuming the maximum length of 512KByte for an AAC file

Content requiring AAC file stop control

Reference to partially received components

Content that subscribes 9 or more and up to 16 event messages at the same time

Content that simultaneously subscribes event messages to be transported by two different ESs

Content that subscribes event messages with event_msg_group_id=1

Function to extract and reference ECMAScript or

CSS as a separate file

Content assuming the increase of constants in an

ECMAScript operation environment

Content assuming the increase of constants in a

BinaryTable

Content using an URI starting with arib://-1.-1.-1/ or arib-dc://-1.-1.-1/

Content that uses lockModuleOnMemoryEx()

Content that references and displays modules locked by the above

TCP/IP communication function

Connection and disconnection function by using functions in broadcasting content

TCP/IP communication function

Use of transmitTextDataOverIP() in broadcasting content

{ (*)

{ (*)

TCP/IP communication function

Transitioning from broadcasting content to

{ (*) communication content

Communication content

{

{

{

{

{

{

{

{

{

{

{

{

{

{

{

{

{

{

5.13.3

1.2.4

1.4.1

3.3.1.3

2.1.2.3

2.3.4.3

2.3.4.3

2.3.4.3

5.6, 5.7.2, 5.7.3

5.12.4, B24, Section 2, Appendix 3

5.12.5, B24, Section 2, Appendix 3

5.12.6.3

5.13.3

5.14.10.4

5.12.6.9 (6)

5.13.3

5.14

5.14

5.14

5.14

Communication content is used in 3.0 only.

― 3-137―

ARIB TR-B15

Version 4.6-E1

Function

Secure communication through TLS

BML1.0

Use

{ (*)

BML3.0

Use

{

References in TR-B14, Section 3, Part

2/Remarks

5.14.14

2.3.1.8

A route certificate shall be put in the module 0xFFFF in the entry ES. A route certificate descriptor shall be put in DII.

When secure communication is carried out from broadcasting content through transmitTextDataOverIP(), BML1.0 can be used only for use of web sites starting with https:// or for transition to sites starting with https://.

5.2 Reading from the terrestrial digital NVRAM broadcaster common area

Reading from and writing to the terrestrial digital

NVRAM affiliate-specific area

Reading from and writing to the BS digital NVRAM broadcaster specific, broadcasting and communication common-use area

Reading from and writing to the bookmark area

{ (*)

{ (*)

{ (*)

{ (*)

Registration to the registered outgoing call NVRAM { (*)

Preset-time call transmission function that supports { (*) the registered outgoing call NVRAM

Calling up the resident bookmark list function

Print function

Mail dispatch function

HTML browser call function

Launch of the IPTV Browser

{ (*)

{ (*)

{ (*)

{ (*)

{ (*)

{

{

{

5.2

{

{

{ (*)

5.2

5.16

5.16.5

5.9.6.2 Use after function check through the receiver application identification function.

{ (*)

{ (*)

5.15.4

5.9.6.2 Use after function check through the receiver application identification function.

5.9.6.1

5.9.6.2 Use after function check through the receiver application identification function.

{ (*) 5.9.4

5.9.6.2 Use after function check through the receiver application identification function.

{ (*) BML1.0:

Use after checking the launchExApp() function through getBrowserSupport().

BML3.0:6.1

5.9.6.2 Use after function check through the receiver application identification function.

{ (*) 6.3

5.9.6.2 Use after function confirmation using the identification function of the receiver application

10.5.4 Operation coverage of browser pseudo-objects

Table 10-5 shows coverage of browser pseudo-objects in BML1.0 and 3.0.

The meanings of descriptions in the "Use" field are as follows:

{

Shall be defined as basic functions in this standard. Usable without checking the processing capability of the relevant function on the receiver by using the getBrowserSupport( ) function.

{

(*1) Optional functions in Terrestrial Broadcasting Operation Standard. For use in content, the processing capability of the relevant function on the receiver shall be examined by specifying APIGroup for functionname and a value specified in B24, Section 2, Appendix 1 for additionalinfo in the getBrowserSupport() function, so that the relevant function shall be called only when the processing

- 3-138-

{

(*2)

{

(*3)

{

(*4)

ARIB TR-B15

Version 4.6-E1 capability is available.

Mandatory functions newly defined in Terrestrial Broadcasting Operation Standard. But they are not implemented in conventional-type BS receivers. For use in content, therefore, the processing capability of the relevant function on the receiver shall be examined by specifying APIGroup for functionname and a value specified in B24, Section 2, Appendix 1 for additionalinfo in the getBrowserSupport() function, so that the relevant function shall be called only when the processing capability is available. Or, examination can be made by specifying BMLversion for functionname and

"3.0" for additionalinfo respectively.

Functions that are optional in BS Level 2 Standard but that become mandatory in Terrestrial

Broadcasting Operation Standard. For use in content, therefore, although examination is possible by specifying either APIGroup or BMLversion in the getBrowserSupport() function, considering Level 2 supported receivers, it is preferable to use APIGroup for examination.

Optional functions newly defined after the start of operation. For use in content, the processing capability of the relevant function on the receiver shall be examined by specifying "BPA" for sProvider, "APIGroup" for functionname, and "Persistent.Media.Support.Ext" for additionalinfo in the getBrowserSupport() function, so that the relevant function shall be called only when the processing capability is available. The details of use are defined in section 8.2.3.

Shall not be defined as basic functions nor optional functions in this standard.

Table 10-5 Operation coverage of browser pseudo-objects in terrestrial and satellite common-use receivers

Function

Ureg-related function

Ureg[]

Greg-related function

Greg[]

EPG-related function

Program-group-index-related function

Series reservation function

BML1.0

Use

{

{ (*3) {

{ {

BML3.0

Use

{

{

{

{

{

{

{

{

{

{ (*3) {

− −

{

{

{

{

{

{

{ (*1) { (*1)

{ (*1) { (*1)

{

{

{ (*1) { (*1)

Remarks

(Note 1)

(Note 1)

(Note 1)

― 3-139―

ARIB TR-B15

Version 4.6-E1

Persistent memory function

X_BPA_setAccessInfoOfPersistentArrayForAnotherProvider( )

X_BPA_writePersistentArrayForAnotherProviderWithAccess

Check( )

X_BPA_readPersistentArrayForAnotherProviderWithAccess

Check( )

Interactive function

Interactive function - delayed call transmission

Interactive function - BASIC procedures

Interactive function - TCP/IP

Function

Control of persistent memory areas with access control

Interactive function - function to obtain the delayed call transmission status that is common between BASIC mode procedures and IP connections

- 3-140-

− −

{

{

{

{

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*1) { (*1)

{ (*1) { (*1)

{ (*2) {

− −

{ (*1)

{ (*1)

{ (*1)

{ (*1)

{ (*1)

− −

{

{

BML1.0

Use

BML3.0

Use

{ (*1) { (*1)

{ (*1) { (*1)

{ (*1) { (*1)

{ (*4) { (*4)

{

{

Remarks

(Note 1)

(Note 1)

(Note 1)

(Note 7)

(Note 2)

(Note 2)

(Note 2)

(Note 2)

Action control function

startExtraBrowser()

Receiver sound control

Timer function

External character function

Function

Interactive function - function to obtain the line connection status

Interactive function - mass call reception service

Interactive function - encrypted communication by using CAS

Interactive function - encrypted communication by secret key encryption instead of

CAS

{

BML1.0

Use

BML3.0

Use

{ (*3) {

{ (*1)

ARIB TR-B15

Version 4.6-E1

Remarks

(Note 2)

(Note 3)

(Note 3)

(Note 3)

{

{

{

{

{

{

{

{

{ {

{ (*1) { (*1)

{ (*1) {(*1)

{ {

{ (*3) {

{

{

{

{

{

{

{

{

{

{

{

{

{

{

{ {

{ (*2) {

{ (*2) {

{ (*1) { (*1)

{ (*3) {

{ (*3) {

{ (*2) {

{

{

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*2) {

{ (*1) { (*1)

{

{

{

{

{

{

{

{ (*1) { (*1)

{ {

{

{

{

{

{

{

{

(Note 6)

(Note 8)

(Note 4)

(Note 5)

(Note 5)

― 3-141―

ARIB TR-B15

Version 4.6-E1

External device control function

Other functionality

Caption display control function

Print-related function API - basic print functions

getPrinterStatus()

printFile()

printTemplate()

printUri()

printStaticScreen()

Print-related function API - memory card-related

saveImageToMemoryCard()

saveHttpServerImageToMemoryCard()

saveStaticScreenToMemoryCard()

Directory operation functions

File operation functions

File input/output functions

Inquiry functions

Data carousel storage functions

Bookmark control function

startResidentBookmarkList()

Function

{

{

{

BML1.0

Use

{

{

{

{

{

{

{

{ (*1) { (*1)

{ (*1) { (*1)

{ (*1) { (*1)

{ (*1) { (*1)

{

{

{

BML3.0

Use

{

{ (*1) { (*1)

{ (*1) { (*1)

{ (*1) { (*1)

{ (*1) { (*1)

{ (*3) {

{ (*3) {

{ (*3) {

{ (*3) {

{ (*3) {

{ (*3) {

{ (*2) {

{ (*1) { (*1)

(Note 1) It is preferable to implement this function to receivers with the series reservation function.

- 3-142-

Remarks

ARIB TR-B15

Version 4.6-E1

(Note 2) Shall be treated as optional in BML3.0, considering receivers without modems in the future.

(Note 3) Shall not be used, as in terrestrial broadcasting, because there is no track record in BS broadcasting.

(Note 4) Differences in interpretation with respect to priorities shall be noted.

(Note 5) Not operated in terrestrial broadcasting.

(Note 6) The method for checking implementation of this function is different between BML1.0 and BML3.0. Refer to Table

10-3.

(Note 7) Not defined in STD-B24 at the moment. Refer to TR-B14, Section 3.

(Note 8) If there is no module that is already locked or that is making a request for locking, an array with a length of 0 shall be returned as a return value. Some receivers exist, however, that return NULL as a return value, so that point shall be considered when using the relevant function in content.

10.5.5 Notes on operation by mixing different BML versions together

For transition from BML3.0 content to BML1.0 content, the functions usable in BML3.0 shall not be assumed in BML1.0 content.

Modules locked by lockModuleOnMemoryEx() in BML3.0 content shall not used in BML1.0 content.

Transition to BML1.0 content after specifying remain for partial JPEG shall be prohibited.

For the beitem element of BML1.0 content, the event_msg_group_id attribute shall not be specified.

Modules locked by lockModuleOnMemoryEx() in BML3.0 should be unlocked within BML3.0 content, but they may be forcibly transitioned to a startup document in the entry component that is written in BML1.0 due to disappearance of the components being presented, return to entry flags, etc. Thus, broadcasters using lockModuleOnMemoryEx() shall consider proper use of unlockAllModulesOnMemory() in a startup document in the entry component or in a BML document that is automatically launched from that startup document so that unnecessary modules will not remain in the content memory.

10.5.6 Communication content

10.5.6.1 BML version

Communication content is presentable only in Level-3-supported receivers and can be shared with terrestrial broadcasting, so its BML version shall be limited to BML3.0 only. Some broadcasting content transitioning to communication content may be written in BML1.0.

10.5.6.2 Security

For the restrictions on the linked/unlinked status of communication content and on use of functions, refer to

TR-B14, Section 3, Part 2, 5.14.

10.5.6.3 Browser specific display

To display unlinked communication content from content other than content in terrestrial digital broadcasting, follow the descriptions in TR-B14, Section 3, Part 2, 1.8.1 Browser-specific display.

10.5.6.4 Route certificate transmission

To provide interactive services using TLS or SSL in BS/wide band CS broadcasting, route certificates should be transmitted. Route certificates shall be operated in accordance with TR-B14, Section 3, Part 2, 5.14.14 and

2.3.1.8. Of all the route certificates, general-purpose route certificates need to be operated under the unified management of a certificate management organization that operates for terrestrial digital data broadcasting.

― 3-143―

ARIB TR-B15

Version 4.6-E1

10.5.6.5 Print-related function

For the print-related function's behavior in communication content, refer to TR-B14, Section 3, Part 2, 5.14.6.16.

For the behavior of the data broadcasting reception status, refer to TR-B14, Section 3, Part 2, 5.12.6.

10.5.7 Using name spaces

In addition to the previous specifications, the following name spaces can be used in BS Level 3.

10.5.7.1 Identification of the area shared among terrestrial digital television broadcasters

Refer to TR-B14, Section 3, Part 2, 5.2.2. However, only reading shall be permitted.

10.5.7.2 Identification of the area reserved for affiliates of terrestrial digital television broadcasters

Refer to TR-B14, Section 3, Part 2, 5.2.3.

10.5.7.3 Identification of the area reserved for BS digital broadcasters, commonly used in both broadcasting and communication

To read/write information from/to the BS digital broadcaster specific, broadcasting and communication common-use area from MM services, readPersistentArray()/writePersistentArray() shall execute by interpreting one fixed-length block as one file. Reading/writing information from/to the BS digital broadcaster specific, broadcasting and communication common-use area from MM services shall execute in units of fixed-length blocks. The URI shown below is used for identification of fixed-length blocks. nvram://[<broadcaster_id>;]local_web/<block-number>

<broadcaster_id> is always omitted, and the broadcaster_id of the stream that transported the currently playing content is specified.

10.5.7.4 Identification of the registered outgoing call storage area

Refer to TR-B14, Section 3, Part 2, 5.16.2.

10.5.7.5 Identification at automatic channel selection by epgTune( ) or epgTuneToComponent( )

"arib://-1.-1.-1" or "arib-dc://-1.-1.-1" shall be specified as a URI for selecting the local channel or the local component by using epgTune( ) or epgTuneToComponent( ) respectively. For details, refer to TR-B14, Section

3, Part 2, 5.12.6.3.

10.5.7.6 Broadcasting stream and mono-media referenced from communication content

To reference a stream in broadcasting content from communication content, a target shall be specified by using an absolute URI that starts with arib://-1.-1.-1. To reference mono-media (not a stream) in broadcasting content, a target shall be specified by using an absolute URI that starts with arib-dc://-1.-1.-1.

For details, refer to TR-B14, Section 3, Part 2, 5.14.10.4.

10.5.8 Selecting services of other media

If the receiver supports media other than BS digital broadcasting, it is possible to select services of such media by using epgTune() or epgTuneToComponent(). For details, refer to ARIB STD-B24, Section 2, Appendix 1,

"8.5.1 Operating the action control function".

To specify a service in terrestrial digital television broadcasting, depending on the content, it is necessary to change the transition destination, area by area; so if a receiver has no area information settings, the button to transition to terrestrial digital television broadcasting shall not be presented on it.

- 3-144-

ARIB TR-B15

Version 4.6-E1

10.5.9 Programmed recording and viewing reservation for other media

If the receiver supports media other than BS digital broadcasting, it is possible to execute programmed recording and viewing reservation (epgIsReserved(), epgReserve(), epgCancelReservation(), epgRecIsReserved(), epgRecReserve(), or epgRecCancelReservation()) for services of such media. Note that there is no guarantee that the receiver can obtain SI information of the target media, and in case of no acquisition, reservation will fail.

10.6 Operation of new functionality for captioning

10.6.1 Captioning rollup mode

This mode is provided as an option in Terrestrial Broadcasting Operation Standard, and its compatibility with receivers not supporting it is considered too; so it is usable also in BS broadcasting for terrestrial and satellite common-use receivers. For details, refer to TR-B14, Section 3, Part 2, 4.10.

10.6.2 Out-screen display function

The out-screen display function is an optional standard, not related to operation of caption text transmission; preferably, this function can operate for reception of BS broadcasts too. For details, refer to TR-B14, Section 3,

Part 2, 4.11.

10.7 Print function

This function is provided as an option in Terrestrial Broadcasting Operation Standard, and it is usable also in BS broadcasting for terrestrial and satellite common-use receivers, as an optional function, in BML1.0 and

BML3.0.

Functions and specifications related to the print function shall be compliant with ARIB STD-B24, Section 2,

"7.6.17 Print-related function" and Section 2, Appendix 1 "Guidelines on the Print Function".

10.7.1 Extended API group

The print function is an option in the implementation of the receiver; for use in content, therefore, the processing capability of the relevant function on the receiver shall be examined by specifying APIGroup for functionname and a value specified in B24, Section 2, Appendix 1 for additionalinfo in the getBrowserSupport() function, so that the relevant function shall be called only when the processing capability is available.

The print-related functions can be classified into the following two groups:

A) Group of functions for printing by using printers:

• getPrinterStatus()

• printFile()

• printTemplate()

• printUri()

• printStaticScreen()

B) A group of functions for storing data for print to memory cards:

• saveImageToMemoryCard()

• saveHttpServerImageToMemoryCard()

• saveStaticScreenToMemoryCard()

Receivers that support the print function shall be able to process either of or both the above A and B.

― 3-145―

ARIB TR-B15

Version 4.6-E1

10.7.2 Print data format

For details, refer to TR-B14, Section 3, Part 2, 6.2.2.

10.7.3 Supplementary items regarding API for print-related functions

Specifications for resolutions in data broadcasting when executing printStaticScreen() and saveStaticScreenToMemoryCard().

These functions shall be made usable with resolutions of 960x540 and 720x480 in data broadcasting. Note that with a resolution of 720x480 in data broadcasting, the aspect ratio of print outputs can become improper, and that requires consideration when in operation. Alpha (

α) composition between planes is not mandatory. And the video plane shall not be composed.

For details of other specifications, refer to TR-B14, Section 3, Part 2, 6.2.3.

10.7.4 Presentation by the receiver

For details, refer to TR-B14, Section 3, Part 2, 6.2.4.

- 3-146-

ARIB TR-B15

Version 4.6-E1

Appendix 1 CLUT Common Fixed Colors

CLUT common fixed colors are shown in Table: Appendix-1. They are based on 64 colors, including half-transparent colors and one transparent color.

They are created based on the following principles:

1) The first 16 colors shall correspond to 8-unit code palette colors. One of them shall be transparent.

2) The remaining colors shall be evenly distributed to color spaces.

4) Because the number of colors based on the above becomes 129, colors with R,G,B,

α = 255, 255, 170,

128 are deleted.

5) Gamma correction is assumed to be imposed.

RGB color assignment level

With four values of RGB=0, 85, 170, and 255

Alpha (

α) value assignment level

With three values of

α=0, 128, and 255

64 colors

Note that although RGB values need to be finally converted into Y, Cb, and Cr, they remain as is to make it easy to understand.

Table: Appendix-1 CLUT common fixed colors (R,G,B = 0, 85, 170, 255

α= 0, 128, 255)

Index value R G

0 0

B

α

0

0

0

Name/Remarks

Black

Red

255

255

4 0

0

6 0

9 170

255

8 0

0

10 0

0

170

255

0

Half bright red

255

11 170 170

12 0

0

0

13 170 0

14 0

170

255

170

255

170

Half bright yellow bright

Half bright magenta

15 170 170

16 0

170 255

85

0

85

Half bright white (gray)

255

85

20 0

170

22 0

255

24 0

0

26 85

0

28 85

85

30 85

85

32 85

― 3-147―

ARIB TR-B15

Version 4.6-E1

Index value R G

33 85

B

α

0

85

Name/Remarks

255

255

170

170

37 85

255

39 85

255

41 170

0

43 170

85

45 170

85

47 170

170

49 170

255

51 170

255

53 255

0

55 255

85

57 255

85

59 255

170

61 255

170

63 255

255

65 0

0

67 0

255

69 0

0

71 0

72 255

73

75

170

170

0

74 0

170

0

0

128

0

128

Half bright red

128

Half bright yellow

76 0

77

79

170

170

0

78 0

170

170

170

128

170

128

Half bright magenta

128

Half bright white (gray)

0

81 0

85

83 0

85

85 0

170

87 0

255

89 85

0

91 85

0

93 85

- 3-148-

ARIB TR-B15

Version 4.6-E1

Index value R G

94 85

B

α

85

Name/Remarks

128

85

96 85

97 85

98 85

99 85

170

101 85

102 85

255

104 85

0

106 170

85

108 170

109 170

110 170

111 170

170

113 170

114 170

255

116 170

0

118 255

85

120 255

121 255

122 255

123 255

170

125 255

126 255

Appendix 2 Module Compression Format

For module compression, based on RFC-1950(ZLIB Compressed Data Format Specification version 3.3), the same compression format as PNG is used. Refer to Table: Appendix-2.

Table: Appendix-2 Detailed operation of zlib compression format

Field

Compression Method(4bit)

Use

8 ("deflate") only

Compression Info(4bit) 7 or less (window 32KB or less)

Flags

FCHECK(5bit) (Value specified in RFC-1950)

Preset Dictionary(1bit) 0 (no preset dictionary) only

Compression Level(2bit) (Free. Shall be ignored when decoding.)

― 3-149―

ARIB TR-B15

Version 4.6-E1

Appendix 3 Notes on Access to NVRAM

z

NVRAM life

In general, NVRAM is assumed to be implemented by using semiconductor memory devices called flash memory. There is a limit to the number of times for writing to this device, and that becomes the life of such a device. As of 2000, the upper limit of the number of times for writing in general is approximately one hundred thousand.

If it is desired to accumulate information as the time of content presentation elapses, use of global variants and Ureg is preferable. If the Greg function, which is added in ARIB STD-B24 Ver3.1, is supported, use of that function is preferable for temporary data storage such as data exchange among multiple services. Use of NVRAM for temporary data storage is not recommended.

Appendix 4 Guidelines on Information Operation on Data Broadcasting NVRAM

1. Basic concept regarding the handling of data broadcasting NVRAM

NVRAM used for broadcasting is based on the following concept:

Physical functionality and performance shall be guaranteed by manufacturers.

Private information written shall be the user's property.

Information management and communication with users regarding permission to use information shall be handled by broadcasters.

2. Definition of private information on NVRAM

Private information on NVRAM treated in the present guidelines is the one defined in JIS Q 15001

"Requirements of Compliance Program Related to Protection of Private Information".

Private information refers to information related to individuals - information contained in the relevant information, such as descriptions including names and dates of birth, numbers, symbols, and other codes, and information that helps to identify individuals by video or sound. (The above includes not identifiable information when used alone that can be easily associated with other information to eventually ascertain the identity of the relevant individual.)

In addition, from the viewpoint of protection of viewers' benefits, data such as "points" used as substitutes for prizes/games/gifts requires much care in handling and shall be thus treated as private information in the present guidelines.

3. How to identify viewers

Presentation of private information, data erasure, and data restoration by data broadcasting content are assumed to be performed based on viewers' approval. As a mechanism for identification of viewers,

Identifying individuals by passwords

Identifying receivers through B-CAS card IDs

Identifying households by caller ID notifications can be considered.

- 3-150-

ARIB TR-B15

Version 4.6-E1

4. Guidelines on the function to present private information handling rules by data broadcasting content

It is preferable that the following is mentioned in "Membership rules", "FAQ," and "Help".

(1) Registered information is stored in the receiver.

(2) Private information stored in the receiver shall be managed on the responsibility of the user of the service (member) and needs to be erased by the user of the service (member) by him/herself in the event of transfer of the receiver's ownership or for disposal of the receiver.

(3) The provider of the relevant service shall manage registered information, protect secrets, and clarify the scope of use for such information.

(4) Providers using authentication through B-CAS card IDS shall clarify the procedure for taking over

NVRAM data for replacement of B-CAS cards.

(5) At the time of member registration, an exemption clause shall be presented to users for their approval with respect to handling in case data such as points is lost.

It is preferable that content is provided with the function to present the details of NVRAM data (private information, etc.) stored in receivers.

(1) The menu item "Check Contents Stored" shall be provided in the "Member Registration" menu.

(2) User authentication, e.g. authentication by using a password, shall be performed for presentation of

NVRAM data.

Preferably, the items to be presented shall cover all the contents of NVRAM data (private information, etc).

Note that for items with higher confidentiality, such as passwords and credit card numbers, they shall not be presented specifically (by numbers) but presented by displaying "****" (asterisks) or the message "Already stored".

5. Guidelines on the function to erase NVRAM data by data broadcasting content

In data broadcasting, for operation of services that require private information to be stored into NVRAM in the receiver, as data broadcasting content, it is preferable for each broadcaster (program or channel supply source) to have the following erase function:

Target to be erased: Part exclusively used by the relevant broadcaster in the NVRAM broadcaster specific area.

User interface: The following implementation is preferable for the purposes of greater ease of operation for users and prevention of operational error . (Refer to the operation window example.)

- The menu item "Erase Contents Stored" shall be provided in the "Member Registration" menu.

- For erasure of the actual part of the NVRAM broadcaster specific area, final confirmation of the viewer's intention shall be made.

- Considering the possibility of NVRAM being accessed by a procedure other than the ones authorized for data broadcasting or receivers, 0x00 or 0x20 shall be written all over the part to be erased.

Note that it is also possible to present content with the erase function only when a viewer instructs his/her withdrawal from membership, instead of always presenting it.

― 3-151―

ARIB TR-B15

Version 4.6-E1 z

Example of how private information handling rules are indicated

We shall take responsibility for management of private information such as member IDs, addresses, names, and credit card numbers.

We shall not disclose a member's information to any third party without the member's consent.

We shall secure protection of privacy for members.

(When data is transmitted by using the uplink.) From information currently entered and information already stored, information such as {{, {{ (example: name, address, telephone number, credit card number) will be transmitted. We shall use the above information only for the present service (example: television shopping). z

Operation window example for NVRAM data erasure

(Main menu or portal window)

Member registration

New/Change

Erase Contents

Stored

Check Contents

Stored

(Member registration window)

OK

OK

Please enter your password.

Password:_ _ _ _

("User authentication" window)

OK

This operation erases member information stored in the receiver.

Are you ready to erase member information stored in the receiver?

No Yes

("Erase Contents Stored" window)

Authentication complete

Member information stored in the receiver

Name:

{{{{

Address:

{{ -{{-{{

TEL: -

Date of birth: /

-

/

("Check Contents Stored" window)

- 3-152-

ARIB TR-B15

Version 4.6-E1

Appendix 5 Use of NVRAM when the ID of the previous broadcaster is assigned

If the ID used by the previous broadcaster is assigned to the local broadcaster ID (broadcaster_id), a new broadcaster (hereafter "elevant broadcaster") should completely erase, before use, the parts of the broadcaster specific NVRAM area and broadcaster specific, broadcasting and communication common area (hereafter

"NVRAM specific area") that are assigned to the relevant broadcaster, because these areas (parts) may have been used by the previous broadcaster. To be specific, 0x00 or 0x20 shall be written all over the relevant parts before using the NVRAM specific area in content. In addition, because it is necessary to judge whether or not the relevant broadcaster already starts using the NVRAM specific area by erasing the relevant parts on its own, it is preferable that the relevant broadcaster shall take a measure such as writing some identification information to any block in the NVRAM specific area.

― 3-153―

ARIB TR-B15

Version 4.6-E1

< Intentionally blank.>

- 3-154-

OPERATIONAL GUIDELINES FOR DIGITAL SATELLITE

BROADCASTING

ARIB TECHNICAL REPORT

ARIB TR-B15 Version 4.6- E 1

(Fascicle 1)

(December 12th, 2008)

This Document is based on ARIB technical report of “Operational

Guidelines for Digital Satellite Broadcasting” in Japanese edition and translated into English in March 2010.

Published by

Association of Radio Industries and Businesses

Nittochi Bldg. 11F

1-4-1 Kasumigaseki Chiyoda-ku, Tokyo 100-0013, Japan

TEL 81-3-5510-8590

FAX 81-3-3592-1103

Printed in Japan

All rights reserved

-

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement