Introduction
The Digital Video Broadcasting[1] (DVB) project recently initiated a study mission on Internet TV content delivery to investigate technology options to deliver DVB-type content over the Internet to a large number of CE devices (including game consoles), PCs or mobile devices. The study mission focuses on content delivery, but other functions such as codecs, security, or metadata are also considered.
The study mission aims to gather information from subject matter experts in the field of Internet Content Delivery to ensure a wide and comprehensive consideration of technology options and the most accurate evaluation against some high-level evaluation criteria. To address these objectives, the study mission starts with a questionnaire to collect information on existing technologies in the respective area. This questionnaire serves to collect information on technologies, services and solutions in the scope of Internet TV content delivery. Given the fact that the DVB Consortium has successfully produced specifications that have been standardized for most TV broadcast systems in the past, we are seeking synergies between the technologies considered in this questionnaire and existing DVB technologies. Such synergies may then be further evaluated and exploited in a specification phase that may be launched after the study mission has been completed in the fall of 2009.
The questionnaire is open to many types of Internet TV Content Delivery technologies and DVB encourages the submission of descriptions and background material of solutions and technologies within this effort. Some guidelines on technologies and solutions in the scope of this questionnaire are provided further below. The questionnaire is made available to DVB members and also in public to non-DVB members. DVB members and non-DVB members alike are encouraged to respond to the questionnaire. The questionnaire does not intend to select any of the submitted technologies during the study mission, but is looking for background and deployment experience in generic Internet TV content delivery solutions. Based on the results of the present questionnaire, DVB may or may not standardize a suitable Internet TV technology for CE devices.
DVB will collect the replies to the questionnaire in an Annex of the study mission report. The report will contain additional information such as an overview on the subject, some categorization of available technologies, and some guidelines for future work in this area within DVB. All DVB members along with non-DVB members who contribute to the questionnaire will have access to the study mission report. Furthermore, DVB invites all DVB members as well as all contributors submitting a reply to this questionnaire to participate in a workshop at the EBU on June 12, 2009 or during the Study mission meeting July 8, 2009 at Pioneer, Maidenhead, UK and to potentially present and discuss their technology during one of the two meetings workshop. Details on the procedures as well as detailed questions will follow in this questionnaire.
The following document will provide some definitions, technologies in the scope of this questionnaire, guidelines for editors, and the questions for the questionnaire. In case of any questions, please contact the task force leader[2] of the DVB study mission on Internet TV content delivery.
Definitions
Internet TV Content Delivery
Internet TV Content Delivery is considered as the delivery of multimedia services over the Internet (non-managed network), or over a network that contains at least one non-managed portion in its end-to-end data flows, and thereby cannot guarantee QoS.
DVB and other organizations have existing specifications for IPTV, e.g. ETSI TS 102 034[3]. IPTV is defined by the ITU-T as multimedia services such as television/video/audio/text/graphics/data delivered over IP based networks managed to provide the required level of quality of service and experience, security, interactivity and reliability.
Both IPTV and Internet TV share the basic capabilities of an IP network. But they differ in the availability of some protocols and on the QoS characteristics. Typical characteristics of such an Internet TV system/service include:
• Elements of the system are open, without a single controlling authority or aggregator.
• Anyone with an Internet connection can make Internet TV services and content available, and will be able to access services.
• There is typically no end-to-end management of quality of service for content delivery.
• Internet TV content can be delivered without resource reservation.
Considered Content Types
The study mission is mostly concerned to find potential solutions to deliver DVB-type content over the Internet. DVB-type content is considered as video and/or audio, subtitles, images/graphics, animations, text (incl. tele-/videotext), webpages or any other information that is intended to be delivered through DVB standardized transport mechanism to and consumed by a user. DVB content is formatted according to ETSI TS 101 154 or ETSI TS 102 005[4] as traditional DVB delivery systems typically only permit the transport of formats specified in either TS 101 154 or TS 102 005. However, specifically for this questionnaire conformance to ETSI TS 101 154 or TS 102 005 is not essential and we are open to technologies using other content formats and types.
Considered Actors in Value Chain
Business value chains in the Internet TV environment are diverse. Nevertheless, a simple linear example business value chain is described in the following to address certain players considered in some areas of this questionnaire. The following actors are considered in the example value chain for Internet TV Content Delivery.
• Internet TV Content Provider (ITVCP), e.g. Broadcaster: provides TV-like content to be delivered over the Internet. Typically an ITVCP provides content not only for Internet TV content delivery, but also for other distribution means.
• Internet TV Service Provider (ITVSP): provides service to the ITVCP to deliver content over the Internet. The ITVSP may act as an aggregator for multiple ITVCP. The provided service may for example include service discovery, portal and content guide services, authentication and billing services, etc.
• Delivery Network Service Provider: provides generic delivery service to specific service providers to deliver generic content over IP networks in a scalable and reliable manner. This typically includes an Internet Service Backbone Provider as well as scalable delivery architectures, for example based on
o a Content Delivery Network (CDN), or
o a peer-to-peer (p2p) Delivery Network.
• Internet Service access Provider (ISP): provides transparent broadband Internet access for a generic broadband consumer
• Internet TV Consumer End-device Manufacturer: provides equipment to consume Internet TV, e.g. Set-top box, game console, PC software, etc.
• Internet TV Consumer: consumes Internet TV services provided by the ITVSP.
It should be noted that in actual deployments, one entity might take on the role of several of the above actors. Also, in other deployments some of the above actors may be further subdivided.
[pic]
Figure 1 Considered Actors in Internet TV Content Delivery Value Chain
The questionnaire primarily targets ITVSPs, but is definitely not restricted to those. In addition, as the study mission focuses on content delivery, in particular the content delivery service parts of ITVSPs are of interest, whereas the delivery of auxiliary functions such as service access and discovery is of lower relevance.
Technologies and Services in the Scope of this Questionnaire
Technologies
Technologies in the scope of this questionnaire explicitly include Internet TV content delivery solutions that permit to deliver audio-visual services (example services provided below) over the Internet to a large number of consumer electronic (CE) devices (including game consoles), PCs or mobile devices. Of specific interest for the questionnaire are technologies that support CE devices, DVB-type content and streamed services.
Example Services
The questionnaire addresses technologies that permit the provisioning of one or several of the below services:
• Linear TV Service, e.g. Live Media Broadcast
• Content-on-Demand Service
• Content Download Service
• Audio-only Services
• Accessibility Components, e.g. subtitles, closed captioning, sign language (either included in one of the above services or in combination with hybrid delivery)
• Network Personal Video Recorder Service (e.g. Catch Up TV service)
Guidelines
Response Guidelines
Respondents are requested to observe the following guidelines, in order that the study mission can efficiently aggregate the answers and arrive at a meaningful conclusion in the required timescale.
1. Replies shall be submitted via e-mail to t.stockhammer@lgtce.com preferably by latest July 3, 2009, 11.59pm cest. DVB members are encouraged to also submit their replies to the study mission list tm-itvcd-sm@list.dvb.org. Any potential respondent who, due to extenuating circumstances, is unable to meet the deadline shall contact the Study Mission task force leader for an alternative procedure. Technologies not meeting the deadline are not automatically excluded from the inclusion in the study mission report.
2. Registration for presenting the included technology at the Workshop June 12, 2009 (details below) shall be submitted by latest May 29, noon cest via e-mail to t.stockhammer@lgtce.com. Registration for presenting the included technology at the Study Mission Meeting July 8, 2009 (details below) shall be submitted by latest July 1, noon cest via e-mail to t.stockhammer@lgtce.com.
3. Partly completed replies are not encouraged, but will not necessarily be excluded from the study mission report.
4. Diagrams should only be incorporated as embedded jpegs
5. Replies to questions should be concise and not be unnecessarily long. Structured answers such as bullet lists are encouraged.
6. Answers of just “yes” or “no” are discouraged except for extremely focused and unambiguous technical questions. At least one additional explanatory sentence is encouraged.
7. Answers that say “it is possible” are discouraged. It should always be clear if the answer addresses part of the current specification or technology or not. An “optional” part of a technology specification is considered to be part of the technology provided it is fully specified.
8. Forward-looking statements are not excluded as long as they are clearly indicated as such.
Editing Guidelines
To collate all answers in a single document, we encourage taking into account the following editing guidelines.
1. Please maintain ALL the formatting (font, tabs, bullet points) as it already exists in this document, unless it absolutely prevents you from providing your answer.
2. Do not change any indents or tab spacing or column widths
3. Do not add any further page breaks, each question is on a separate page.
4. Do not change the font – the default font is “Times New Roman” Size 12. All text within a table cell should be “normal style”, do not use “Heading Styles”. Only use the “strong” style if you wish to highlight text.
5. When cutting and pasting text from external documents, do not bring over any formatting; for example use “Paste Special” -> “Unformatted Text”
6. Please maintain “English US” as the language of this document
7. Please maintain the document as “Word 97–2003 format”, submissions in PDF or any other document style are positively discouraged.
8. If you are responding for more than one technology please provide separate contributions, both starting from the same base clean document.
9. If in doubt please ask the editor for assistance t.stockhammer@lgtce.com.
Presentation at Workshop
All editors of the replies to the questionnaire are invited to present their technology during a workshop conducted on June 12, 2009, at the EBU, Geneva, Switzerland. All DVB members are invited to participate in the workshop. For logistical details, please refer to
http://www.dvb.org/groups_modules/technical_module/tmipi/meetings/meeting_details/index.xml?groupID=14&mID=1207
In addition, the workshop will be open to invited experts (non DVB members), in particular (but not restricted to) those who have submitted a reply to the questionnaire. In case you would like to participate, please send an e-mail to t.stockhammer@lgtce.com to receive an invitation along with all logistical details.
Registration for a presentation at the workshop is encouraged by latest May 29, noon cest via e-mail to t.stockhammer@lgtce.com.
Presentation at Study Mission Meeting July 8
All editors of the replies to the questionnaire are invited to present their technology during the first day of the study mission meeting conducted on July 8, 2009, at the Pioneer Digital Design Centre Limited, Hollybush Hill, Stoke Poges, South Bucks at UK, Maidenhead. All DVB members are invited to participate in the workshop. For logistical details, please refer to
http://www.dvb.org/groups_modules/technical_module/tmipi/meetings/meeting_details/index.xml?groupID=14&mID=1215
The meeting will be open to anyone (also non DVB members) who has submitted a reply to the questionnaire. In case you would like to participate, please send an e-mail to t.stockhammer@lgtce.com to receive an invitation along with all logistical details.
Registration for a presentation at the study mission meeting is encouraged by latest July 1, noon cest via e-mail to t.stockhammer@lgtce.com.
Facilities for remote participation and presentation will be provided. Detailed logistics will be announced.
Glossary
For the purpose of this document, the following abbreviations hold:
|Acronym/Term |Definition |
|API |Application Programming Interface |
|CDN |Content Delivery Network |
|CE |Consumer Electronics |
|CPU |Central Processing Unit |
|DVB |Digital Video Broadcasting |
|EBU |European Broadcast Union |
|HDTV |High-Definition TeleVision |
|HTTP |Hypertext Transfer Protocol (IETF RFC2616) |
|IGMP |Internet Group Management Protocol |
|IPR |Intellectual Property Rights |
|IPTV |Internet Protocol TeleVision |
|ISP |Internet Service access Provider |
|ITU-T |International Telecommunications Union – Telecommunications Sector |
|ITVCP |Internet TV Content Provider (definition above) |
|ITVSP |Internet TV Service Provider (definition above) |
|NAT |Network Address Translation |
|NSP |Network Service Provider |
|P2P |Peer-to-Peer |
|P2PSIP |Peer-to-Peer Session Initiation Protocol |
|QoS |Quality of Service: (measurable) quality of the content delivery |
|QoE |Quality-of-Experience: observed quality by the Internet TV Consumer |
|RSA |Rivest, Shamir und Adleman (refers to algorithm for public-key cryptography) |
|RTCP |Real-Time Control Protocol (IETF RFC3550) |
|RTP |Real-Time Protocol (IETF RFC3550) |
|RTSP |Real-Time Streaming Protocol (IETF RFC2326) |
|SDTV |Standard-Definition TeleVision |
|SIP |Session Initiation Protocol (IETF RFC3261) |
|SSM |Source Specific Multicast |
|SCTP |Stream Control Transmission Protocol (IETF RFC4960) |
|TCP |Transmission Control Protocol (IETF RFC793) |
|TPM |Trusted Platform Module |
|TVA |TV Anytime (Reference) |
|UDP |User Datagram Protocol (IETF RFC768) |
|VoD |Video-on-Demand |
Questions and Reply Template
Logistical Information
|Name/Acronym of Technology1 | |
|Editor(s)2 of this Reply |
|Name: | |
|Company: | |
|Is your company DVB member? | |
|Contact |e-mail: | |
| |Phone: | |
|How are you affiliated to the technology? | |
|Notes: |
|1 Update all fields in this document |
|2 Please add this information for each editor |
|Workshop Participation |
|Will you be available to present the technology during the study mission meeting on July 8, 2009 at Pioneer, | |
|Maidenhead, UK? | |
|Publication/Distribution of Material |
|Do you permit DVB to publish the below information, e.g. in a bluebook? (Note that you may exclude specific | |
|answers from being published) | |
|If not, can the published report at least mention that the technology had been submitted? | |
|Do you envisage any copyright issues with the information provided below? If yes, please provide some further | |
|information and guidance | |
|Would you like to receive a copy of the information collected by DVB? | |
The remaining questions/replies will be part of a collated document.
Overview
|Q1: Overview |
|Please give a short overview of the technology, in particular the delivery system (200 words). |
| |
| | Not applicable |
| |Not available |
| |Do not publish |
Commercial Aspects
|Q2: Usage of Technology |
|Where is the technology used? |
|Who uses the technology? |
|If the technology is already deployed, please indicate where and by whom? |
|If the technology is not yet deployed, please indicate any future plans for deployment. |
| |
|Geography | | Not applicable |
| | |Not available |
| | |Do not publish |
|ITVCPs | | Not applicable |
| | |Not available |
| | |Do not publish |
|ITVSPs | | Not applicable |
| | |Not available |
| | |Do not publish |
|Supported Internet TV End | | Not applicable |
|Devices | |Not available |
| | |Do not publish |
|Number of subscribed users | | Not applicable |
| | |Not available |
| | |Do not publish |
|Additional Comments: | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q3: Service Types |
|What service types are supported by the technology? For examples, see above. |
| |
| | Not applicable |
| |Not available |
| |Do not publish |
|Q4: Business Value Chain |
|Referring to the example business value chain in Figure 1 |
| |
|To which player in the above business value chain would the technology be most applicable? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Who are the enablers and/or partners for the service/technology? (for example cooperation with CDNs or Internet TV | Not applicable |
|Consumer end-device manufacturers) |Not available |
| |Do not publish |
| | |
|Q5: IPR Situation |
|Please provide information about IPR licensing including the following |
| |
|Is there any knowledge on the IPR situation of the technology? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Are the licensing terms fair, reasonable and non-discriminatory or anything else? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Is there a patent pool already formed? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q6: Competitiveness of Technology |
| |
|How does the technology provide cost effectiveness compared to other technologies? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Please indicate the other commercial reasons why the technology has been chosen or is considered to be selected? These | Not applicable |
|reasons could be operational, economic, regulatory, or any combination of those. |Not available |
| |Do not publish |
| | |
|How does/can the technology/service create revenue streams (e.g. subscription, content hosting, ads, targeted ads, | Not applicable |
|personalized ads)? Are different models supported? |Not available |
| |Do not publish |
| | |
Standardization
|Q7: Standardization |
| |
|Do you consider the DVB Consortium as an appropriate body to agree and standardize an Internet TV Content Delivery | Not applicable |
|technology for CE devices? |Not available |
| |Do not publish |
| | |
|Do you consider that potential DVB standards on Internet TV Content Delivery may be applied to a wider range of devices, | Not applicable |
|e.g. mobile devices or gaming consoles? |Not available |
| |Do not publish |
| | |
|If such an activity would be started is your organization prepared to contribute towards such a standardization activity | Not applicable |
|under DVB conditions? |Not available |
| |Do not publish |
| | |
|If you own the technology, would you be prepared to submit it for possible inclusion into a DVB specification at an | Not applicable |
|appropriate time? |Not available |
| |Do not publish |
| | |
|What is the latest time by when a specification for this technology should be available, e.g. end of 2010, to have | Not applicable |
|relevance for the market? |Not available |
| |Do not publish |
| | |
Specification
|Q8: Specification of the Technology |
| |
|How is the technology specified (proprietary, standards organization, research project, open source, others)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Please give references to information about the technology including the specification if possible, e.g. www.myspec.org. | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Is this technology appropriate for inclusion in potential future DVB standards? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|If the technology is standardized |
|What is the maturity of the specifications (draft, approved, version, specification maintenance, deployed)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|When was/will the specification (be) approved? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Which body/authority approves the specification? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|How available is the specification (e.g. not available at all, available under NDA, available with fee, available under | Not applicable |
|certain conditions, available to anyone without fee)? |Not available |
| |Do not publish |
| | |
|How can the technology be extended, e.g. only by the owning organization, by DVB additions to the standard? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q9: Compliance |
|How is compliance to the specification ensured for the technology (e.g. open API, test specifications, compliance test suite, etc.)? |
| |
| | Not applicable |
| |Not available |
| |Do not publish |
Technical Features - Architecture
|Q10: Architecture |
|How can the underlying architecture of the technology be best described? (e.g., P2p, CDN, IP multicast, etc. or a combination of those). If |
|possible, |
|provide a diagram illustrating the architecture of the technology, |
|name and describe the most important components in the architecture, and |
|indicate which is provided by which actor in the value chain. |
|The answer may be up to 2 pages. |
| |
| | Not applicable |
| |Not available |
| |Do not publish |
|Q11: Network Infrastructure |
| |
|What dedicated network infrastructure is required for the technology? (e.g., NAT, super-peers, trackers, VoD servers, …)?| Not applicable |
| |Not available |
| |Do not publish |
| | |
|How can the technology cope with network asymmetry (e.g., in case down and up link capacities may differ by a factor of 5| Not applicable |
|to 10)? |Not available |
| |Do not publish |
| | |
|Q12: Network Topology awareness |
| |
|Is the technology aware of network topology? | | Not applicable |
| | |Not available |
| | |Do not publish |
|If yes, please provide |
|some indication of its effectiveness. | Not applicable |
| |Not available |
| |Do not publish |
| | |
| | |
|What are the provisions within the technology for the discovery of network topology information, which may for example be| Not applicable |
|acquired through one of the following means: |Not available |
|ping times (as a measure of network distance) |Do not publish |
|connection speed measurements | |
|access to external topology databases? | |
| | |
| | |
|Is network topology information used by the technology to maximize its operating efficiency in the sense of reduced | Not applicable |
|operating costs and/or increases in streaming/download performance? If not, are you considering incorporating such |Not available |
|features into your technology at a later date? |Do not publish |
| | |
| | |
|Q13: Scalability of Technology |
| |
|How does the architecture support scalability in terms of the number of (concurrent) users? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|How does the architecture support scalability in terms of bandwidth? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Please provide typical numbers on how many servers per active Internet TV consumers are necessary? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|How does scaling the number of users affect the network load in the different parts of the network? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q14: Internet Access |
|Are there any specific requirements for Customer Premises Equipment (CPE) spanning the Internet Access equipment and/or the consumer end devices? |
| |
|Support of specific ISP functionalities? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Minimum required access bitrates (upstream/downstream)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Open ports for inbound and outbound connections to the Internet TV Consumer End Device? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Support of specific versions of IP, e.g. IPv4, IPv6? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q15: Service-related Questions |
| |
|Can ITVSP/ITVCPs independently make services available using the technology (e.g., similar to the world wide web), or is | Not applicable |
|there a single entity that aggregates all content and services available via the technology or that otherwise controls |Not available |
|which services are available (e.g. as typically done in IPTV services)? |Do not publish |
| | |
|If a VoD-like service is supported, does the technology support trick modes? Please explain supported features. | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Service Deployment and Accessibility | Not applicable |
|How are the various services of your technology made easy to deploy, adopt and access? |Not available |
|Does your technology provide APIs (e.g. for content discovery, ingest, targeted/personalized/regionalized ads, |Do not publish |
|registration, authentication, purchasing)? | |
|Are these APIs programming language and/or platform independent? | |
| | |
| | |
| | |
|Q16: Client Management |
|Does the technology embed any provision for the ITVSP to manage the client? If yes, please provide technical, operational and security-related |
|mechanisms. Management of the device may include any one of the following type of features: |
| |
|an awareness on the side of the ITVSP of the physical identity of an authorized client? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|requiring a registration and authentication process for the client or its end user(s)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|maintenance of the client's (or its end user's) privileges to access the various services available? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|remote configuration of certain operational aspects of the client device? | Not applicable |
| |Not available |
| |Do not publish |
| | |
Technical Features - End-device Functions and Platforms
|Q17: Target Devices |
| |
|Please indicate which types of end devices the technology targets at the moment? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|What are the plans on embedding the technology in |
|Consumer Electronic devices (e.g. TV sets, Set-top Box)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|mobile devices? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|others? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|How does the technology adapt to terminal device capabilities (e.g. screen sizes, processing power) and the access | Not applicable |
|network characteristics (bitrates, QoS, etc.)? |Not available |
| |Do not publish |
| | |
|Q18: Device Capabilities |
|What client/end-device capabilities are required for the technology? |
| |
|Is it a browser plugin, application, etc.? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Which platforms and operating systems are supported? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|What are typical numbers for code-space footprint, workspace memory, and CPU consumption (e.g. SDTV @ 2.5 MBit/s or HDTV | Not applicable |
|@ 8 MBit/s or other measures)? |Not available |
| |Do not publish |
| | |
|What are specific security-related capabilities, (e.g. hardware-accelerated RSA, Trusted Platform Module (TPM), etc.)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
Technical Features - Content and Network Security
|Q19: Service Sign-In and Device Authentication |
|How does the Internet TV consumer sign-in to the service or otherwise authenticate its device? Please describe the procedures. |
| |
| | Not applicable |
| |Not available |
| |Do not publish |
|Q20: Protection against Attacks of Infrastructure |
|What provisions (if any) does the technology make available for protection against the various forms of attack known to effect infrastructure and |
|information packets operating or carried within the Open Internet? |
| |
|man-in-the-middle? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|denial-of-service? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|spoofing or masquerading? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|spamming attacks (poisoning)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|transitive trust e.g. exploiting host-host or network-network trust e.g. to hijack identities? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|others? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q21: Content Protection / Conditional Access |
| |
|What Content Protection mechanism is used (if any)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Does the architecture/technology prevent the use of other Content Protection solutions? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|How is content integrity ensured? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|How is content authenticated as coming from the source it is claiming to be from? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Is transport limited to a specific geographic region of the Internet e.g. through use of a GeoIP type solution? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q22: Privacy of the end-user |
| |
|Is the viewing behavior of the end-user monitored? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|What measures (if any) are provided for the protection of end-users privacy rights? | Not applicable |
| |Not available |
| |Do not publish |
| | |
Technical Features - Protocols
|Q23: Protocols |
|What protocols are core to the technology for different functionalities? |
| |
|Functionality |
|Comments: |
| |
| |
| |
Technical Features - Content Search and Metadata
|Q24: Content Search and Metadata |
| |
|How can the Internet TV Consumer End Device and the Internet TV Consumer locate content items available through this | Not applicable |
|technology? |Not available |
| |Do not publish |
| | |
|What standardized or proprietary content metadata schema is used? (e.g. TVA) | Not applicable |
| |Not available |
| |Do not publish |
| | |
Technical Features - Formats
|Q25: Codec Formats |
|Which codec formats are used/supported by the technology? |
| |
|For audio? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|For video? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|For subtitles? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Others? Please specify | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Does the technology, in particular the content delivery, prevent the use of any DVB codecs as specified in TS 102 005 and| Not applicable |
|TS 101 154? |Not available |
| |Do not publish |
| | |
|Q26: Encapsulation/file format |
| |
|Which encapsulation/file formats are used within the technology? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Are the content components offered in a multiplex, or as individual parallel streams/sessions? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Does the technology (in particular the content delivery) prevent the use of MPEG-2 Transport Streams? | Not applicable |
| |Not available |
| |Do not publish |
| | |
Technical Features – QoS Tools and Key Performance Indicators
|Q27: QoS Tools |
|Are any end-to-end QoS tools used? If yes, please elaborate … |
| |
|For data loss prevention? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|For effective bit-rate variations? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Robustness, e.g. server outages, etc.? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|to cope with abrupt increase in the number of concurrent users, e.g. in the beginning of very popular events (example: | Not applicable |
|Eurovision Song Contest)? |Not available |
| |Do not publish |
| | |
|Others? Please specify | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q28: QoS/QoE Measurement and Reporting |
| |
|Is the observed QoS/QoE measured and reported? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|If yes, how are the measurements used during operation (adaptation, billing, re-routing, etc.)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q29: Bitrates and A/V Quality |
| |
|What are typical video bitrates in today’s deployments? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|What are typical spatial and temporal video resolutions and audio quality levels? | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Can the technology support live streaming of HDTV? (Please provide your “definition” of HDTV). | Not applicable |
| |Not available |
| |Do not publish |
| | |
|Q30: Times/Delays for live and real-time services |
| |
|What are typical service startup times once subscribed to the service? Provide main contributors and optimizations to | Not applicable |
|reduce this time. |Not available |
| |Do not publish |
| | |
|What are typical end-to-end delays for live services, if supported? Provide main contributors and optimizations to reduce| Not applicable |
|these delays. |Not available |
| |Do not publish |
| | |
|What are typical channel change times? Provide main contributors and optimizations to reduce this time. | Not applicable |
| |Not available |
| |Do not publish |
| | |
|What are the typical ad-hoc seek times (if supported within a VoD asset)? Provide main contributors and optimizations to | Not applicable |
|reduce this time. |Not available |
| |Do not publish |
| | |
|If applicable, what is the turnaround time for on-demand content? (e.g. time between live broadcast and availability of | Not applicable |
|content for on-demand consumption) |Not available |
| |Do not publish |
| | |
|Q31: Scalability of the technology |
| |
|What is the cost (e.g., in terms of the number of new servers/peers) of extending the number of concurrent | Not applicable |
|end-devices/users over a Live TV service? |Not available |
| |Do not publish |
| | |
|How does the increase in number of end-devices/users affect the involved actors? (ITVCP, ITVSP, Delivery NSP, ISP)? | Not applicable |
| |Not available |
| |Do not publish |
| | |
-----------------------
[1] http://www.dvb.org
[2] Thomas Stockhammer, t.stockhammer@lgtce.com, +49 89 978980 02.
[3] ETSI TS 102 034 specifies DVB-IPTV technologies, specifically the Transport of MPEG-2 TS Based DVB Services over IP Based Networks.
-----------------------
DVB Study Mission on Internet TV Content Delivery
This questionnaire serves to collect information on technologies, services and solutions in the scope of Internet TV content delivery within the DVB Study Mission on Internet TV Content Delivery. The document contains an introduction to the topic, submission guidelines and the questions itself.
Digital Video Broadcasting (DVB) – Technical Module (TM-4216)
Questionnaire
08
Fall 