TNT 2.0 Terminal Specification. July 9th, 2012 Version 1.1

Transcription

1 TNT 2.0 Terminal Specification July 9th, 2012 Version 1.1

2 Change Control... 3 Acronyms Table... 4 References Introduction TNT 2.0 specification Reference specifications HbbTV Browser HbbTV activation HbbTV minimum features Terminal capabilities signalling Application/oipfCapabilities object usage (informative) HbbTV services integration with Terminal native UI Applications visual signalling Applications launching Synchronization Reliability EXIT function HbbTV on pay TV services (informative) Communication with a smartcard inserted in a CI+ module Startup of an HbbTV application on a pay TV service Broadband Media Formats Streaming Protocols Constant Bit Rate Streaming Adaptive Bit Rate Streaming DASH Profile Mapping to Audio/Video media format (informative) ABR Trick Modes Support (informative) Content Protection System Signalling Content Encryption Marlin PlayReady DRM private information handling Long period Key rotation Introduction (informative) Updating KID Key windows Protection of Broadcasters Signals Display model for DTT Channels Broadband Content Recording Terminal & Application Security Terminal Security Software and Hardware Requirements HbbTV Application Security (informative) Broadcast-Related Application Authentication Broadcast-Independent Application Authentication Hardware Specification IP connectivity Remote Control (Informative) CI+ Support Terminal set-up and maintenance DTT channels set-up Menu Naming Convention IP configuration Software update Diagnostics HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 2 of 21

3 Change Control Version Dated July 7 th, 2011 FINAL DRAFT Dated February 22 nd, 2012 Version 1.0 Dated July 17, 2012 Version 1.1 Description Final distributed for comment, including Annex for submission to HbbTV 1.5 working group Approved by HD FORUM Board with limited comments. Version published following completion of specification work, removal of HbbTV 1.5 Annex and including references to HbbTV 1.5 as well as integration of comments received on Final Draft. Refined wording about DRM to follow the exact terms of HD Forum recommendation. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 3 of 21

4 Acronyms Table Acronym Description A/V Audio/Video AIT Application Information Table ATH Association de Téléchargement Hertzien CA Conditional Access CE Consumer Electronics CI Common Interface DASH Dynamic Adaptive Streaming over HTTP DHCP Dynamic Host Configuration Protocol DLNA Digital Living Network Alliance DNS Domain Name System DRM Digital Rights Management DTT Digital Terrestrial Television DVB Digital Video Broadcasting DVD Digital Versatile Disc HbbTV Hybrid Broadcast Broadband TV IP Internet Protocol MAC Media Access Control MMI Man Machine Interface OIPF Open IPTV Forum PVR Personal Video Recorder RJ45 Registered Jack 45 RTSP Real Time Streaming Protocol TCP Transmission Control Protocol TLS Transport Layer Security TNT Télévision Numérique Terrestre Digital Terrestrial Television UI User Interface WEP Wired Equivalent Privacy WPA Wi-Fi Protected Access WPA-PSK Wi-Fi Protected Access Pre-Shared Key WPS Wi-Fi Protected Setup HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 4 of 21

