Broadcast Technology No.55, Winter 2014 ● C NHK STRL10

*1 IPTV Forum Japan: The standardization body setting IPTV related domestic standards in Japan.

*2 An application programming interface (API) defined to implement functions needed in Hybridcast, in addition to the standard HTML5 APIs. An API is a set of commands and functions used when developing software to run for a given OS or run-time environment.

NHK launched Hybridcast in September, 2013. Hybridcast, which uses HyperText Markup Language 5 (HTML5) as an application language to combine broadcast and broadband functionalities channels, currently provides the latest news, weather, and sports to televisions supporting this system. Moreover, we are planning on starting other Hybridcast services, such as interactive programs and video on demand (VoD). In this article, we discuss the technical specifications of Hybridcast and possible extensions to enable it to support new services.

1. Hybridcast Technical SpecificationsThe first version (Ver. 1.0) of the Hybridcast Technical

specifications is defined by the IPTV Forum Japan (hereinafter, IPTVFJ)*1 and Association of Radio Industries and Businesses (ARIB) standards1)2)3). The technical specifications of IPTVFJ stipulate the system model, application model, receiver functions, and HTML5

extension APIs*2 and deal mainly with the functionalities and models of the broadband part. The ARIB standards stipulate the application control signal formats and deal with the parts related to broadcast signals.

2. Hybridcast System ModelHybridcast provides services that combine

broadcasting and broadband functions. In order to promote and diversify the services that can be offered over broadband network, its service model (Figure 1) is one in which service providers are not limited to broadcasters.

In Figure 1, a broadcaster provides control signals for starting or stopping Hybridcast applications (called “App.” in the figure). They are multiplexed into the normal broadcast signal. Service operators who have

Hybridcast: Technical Specifications and Recent Progress

Figure 1: Hybridcast system model (from IPTVFJ STD-0010)

Broadcast contentInformation added to broadcast signal (standardized)

Broadcast station Service Provider Receiver

App. App. App.

Station server

Security functions

Application management/

distribution

Per-service servers Transportformat

Repository†2

App.

App.

API †1

Broadcast and communications linking functions Partly standardized

APIBasic functions

Linked terminal

Security functions

†1 Application Programming Interface †2　Function providing application list to receivers

Ap

plic

atio

n s

erve

r

Stre

amse

rver

Broadcast Technology No.55, Winter 2014 ● C NHK STRL

Feature

11

signed contracts with the broadcaster are then able to control their applications with these signals.

Service providers play a major role in a service chain of Hybridcast. They distribute their applications to the viewers’ receivers and control the data streamed to the applications.

The receiver runs Hybridcast applications, provides the functionality that enables users to receive services linking broadcasting and communications, and communicates with external devices such as tablet computers over a home network for second screen usage.

Hybridcast system model illustrated in Figure 1 is a logical model, and a variety of form of operation is allowed to implement the functions in the model.

3. Hybridcast ApplicationsApplications are the means for realizing individual

services in Hybridcast, and the way they work depends on the service being provided. In order to support a wide range of services, various application types have been defined, as shown in Table 1.

In Table 1, managed applications refers to reliable applications approved by broadcaster(s) that are allowed for simultaneous presentation with a broadcast program, and these are further categorized into broadcast-oriented managed and non-broadcast -oriented managed applications.

Broadcast-oriented managed applications are launched by application control signals (see Section 4) within the broadcast signal. Applications are coded in HTML5, so they can include links to other sites. On the other hand, an application can also be given a domain scope by using the control signals multiplexed on the broadcast signal. The application keeps its status of broadcast-oriented managed application as long as all transitions remain within this scope, and even transitions to sites of other service providers are allowed while keeping its status if they are approved by the broadcaster. In such cases, the service provided by the other party can use broadcast functions within the scope permitted by the broadcaster. Also, as long as the application remains broadcast-oriented managed, the application can be stopped by using application control signals in the broadcast even if an application of a third party is being displayed. If the application exceeds this scope, the application is converted to general application and can no longer use broadcast functions and be exhibited with a broadcast program. Once the application becomes

a general application, it cannot become a broadcast-oriented managed application again. The user must select the channel again to restart the application.

Non-broadcast managed applications are applications that can operate in the same manner as broadcast managed applications, but whose legitimacy is preserved by some means other than the broadcast signal, such as code signing. Because of this, the user is able to select, start, or stop the application at any time, independently of the broadcast signal. The application continues to run even if the channel is changed. This allows services that span multiple channels to be provided.

