This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/DVB/DVB A144 DVB-HN Commercial Requirements Phase 1 (November 2009).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. ---------------------------------------------------------------                               DVB-HN Commercial Requirements Phase 1 DVB Document A144 November 2009 SB1884 MHP-HN091R9 CM639R2 TM 3422 DVB-HN Commercial Requirements Phase 1 DVB-CM-HN Group Editors: Marten van der Laan, Ron Leenders: ICT Embedded B.V. Jean-Baptiste Henry, Ralf Schäfer: Thomson Damien Alliez: NDS Version: R9 Date: July 4 th , 2005 th Revision Date June 5 2006 MHP-HN091R9 (CM639R2) © DVB Project 1/28 Summary The Home Network (HN) market is there pushed by the PC and CE industries and also by the widespread broadband connectivity, a significant part of connected people are likely to use DVB services within this environment. Thus, it raises a need for standardisation. The goal is to build an understandable view about what is needed at the commercial level for a DVB home network to happen. It means that this home network and its composing devices have to be attractive for the end-user: o they need to provide useful added-value services o they need to integrate easily and smoothly to the existing notion of home network o they need to integrate easily and smoothly to the existing notion of DVB quality TV programs Furthermore, the aim of DVB is not to define a complete home networking solution, but it has to rely on strong technologies, already well accepted at the commercial level by the market. It is important also that the functionality and application of DVB CPCM rules and technologies is preserved and supported Those requirements have been elaborated based on use-cases and scenarios provided by each member of the group. DVB being composed of broadband and broadcast operators, manufacturers and service providers, the DVB-HN group is confident that this document has been built based on a broad coverage of use-cases. It is expected that the extracted requirements represent a thorough view of what is needed, and convey real added-value for technical groups to design a successful solution for the market. Chapter 1 introduces the general context of Home Networking and explains the rationale behind the creation of this DVB group. This chapter defines also the scope of the document and the positioning of DVH-HN regarding other standards. Chapter 2 defines a series of fundamental uses cases reflecting main issues and concerns in a home network from a DVB standpoint. Chapter 3 is more system and architecture oriented. It gives an overview, in a migration path perspective, about the various network architectures used or imagined today by DVB and DLNA while laying emphasis on the interoperability of both models. Chapter 4 is the key part and describes extensively the commercial requirements for the phase 1 throughout all dimensions of a home network (physical layer, protocols, device classes, network management, security, user services…). Chapter 5 lists the relations and liaisons between the DVB-HN forum and other relevant forums within DVB or not. This chapter is important though being short since there are strong implicit dependencies with works led in listed forums. MHP-HN091R9 (CM639R2) © DVB Project 2/28 Table of Contents 1 Introduction ..................................................................................................................... 4 1.1 Purpose and Scope .................................................................................................... 5 1.2 Document History ....................................................................................................... 7 1.3 Terminology and Conventions ..................................................................................... 7 1.4 References ................................................................................................................ 7 1.5 Definitions and Abbreviations ...................................................................................... 8 2 Use Cases ...................................................................................................................... 10 2.1 Home-wide Distribution of DVB A/V Services .............................................................. 10 2.2 Storage Management and Distribution ........................................................................ 11 2.3 Remote Access to the HN .......................................................................................... 11 3 DVB-HN Network Architecture ......................................................................................... 12 3.1 Today Situation ......................................................................................................... 13 3.2 Insertion of DVB-HN Player ....................................................................................... 13 3.3 Insertion of the DVB-HN Broadband Tuner ................................................................. 14 3.4 Insertion of a DVB-HN Broadcast Tuner ..................................................................... 14 4 Commercial Requirements ............................................................................................... 16 4.1 General Requirements ............................................................................................... 16 4.1.1 Required Standardisation Activities ...................................................................... 16 4.1.2 Technology Requirements ................................................................................... 16 4.1.3 Wireless Specific Requirements ........................................................................... 17 4.2 Device classes and content formats ........................................................................... 17 4.2.1 Device Classes ................................................................................................... 17 4.2.2 Content Formats ................................................................................................. 17 4.3 Home Network Management ...................................................................................... 18 4.3.1 Network Topology ............................................................................................... 18 4.3.2 Device Discovery ................................................................................................ 18 4.3.3 Device Configuration ........................................................................................... 19 4.3.4 Third Party Management ...................................................................................... 19 4.3.5 Remote Maintenance ........................................................................................... 19 4.3.6 Application Resource Management ...................................................................... 19 4.4 Home Network Functionality ...................................................................................... 20 4.4.1 General Functionality........................................................................................... 20 4.4.2 Viewing Broadcast Content .................................................................................. 21 4.4.3 Viewing Broadband Content ................................................................................. 21 4.4.4 Viewing Local Content ......................................................................................... 21 4.4.5 Content Recording .............................................................................................. 21 4.4.6 Content Copying, Download and Exporting ........................................................... 22 4.5 Content Discovery and Selection ................................................................................ 22 4.6 Device and Content Control ....................................................................................... 23 4.6.1 Device Control Across the HN .............................................................................. 23 4.6.2 Content Presentation Control ............................................................................... 24 4.6.3 Event Programming ............................................................................................. 24 4.7 Quality ...................................................................................................................... 24 4.7.1 Quality of Service mechanisms ............................................................................ 24 4.7.2 Contention Management ...................................................................................... 25 4.8 Security, Content Protection and Privacy .................................................................... 26 4.8.1 Security .............................................................................................................. 26 4.8.2 Protection ........................................................................................................... 26 4.9 User Specific Functionality ........................................................................................ 26 4.9.1 Log On ............................................................................................................... 26 4.9.2 Accounting .......................................................................................................... 27 5 Interaction with Other Forums .......................................................................................... 28 MHP-HN091R9 (CM639R2) © DVB Project 3/28 1 Introduction Background on DVB DVB provided in the past many specifications describing how commercial broadcast services can be transmitted to homes and can be rendered on devices connected directly to access networks. These broadcast specifications are today of high maturity, are deployed in many regions of the world and specify modulation schemes, coding formats, interactive format, signalling, content scrambling, etc. DVB provided also a first specification for handling television over broadband networks, called the DVB-IP Phase 1 specification. This specification is quite new, addresses a market with exponential growth rates and specifies transport, coding format, signalling, etc. Additional releases of the DVB-IP Phase 1 specification are planned – increasing the interoperability of broadband television. Why home networking? Consumers are increasingly investing in digital audio/video equipment. A typical household in 2006 owns one or more (digital) television sets, PC’s, DVD player/recorder, PVR, digital camcorders and still picture cameras, portable audio players, portable phones with A/V capability, etc. There is an increasing need of sharing content between these devices, for example to watch home videos assembled at the study-room PC on the TV screen in the living room. Moreover, consumers get a better connection to the outside world. Switchover from analogue TV to digital TV is ongoing in many countries, and broadband internet connections are getting common. This leverages the possibility of high-quality A/V delivery towards the home, either in a traditional broadcast manner, but also via Video-on-Demand services. Consumers want these services to be delivered on any A/V capable device in their house, not only to the main television set. They also might want simultaneous access to multiple services. In-house networking has already become common in the PC domain, driven by the fact that people want to share their (broadband) internet connection with multiple PC’s. People get to understand the concepts and the additional benefits. This has also led to a rich variety of networking equipment like modems, switches, routers and wireless access points for relatively low prices. Wireless network technology has developed very fast. It can now provide a good alternative for wired networks with sufficient bandwidth and quality. These developments, such as in-house content sharing, digital A/V service delivery, and other internet services like chatting, gaming, etc. are the main driving forces for consumer’s interest in Home Networks. Without a home network, people would have to carry physical media (discs, memory cards, etc.) throughout their house or to establish (temporary) ad-hoc connections between their devices. With a home network it becomes easier and more cost efficient to distribute broadcast, broadband and local content to every TV set in the home. Home network systems can have a number of major benefits over analogue systems for TV services:  simultaneous access to multiple DVB services;  better picture and sound quality;  increased flexibility;  privacy and security;  interconnection of IT and broadcast terminals;  delivery of content to mobile and portable terminals like webpads, handhelds, etc. Why should DVB get involved? Following the reasoning above there is a clear demand for Home Networks, the technology is there and the consumers will understand the concepts. This is clearly illustrated by the fact that many ad-hoc solutions for A/V content sharing were introduced on the market in the past years. Many consumers are today building home networks to share content stored in the home. They also want to be able to share DVB content coming to their homes via DVB access networks. Consumers also expect to have access to this DVB content on their existing home network equipment. There is also considerable interest in other industry groups. A major industry forum, the Digital Living Network Alliance (DLNA), is publishing guidelines for standardising a Home Network MHP-HN091R9 (CM639R2) © DVB Project 4/28 dedicated to media content sharing. The DLNA group has published already version 1.0 and is finalising version 1.5 at the moment of writing this document. DLNA is foreseen as the key driver for Home Networks. However, there is additional work to do: the DVB project has to make sure that its major achievement, the delivery of high-quality digital video towards the home, will now also persist in a networked environment with multiple A/V capable devices. In other words, DVB should enable delivery of DVB services to any particular end-point in the Home Network. This will allow for interoperable mass-market products that are easy to use between manufacturers, operators, service and content providers. What is the added value of Home Networks? A properly standardised Home Network will leverage a horizontal market for Home Networking devices. Consumers will have confidence in their investments and can gradually build up their desired functionality. A network will increase the adoption of digital TV and the usage of advanced services like broadband video distribution, video-on-demand services, PDR, off- home recording/storage services, etc. This creates business for the manufacturer who can sell more devices as the market is extended to include richer TV applications. The devices are also more sophisticated and this can enable differentiation of products and justify higher prices. Service providers can sell more content. Home Networks are ready to receive simultaneous content in different ways (live streaming, VoD, download, etc.). 1.1 Purpose and Scope The purpose of the DVB-HN is to enable the delivery of DVB services from different access networks to end devices in the home network and between end devices in the same home network. The DVB-HN specification suite will consist of several specifications, where the commercial requirements in this document cover the DVB-HN Phase 1. Home Networking is a complex subject and in order to be reactive to market requirements it is needed to limit the scope of Phase 1 and this section describes the CM-HN group’s proposal for DVB-HN Phase 1. The DVB-HN Phase 1 is limited to the most important use cases of operators and end users: the distribution of existing commercial DVB services (broadcast and broadband) over a common home network to end user devices in a single home. This means that broadcast and broadband networks will be terminated at specific devices and the content will then flow over the home network to (other) specific end devices. In this way we can call DVB-HN Phase 1 “device-to-device home networking” supporting features on the same home network like:  detecting devices  detecting features of devices  detection of content  content streaming  controlling devices  getting events from devices  displaying user interfaces of devices By supporting this list, it is expected that all features of broadcast and broadband services are networkable and that they can work as on a device directly connected to an access network. Handling common storage is an important feature of home networking. Therefore the CM-HN group has checked that the DVB-PDR requirements are coherent with the requirements in this document. There are also additional home network specific requirements. This document does not contain requirements for MHP or any other interactive system. It is expected that an MHP application is signalled as usual and that as soon as the stream is selected on a specific server, it is downloaded to the MHP capable player and executed there. However, in phase 1, DVB-HN does not have to provide solutions that ensure the operation of interactive applications like MHP on any DVB-HN terminal. DVB-HN Phase 1 contains some requirements for getting assistance with problems in the home network, but will not yet address fully managed home networks. MHP-HN091R9 (CM639R2) © DVB Project 5/28 DVB-HN Phase 1 remains limited to content flow in a single home. However, there are requirements for controlling home network devices from the external world – such as the office PC for programming a recording. The members of the CM-HN group recognized that it is insufficient to sell devices that provide only functionality for DVB services. A successful home network needs also to support picture viewing, DVD distribution, etc, but these are not DVB services. It has been decided that the best way is to base DVB-HN on DLNA, a commercially strong base specification which is expected to cover a large part of the job and where DVB can add what is necessary for distributing DVB broadcast and broadband services over DLNA home networks. The elements that DVB-HN adds on top of DLNA deal only with DVB content, handling of non DVB content is not described. The remit of DVB is to provide specifications for DVB-HN devices and not for other devices (e.g. DLNA) on the home network. All content related operations in the DVB-HN are subject to DVB CPCM rules Although DVB-HN Phase 1 is limited in scope, it is desirable to indicate priorities in the list of commercial requirements, so that the TM is able to release a first technical specification in a reasonable time frame. The following list explicitly shows what is considered out of scope for DVB-HN Phase 1 but is expected to at least be covered by DVB-HN Phase 2:  Support of HN-specific MHP APIs that deal with Home Networking for example for finding other devices on the home network.  Support of multi-service Home Gateway (e.g. OSGi Service Platform). This would not mean that DVB should provide Home Gateway specifications. DVB could provide requirements to a partner organisation working on it or contribute video related specification parts to a partner organisation.  Distributing DVB content from one home to another home, e.g. principle home to a summer home. MHP-HN091R9 (CM639R2) © DVB Project 6/28 1.2 Document History Date Version Remarks 2004-08-26 R0 Original revision, processed input from MHP-HN077R2. 2005-02-16 R1 Clarified some requirements. Processed input from MHP- HN077R5 2005-03-15 R2 Changed document organization. Included introduction + new text for chapters 2, 3, and 4. Processed input from MHP-HN077R7. Incorporated changes/proposals/comments from first editing session on March 14. Note that due to new document organisation all requirements have different numbers compared to MHP- HN091R1. 2005-03-25 R3 Updated during the editing session of 2005-03-22. 2005-04-07 R4 Updated during review at April 5 th and April 6 th . Presented to the CM group for information. 2005-04-26 R5 Update after 20 th April conf call. 2005-06-17 R6 Sections reworked during conf call, meetings, and by mail. Cleaning on agreed CR. 2005-06-20 R7 Updated version after face-to-face meeting in Roissy. 2005-07-04 R8 Final version for TM review. 2006-05-10 R9 Updated following TM-IPI HN comments. 1.3 Terminology and Conventions Requirement tagging scheme: Req x.*[y].z. Category.[Subcategory].Name.[x] Status Priority Numeric requirement Alphanumeric requirement id. Status Priority ref. x = section This is a unique id for a given This status field can have This field is y = subsection(s) requirement that remains the following states: the z = sequence number constant over different versions. associated Draft priority set by This is a unique id within This id consists of an = work in progress the technical the document that could alphanumeric part that has a Agreed module to the be used to refer to a meaning to the reader and an = agreed within DVB-HN requirement. requirement within a optional number to make the id Accepted 1= Must have specific version of this unique. = accepted by DVB-CM 2= Nice to document. have 3= Postponed Note that this id. is not to next phase strictly coupled to the particular requirement, could vary across different versions of this document In the requirements text we have used the following conventions:  Shall: Mandatory requirement  Should: Nice-to-have requirement  : Explanation or rationale for a requirement (informative) 1.4 References [1] DLNA guidelines Home Networked Device Interoperability Guidelines, v1.0, Digital Living Network Alliance, 2004 [2] TS 101 154 Digital Video Broadcasting (DVB); Implementation guidelines for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream. ETSI Technical specification, ETSI TS 101 154 v1.7.1 (2005-06). MHP-HN091R9 (CM639R2) © DVB Project 7/28 [3] TS 102 034 Digital Video Broadcasting: Transport of MPEG2 based DVB services over IP based networks (DVB-IP). ETSI Technical specification, ETSI TS 102 034 v1.1.1 (2005-03). [4] CM370R2 DVB-PDR Commercial Requirements [5] CM-CP1079R5 Commercial Requirements for CPCM [6] TS 102 822-3-1 ETSI TS 102 822-3-1 V1.2.1: Broadcast and On-line Services: Search; select and rightful use of content on personal storage systems (“TV-Anytime Phase 1”), Part 3 Metadata, Sub-part 1: Metadata Schemas. [7] TS 102 822-3-2 ETSI TS 102 822-3-2 V1.2.1: Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems (“TV-Anytime Phase 1”), Part 3: Metadata, Sub-part 2: System Aspects in a Unidirectional Environment. [8] MHP specification Digital Video Broadcasting (DVB); Multimedia Home Platform Specification MHP 1.0.3 TS 101 812 v1.3.1 [9] MHP-HN029 Scenarios from Philips [10] MHP-HN030R1 Scenarios from Thomson [11] MHP-HN076 Scenarios from BT [12] MHP-HN095 Scenarios from Sony [13] MHP-HN101 Scenarios from NTL 1.5 Definitions and Abbreviations Access network A uni- or bi-directional network that delivers content to the home such as DVB-S, DVB-T, DVB-C, DVB-H or DVB-IP Broadband content/service A DVB service delivered across a bi-directional broadband access network, i.e. DVB-IP. Broadcast content/service A DVB service delivered across a uni-directional broadcast access network, i.e. DVB-S, DVB-S2, DVB-T, DVB-C, or DVB- H. CPCM Content Protection and Copy Management CPCM USI CPCM Usage State Information: CPCM Content metadata that signals the Authorised Usage for each CPCM Content Item. CRI Content Resolution Information CRID Content Reference Identifier (TV Anytime) DLNA Digital Living Network Alliance DMP Digital Media Player, see Table 3.1. DMR Digital Media Rendered, see Table 3.1 DMS Digital Media Server, see Table 3.1. DVB content Any content that is compliant to DVB specifications. DVB service DVB service: any service that is compliant to DVB specifications and delivers DVB content to a customer premises’ equipment DVB stream A transport format for transporting DVB services towards the home. A DVB stream is typically a multiplex of multiple DVB services, each consisting of multiple service components. In case of broadcast services, a DVB stream complies with MPEG-TS ETR154 [2]. DVB-HN DVB Home Network: a Home Network that satisfies the requirements stated in this document DVB-HN (compliant) device A device satisfying the requirements in this document. DVB-HN application An abstract functional entity that performs a specific task or function within the HN that has a benefit to the user of the HN DVB-HN content Content stored and accessible within the HN, this can be either DVB content or other content. (Home) Gateway A device that physically separates the access network from the home network and that has a routing function. HN Home Network HNED Home Network End Device: device that is connected to the home network and which typically terminates the IP-based information flow. IP Internet Protocol (DVB) Metadata Data that describes information about DVB content such as DVB-SI, TV Anytime… MHP-HN091R9 (CM639R2) © DVB Project 8/28 network segment A part of the HN consisting of a single link layer technology that provides layer-2 connectivity between HN-devices and link-layer level connecting devices (e.g. hubs, layer-2 bridges …). NVoD Near Video on Demand PDR Personal Digital Recorder PVR Personal Video Recorder QoS Quality of Service SAC Secure Authenticated Channel network segment A part of the HN consisting of a single link layer technology that provides a layer-2 connection between HN-devices and link-layer level connecting devices (e.g. hubs, layer-2 bridges …). (Service) Component A part of a DVB service. For a DVB service, service components are normally the MPEG elementary streams listed in the Program Map Table for the service (TAM232R32) TVA TV Anytime UpnP Universal Plug and Play, see www.upnp.org VoD Video On Demand VoIP Voice over IP VPN Virtual Private Network, a mechanism to tunnel data between a DVB-HN and an external private network (e.g. a company intranet) over a public IP network MHP-HN091R9 (CM639R2) © DVB Project 9/28 2 Use Cases The use cases as provided in this chapter are intended to form an introduction to some basic scenarios that a user may pursue using his home network. It will be used to introduce also specific terms. The comprehensive set of use cases and a discussion of these use cases are available on the DVB site (see [9] [10] [11] [12] [13]). Note that it is an important goal for DVB to guarantee a high quality level of DVB content distribution across the home, while safeguarding the DVB defined copy and content protection rules. 2.1 Home-wide Distribution of DVB A/V Services Thanks to his home network, Mr. Smith is able to view broadband and broadcast services everywhere in his home:  Locate content/services that are accessible over DVB access networks (DVB-S,-C,-T, -IP).  Browse content/service information of any audiovisual content/service that is accessible to the home via a DVB access network; Mr. Smith enjoys the specific look & feel of the way the services are presented to him by the service/content provider.  Select and enjoy the content that is accessible over DVB access networks.  It is possible to distribute one or more streams to one or more terminals, with the aim of providing guaranteed quality of service, enabling perfect experience for the end-user.  Content can be live stream, NVoD service, full fledged VoD, …  DVB defined copy and content protection applies. MHP-HN091R9 (CM639R2) © DVB Project 10/28 2.2 Storage Management and Distribution Mr. Smith has purchased a networked Digital TV and a networked PDR. PDR related functionalities (record, play, time-shift) can be controlled via the resident application in the networked Digital TV. Mr. Smith can also view the content from the DVD player on the same digital TV. The DVD content is presented, as the player would be in front of him, i.e. menus, subtitles and add-ons are presented. DVB defined copy and content protection applies. 2.3 Remote Access to the HN Mrs. Smith has got a networked tuner, a networked PDR and a networked Digital TV device. Unfortunately she needs to work longer than planned and she will miss her favourite soap opera. So she remotely programs the recording of this specific event either via the internet access from her office or by using her advanced mobile phone. MHP-HN091R9 (CM639R2) © DVB Project 11/28 3 DVB-HN Network Architecture This section is presenting the view of the DVB-HN group regarding the architecture of the home network. Before presenting these views, it is important to note that, to enable support of all possible DVB-HN network topologies, the DVB-HN group has, in alignment with DLNA [1], distinguished different classes of devices. The identified classes for a DVB-HN are listed in the table below. Please note this device classes list may be modified by the technical group. The table below shows the type of classes which the technical group needs to consider, it is not representative of what will be the final DVB HN technical solution. The only purpose of this table is to describe in a consistent way the commercial requirements presented in this document. Table 3.1: DVB-HN Device Classes Acronym Name Clarification DVB-DMR/P DVB compliant Digital Media This device is able to play Renderer/Player for A/V content (decode and render) an A/V content, coming from the outside via a DVB-HG-xx or from inside the home from a DVB-DMS. It can also play content from a DLNA DMS. DVB-HG-BB DVB compliant Home Gateway for This device is acting as a server DVB-content from broadband of DVB content which original channel source is outside of the home, thanks to a bi-directional broadband access network. DVB-HG-BC DVB compliant Home Gateway for This device is acting as a server DVB-content from broadcast of DVB content which original channel source is outside of the home, thanks to a uni-directional broadcast access network DVB-DMS DVB compliant Digital Media This device is acting as a server Server for local DVB-content of DVB content which is located in the device itself, thus it is not connected to an access network The build-up of the home network is provided in a number of incremental steps from today’s situation to the final targeted situation with full-featured DVB-HN devices (servers and players). It is not intended to show a complete set of possible home networks, but it shows how upcoming DVB-HN devices will be integrated into foreseen home networks and how they will interact between each other and with other legacy devices. The steps, further detailed in the subsequent sections, are: 1. Today situation with a DVB-IP phase 1 client, DLNA 1.x compatible servers and players, and a modem acting as a routing gateway. 2. The DVB-IP client has been upgraded to a DVB-HN player, still able to receive the DVB-IP phase 1 streams from the broadband access, and then also able to access the DLNA content. 3. The routing gateway has been upgraded to a real DVB broadband tuner functionality, delivering DVB streams to the DVB-HN player in full quality but also to the DLNA player but without guarantee of full quality. 4. The broadcast tuner has been upgraded to a DVB-HN broadcast tuner, still able to deliver content to the DLNA player with same quality as before, but now can send content to the DVB-HN player with full quality guaranteed. MHP-HN091R9 (CM639R2) © DVB Project 12/28 3.1 Today Situation Figure 3.1: Hybrid network consisting of DLNA devices and a DVB-IP phase 1 HNED. Figure 3.1 shows a Home Network consisting of several DLNA devices, a DVB-IP HNED device capable of receiving DVB-IPTV services and a routing gateway for the connection towards the DVB-IP access network. The red arrows indicate content flows from the DLNA storage device and the DLNA broadcast DMS towards the DLNA DMP. Although the current DLNA specification supports DVB broadcast services, it does not satisfy all DVB-HN commercial requirements as listed in this document. We expect DLNA to adopt the solutions that meet our requirements in its future versions. Although the DVB-IP HNED is connected on the HN, the content flow from the DVB-IP access network to the DVB-IP HNED is a direct connection, i.e. the DLNA devices would no see/use this information flow. The access network is not aware of the HN behind the routing gateway. The HNED is not able to play content from other sources on the HN as it does not know about DLNA. 3.2 Insertion of DVB-HN Player DVB-HN Protocol DVB-IP Phase 1 Protocol DLNA 1.x BC DMS DLNA 1.x Protocol (does not meet all DVB-HN req.) DLNA 1.x DMP DLNA 1.x Storage Networ Segmen Home Network Home k t DVB-DMP DVB-IP Access Network Routing Gateway Figure 3.2: Home network consisting of DLNA devices and a DVB-HN DMR/P. The HN is connected to the DVB-IP access network via a routing gateway. DVB-IPTV services are played on the DVB-HN DMR/P. MHP-HN091R9 (CM639R2) © DVB Project 13/28 Figure 3.2 shows a similar network, but now the DVB-IP HNED has been replaced by a DVB- HN compliant DMR/P. This device can receive all DLNA streams from the DMS devices on the HN (with the possible limited functionality explained above). It might also be able to receive the DVB-IP services from the DVB-IP access network as in the first step. Please find more information on DLNA compliance of DVB-HN devices in the requirements part of this document. 3.3 Insertion of the DVB-HN Broadband Tuner DVB-HN Protocol DVB-IP Phase 1 Protocol DLNA 1.x BC DMS DLNA 1.x Protocol (does not meet all DVB-HN req.) DLNA 1.x DMP DLNA 1.x Storage Networ Segmen Home Network Home k t DVB-DMP DVB-IP Access Network DVB-HG-BB Figure 3.3: Home network consisting of DLNA devices and DVB-HN devices. The HN is connected to the DVB-IP access network via a DVB- DMS, which acts as a terminator for the DVB-IP access network and streams the DVB-IPTV services to DMR/P on the HN. Figure 3.3 shows a similar network, but now the routing gateway has been replaced by a DVB- HN compliant broadband home gateway (DVB-HG-BB). This device acts as a terminator for the access network. Moreover, it is capable of streaming the DVB-IP service to other devices on the HN. In particular it can stream towards a DLNA DMP in a DLNA compliant manner. The DVB-HG-BB can also stream towards a DVB-HN compliant DMR/P in a DVB-HN compliant manner (orange arrow). The DVB-HN enables the delivery of DVB services from the DVB-HG- BB to the DVB- DMR/P according the requirements in this document. 3.4 Insertion of a DVB-HN Broadcast Tuner DVB-HN Protocol DVB-IP Phase 1 Protocol DVB-HG-BC DLNA 1.x Protocol (does not meet all DVB-HN req.) DLNA 1.x DMP DLNA 1.x Storage Networ Segmen Home Network Home k t DVB-DMP DVB-IP DVB-DMS Access Network DVB-HG-BB MHP-HN091R9 (CM639R2) © DVB Project 14/28 Figure 3.4 Home network consisting of DLNA devices and DVB-HN devices. The DVB-HG-BB and the DVB-HG-BC are fully DVB-HN compliant, capable of streaming DVB services towards all DMR/P on the HN and also to DVB-DMS storage devices. Figure 3.4, finally, shows a home network with a DVB-HN compliant broadcast home gateway and a DVB-HN compliant broadband home gateway. Both can stream towards DVB-DMR/P and DLNA DMP with the same levels of quality as already mentioned in the previous steps. Furthermore the DVB-DMS storage device is able to receive, store and serve back DVB content with no degradation compared to the live stream coming from the home gateway. MHP-HN091R9 (CM639R2) © DVB Project 15/28 4 Commercial Requirements 4.1 General Requirements 4.1.1 Required Standardisation Activities Req 4.1.1.1 Standardisation.Guidelines Agreed 1 DVB shall provide guidelines for HN topology, pointing out problem areas.  This should cover large part of the problem areas. 4.1.2 Technology Requirements Req 4.1.2.1 Technology.IP Agreed 1 DVB-HN shall be based on the IP-protocol. Req 4.1.2.2 Technology.Independence Agreed 1 DVB-HN shall be able to include wired and wireless network segments. Req 4.1.2.3 Technology.Wired Agreed 1 DVB-HN wired network segments shall be based on Ethernet 100 Base-T or compatible upgrades. Req 4.1.2.4 Technology.Wireless Agreed 1 DVB-HN wireless network segments shall be based on 802.11 (2.4GHz – IEEE802.11g – and/or 5GHz – IEEE802.11a+h), but other interesting technologies such as WiMAX shall be considered in future specifications. Req 4.1.2.5 Technology.Interfacing Agreed 1 DVB-HN device shall be able to interface with a wired and/or a wireless network segment. It is recommended that DVB-HN compliant devices include an Ethernet 100 Base-T interface to achieve maximum interoperability and QoS. Req 4.1.2.6 Technology.IPv6 Agreed 3 The HN shall allow for migration to IPv6. Coexistence of IPv4 and IPv6 devices on the HN shall be possible. IPv4 devices are not required to support IPv6. Req 4.1.2.7 Technology.DLNA.Compatibility Agreed 1 The standard shall guarantee the following level of compatibility between a DVB-HN compliant device and a DLNA compliant device:  A DVB-HN compliant server shall offer DVB content in an optional or mandatory DLNA compliant manner and format.  A DVB-HN compliant player shall be able to discover all contents on a DLNA compliant server.  Transcoding between content formats, such as AVC to MPEG-2 is not required.  If content is streamed between a DVB-HN and a DLNA compliant device the quality and/or user experience may be lower than when the same content is streamed between two DVB-HN devices. In all cases DVB-HN solutions should be identical or based on DLNA protocols when available. Req 4.1.2.8 Technology.DVB-IP.Compatibility Agreed 1 It shall be possible to connect a DVB-IP Phase 1 HNED device to the DVB-HN (see Figure 3.1).It is not required that the DVB-IP phase 1 HNED device interoperates with the DVB-HN devices. MHP-HN091R9 (CM639R2) © DVB Project 16/28 Req 4.1.2.9 Technology.Extensions Agreed 1 Manufacturers shall be able to add improvements to DVB-HN devices as long as they do not affect interoperability with other DVB-HN compliant equipments.  Diversity processing is likely to be needed for wireless systems but does not have to be standardized. Req 4.1.2.10 Technology.LowPower Agreed 2 The DVB-HN should permit low-power states of devices. Req 4.1.2.11 Technology.Wakeup Agreed 2 It should be possible to wake-up a DVB-HN device from standby via the DVB-HN. 4.1.3 Wireless Specific Requirements Req 4.1.3.1 Wireless.Range Agreed 1 It shall be possible to transport at least one DVB compliant standard definition MPEG-2 video stream over a range of 10m via three typical obstructions (e.g. walls and ceilings using materials other than concrete) while deploying only a single Access Point (AP) in the IEEE802.11 network. However, the system shall also be scalable to increase the number of services that can be transported or must be defined to carry more services than the above at the base level. Req 4.1.3.2 Wireless.Coexistence Deleted 3 . Req 4.1.3.3 Wireless.Identification Agreed 1 It shall be possible to identify all active wireless nodes unambiguously to ensure they only communicate directly with other nodes on the same DVB-HN. When a new wireless node is being added to the network it must be authenticated.  This issue is typical from wireless network where an external undesirable device can be attached to an existing network without knowledge from the network owner. Nevertheless, this requirement may also be applicable to the wired part of the network. It is important to restrict the HN usage to authenticated devices. Req 4.1.3.4 Wireless.Improvements Agreed 1 Manufacturers shall be able to add improvements, such as receive diversity processing, to a basic wireless node to improve throughput as long as they do not affect interoperability. 4.2 Device classes and content formats 4.2.1 Device Classes Req 4.2.1.1 Device.Classes Agreed 1 A DVB-HN compliant device shall be of one of the device classes defined in Table 3.1. It is allowed to combine multiple device classes in a single physical device. It shall be possible to determine the device class over the HN.  The Table 3.1 is an indication and may be modified by the technical group 4.2.2 Content Formats Req 4.2.2.1 Content.DVB Agreed 1 DVB-HN shall be able to transport DVB services and DVB content between DVB-HN compliant end-devices. The protocols used to transfer DVB content on the DVB-HN should require no or only minimal adaptation from the protocols on the DVB access network from which the content originated. Req 4.2.2.2 Content.Other Agreed 1 MHP-HN091R9 (CM639R2) © DVB Project 17/28 DVB-HN shall not preclude non-DVB services like PC networking, DVD, gaming, IP telephony (including hand-over from mobile), video-telephony, surveillance cameras, data services, general internet inc. web browsing and file transfers, VPN, e-mail, video, audio and text messaging, (multi-media) chat. These non-DVB services may occur simultaneously with DVB services. 4.3 Home Network Management 4.3.1 Network Topology Req 4.3.1.1 Topology.Agnostic Agreed 1 DVB-HN shall not make assumptions about the physical structure of the network e.g. it shall be possible to support multiple network segments with different technologies. Req 4.3.1.2 Topology.Intrusion Agreed 1 The HN shall not preclude the use of firewalls, virus protection systems, and network address translations, etc. on multiple devices simultaneously. Req 4.3.1.3 Topology.End-to-end Agreed 1 It shall be possible to set-up an end-to-end path between any 2 DVB-HN compliant devices in the HN. Req 4.3.1.4 Topology.Dynamics Agreed 1 The HN shall support the dynamic addition and removal of DVB-HN devices. Req 4.3.1.5 Topology.FaultTolerance Agreed 1 DVB-HN shall not prescribe a network topology to have a single point-of-failure.  A very common topology for homes is to have a single access point serving as a gateway or router. If the access point fails the network usually fails, however, DVB- HN will not prescribe a topology with multiple gateways. This requirements means if a single instance of most types of device fails communication across the HN between devices will still be available . Req 4.3.1.6 Topology.Interoperability Agreed 2 DVB-HN shall work with any type of network infrastructure equipment although the performance might not be optimal. The guidelines provided by DVB should describe how to optimise this performance. Req 4.3.1.7 Topology.Monitor Agreed 1 It shall be possible to monitor the ongoing network state, including existing connections and their respective end-points. Req 4.3.1.8 Topology.DHCP Agreed 1 The DVB-HN shall be able to function fully in a stand-alone mode at the IP addressing level (i.e. using auto-IP), hence it shall not rely on the presence of a DHCP server.  This precludes the use of routers in the HN. Req 4.3.1.9 Topology.NetworkSegments Agreed 2 The service disruptions when switching between network segments should be minimised, e.g. switching from wired to wireless. 4.3.2 Device Discovery Req 4.3.2.1 DeviceDiscovery.Functions Agreed 1 Different functions within a DVB-HN device shall be distinguishable and detectable across the home network. MHP-HN091R9 (CM639R2) © DVB Project 18/28 Req 4.3.2.2 DeviceDiscovery.Standard Agreed 1 The HN shall provide a standardized way for DVB-HN device discovery. Req 4.3.2.3 DeviceDiscovery.Standby Agreed 2 Every DVB-HN device on the HN shall be discoverable even in standby.  Provide as much information as possible, at a minimum the device discovery information. Req 4.3.2.4 DeviceDiscovery.DataAdvertisement Agreed 1 A DVB-HN device may advertise its ability to provide content metadata and location information. The advertisement shall include the delivery mechanism (push or pull modes) and the scope of the information (e.g. CRID authorities) 4.3.3 Device Configuration Req 4.3.3.1 Configuration.DeviceName Agreed 2 DVB-HN compliant devices shall have a pre-assigned human-readable name, modifiable by the user. Req 4.3.3.2 Configuration.DeviceToDeviceUI Agreed 2 It shall be possible to view and modify the network interface and access rights configuration of a DVB-HN device over its network interface using the device-to-device UI (see “DeviceControl.UI-upload“ – Req 4.6.1.1). The device manufacturer defines the actual set of parameters that may be modified. Req 4.3.3.3 Configuration.PowerDown Agreed 2 The network interface configuration and access rights configuration shall persist after a power- down cycle of a reasonable duration.  The configuration should ‘survive’ a holiday. 4.3.4 Third Party Management Req 4.3.4.1 Management.ThirdParty Agreed 3 The HN technology shall not prohibit nor shall it mandate remote network management by a third party from outside the home. If a remote management technology exists, it shall be a standardized mechanism.  It doesn't mandate remote management by a 3rd party but it does allow it. Req 4.3.4.2 Management.Authorisation Agreed 3 Remote management and configuration by a 3 rd party outside the home shall only take place after explicit authorisation by the home owner.  The home owner is the end-customer. 4.3.5 Remote Maintenance Req 4.3.5.1 Maintenance.Secure Agreed 3 The remote maintenance channel (outside the home) shall be secure. See section 4.8.1 for details on security. Req 4.3.5.2 Maintenance.FirmwareUpdate Agreed 3 A secure means of downloading software updates from an IP access network to a DVB-HN device shall be provided. 4.3.6 Application Resource Management Req 4.3.6.1 Application.ResourceSignalling Agreed 1 MHP-HN091R9 (CM639R2) © DVB Project 19/28 A means of signalling or identifying the different types of applications and their bandwidth requirements should be specified to enable appropriate network management. 4.4 Home Network Functionality 4.4.1 General Functionality Req 4.4.1.1 Functionality.EaseOfUse Agreed 1 The DVB-HN shall be easy to use and manage. Its installation, configuration and management shall not require the presence of a trained technician. Req 4.4.1.2 Functionality.BootingOrder Agreed 1 The sequence of turning on or off the equipment in your home network shall not be relevant. Req 4.4.1.3 Functionality.BootingDependency Agreed 1 Turning on or turning off a device in the home network should not disrupt running DVB services, which do not use this device. Req 4.4.1.4 Functionality.Multicast Agreed 1 Multicast support of A/V content within the HN is not required in phase 1. Multicast services from the access network shall be supported.  Note that the delivery of DVB service to DLNA devices cannot be done via multicast (see “Technology.DLNA.Compatibility “– Req 4.1.2.7). Req 4.4.1.5 Functionality.Simultaneous Agreed 1 It shall be possible to have multiple simultaneous streams across the HN. Req 4.4.1.6 Functionality.MetaData Agreed 1 It shall be possible to discover and retrieve metadata along with any content across the HN. Req 4.4.1.7 Functionality.PrivateContent Agreed 1 The HN shall not preclude the carriage, storage and display of user content. Req 4.4.1.8 Functionality.NetworkingApplications Agreed 1 General networking applications (e.g. VPN) and DVB-HN applications shall be able to run simultaneously on the HN. Potential resource conflicts (e.g. bandwidth) shall be handled according to MHP-HN091 “Contention.Policy” (see Req 4.7.2.1).  VPN connections typically prevent other networking activities on the same network adapter. However, other HN applications, not using this adapter, shall not be affected. Req 4.4.1.9 Functionality.Standalone Agreed 1 The DVB-HN shall stay operational without connections to an access network. Req 4.4.1.10 Functionality.ServiceComponents Agreed 2 It shall be possible to request any subset from the components available from a server. When the bandwidth of the underlying network is restricted (e.g. for loaded Ethernet, for 10BaseT or for wireless), there shall exist the possibility to choose an appropriate default subset of service components.  It shall be possible to request any combination of components but the content server may not be able to honour it. Req 4.4.1.11 Functionality.Interactivity Agreed 2 A DVB-HN device that is capable of running interactive applications should make available to the applications any resources that are available over the HN (e.g. tuner, interaction channel), accessible via the existing (standardized) API’s. MHP-HN091R9 (CM639R2) © DVB Project 20/28 Req 4.4.1.12 Functionality.Synchronisation Agreed 1 The HN shall preserve synchronisation between service components as they exist on the access network. 4.4.2 Viewing Broadcast Content Req 4.4.2.1 Broadcast.DVB Agreed 1 The HN shall support DVB broadcast services. Req 4.4.2.2 Broadcast.SimultaneousServices Agreed 1 The HN shall be able to simultaneously carry over the home network multiple services from multiple access networks and multiple service providers. 4.4.3 Viewing Broadband Content Req 4.4.3.1 Broadband.DVB-IP Agreed 1 The HN shall support DVB-IP services; including SD&S, EPG, etc. (see [3]) Req 4.4.3.2 Broadband.SimultaneousServices Agreed 1 The HN shall be able to simultaneously receive multiple DVB services from one or more service providers. Req 4.4.3.3 Broadband.InternetServices Agreed 2 DVB-HN devices shall be able to discover DVB services on the internet (over the HN). 4.4.4 Viewing Local Content Req 4.4.4.1 LocalContent.DLNA Agreed 1 The HN shall support local content streaming from a DLNA-DMS to a DLNA-DMP in a DLNA compliant manner. Req 4.4.4.2 LocalContent.Simultaneous Agreed 1 The HN shall allow simultaneous transfers of multiple streams. 4.4.5 Content Recording Req 4.4.5.1 Recording.PDR Agreed 1 Basic PDR functionality shall be networkable. Functionalities may include:  discovery of, access to, and control of networked devices;  access to content lists;  basic control of content: play, pause, stop;  deletion of content;  remote programming, from another DVB-HN compliant device in or outside the home. For more details see [4]. Req 4.4.5.2 Recording.Capacity Agreed 2 A storage device shall be able to expose its available storage capacity across the HN.  In order to allow a high-level management service to auto-select a storage device on the HN for a requested recording. Req 4.4.5.3 Recording.TargetDevice Agreed 2 It shall be possible for the HN user to select a particular storage device on the HN for storing/recording content. Req 4.4.5.4 Recording.Distributed Agreed 1 MHP-HN091R9 (CM639R2) © DVB Project 21/28 The DVB-HN shall not consider scenarios where one piece of content is distributed across multiple storage devices.  Could possibly be handled in phase 2. 4.4.6 Content Copying, Download and Exporting Req 4.4.6.1 Content.Transfer Agreed 1 It shall be possible to stream, copy or move DVB content between DVB-HN devices in the Home Network, if allowed by CPCM. Req 4.4.6.2 Content.CPCM Agreed 1 A DVB-HN compliant device shall obey the CPCM USI for the consumption, copying and moving of CPCM protected content if a compliant implementation of CPCM is included in the device Req 4.4.6.3 Content.Download Agreed 1 The DVB-HN shall support content download entering the home either via broadband networks or broadcast networks.  Mechanisms to be defined by DVB-IP (broadband) or GBS (broadcast). Req 4.4.6.4 Content.Delete Agreed 1 It shall be possible for a DVB-HN device in or outside the home to delete DVB content files stored on another DVB-HN device, if allowed by the security model. 4.5 Content Discovery and Selection Req 4.5.1 ContentDiscovery.Standard Agreed 1 The HN shall provide a standardised way for content discovery. Req 4.5.2 ContentDiscovery.HN-remote Agreed 2 It should be possible to have HN/device/content discovery from a DVB-HN device outside the home (e.g. office PC or mobile phone). Req 4.5.3 ContentDiscovery.Private Agreed 1 A DVB-HN compliant device should be able to discover user content advertised in a DVB-HN compliant way. Req 4.5.4 ContentDiscovery.Beforehand Agreed 1 A DVB-HN compliant server should advertise the following information in a standardised manner as available over the access network : mandatory DVB SI information, encoding format, peak bitrate, service/content name, FTA/scrambled, pricing information, parental control information, TV guide information, SD&S , TVA metadata, trick mode availability (note that there might be multiple peak bitrates for every trick mode). This includes streamed and broadcast content for which the user currently does not have a subscription and content that may have been pushed into his DVB-HN, for which he has yet to complete a financial transaction. Req 4.5.5 ContentDiscovery.Accessibility Agreed 1 It shall be possible for the DVB-DMR/P to access all standard information related to the DVB service delivered to the DVB-HG. Req 4.5.6 ContentDiscovery.ServiceComponents Agreed 2 The DVB-DMR/P shall be able to request at the DVB-HG or DVB-DMS any possible components of a DVB service.  It shall be possible to request any combination of components but the server may not be able to honour it (e.g. CPCM rules may restrict the sub-setting of contents). MHP-HN091R9 (CM639R2) © DVB Project 22/28 Req 4.5.7 ContentDiscovery.StreamComponents Agreed 2 The DVB-DMR/P shall be able to request at the DVB-HG or DVB-DMS any possible components of a DVB stream, e.g. software download.  It shall be possible to request any combination of components but the server may not be able to honour it (e.g. CPCM rules may restrict the sub-setting of contents). Req 4.5.8 ContentDiscovery.MetadataSource Agreed 1 It shall be possible for HN devices to discover all sources of DVB standardised metadata (for local stored content and content available through access networks) and to access this metadata. Req 4.5.9 ContentDiscovery.MetadataSharing Agreed 1 DVB-DMR/P shall have access to as much metadata as possible but without imposing extra costs on the DVB-HG. The DVB-HN shall support TVA in the following manners (DVB-HG can support any of these options): o The DVB-DMR/P can access directly the native TVA transport mechanism delivered over the access network. DVB-HG is then a pass-through. o DVB-HG understands TVA and can extract and present the data in a standard manner allowing for search and filtering functions. The DVB-HG shall advertise which of the two above methods it supports. Req 4.5.10 ContentDiscovery.Identifier Agreed 1 An identifier (e.g. CRID) shall be associated with each item of DVB content advertised or stored and the metadata for the content must be associated with that identifier. The identifier should be the one allocated by the SP or broadcaster, unless it is not known whether the identifier will be re-used for different content at a later time. The purpose of the identifier is: o to enable an HNED to associate metadata with the content o to enable the metadata to be updated in the future o to allow multiple copies of the same content to be identified (it follows that if the content is modified the identifier must be changed) o to enable linking between metadata entries o to be used by an HNED as part of the process of locating the content in time and space Req 4.5.11 ContentDiscovery.LifeTime Agreed 1 If the lifetime of the identifier is not ‘permanent’ there shall be expiry information for the identifier (ref. work on TV-Anytime CRID lifetime in DVB-GBS Segmentation) and another permanent unique identifier assigned. 4.6 Device and Content Control 4.6.1 Device Control Across the HN Req 4.6.1.1 DeviceControl.UI-upload Agreed 2 A DVB-HN device should be able to upload a user interface to another DVB-HN device on request. Req 4.6.1.2 DeviceControl.Status Agreed 1 A DVB-HN device shall make available its status (no disc, blank disc, etc.) Req 4.6.1.3 DeviceControl.Events Agreed 1 MHP-HN091R9 (CM639R2) © DVB Project 23/28 The DVB-HN technology solution shall be capable of efficiently conveying event information around the home network.  Examples for events are: tape at the end, no disk … 4.6.2 Content Presentation Control Req 4.6.2.1 ContentPresentation.FlowControl Agreed 2 A control point shall be able to control the streaming from a DMS or DVB-HG to a DMR/P. This control includes all control possibilities as defined by UPnP AV, provided that the DMS or DVB-HG can handle these commands.  This includes start/stop/pause/seek/fast/slow. Req 4.6.2.2 ContentPresentation.PushPull Agreed 2 The DVB-HN shall allow for a content-push model (e.g. stream this music towards the bathroom) and also for a content-pull model (e.g. get my music from the living room server). Req 4.6.2.3 ContentPresentation.ThirdParty Agreed 2 It should be possible for a third DVB-HN device, which is not involved in the stream transfer, to control the streaming (i.e. an intelligent remote control).  In DLNA 1.5 this device is called a DMC. UPnP also defines Media Server Controllers and Media Renderer Controllers. Req 4.6.2.4 ContentPresentation.UI Agreed 2 DVB-HN shall include a standardised mechanism to allow DVB-HN devices to upload and present a user interface on other DVB-HN devices. It is not mandatory for DVB-HN devices to support this mechanism, however in such circumstances a device may not get offered the full richness of the services being offered by the provider.  Such a feature may be used to display more complex content selling information whereby there is not a simple one price for one content item scenario. Req 4.6.2.5 ContentPresentation.Bitrate Agreed 2 Trick modes shall not exceed the earlier signalled peak bitrate (see “Discovery.Beforehand”, Req 4.5.4). 4.6.3 Event Programming Req 4.6.3.1 Programming.ScheduledRecording Agreed 1 It shall be possible for a DVB-HN device to schedule the recording of a DVB service by another DVB-HN device. This programming is either manual (date, start time, end time, etc.) or via a DVB defined identifier. Req 4.6.3.2 Programming.Remote Agreed 2 Scheduling of a recording shall be possible from a location outside the home. Req 4.6.3.3 Programming.Secure Agreed 2 Remote event programming shall be secure. See section 4.8.1 for details on security. 4.7 Quality 4.7.1 Quality of Service mechanisms Req 4.7.1.1 Quality.QoS Agreed 1 The HN technical solution shall include mechanisms that aim to enable the support of high quality user experience similar to DVB1.0 implementations. This is referred to as QoS mechanisms. (QoS includes bandwidth, latency and jitter: glossary). Note that 100% QoS cannot be guaranteed, especially in wireless networks. MHP-HN091R9 (CM639R2) © DVB Project 24/28 Req 4.7.1.2 Quality.ProblemDetection Agreed 1 The HN shall provide means to detect network QoS problems. Ideally, it should provide information about individual links and devices. Req 4.7.1.3 Quality.ExposeInfo Agreed 1 A DVB-HN device that is connected to an access network shall expose available QoS information about this access network.  In order to distinguish between QoS problems within the HN and QoS problems on the access network. Req 4.7.1.4 Quality.Priority Agreed 1 No device on the DVB-HN shall be able to allocate a higher priority to its data without prior authority from the user (network manager). Req 4.7.1.5 Quality.Management Agreed 1 A means of signalling or identifying the different types of applications and their bandwidth requirements should be specified to enable appropriate network management. Req 4.7.1.6 Quality.Latency Agreed 1 The increase in latency due to one wireless network segment compared to one wired network segment shall be less than 20ms to ensure that interactive TV and games applications can be supported. Req 4.7.1.7 Quality.DifferentiatedServices Agreed 1 The DVB-HN shall support a configurable mechanism such that the user can indicate the relative importance of the different content and services. The user shall always be able to determine this configuration, which could be delegated to a 3 rd party. It shall always be possible for the HN user to regain delegated configuration. Req 4.7.1.8 Quality.Roaming Agreed 2 When a DVB-HN device moves from one network segment to another network segment, there should be minimum disruption of the DVB service. 4.7.2 Contention Management Req 4.7.2.1 Contention.Policy Agreed 1 The HN shall include policy management functionality, providing mechanisms for contention management (e.g. sharing the tuner resource). The user shall always be able determine the rd policy, which could be delegated to a 3 party. It shall always be possible for the HN user to regain delegated control. Req 4.7.2.2 Contention.ResourceAvailability Agreed 1 It shall be possible to discover the current availability of resources on the HN. Req 4.7.2.3 Contention.ConflictHandling Agreed 1 An established connection between DVB-HN devices shall never be interrupted without explicit user confirmation.  VoIP calls to emergency services may be an exception; a higher priority service may take resources away from a lower priority service without confirmation. Req 4.7.2.4 Contention.GracefulDegradation Agreed 1 The HN should adapt gracefully under conditions of network degradation (e.g. by filtering out components of a service or filtering out complete services). Req 4.7.2.5 Contention.Admission Agreed 1 The HN shall provide mechanisms for admission control of streams on the network. MHP-HN091R9 (CM639R2) © DVB Project 25/28  In order to preclude streams when network capacity is insufficient. This situation may occur when multiple users watch different live streams with time-shifting feature. 4.8 Security, Content Protection and Privacy 4.8.1 Security Req 4.8.1.1 Security.SAC Agreed 1 It shall be possible to set up a SAC between DVB-HN devices within the home network, following the CPCM requirements. Req 4.8.1.2 Security.Remote Agreed 3 DVB-HN devices outside the home shall be able to communicate with the HN via a SAC. Req 4.8.1.3 Security.Tunnel Agreed 1 The DVB-HN shall not block a non DVB secure channel between devices in the home network (e.g. VPN). Req 4.8.1.4 Security.AppData Agreed 1 The DVB-HN specification shall include a standardised mechanism different from SAC (e.g. https) to allow secure transfer of IP application data. Not all devices need to implement this feature. Req 4.8.1.5 Security.Transactions Agreed 1 The DVB-HN shall not reduce the security of user interactions conducted via a home gateway that interfaces between an IP access network and the DVB-HN e.g. financial transactions. Req 4.8.1.6 Security.Wireless Agreed 1 The DVB-HN shall include means of minimising the risk of eavesdropping, tampering or invasion 4.8.2 Protection Req 4.8.2.1 Protection.UsagePermissions Agreed 1 DVB-HN shall offer a standardised way to set-up usage permissions for DVB content, DVB services, DVB-HN devices, and device configuration on the HN (e.g. parental control, content deletion on PVR). Req 4.8.2.2 Protection.Mechanism Agreed 1 DVB-HN shall offer a standardised way to access restricted DVB content, DVB services, DVB- HN devices, and device configuration on the HN.  User profiles could be used as part of the solution. Req 4.8.2.3 Protection.CPCM Agreed 1 All content related operations shall be subjected to DVB CPCM rules. The DVB-HN shall not reduce the effectiveness of the media rights management protocols that are being defined by DVB CPT. Req 4.8.2.4 Protection.ParentalRating Agreed 1 The DVB-HN devices shall support DVB parental rating information coming from service providers. 4.9 User Specific Functionality 4.9.1 Log On Req 4.9.1.1 LogOn.Standard Agreed 2 MHP-HN091R9 (CM639R2) © DVB Project 26/28 There shall be a standardised way to log on to a DVB-HN device. Logging on a device shall automatically give access to all network resources granted to your user profile. A default logon shall be available on all devices.  An example of implementation of the default logon can be no logon at all. Req 4.9.1.2 LogOn.Default Agreed 2 It shall be possible to watch content which has not been restricted by user-profiles on a DVB- HN device (DVB-DMR/P) using the default logon. Req 4.9.1.3 LogOn.Remote Agreed 2 It shall be possible for a DVB-HN device outside the home to connect to the HN after an authentication process. This process shall include device authentication and user authentication. Once connected, the remote DVB-HN device shall have complete DVB-HN functionality, given its device capabilities and within the scope of DVB-HN phase 1. Req 4.9.1.4 User.Profiles Agreed 2 It shall be possible to generate and retrieve network-wide user profiles.  For example to assemble/store a personalised EPG. Req 4.9.1.5 User.Bookmarks Agreed 2 The DVB-HN shall allow users to set and clear marker points in DVB-HN content. Furthermore, the DVB-HN shall allow making content selections from specific marker points. Marker points should be user specific, and shall contain tags for specific applications.  Follow-me functionality can be implemented by using a marker point with a “follow-me” tag. The application on the display device can then present either all “open” follow-me’s, or use the user profile to allow the user to automatically resume content viewing. 4.9.2 Accounting Req 4.9.2.1 Accounting.PriceInfo Agreed 1 The metadata for a piece of purchasable content should include price information (will be included in TVA phase 2). MHP-HN091R9 (CM639R2) © DVB Project 27/28 5 Interaction with Other Forums DLNA The Digital Living Network Alliance is a group of industry makers from the IT and the CE worlds. The outcome of DLNA is a set of guidelines for exchanging multimedia content within a home network. Considering the importance and the rapid adoption of those guidelines, DVB- HN has chosen to rely on this group for the basic bricks of the home networking technology. The Commercial Requirements from DVB-HN will provide the extensions to the DLNA Guidelines covering the additional areas currently not included by DLNA for the combined home network functionality and access network connectivity for IPTV and DVB 1.0 services. DVB-IPI DVB IP Infrastructure is a technical group which has already defined a method to build IPTV services, including discovery, transport and coding format. Based on the Commercial Requirements from DVB-IPTV and DVB-HN (this document) groups, the DVB_IPI group is currently starting work on updating the DVB-IP phase 1 document to include extensions for new IPTV requirements, and to extend the IP infra-structure to support combined home network functionality and access network connectivity for IPTV and DVB 1.0 services to the end-user terminals. DVB-PDR The DVB Personal Digital Recorder group has released a set of commercial requirements around the PDR concept. Since one or more PDR device may form a significant part of the home network, DVB-HN has reviewed those requirements and checked whether they could be integrated as-is or needed HN specific extensions. DVB-CP/CPT There has not yet been a specification from these groups which can be fully incorporated into the DVB-HN Commercial Requirements document. Based on the information available they have, however, been considered. DVB-WIN The DVB Wireless In-Home group is focusing on the wireless aspect of the home networking. As such, the WIN group provided to DVB-HN some commercial requirements specific to the wireless transmission of the DVB services. Those requirements have been integrated into this document. DSL Forum The DSL Forum is a well established group that defines technologies on DSL domain. The relation with DVB-HN is not clear, except that they have a remote management solution for the home gateway and they work on extensions of this solution for the in-home devices. Home Gateway Initiative HGI is a young group of operators, manufacturers and service providers. It targets to standardize the home gateway as a set of standard HW/SW components and interfaces between an access network and the home network. The home gateway should enable full end- to-end service delivery (triple play) to home network devices while minimizing the home gateway cost and the service deployment cost. HGI is working on specific home networking aspects such as QoS and remote device management. As it is a new group, liaisons are not yet in place. TV-Anytime Forum An international alliance responsible for producing a specification for metadata suitable for describing content to be delivered to a presentation client in a way which supports all the features required for accurate recording and identification for playback, and its extended modes, e.g. segmentation. The work done by TV-Anytime is agnostic to carrier type. Having completed it's work TV-Anytime Forum is currently in a process of closing down, with the maintenance to be taken over by implementation groups. DVB-GBS has produced the specification enabling metadata structured according to TV- Anytime to be carried over DVB 1.0 Transport Stream delivery. MHP-HN091R9 (CM639R2) © DVB Project 28/28