5 References Standards References [DASH] [OIPFDAE] [OIPFCSP] ISO/IEC Information technology Dynamic adaptive streaming over HTTP (DASH) Part 1 : Media presentation description and delivery formats OIPF Release 1 Specification Volume 5 Declarative Application Environment [V1.1] [ ] OIPF Release 1 Specification Volume 7 Authentication, Content Protection and Service Protection [V1.1] [ ] [TLS] RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [HbbTV] [HbbTV Errata] [HbbTV1.5] [CENC] [ISOBFF] [CIPLUS] ETSI TS Hybrid Broadcast Broadband TV Errata to TS V1.1.1, dated TBD HbbTV Specification Version 1.5 dated TBD ISO/IEC MPEG Common Encryption (Previously Annex I of [ISOBFF]) ISO/IEC ISO Base File Format CI Plus Specification Content Security Extensions to the Common Interface v1.3.1 TNT 2.0 Specific References [TNT2.0-FR] TNT 2.0 Functional Requirements v1.04 [FR-HD-DTT] Functional and signal specifications for HD DTT (TNT) 2.5e [FR-DTT] [MAS] [MRLBB] [MS3] [MIHBBTV] [MSPR] [MSPR1] Arrêté du 24 décembre 2001 relatif à la télévision numérique hertzienne terrestre fixant les caractéristiques des signaux émis, modifié par arrêté du 25 août 2010 Marlin Simple Adaptive Streaming (working draft WD001) Marlin Developer Community, Marlin Broadband Network Service Profile Specification, version 1.2 Marlin Developer Community, Marlin Simple Secure Streaming Specification, Version 1.0 Marlin Integration to Hybrid Broadcast Broadband TV, Version 1.0, Draft003 Microsoft PlayReady PlayReady Documentation CHM file, available to PlayReady licensees, version 2.0 [MSPR2] PlayReady Format Specification, included in MSPR1, version 2.0 [MSPR3] PlayReady Integration to HbbTV Specification, version 1.0 [MSPR4] PlayReady Binding to MPEG-DASH Specification, version 1.0 HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 5 of 21

6 1 Introduction This document is the minimum technical specification for terminals complying with the requirements expressed in [TNT2.0-FR]. TNT 2.0 aims at ensuring terminals interoperability with TNT 2.0 services. This document defines the minimum specification to be implemented to achieve this goal. It does not affect in any manner the ability of terminal manufacturer to implement any additional feature to differentiate their products and foster innovation beyond the TNT 2.0 requirements. A TNT 2.0 terminal may be a TV set, a Set-Top-Box, a DVD/Blu-Ray player/recorder or any other terminals equipped with a TNT Tuner and complying with these specifications. The scope of this document is to specify the minimum hardware and software elements required for a TNT 2.0 terminal. Where a device includes other features than just TNT 2.0 reception, this document only applies when presenting content delivered by DTT or presenting broadband content which the user reached starting from an HbbTV application signalled in the DTT broadcast. A non-exclusive list of features which are outside the scope of this document include receivers offering access to content on the home network (e.g. via DLNA), access to networks other than DTT and access to the open internet. 1.1 TNT 2.0 specification TNT 2.0 terminals shall implement all of the mandatory requirements in the HbbTV specification [HbbTV] and [HbbTV 1.5] (including [HbbTV Errata]) as well as [FR-DTT] and [FR-HD-DTT] plus the extensions in this document. It is expected that most of these extensions will be incorporated into the next version of the HbbTV specification. In addition, TNT 2.0 terminals shall include at least one DRM. HD Forum recommends that TNT2.0 terminals support either Marlin or Microsoft PlayReady that are the DRMs that will be supported by the broadcasters. HD Forum may recommend additional DRMs according to the evolution of the market. 1.2 Reference specifications TNT 2.0 is mainly based on the standards and specification shown in the table below: HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 6 of 21

7 Hybrid Broadcast Broadband TV Proposed extension for HbbTV 1.5 TS MPEG DASH Adaptive Streaming protocol ISO/IEC MPEG Common Encryption ISO/IEC DRM Providers Vol 2 & 5 CEA-2014 TS Marlin PlayReady W3C specs The aim of this specification is threefold: 1. Provide references to the applicable standards for TNT When required, provide additional specification for the implementation of existing standards 3. If needed, provide the specification of TNT 2.0 component not already covered by a standard HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 7 of 21

