1、 Recommendation ITU-R BT.2075-0 (06/2015) Integrated broadcast-broadband system BT Series Broadcasting service (television) ii Rec. ITU-R BT.2075-0 Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economical use of the radio-frequency spectrum by
2、 all radiocommunication services, including satellite services, and carry out studies without limit of frequency range on the basis of which Recommendations are adopted. The regulatory and policy functions of the Radiocommunication Sector are performed by World and Regional Radiocommunication Confer
3、ences and Radiocommunication Assemblies supported by Study Groups. Policy on Intellectual Property Right (IPR) ITU-R policy on IPR is described in the Common Patent Policy for ITU-T/ITU-R/ISO/IEC referenced in Annex 1 of Resolution ITU-R 1. Forms to be used for the submission of patent statements an
4、d licensing declarations by patent holders are available from http:/www.itu.int/ITU-R/go/patents/en where the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC and the ITU-R patent information database can also be found. Series of ITU-R Recommendations (Also available
5、 online at http:/www.itu.int/publ/R-REC/en) Series Title BO Satellite delivery BR Recording for production, archival and play-out; film for television BS Broadcasting service (sound) BT Broadcasting service (television) F Fixed service M Mobile, radiodetermination, amateur and related satellite serv
6、ices P Radiowave propagation RA Radio astronomy RS Remote sensing systems S Fixed-satellite service SA Space applications and meteorology SF Frequency sharing and coordination between fixed-satellite and fixed service systems SM Spectrum management SNG Satellite news gathering TF Time signals and fr
7、equency standards emissions V Vocabulary and related subjects Note: This ITU-R Recommendation was approved in English under the procedure detailed in Resolution ITU-R 1. Electronic Publication Geneva, 2015 ITU 2015 All rights reserved. No part of this publication may be reproduced, by any means what
8、soever, without written permission of ITU. Rec. ITU-R BT.2075-0 1 RECOMMENDATION ITU-R BT.2075-0 Integrated broadcast-broadband system (Question ITU-R 131/6) (2015) Scope This Recommendation provides guidance in choosing an integrated broadcast-broadband (IBB) system. The guidance is described in te
9、rms of service capabilities and technical elements of the IBB systems. The ITU Radiocommunication Assembly, considering a) that Question ITU-R 131/6 has invited the ITU-R to study, inter alia, what data structure(s) is(are) most suited to conveying multimedia information to digital broadcast receive
10、rs and what Application Programming Interfaces (APIs) should be specified for multimedia applications in broadcasting and webcasting platforms; b) that Report ITU-R BT.2267 describes several IBB systems; c) that Recommendations ITU-R BT.2037 and ITU-R BT.2053 define requirements of IBB systems; d) t
11、hat devices with broadband Internet access are becoming widely available and offer multimedia applications; e) that an ability to provide connected TV enabled devices with already integrated off-the-shelf applications is of relevance to the end-user; f) that an addition of content delivery over broa
12、dband network to the broadcast channel optimizes the bandwidth usage of the broadcast channel; g) that common platforms are desirable for production and international exchange of IBB content and applications, recommends 1 that administrations, broadcasters, and related industries wishing to implemen
13、t an IBB system should consider the service capabilities and technical elements of the IBB systems described in this Recommendation; 2 that the IBB systems listed in the Annex should be considered for the choice of an IBB system and implementation of IBB services. 2 Rec. ITU-R BT.2075-0 Annex 1 Intr
14、oduction This Recommendation provides guidance information for administrations, broadcasters, and related industries to consider implementing an IBB system. Section 3 describes the IBB systems while 4 and 5 describe the service capabilities and technical elements of the IBB systems. 2 Abbreviations
15、ACAP Advanced common application platform CEA Consumer electronics association DAE Declarative application environment DASH Dynamic adaptive streaming over HTTP DRM Digital rights management DVB Digital video broadcasting IBB Integrated broadcast-broadband OIPF Open IPTV forum MMT MPEG media transpo
16、rt MPEG Motion picture expert group VOD Video on demand W3C World Wide Web Consortium 3 The IBB Systems 3.1 System definition The IBB Systems considered in this Recommendation are defined by the following specifications or standards. HbbTV For HbbTV1.5: ETSI TS 102 796 V1.2.1 (2012) http:/webapp.ets
17、i.org/ewp/copy_file.asp?wki_id=39272 For HbbTV 2.0: HbbTV Specification 2.0 http:/hbbtv.org/pages/about_hbbtv/HbbTV_specification_2_0.pdf Hybridcast IPTVFJ STD-0010 and STD-0011 http:/www.iptvforum.jp/en/download/ ARIB STD-B62 V1.0 http:/www.arib.or.jp/english/html/overview/sb_ej.html Rec. ITU-R BT.
18、2075-0 3 HTML5 based Smart TV Platform TTAK.KO-07.0111/R1 http:/www.tta.or.kr/English/new/standardization/eng_ttastddesc.jsp?stdno=TTAK.KO-07.0111/R1 3.2 System summary 3.2.1 HbbTV HbbTV (Hybrid Broadcast Broadband TV) is an industry standard providing an open and business neutral technology platfor
19、m that seamlessly combines TV services delivered via broadcast with services delivered via broadband and also enables access to Internet only services for consumers using connected TVs and set-top boxes. The HbbTV specification is based on existing standards and web technologies including OIPF (Open
20、 IPTV Forum), CEA, DVB and W3C. The standard provides the features and functionality required to deliver feature rich broadcast and internet services. Utilizing standard Internet technology, it enables rapid application development. It defines minimum requirements simplifying the implementation in d
21、evices and leaving room for differentiation, this limits the investment required by CE manufacturers to build compliant devices. For a Connected TV set that is equipped with the HbbTV function, the consumer just has to push the red button on the TVs remote control to make the HbbTV launch page of th
22、e corresponding broadcaster visible. Subsequently, the end-user can select all services (incl. video-on-demand (VOD) and search functions) that are offered by or via this broadcast service specific portal. Example: A user would like to have more information on, say “Napoleon”. The result of the sear
23、ch will be a list of all Napoleon-related video clips that are stored and offered by the collaborating broadcasters. Potentially, sound radio programmes and adapted Web-pages (incl. pictures and text files) could also be included in the result list. Viewing of the retrieved content is currently acco
24、mplished on the TV set but may in future also happen on a second screen, e.g. on a tablet computer. HbbTV was developed in 2009 and first standardized by ETSI in 2010. Version 1.5 of the HbbTV specification has been published by the HbbTV Consortium in April 2012. Standardization of HbbTV 1.5 as ETS
25、I TS 102796 v1.2.1 took place by ETSI in November 2012. Amongst other new features, adaptive streaming (in line with MPEG-DASH) is supported. Currently, work on Version 2.0 based on HTML5 is completed. Version 2.0 of HbbTV was released by the HbbTV Alliance in February 20215. HbbTV is used for infor
26、mation, education and entertainment (e.g. catch-up TV). It is also used for commercial applications (music download, online shopping, (targeted) advertisement, etc.). HbbTV is very suited to provide access services for people with disabilities: signer video, audio description, spoken subtitles, mult
27、i-lingual text subtitles, multi-language sound tracks or additional sound tracks with clear(er) audio dialogues, etc. It was also demonstrated that HbbTV represents a prime means to alert the general public in case of a crisis (automatic popup of alert messages). 3.2.2 Hybridcast Hybridcast, the IBB
28、 system that uses HTML5, was standardized in Japan for versions 1.0 and 2.0 in March, 2013 and June, 2014 respectively. The system facilitates the offering of services through a combination of broadcast and broadband telecommunication resources and features. The latest specifications considered most
29、 of the requirements in Recommendations ITU-R BT.2053 and ITU-T J.205 including broadcast centric scenario. To achieve the required functionalities, the specifications define system model, application model, application control signals, receiver behaviour, additional APIs etc. The specifications als
30、o define mechanisms and functionalities for companion device collaboration, non-broadcast-oriented managed application, application 4 Rec. ITU-R BT.2075-0 programming interfaces (APIs) for accurately synchronized presentation of video or graphics with broadcast video, application invocation for play
31、ing back of VOD or recordings, and support for MPEG-DASH. In addition, to support interactive ultra high definition television (UHDTV), ARIB STD-B62, the second generation multimedia coding scheme for digital broadcasting, was standardized in July, 2014. ARIB STD-B62 defines Hybridcast application e
32、nvironment for UHDTV with MPEG2-TS and MPEG media transport (MMT). When using MPEG2-TS, existing digital broadcasting standards can be used for interactive UHDTV services. When using MMT, ARIB STD-B62 states how Hybridcast application environment works with MMT. One of the system specifications, IPT
33、VFJ STD-0010, defines system model, application model, application control signals, transport protocols, behaviour for using VOD, monomedia coding, and receiver functions. IPTVFJ STD-0011 defines HTML application structure, behaviour and syntax of elements, and additional objects and APIs. In Hybrid
34、cast standards, two types of applications are defined to allow flexible and varied IBB services. One of the types, broadcast-oriented managed application, is an application which is strictly associated to broadcast channels. This type of applications is controlled by an application control signal de
35、livered over broadcast signals to launch and terminate such applications. The other type, non-broadcast-oriented managed application, is an application authorized by broadcasters and allowed access to broadcast resources. Non broadcast-oriented managed applications are allowed to be presented with b
36、roadcast programmes simultaneously, and end-users can control the launch and termination of the applications at any time regardless of the selection of broadcast channel. All Hybridcast applications are under control of application control information. When providing service associated IBB services
37、which is tightly combined with broadcasting services and can be provided by broadcast-oriented managed applications, providing a retrieval chain of application control information initiated by broadcast services is required. For stand-alone IBB services independent from broadcast channels and provid
38、ed by non-broadcast-oriented managed applications, it is assumed that a receiver obtains application control information from repository servers. Application control information for this type notifies broadcast and receiver resources the application accesses. Broadcasters provide application control
39、 information that contains information on execution condition and access restriction to broadcast resources. A receiver evaluates application control information from both application repository and broadcasters, and determines how to manage the application. Formats of application control informatio
40、n are defined in ARIB STD-B24, IPTVFJ STD-0011 and ARIB STD-B60 each of which is used for relevant delivery channels and services. Hybridcast services were launched in September, 2013. Hybridcast is used to offer a variety of information including news, weather, stock market information, Electronic
41、Program Guide (EPG), and VOD as well as program related services for quiz shows. HTML5 allow the provision of rich and useful services by involving existing web servers and thus the number of services that use Hybridcast is increasing rapidly. 3.2.3 HTML5 based Smart TV Platform “HTML5 based Smart T
42、V Platform” is an open smart TV platform standard that specifies the web runtime environments for smart TV application based on state-of-the-art HTML5 technologies. An application in compliance with this specification can be developed and deployed taking advantage of HTML5 features and interfaces, a
43、nd will provide the same user experience on smart TV receivers from various broadcasting systems like terrestrial, cable, satellite and IPTV. This specification suggests four criteria to define smart TV applications types considering smart TVs specific features different from PC or smart phone. They
44、 consist of execution method, application packaging, broadcasting resource relation and channel bound. According to four criteria, Rec. ITU-R BT.2075-0 5 application can be divided into signal application, store application and broadband application, or divided into package application and non-packa
45、ge application, or divided into broadcast activated application and broadcast inactivated application, or finally divided into channel bound application and channel unbound application. These kinds of applications types define the specific smart TV receivers behavior according to these types of requ
46、irements. Furthermore, it defines smart TV extended APIs that is the set of interfaces to support smart TV specific features such as smart TV application, broadcasting resources, smart TV devices and other advanced functionalities. Through the extended APIs, smart TV application can use interfaces t
47、o manage current running application like create, destroy and key/permission control, to control broadcasting video, channel and program, to get information about manufacturer, model and version. Besides, the extended APIs also supports multiscreen interfaces to communicate and work together with co
48、mpanion devices like smart phone or tablet and digital rights management (DRM) interfaces to present protected contents. Finally, to support the applications lifecycle control according to application signal provided by broadcaster, this specification defines an application signal profile based on A
49、IT of ETSI TS 102 809. It defines application package profile for configuration and compression format to support download and install from application repository. Furthermore, it has other features like protocol and contents formats, receiver minimum requirements and own profile definitions. This specification has been developed in continuous relationship with the standardization committee of TTA (Telecommunications Technology Association). The next version will include new features like content synchronization, remote application control, advanced user input like gesture a