General applications are applications that are not managed. These are comparable to accessing an ordinary Web site.

Note that Ver. 1.0 of the Hybridcast technical specifications standardized by the IPTVFJ in March, 2013, covers only broadcast managed applications; non-broadcast managed applications are to be studied in the future.

4. Hybridcast Application Control SignalsApplication control signals control the launching

and terminating of applications, the scope of broadcast functions available to various network domains (called the “application boundary”), the execution priority of data broadcasts, and other factors3). Two formats are specified for the application control signal: the Moving Pictures Experts Group (MPEG) section format*3, and Extensible Markup Language (XML) notation.

And, three methods are specified for transmitting these signals: transmission in a dedicated elementary stream (ES), transmission in a data carousel*4, and by retrieving a control signal file placed on a server over broadband network. A Hybridcast receiver retrieves applications from a site specified by uniform resource locators (URLs) in the application control signal and performs the necessary controls, such as staying within the application boundary, by executing the commands in the application control signals.

5. ReceiversThe Hybridcast receiver model is shown in Figure

Table 1: Hybridcast application types

Application type

Launch command

Non-broadcast-oriented managed

Allowed

Broadcast-oriented managed

Broadcast signal

Channel spanning EPG†2, etc.

Multi-language captions,program recommendations, etc

General

Other

Managed Applications Unmanaged Applications

†1 Service Information †2 Electronic Program Guide

Not allowedAccess to broadcast resources(broadcast video, sound, SI†1)

Application examples

Non-broadcast signal

*3 A generic data description format defined in the MPEG2 Transport Stream (MPEG2-TS) specification.

*4 A transmission scheme that transmits the same data repeat-edly.

Broadcast Technology No.55, Winter 2014 ● C NHK STRL12

2. An HTML5 browser with extension APIs to support Hybridcast is provided as the application engine*5. It also includes functionalities particular to Hybridcast, including ones to receive and play-back VoD and other content sent through broadband channels, functions to control applications based on the control signals described in the previous section, security management functions, and functions for linking with and controlling tablets and other external terminals.

6. Extension APIsThe HTML5 browser specifications defined by IPTVFJ2)

encompass the application engine described above. In addition to this basic HTML5 functionality, extension APIs enabling various application behaviors are defined. The major extension APIs and extension objects*6 are shown in Table 2.

7. Device Linking AgeBesides remote controls, easy-to-operate devices

such as tablets and smart phones are good means of performing interactive operations. They can also act as a second screen on which to present information. For these reasons, functionalities for linking with such terminals

Table 2: Main extension APIs and extension objects

Application object

Application Information

table object

Receiver Device object

EIT†1 related object

Stream-Event-Target object

BMLCompatObject object

Device linking functions

Broadcast Video Object

†1 Event Information Table: A Table (or series of Tables) containing EPG information multiplexed on the broadcast signal.

†2 Introduced in HTML5, functions for handling video (tags).

Object for controlling application launch and other application state.

Object representing application control information. This enables applications to

obtain information related to the application boundary.

Object representing the receiver device. This object provides access to channel

selection information, information about the program currently being viewed,

and other information specific to the receiver device.

Object representing EPG information.

Object for handling trigger signals from the broadcast signal (event messages).

Object for handling functions particular to data broadcasts.

A subset of the Receiver Device object functions such as, for passing the initial

URL to the linked terminal, and for exchanging messages.

The object for handling broadcast video. With Hybridcast, broadcast video is not

handled by the HTML5 Video element†2. This object is defined as an alternative.

*5 The application run-time environment provided for excution of applications in a receiver.

*6 Collections of extension APIs classified by function.

Figure 2: Organization of Hybridcast receiver (from IPTVFJ STD-0010)

HTML5 Application

Application Engine

Application Launcher†1

Resident �Application†2

Receiver Functions

Hardware

Communications Interface

Video Decoder

Audio Decoder ・・・

†1 Receiver function allowing the user to select an application to run.†2 Applications built into the receiver.†3 Function that extracts the video, audio and other data multiplexed in the broadcast signal.

TunerDeMux†3

Broadband content reception/play back function

Application control function

Security management function

Device linking and control function

Broadcast reception/playback function

Broadcast Technology No.55, Winter 2014 ● C NHK STRL

Feature

13

Figure 3: Structure of device linking software (from IPTVFJ STD-0010)

Linked terminal application

Application engine

Companion application

Basic functions for device linking

Device discovery (+ receiver control)

Text transmission

Hybridcast application

Application engine

Basic functions of receiver