8 2 HbbTV Browser 2.1 HbbTV activation The terminal may include a menu option to allow the user to activate / deactivate the HbbTV feature channel by channel. By default, the HbbTV feature shall be activated. 2.2 HbbTV minimum features The following table presents which HbbTV features are required for TNT 2.0: Feature DRM CI+ Status Mandatory Mandatory if Common Interface port available 2.3 Terminal capabilities signalling Application/oipfCapabilities object usage (informative) The device capabilities are returned by the application/oipfcapabilities object that is defined in section 10.3 of [HbbTV 1.5] and required by section 1.1 of this specification. The xmlcapabilities property of the application/oipfcapabilities object shall provide the DRMSystemID of the DRM supported by the terminal, as defined in section of [OIPFDAE]. 2.4 HbbTV services integration with Terminal native UI Applications visual signalling The user interface displayed on channel change is the responsibility of the terminal manufacturer. However, the presence of broadcast-related TNT 2.0 services may be indicated to the consumer in this user interface. This information shall be presented whenever this UI is recalled (e.g. when pressing INFO button or equivalent) Applications launching It is accepted that the terminal UI may need to temporarily gain focus and use some keys requested by the running HbbTV application. This may be when the terminal requires the user to interact with the system user interface, for example a dialogue box saying You have lost broadband connection. Press RED to close this message, or a CI+ MMI message. It is the responsibility of both the terminal implementation and the application implementation to ensure that starting and stopping applications does not cause any A/V glitch when that application has not modified the broadcast video. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 8 of 21

9 2.4.3 Synchronization It is expected that do it now stream events support, as mandated by HbbTV, will be sufficient for TNT 2.0 needs. A do it now event should be executed by the terminal in less than 2s. This duration shall be measured between the do-it-now event occurring in the Transport Stream at the input of the terminal, and the call to the corresponding function registered with addstreameventlistener. 2.5 Reliability Broadcasters shall take every precaution necessary to ensure their applications conform to the specifications and do not use any non-specified extensions. It is expected that HbbTV applications are properly tested before being deployed. To preserve a positive perception of interactivity by the end user, it is also important that the HbbTV software implementation ensures a good level of robustness regarding faulty applications and low resources availability (e.g. insufficient memory). Therefore it is expected that terminal manufacturers take every precaution necessary to prevent an HbbTV application to alter or crash the whole software of the terminal, in particular under the following conditions: 1. An application is opened and closed by the user 20 times consecutively 2. The user changes the program selection before the application has been completely loaded, whether from broadcast or broadband. 3. The terminal downloads, or attempts to download an XML, HTML, or media file, which has been truncated. 4. A broadband application download is prematurely interrupted by a TCP connection reset, or a sustained packet loss. 5. A broadcast application download is prematurely interrupted by a carousel removal on the broadcast side. 6. The terminal attempts to download an initial HTML page, with a file size of 100MB (for the avoidance of doubt, it is not required that such a page can be properly loaded and rendered) 7. An application attempts to carry out operations requiring more memory than the receiver has available. (For example, creation and initialisation of an arbitrarily large array) 8. The browser raises exceptions that are not explicitly caught by the application 9. An application enters an infinite loop (including infinite recursion) In all of these cases the terminal shall remain responsive to channel change requests. During the execution of an application, the exit function (see 2.6) shall terminate the application in all circumstances. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 9 of 21

10 2.6 EXIT function [HbbTV] describes an EXIT or TV or comparable button in Table 15 with a status of optional. This function shall be mandatory for TNT 2.0 devices. Its role shall be to terminate the currently running HbbTV application, as described in [HbbTV] section ( Directly by the user ). Note that exiting a broadcast-related application results in the autostart application of the current channel being re-started from the beginning. It does not offer the possibility to exit from HbbTV. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 10 of 21

11 3 HbbTV on pay TV services (informative) 3.1 Communication with a smartcard inserted in a CI+ module It is reminded that a HbbTV compliant receiver implementing a CI+ interface shall implement the Content Service Protection API defined in clause 7.6 of specification [OIPFDAE]. This API can be used to communicate with the smartcard inserted in a CI+ module using the SAS resource implemented by this module in conformance with clause of specification [OIPFCSP]. 3.2 Startup of an HbbTV application on a pay TV service It is reminded that the life cycle of an HbbTV application declared on a pay TV service is not related to the ability to access and descramble the audio/video components of this service. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 11 of 21

