TNT 2.0 Terminal Specification July 9th, 2012 Version 1.1

Transcription

TNT 2.0
Terminal Specification
July 9th, 2012
Version 1.1
Change Control .................................................................................................................................... 3
Acronyms Table ................................................................................................................................... 4
References ........................................................................................................................................... 5
1 Introduction .................................................................................................................................. 6
1.1
TNT 2.0 specification .............................................................................................................. 6
1.2
Reference specifications ......................................................................................................... 6
2 HbbTV Browser ............................................................................................................................ 8
2.1
HbbTV activation ..................................................................................................................... 8
2.2
HbbTV minimum features ....................................................................................................... 8
2.3
Terminal capabilities signalling ............................................................................................... 8
2.3.1
Application/oipfCapabilities object usage (informative) ................................................... 8
2.4
HbbTV services integration with Terminal native UI ............................................................... 8
2.4.1
Applications visual signalling ........................................................................................... 8
2.4.2
Applications launching ..................................................................................................... 8
2.4.3
Synchronization ............................................................................................................... 9
2.5
Reliability ................................................................................................................................. 9
2.6
EXIT function ......................................................................................................................... 10
3 HbbTV on pay TV services (informative) ................................................................................. 11
3.1
Communication with a smartcard inserted in a CI+ module ................................................. 11
3.2
Startup of an HbbTV application on a pay TV service .......................................................... 11
4 Broadband Media Formats ........................................................................................................ 12
5 Streaming Protocols .................................................................................................................. 13
5.1
Constant Bit Rate Streaming................................................................................................. 13
5.2
Adaptive Bit Rate Streaming ................................................................................................. 13
5.2.1
DASH Profile Mapping to Audio/Video media format (informative) ............................... 13
5.2.2
ABR Trick Modes Support (informative) ........................................................................ 13
5.2.3
Content Protection System Signalling ........................................................................... 13
6 Content Encryption .................................................................................................................... 14
6.1
Marlin..................................................................................................................................... 14
6.2
PlayReady ............................................................................................................................. 14
6.3
DRM private information handling ......................................................................................... 14
6.4
Long period Key rotation ....................................................................................................... 15
6.4.1
Introduction (informative) ............................................................................................... 15
6.4.2
Updating KID .................................................................................................................. 15
6.4.3
Key windows .................................................................................................................. 15
7 Protection of Broadcasters Signals ......................................................................................... 16
7.1
Display model for DTT Channels .......................................................................................... 16
7.2
Broadband Content Recording ............................................................................................. 16
8 Terminal & Application Security ............................................................................................... 17
8.1
Terminal Security .................................................................................................................. 17
8.1.1
Software and Hardware Requirements.......................................................................... 17
8.2
HbbTV Application Security (informative) ............................................................................. 17
8.2.1
Broadcast-Related Application Authentication .............................................................. 17
8.2.2
Broadcast-Independent Application Authentication ....................................................... 17
9 Hardware Specification.............................................................................................................. 18
9.1
IP connectivity ....................................................................................................................... 18
9.2
Remote Control (Informative) ................................................................................................ 18
9.3
CI+ Support ........................................................................................................................... 19
10
Terminal set-up and maintenance ........................................................................................ 20
10.1
DTT channels set-up ......................................................................................................... 20
10.2
Menu Naming Convention ................................................................................................. 20
10.3
IP configuration .................................................................................................................. 20
10.4
Software update ................................................................................................................ 20
10.5
Diagnostics ........................................................................................................................ 20
HD FORUM TNT 2.0 Terminal Specification V1.1- Confidential
Page 2 of 21
Change Control
Version
Description
th
Dated July 7 , 2011
FINAL DRAFT
nd
Final distributed for comment, including Annex for submission to
HbbTV 1.5 working group
Approved by HD FORUM Board with limited comments.
Dated February 22 , 2012
Version 1.0
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.
Dated July 17, 2012
Version 1.1
Refined wording about DRM to follow the exact terms of HD Forum
recommendation.
Page 3 of 21
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
Page 4 of 21
References
Standards References
[DASH]
ISO/IEC 23009-1 Information technology –Dynamic adaptive streaming over
HTTP (DASH) – Part 1 : Media presentation description and delivery formats
[OIPFDAE]
OIPF Release 1 Specification Volume 5 – Declarative Application Environment
[V1.1] – [2009-10-08]
[OIPFCSP]
OIPF Release 1 Specification Volume 7 – Authentication, Content Protection
and Service Protection [V1.1] – [2009-10-08]
[TLS]
RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2
[HbbTV]
ETSI TS 102 796 1.1.1 Hybrid Broadcast Broadband TV
[HbbTV Errata]
Errata to TS 102 796 V1.1.1, dated TBD
[HbbTV1.5]
HbbTV Specification Version 1.5 dated TBD
[CENC]
ISO/IEC 23001-7 MPEG Common Encryption
(Previously Annex I of [ISOBFF])
[ISOBFF]
ISO/IEC 14496-12 ISO Base File Format
[CIPLUS]
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]
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
[MAS]
Marlin Simple Adaptive Streaming (working draft WD001)
[MRLBB]
Marlin Developer Community, Marlin – Broadband Network Service Profile
Specification, version 1.2
[MS3]
Marlin Developer Community, Marlin – Simple Secure Streaming Specification,
Version 1.0
[MIHBBTV]
Marlin Integration to Hybrid Broadcast Broadband TV, Version 1.0, Draft003
[MSPR]
Microsoft PlayReady
http://www.microsoft.com/playready/default.mspx
[MSPR1]
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
Page 5 of 21
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:
Page 6 of 21
Hybrid Broadcast Broadband TV
Proposed extension for HbbTV 1.5
MPEG DASH
Adaptive
Streaming
protocol
ISO/IEC
23009-1
TS 102 796
MPEG
Common
Encryption
ISO/IEC
23001-7
DRM Providers
Vol 2 & 5
CEA-2014
TS 102 809
Marlin
PlayReady
W3C specs
The aim of this specification is threefold:
1. Provide references to the applicable standards for TNT 2.0
2. 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
Page 7 of 21
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
Status
DRM
Mandatory
CI+
Mandatory if Common Interface port available
2.3 Terminal capabilities signalling
2.3.1 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 9.3.10 of [OIPFDAE].
2.4 HbbTV services integration with Terminal native UI
2.4.1 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).
2.4.2 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.
Page 8 of 21
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.
Page 9 of 21
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 6.2.2.1 (“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.
Page 10 of 21
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 4.2.3 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.
Page 11 of 21
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.
Page 12 of 21
5 Streaming Protocols
5.1 Constant Bit Rate Streaming
Support for unicast streaming that is defined in clause 7.3.2.1 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 2.0.
5.2.1 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.
5.2.2 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.
5.2.3 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.
Page 13 of 21
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.
Page 14 of 21
6.4 Long period Key rotation
6.4.1 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).
6.4.2 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 2.0.
6.4.3 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.
Page 15 of 21
7 Protection of Broadcasters Signals
7.1 Display model for DTT Channels
When the video plane of the terminal as specified in Section 10.1.1 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.
Page 16 of 21
8 Terminal & Application Security
8.1 Terminal Security
8.1.1 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.
8.2.1 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.
8.2.2 Broadcast-Independent Application Authentication
This is out of scope of this document.
Page 17 of 21
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 802.11x)
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 2.0.
9.2 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 102 796
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.
Page 18 of 21
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.
Page 19 of 21
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.
10.2 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).
10.4 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.
10.5 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,
Page 20 of 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.
Page 21 of 21

TNT 2.0 Terminal Specification July 9th, 2012 Version 1.1

Transcription

Documents pareils

This course covers the 1553 military bus - ac6

Calais Map - Auto Europe

504051-1001 Datasheet

Fraport v Philippines (Germany-Philippines BIT)

Quick Reference Guide Hyper Terminal Setup

8212 Moneris Transelect QRG

NOTE

Leidenfrost on a ratchet - PMMH

Oliver Rothschild is a corporate strategist, active within a range

IMEX – MPI – MCI Future Leaders Forum

TS 102 230 - V7.2.0