ReceiverMobile terminal

has been incorporated into Hybridcast.Linking with such devices is achieved by

communication between Hybridcast application running on the receiver and an application running on the device. A device discovery function is needed to find and identify the device to communicate with. In Hybridcast, such discovery functions and communication between the receiver and terminal are accomplished by a remote-control application on a tablet or smartphone by using proprietary methods defined by the receiver manufacturer. For this reason, the device discovery and communication protocols between the receivers and linking terminals are outside of the scope of the Hybridcast specifications. Instead, an enhanced remote-control application released by the receiver manufacturer (called a companion application) provides standardized functions for communication between an application on the receiver and an application on the companion application, as well as an application runtime environment for the tablet and smartphone applications used by the individual Hybridcast services.

Users install the companion application on their tablet or smartphone.

The software architecture for device linking is shown in Figure 3. The communication indicated by the red line is for device discovery and for establishing communication between the receiver and device. Once communication is established, applications running on the receiver and the linked terminal are able to communicate with each other.

8. Example Services of HybridcastExamples of Hybridcast services were exhibited at the

2013 NHK STRL Open House. Figure 4 is an example of a menu application. The menu on the left is for selecting other applications, whereas news and a weather forecast are displayed in the middle. The dedailed news and weather forecasts are displayed by pressing a button to launch the news and weather forecast application. The menu displayed on the right contains various settings and is for selecting widget-like applications.

The menu itself is an application, so various techniques

Figure 4: Menu application example

Broadcast Technology No.55, Winter 2014 ● C NHK STRL

such as animation can also be used to display them.Figure 5 is an example of a news application called

Ticker-tape News. As its name suggests, it shows news on

a ticker-tape scrolling along the bottom of the broadcast video screen. If a headline is selected with the remote control, the NHK Web site (NHK ONLINE) is accessed,

14

Figure 6: Example application for selecting VoD content using device linking functions

TV screen

Tablet screen

Figure 5: News application example (Ticker-tape news)

News article is displayed after selecting a headline

Broadcast Technology No.55, Winter 2014 ● C NHK STRL

Feature

15

and detailed articles are retrieved and displayed on the TV screen.

The example application in Figure 6 is for selecting video on demand (VoD) content. Available and recommended content is displayed in response to requests from each receiver. This user interface is displayed on the tablet screen, in the same way as it is shown on the TV screen. Device linking functions bring the same result on the TV screen as that on the tablet, in response to manipulation on the tablet.

HTML5 capabilities imbue the application user interface with a new set of intuitive operations that complement the functions found on normal remote controls.

9 International Standardization and Future Pros-pects

The work toward international standards for systems combining broadcasting and broadband is being done by the International Telecommunication Union (ITU) and the World Wide Web Consortium (W3C). Standards created at the ITU include ITU Radiocommunications Sector (ITU-R) Recommendation BT.2037, which defines general requirements for systems, ITU Telecommunications Sector (ITU-T) Recommendation J.205, which defines technical requirements, and ITU-T Recommendation J.206, which specifies a reference architecture*7. The Hybridcast technical specifications Ver. 1.0 conform to these Recommendations. ITU-R has also issued the Report, BT.2267, which summarizes information related to systems combining broadcasting and broadband. This Report describes three systems, including HbbTV*8 from Europe, Hybridcast, and Broadcast Markup Language (BML) Type 2*9. On the other hand, HTML5 is a candidate recommendation at W3C, who handles Web standards, and it is expected to become a recommendation in 2014.

10. ConclusionsAs mentioned in Section 3, the current Hybridcast

technical specifications Ver. 1.0 defines only broadcast-oriented managed application. In the future, the Ver. 1.0 functions will be extended to include non-broadcast-oriented managed application, synchronized presentation of multiple streams, digital video recorder (DVR), and other functions.

We also anticipate studies of Hybridcast services on 8k Super Hi-Vision, which has sixteen times the resolution of current digital broadcasts, and eventual standardization of such services.

References1) IPTVFJ STD-0010, “Broadcast and Communications

Linking System Specifications Ver. 1.0” 2) IPTVFJ STD-0011, “HTML5 Browser Specifications Ver.

1.0”3) ARIB STD-B24, “Data Coding and Transmission

Specification for Digital Broadcasting 4th Edition (Ver. 5.8)”

*7 A reference for system structure and configuration.*8 A system for combining broadcasting and broadband, stan-

dardized in Europe.*9 An extended data broadcasting specification enabling VoD

content playback and simple services combining broadcast-ing and broadband.