12 4 Broadband Media Formats The terminal may include functionalities implying the simultaneous processing of multiple video streams potentially coming from different sources, for example a PVR. In such cases, the terminal shall still be able to present the A/V contents streamed over broadband in conformance with the specifications regulating the presentation of the supported formats. When content is streamed in adaptive bit rate, in the clear or encrypted, the additional specifications described in Section 5 and Section 6 of this document shall apply. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 12 of 21

13 5 Streaming Protocols 5.1 Constant Bit Rate Streaming Support for unicast streaming that is defined in clause of [HbbTV] is required by section 1.1 of this specification. 5.2 Adaptive Bit Rate Streaming Support for adaptive streaming that is defined in Annex B of [HbbTV 1.5] is required by section 1.1 of this specification. For the avoidance of doubt, the support of Segments being delivered over https and the support of MPD delivery over https are not mandated for TNT DASH Profile Mapping to Audio/Video media format (informative) For the avoidance of doubt, it is reminded that support of the Base media file format live profile implies that the terminal is able to decode streams when each moof box contains only one track fragment box traf and the associated media data box mdat contains only the media samples referenced from that track fragment box ABR Trick Modes Support (informative) The terminal shall allow the HbbTV application to control the Play, Pause, Stop, Fast Forward and Fast Rewind keys as defined in [HbbTV]. This will enable the service provider to disable trick modes when required. Note: Service providers should always request the Play, Pause, Stop, Fast Forward and Fast Rewind keys when playing broadband content. If any trick mode function is not supported, the application should display a suitable message to the user when the relevant key is pressed Content Protection System Signalling In case content is protected by one or more recommended TNT2.0 DRM system(s), these DRM system(s) shall be identified in the DASH MPD using the schemeiduri attribute of the ContentProtection element of a Representation, or of a Group of Representations. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 13 of 21

14 6 Content Encryption TNT 2.0 content protected with a DRM shall be streamed using [DASH] in compliance with Section 5 of this document. Support for [CENC] that is defined in Annex C of [HbbTV 1.5] is required by section 1.1 of this specification. For the avoidance of doubt, TNT 2.0 Terminal is not required to support DRM encryption for content not streamed using [DASH]. For all DRMs providing Content Protection in TNT 2.0, the DRM/HbbTV integration will be based on the principles as defined in Section 7.6 of [OIPFDAE]. Terminal manufacturers shall implement at least one DRM (see 1.1) Terminals shall comply with the relevant DRM vendor robustness and compliancy rules, and special care shall be taken when implementing the DRM secure key box in the terminal. 6.1 Marlin Marlin is one of the DRMs recommended for TNT 2.0 content protection. When Marlin is supported by the Terminal: Terminals shall support the Terminal-Centric approach as defined in Section 4.1 of [OIPFCSP] and Terminals shall further support Marlin Simple Secure Streaming as per [MS3] and [MIHBBTV]. 6.2 PlayReady PlayReady is one of the DRMs recommended for TNT 2.0 content protection. When PlayReady is supported by the Terminal: Terminals shall support Microsoft PlayReady as per [MSPR3] and [MSPR4] to allow Content Protection operations and Protected Content consumption. For PlayReady signaling to the HbbTV application, the CA System ID to be used is provided in [MSPR3] For PlayReady signaling in the MPEG-DASH asset, the format and values to be used (including SystemID) are provided in [MSPR4] and [MSPR2] The specifications are provided by Microsoft to PlayReady licensees. 6.3 DRM private information handling If DRM private data are available in the DASH MPD and in the pssh box located in the moov box, the terminal shall use the information from the MPD. If DRM private data are available in the DASH MPD and in the pssh box located in the moof box, the Terminal shall use the information from the pssh box. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 14 of 21

15 6.4 Long period Key rotation Introduction (informative) Long period key rotation means changing the encryption key(s) used to encrypt the media fragments in an MPEG DASH representation at a low update frequency. Typically, this means a key update every few hours, on the order of 6 or more hours. This is not about supporting high-frequency key changes with group key mechanisms as defined in [CENC], nor trying to reproduce the frequency update of control word as typically done in broadcast DVB services. The use case for key rotation is mainly for linear channels, where stream duration is not related to an asset boundary. In that case, a TNT 2.0 Terminal may stream across a point in time where the encrypted fragments may need to change encryption key(s) Updating KID The terminal shall support long period key rotation, where each Period of a stream may use new KIDs. KID changes shall be signaled by using a change of Period, as defined in [DASH]. During a single period, the KID(s) associated with the media fragments shall always stay the same and shall all be signalled via the default_kid field of the TrackEncryptionBox located in the sample description of each track. To allow automatic update of Periods, the MPD for the stream shall signal MPD@type="dynamic", to indicate to the terminal that it needs to update the MPD when it reaches the end of available periods and/or based on the duration signaled in MPD@minimumUpdatePeriod. For the avoidance of doubt, the sample group mechanism defined in [CENC] is not used to signal a change of KID for the media samples, and the support of sample groups is not required for TNT Key windows Each Period of the stream has its own KID(s) and associated media encryption keys. When a terminal requests the license that will entitle it to obtain the media decryption keys necessary to decrypt the media fragments, the DRM license server can deliver not only the key(s) for the current Period, but also for one or more upcoming Periods (for example, the next and next-next Period). By thus doing, the terminal does not need to acquire a new license when it reaches the end of the current Period, or subsequent Periods, until it reaches the last Period for which it has obtained keys. Should the terminal reach a point in time past the last Period in the window of keys returned by the license server (which would be quite a long time after starting the stream), the terminal shall raise an ondrmrightserror event to the application. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 15 of 21

16 7 Protection of Broadcasters Signals 7.1 Display model for DTT Channels When the video plane of the terminal as specified in Section of [HbbTV] is displaying content provided by a DTT service provider, either broadcast or broadband, full screen or resized, the following restrictions shall apply: The usage of the HbbTV application graphic plane is reserved for the applications under the control of the broadcaster (i.e. signalled in the AIT or launched by an application signalled in the AIT). CI+ MMI messages and the terminal system UI are allowed to use the terminal-specific application graphic plane. 7.2 Broadband Content Recording It shall not be possible for the user to directly initiate the recording of broadband delivered content onto any form of local storage when that content has been requested by an HbbTV application. Attempting to record by pressing a REC button or equivalent shall be ignored. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 16 of 21

17 8 Terminal & Application Security 8.1 Terminal Security Software and Hardware Requirements TNT 2.0 does not require any specific requirement with regard to security for the hardware design and the software part of a TNT 2.0 terminal developed by the CE manufacturer. However, a TNT 2.0 terminal shall be compliant with the compliance and robustness rules of the supported DRM solution which may have impact on the overall design and manufacturing of the terminal. 8.2 HbbTV Application Security (informative) This aspect of the trust model deals with how a terminal may trust applications that are downloaded and run. In an HbbTV model, there are two possible sources for applications, including broadcast and broadband channels. It is important for the platform trust model to address what HbbTV applications may be allowed to run, and for those that can run, what functionality they are allowed to access Broadcast-Related Application Authentication In this case, the authentication of an application coming from the broadcast network is implicit. Inserting an application in a broadcast signal by an unauthorized person is not so easy, hence considering a broadcast application as trusted and authenticated by default can be accepted Broadcast-Independent Application Authentication This is out of scope of this document. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 17 of 21

18 9 Hardware Specification The following describes the minimum hardware specification for a TNT 2.0 terminal. The terminal manufacturer shall be free to go beyond these expectations. 9.1 IP connectivity The terminal shall provide a broadband network interface supporting TCP/IP. This may be achieved by implementing an RJ45 Ethernet port or by providing wireless networking capability (IEEE x) or by other means. It is recommended that at least one RJ45 port is available on the terminal. For diagnostic purposes, it is recommended that the port have link/traffic indicators. If Wi-Fi is supported, the terminal shall implement security protocols to protect data transmission over the wireless network. For compliancy reasons with common home network equipments, it is recommended that at least WEP, WPA-PSK and WPA2-PSK protocols are supported. IPv4 shall be supported. For the avoidance of doubt, IPv6 is not required for TNT Remote Control (Informative) The remote control device must provide (or emulate for non classic devices) the following functions: 10 digit functions labelled from 0 to 9 Colour Functions (Red, Green, Yellow, Blue) Arrow Functions (Up, Down, Left, Right) OK or ENTER Play / Stop / Pause Fast Forward / Fast Rewind Back Exit Guide Text The Text function is usually used to launch teletext services when available. For the avoidance of doubt, the support of Standard Teletext (as defined in [HbbTV]) is not mandated by TNT 2.0. Only Digital Teletext Application, as defined in [HbbTV], is required. In case the device is not a conventional remote control with buttons, the key press must be emulated so that HbbTV applications can handle key press events transparently as required in TS section 5.2. In this document, the device, regardless of its physical implementation, will be referenced as the remote control, and key press will be mentioned as events perceived by the HbbTV software. In order that all forms of remote control technologies can be catered for, this specification will, wherever possible, refer to remote control functions, rather than traditional key presses. It is however recognised that the term key press has become a de facto accepted TV terminology, and should the key press or button press terminology be used, or referred to in this specification, it must be assumed that this refers to any other means by which the equivalent functionality can be achieved. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 18 of 21

19 9.3 CI+ Support If the receiver incorporates a Common Interface slot, this shall be compliant with the CI-Plus specification. As recommended by the HD FORUM, the use of a module to support the DRM functionalities is a solution to be investigated, however, the implication on the CI Plus specification, and the TV set itself are not compatible with the launch timeframe of TNT 2.0. Such addition to the functional scope of CI Plus is outside the mandate of the TNT2.0 technical working group. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 19 of 21

20 10 Terminal set-up and maintenance 10.1 DTT channels set-up The terminal shall automatically detect modifications to the DTT broadcast channel line up, and update its internal database accordingly. The mechanism to be used to detect such modifications and the operational mode to update the channel line-up are left open to the terminal manufacturer Menu Naming Convention Terminal manufacturers should use a common naming convention to ease communication with consumers. The common naming convention for TNT 2.0 terminal set up includes: INSTALLATION DES CHAINES (Channel scanning) MISE A JOUR DU LOGICIEL (Firmware update) 10.3 IP configuration By default, the broadband network interface shall be automatically configured using DHCP protocol. It shall also be possible to manually configure the interface, by entering the following parameters: IP address, Network mask, Gateway address, DNS server address Wi-Fi is not mandated for TNT 2.0, but if it is supported, it is recommended that the terminal provides a setup facility (e.g. WPS) Software update The terminal shall support a secured mechanism to enable the update of the embedded software using a practical mechanism such as the ATH infrastructure. Other proprietary secure network updates through IP are valid. In addition, terminals may support additional update mechanisms such as firmware download over broadband or using an external mass storage device. It is recommended that the terminal informs the user when new software is available. The update mechanism is under the responsibility of the terminal manufacturer Diagnostics In order to ease troubleshooting by a customer care service, the receiver should provide a resident info screen presenting at least the following information: CE manufacturer name, Model name, Hardware & Software versions, HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 20 of 21

21 CA System ID supported by the terminal MAC address IP status (connected / not connected) IP parameters (IP address, Network mask, gateway address, DNS server address) This info screen shall be presented on user request, and shall be available from the terminal system UI. HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential Page 21 of 21