• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ITU IPTV Definition
 

ITU IPTV Definition

on

  • 2,785 views

 

Statistics

Views

Total Views
2,785
Views on SlideShare
2,785
Embed Views
0

Actions

Likes
0
Downloads
102
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ITU IPTV Definition ITU IPTV Definition Document Transcript

    • INTERNATIONAL TELECOMMUNICATION FOCUS GROUP ON IPTV UNION TELECOMMUNICATION STANDARDIZATION SECTOR FG IPTV-MR-0001 STUDY PERIOD 2005-2008 Original: English WG(s) 1 1st FGIPTV meeting: Geneva, 10 – 14 July 2006 MEETING REPORT Source: WG 1 leaders Title: WG 1 (Requirement and Architecture of IP TV) meeting report Working Group 1 met in Geneva, Switzerland from 10 to 14 July 2006. Mr. Jun Kyun Choi (ICU, Korea), Mr. Julien Maisonneuve (Alcatel, France), Christian Bertin (France Telecom, France) jointly chaired the meeting and considered 39 contributions and 4 liaisons. 1 Goals of the meeting The working group 1 (Requirement and Architecture of IP TV) met to progress the work on the following subjects. • Term of References (refer FG IPTV-OD-0001) • Requirements of IPTV • Architecture of IPTV The Architecture subgroup met to progress the work on the following subjects. • Review contributions : 8, 10, 52, 56, 85, 94, 29, 31, 32, 35, 48, 53, 54, 58, 76, 77, 78, 100, 92, 17, • Agree on output documents and progress them • Provide Guidance for the following meeting • Service Scenario of IPTV Jun Kyun Choi Tel: +82-42-866-6233 Contact: Korea (Republic of) Fax: +82-42-866-6226 Email jkchoi@icu.ac.kr Julien Maisonneuve Tel: +33 1 4076 1145 Contact: Alcatel SA Fax: +33 1 4076 1259 France Email: Julien.Maisonneuve@alcatel.com Christian Bertin Tel: +33 2 99 12 40 16 Contact: Fax: +33 2 99 12 40 98 Email christian.bertin@francetelecom.com Attention: This document is an internal ITU-T Document intended only for use by the Member States of the ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of the ITU-T. All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of the source/author of this document.
    • -2- FG IPTV-MR-0001 2 Summary of the results Discussion has taken place on three subgroups of requirement, architecture, and service/scenario for this meeting. • (ToR) The term of references of WG1 are produced at FG IPTV-OD-0001. • (Requirement) The requirements for IPTV services are contained at FG IPTV-OD-0024, which is first produced at this meeting. The living lists on requirements for IPTV are also produced at FG IPTV- OD-0025, which contains some technical issues for further study and requests additional inputs at next meeting. • (Architecture) Reviewed all assigned contributions. • Liaison : 7, 8, 100 • Processed : 10, 52, 56, 85, 94, 29, 31, 32, 48, 53, 54, 58, 92, 17 • Deemed more relevant for Requirements : 35, 76, 71, 77 • Deemed more relevant for Scenarios : 78 • In addition, reviewed and edited 69. • Produced several Output Documents • Draft Architecture Document at FG IPTV-OD-0027 • Draft Gap Analysis Document at FG IPTV-OD-0028 • Draft Standards Inventory Document at FGIPTV-OD-0029 • Architecture Living List at FG IPTV-OD-0030 • This report contains recommendations as to what is expected from contributors for the next meeting. In addition, editor’s notes were provided in the output documents above. • (Service/Scenario) The discussion of the scenario sub-working group has started on : – identification of IPTV Services – identification of players/roles – identification of commercial/business models The working documents on service scenario for IPTV are contained at FG IPTV-OD-0026. The working group 1 produce three Liaison statements to ATIS (FGIPTV-OD-0031).
    • -3- FG IPTV-MR-0001 3 Detailed Results 3.1 Term of References Related contributions: FG IPTV-ID-0015, FG IPTV-ID-67 Doc. No. Titles Sources WGs Proposal of Terms of Reference on Korea (Republic FG IPTV-ID-15 ToR architecture and requirements of IP TV of) Architecture Working Group proposed FG IPTV-ID-67 Alcatel ToR orientations Term of References of WG1 are contained at FG IPTV-OD-0001. 3.2 Requirements Input contributions are as follows. Doc. No. Titles Sources WGs ATIS IPTV FG IPTV-ID-8 ATIS IIF Initial Deliverables Interoperability all Forum (IIF) FG IPTV-ID-10 Starting point for IPTV requirements work Siemens AG all Korea FG IPTV-ID-17 Technical issues on IP TV standardization all (Republic of) CATR of MII, Service FG IPTV-ID-52 Proposal studying NGN-based IPTV Huawei scenario Work method FG IPTV-ID-56 Suggestion to IPTV standardization MII, China (stage process) Requirement FG IPTV-ID-71 Work on Requirements of IPTV Service ETRI (work method) A Framework Architecture and Work Framework FG IPTV-ID-85 Cisco Items for IPTV standards architecture NTT, KDDI, Hitachi, Service FG IPTV-ID-94 IPTV Service Architecture Mitsubishi scenario and Electric, Sharp, architecture Sony, Toshiba Proposal to request of AVS video standard China Netcom, FG IPTV-ID-21 requirements to be the must IPTV video format PCCW
    • -4- FG IPTV-MR-0001 Interactive control Requirements for IPTV FG IPTV-ID-28 KT requirements Service proposal of IMS-based IPTV architecture FG IPTV-ID-31 Huawei, CATR requirements on NGN requirement for P2P-based IPTV media P2p FG IPTV-ID-34 Huawei, Inc. delivery system requirements Huawei Requirements FG IPTV-ID-35 Study of bearer network for the IPTV Technologies and architecture Requirement Media Adaptation to Usage Environments and service FG IPTV-ID-36 ETRI for IPTV Services scenario (MPEG) SAMSUNG Requirement FG IPTV-ID-38 IPTV: Mobile Scenario and Architecture Electronics. (mobile) Multiple Service Provider Connectivity and Samsung Requirement FG IPTV-ID-39 Transparency of IPTV Service Electronics (transparency) IPTV features required for accessibility for Requirement FG IPTV-ID-41 Omnitor people with disabilities (disability) FG IPTV-ID-43 IPTV Service Requirement CATR, China requirements Proposed requirements for IP access MII, Alcatel Requirements FG IPTV-ID-49 network in IPTV Shanghai Bell (access) Functional Requirements and Architecture CATR of Requirement FG IPTV-ID-53 of the IMS-based IPTV MII,Huawei and architecture Functional Requirements and Architecture CATR of Requirement FG IPTV-ID-54 of the non-IMS based IPTV MII,Huawei and architecture Architecture and Requirement of IPTV Requirement FG IPTV-ID-58 ZTE Corporation Network Management (management) Proposal about CDN architecture based Requirement FG IPTV-ID-59 ZTE Corporation IPTV media delivery system (service) A discussion issue on the IMS-based IPTV FG IPTV-ID-65 ETRI requirements service Desirable feature of IPTV system for Nippon Hoso DTTB re-transmission platform and an Kyokai (Japan FG IPTV-ID-70 Requirements introduction of experimental IPTV system Broadcasting for ISDB-T Corporation) Requirements Proposal on Feature Interactions in Overlay FG IPTV-ID-76 ETRI (overlay Networks for IPTV Services multicast)
    • -5- FG IPTV-MR-0001 Requirements Proposal on Feature Interactions in Overlay FG IPTV-ID-77 ETRI (overlay Networks for IPTV Services multicast) The requirements for IPTV services which are accepted or adopted at this meeting are contained at FG IPTV-OD-0024. The living lists are also produced for further study at FG IPTV-OD-0025. The detailed results of discussion are as follows.  FG IPTV-ID-21: It proposes requirements to accommodate the existing video coding formats including No. GB/T20090.2 (consider other types of video coding technologies) It is a kind of specification. The existing video coding technologies will be included. The meeting agreed that the specific coding format should not be included at the requirement.  FG IPTV-ID-28: It proposes the interactive control requirements (4 requirements). It contains new requirements (as a gap analysis between the existing standards). The meeting agreed that some requirements are taken in network and control aspects and interworking aspects. Other specific requirements are taken in the living list issues.  FG IPTV-ID-31: It proposes architectural and functional requirements for IMS-based IPTV service including service control functions, which is in relationship with the IMS-based NGN requirements, new requirements including navigation, content distribution, content locating, etc. It is generally agreed that we start to develop requirements based on IMS NGN platform and the most of proposed requirements are included in network and control aspects (WG4). But, some specific requirements should be aligned with architecture and scenario aspects of IPTV.  FG IPTV-ID-34: It proposes functional requirements for p2p IPTV. It contains new requirements (gap analysis between the existing IPTV standards). The meeting agreed that some requirements are taken at network and control aspects, interwoking aspect, and end system aspects.  FG IPTV-ID-35: It proposes requirements for bearer transport capability for IPTV. The detail requirements including QoS in the existing legacy IP network are proposed. The meeting agreed that the proposed requirements are taken into the living list for further study.  FG IPTV-ID-36: It proposes requirement of media provisioning entities and terminal, requirements for heterogeneous network environment. It contains new requirements (gap analysis). The meeting agreed that some requirements are taken into the application aspects and architectural aspects.  FG IPTV-ID-38: It proposes requirements of mobile terminals to support IPTV service, requirements of wireless access for IPTV including seamless handover. The existing mobile broadcast is not based on IP technologies (gap analysis). The meeting agreed that the proposed requirements are adapted.  FG IPTV-ID-39: It proposes requirements for multiple service provider connectivity, requirements for transparency such network transparency, middleware transparency, device transparency. It contains new requirements (gap analysis). The meeting agreed that the proposed
    • -6- FG IPTV-MR-0001 requirements are taken.  FG IPTV-ID-41: It proposes requirement for Accessibility. It contains new requirements (gap analysis). The meeting agreed that a high level accessibility requirement and some detailed requirements are taken into normative requirement of IPTV. The additional detailed requirements were included in the living list of WG1.  FG IPTV-ID-43: It proposes requirements for user, network, service provider, and content provider, service requirements in details, functional requirement, security requirement, management requirement, interworking requirements, performance requirements. It contains new requirements (gap analysis). The meeting agreed that some parts of proposed requirements are taken at the requirement document and the remaining parts will be contained at the living lists.  FG IPTV-ID-49: It proposes requirements of IP access network for IPTV. It contains new requirements (gap analysis). The meeting agreed that some of the proposed requirements are accepted.  FG IPTV-ID-53: It proposes functional requirements for IMS-based IPTV. It contains new requirements (gap analysis). The meeting agreed to develop the requirements of IMS-based IPTV architecture.  FG IPTV-ID-54: It proposes functional requirement for non-IMS-based IPTV. The meeting agreed not to preclude the development of the requirements of non-IMS IPTV architecture.  FGIPTV-ID-58: It proposes requirement of network management and terminal management for IPTV. New requirement is for terminal management (gap analysis). The meeting agreed that the proposed requirements are accepted.  FG IPTV-ID-59: It proposes architectural requirements and control requirements with CDN architecture for IPTV. It contains new requirements (gap analysis). The meeting agreed that the requirements for distribution and delivery of contents within IPTV service are needed.  FG IPTV-ID-65: It proposes requirement for IMS-based IPTV including MBMS architecture of 3GPP (using UMTS). It contains new requirements (gap analysis). The meeting agreed that the high level requirements of IMS-based IPTV network by using MBMS are adapted as an optional solution.  FG IPTV-ID-70: It proposes requirements of re-transmission of digital terrestrial television (DTT) platform for IPTV. The meeting agreed that the proposed requirements are adopted.  FG IPTV-ID-76: It proposes requirement of service level multicast for IPTV, requirement for overlay multicast network in multiple service provider environments and carriers, requirement of service management for IPTV. Some parts are new requirements (gap analysis). The meeting agreed that the high level requirements for service level multicast may be needed.  FG IPTV-ID-77: It proposes requirement of overlay multicast network in fixed and mobile environment (like NGN as converged network environment), service level requirement including service interaction. It contains new requirements (gap analysis). The meeting agreed that the
    • -7- FG IPTV-MR-0001 proposed requirements are taken into the living lists.  FG IPTV-ID-08 (ATIS IIF Initial Deliverables): This Liaison Statement provides good information to develop the requirements of IPTV. The document identified 224 architectural requirements. The meeting agreed to send back to Liaison statement. If ATIS IIF could submit the contributions containing the relevant information from the IIF Architecture Requirements document, so that this work group can review, and include where agreed, this information.  FG IPTV-ID-10 (Starting point for IPTV requirements work): This contribution proposes to start the requirements for IPTV from the ATIS activities. The meeting also agreed to send back to Liaison statement to ATIS.  FG IPTV-ID-17 (Technical issues on IP TV standardization): The contribution proposes the existing network environment. If the requirements for IPTV will be produced, it should be aware of the existing networks and service environments of IP/NGN network, mobile cellular network and cable network. The raised issues are taken into the living lists.  FG IPTV-ID-52 (Proposal studying NGN-based IPTV): This contribution proposes to study IMS- based IPTV and non-IMS based IPTV solutions. The meeting had already agreed to develop the requirements for IMS-based IPTV. But, not to preclude a non-IMS based solution.  FGIPTV-ID-56 (Suggestion to IPTV standardization): This contribution proposes the release approach to develop the relevant document for IPTV. The service and scenario Working Group may handle this issue first. This contribution does not contain any requirement issue.  FG IPTV-ID-71 (Work on Requirements of IPTV Service): This contribution proposes work priority and work method for IPTV. It proposes to start the requirement document first. And develop the gap analysis including step-by-step approach. The meeting agreed that the requirements document is already adopted as the initial starting activities. The step wise approach is very useful to develop the stable document. It is requested to submit what release or phase approaches are needed at the next meeting.  FG IPTV-ID-85 (A Framework Architecture and Work Items for IPTV standards): This contribution proposes the general framework architecture consistent with NGN and also some outstanding requirements. The meeting agreed that the proposed requirements are taken into the living lists for further consideration, specifically, Ad insertion, IPTV endpoint management, Customized channel lineup, Viewership data management.  FG IPTV-ID-94 (IPTV Service Architecture): This contribution proposes the NGN service architecture including terminology, domain concept, and some technical details. The meeting agreed that some requirements are taken into the requirement document and also the living lists. The requirements for IPTV service can be classified into the high level requirements and specific requirements including some technical details. At this meeting, it is mainly focused at the high level requirements for IPTV. If the requirements for IPTV will be developed, all the requirements must be aligned with architectural documents and scenario documents. The requirements which will be developed at WG1 meeting can give a guideline to develop the relevant documents at each working group.
    • -8- FG IPTV-MR-0001 Also, it requests to clarify the objectives of IPTV focus group within a time frame of one year. 3.3 Architecture 3.3.1 Input Contributions Related contributions: FG IPTV-ID-08, 10, 52, 56, 85, 94, 29, 31, 32, 35, 48, 53, 54, 58, 71, 76, 77, 78, 100, 92, 17,  10 Siemens: Proposes to use ATIS IIF Architecture Requirement as a starting point for own requirements and architecture. Conclusion is that those documents should be used as reference. Submitter agreed that this was taken into account.  52 CATR : Proposal of 2 work items, one on IPTV based on IMS, one based on non-IMS. After a rich debate, the authors proposed to lift section 2 and put it in the living list. No agreement could be found on this conclusion because of the implied assumptions of the document about NGN and IMS.  56 CATR: Proposal for phasing work in video-related services, then others. No particular input could be found, document was noted.  85 Cisco: Generic Framework Architecture for IPTV systems. It was felt that several documents were providing similar contributions and that some harmonization could be attempted to find a common structure in an ad-hoc group (see below). Sections of this document were included in the document ad-hoc1. The submitter proposed to lift section 2 and 3, which were not input into the adhoc document, into the Living List, which was approved.  94 NTT : Service architecture. Debate was linked to that of document 85 and ad-hoc group 1. Tthe submitter agreed that the important parts had been included in the document ad-hoc2 (see below).  31 Huawei: IMS-Based IPTV. IMS IPTV architecture. Debate was linked to that of document 85 and ad-hoc group 1. In addition, the diagrams were found to be close to those of the NGN FG, but with added boxes for an “enhanced IMS” and “Application and Service Support Functions” that were found insufficiently described. Submitter agreed that the important sections and diagrams of this document were included in the document ad-hoc1 (see below).  32 Huawei: IMS IPTV architecture. Debate was linked to that of document 85 and ad-hoc group 1. Submitter agreed that the important sections and diagrams of this document were included in the document ad-hoc1 (see below).  35 : It was found this document was more appropriate for the requirements group.  48 MII : A generic architecture. Debate was linked to that of document 85 and ad-hoc group 1. Submitter agreed that the important sections and diagrams of this document were included in the document ad-hoc1 (see below).
    • -9- FG IPTV-MR-0001  53 CATR Huawei :Outline for an IMS IPTV architecture. Debate was linked to that of document 85 and ad-hoc group 1. Submitter agreed that the important sections and diagrams of this document were included in the document ad-hoc1 (see below).  54 CATR Huawei : Outline for a non-IMS IPTV architecture. Debate was linked to that of document 85 and ad-hoc group 1. Submitter agreed that the important sections and diagrams of this document were included in the document ad-hoc1 (see below).  58 ZTE : IPTV Management. Despite the fact that this document was containing good material, it was agreed that it was too early to determine if could be reused in the architecture document. The document was inserted (by reference) in the Living List for future consideration. It was found that it should be considered by WG4 or WG5, whichever is more appropriate for network or system management.  92 ChinaTelecom : Management of IPTV Services. It was found that it was early to be considered in the architecture document. It was found it should be considered by WG5 or WG6, whichever is more appropriate for service management.  17 ICU/ETRI: Lists a number of architectural issues that some saw close to requirements. The submitter found only p4 to be appropriate for the subgroup. It was agreed to put this page by reference in the Living List for future reference.  71, 76, 77: Those documents were found more appropriate for the requirement subgroup.  78: This document was found more appropriate for the Scenario subgroup. During the course of the debates two ad-hoc groups were started and concluded.  One was chartered to come up with an outline or table of contents for one architecture document, or two documents that could be merged together at a later point. The group came back with two documents that was a merging of several contributions (document adhoc-1 was about the framework architecture, document adhoc-2 was about the service architecture). Neither was not accepted as an architecture document because the document had controversial content and even the structure seemed to have unwanted implications. After debate, both documents were lifted into the living list.  The second was chartered because since no agreement could be obtained on the structure of the architecture document, a diagram could still help. The group considered several diagram before creating its own, loosely based on the IIF domain decomposition with added functions. There was considerable debate before agreement could be found to include the diagram into the architecture document. In addition, the subgroup reviewed and edited contribution 69 on Reference standards, yielding document 69r1, which was then turned into an output document. This document if far from complete and still needs input from other WGs.
    • - 10 - FG IPTV-MR-0001 3.3.2 Liaison offers  8 ATIS IIF Liaison: The group saw great interest in the contribution, although most of was related to requirements. It was noted by the group that it was difficult to reuse elements of the ATIS IIF liaison for reuse since they are copyrighted material for which no copy authorization has been granted.  100 JCA HN Liaison: It was agreed that it was too early to determine whether Home Networks were to be included into the architecture. However it was agreed that it was appropriate to reply to the liaison statement and signal interest.  7 DSFL Liaison: The list of published document was considered. DSLF works at the layer 2 and 3, and has little impact on the IPTV architecture at this stage of the work. 3.3.3 Other Conclusions It was indicated by some members that there was a need to study the IMS-based IPTV architecture. There was consensus that a section on the relationship between NGN and IPTV shall be added to the Architecture Output Document. The exact location for this section is TBD, so the section header was not added in the output document. There was consensus to request contributions for high-level diagrams with their rationale and technical justifications. Example diagrams could be : Network Architecture, IPTV Service Architecture. Contributions should remain at a high-level to remain Technology Neutral. If possible, diagrams should help determining collaborations areas with other working groups of the Focus Group. The group solicits contributions for the Architecture Output Document around • Structure of the Document • Scope of the document The group targets to have a complete Table of Contents for the Architecture Document with at least one sentence under each heading at the end of the next meeting.
    • - 11 - FG IPTV-MR-0001 3.4 Service/Scenario 3.4.1 Input Contributions Doc. No. Titles Sources WGs ATIS IPTV FG IPTV-ID-8 ATIS IIF Initial Deliverables Interoperability all Forum (IIF) FG IPTV-ID-10 Starting point for IPTV requirements work Siemens AG all Some discussion issues on the IPTV Korea FG IPTV-ID-12 Scenario service scenario (Republic of) IPTV service scenarios using NACF over Korea FG IPTV-ID-14 Scenario NGN (Republic of) Some classifications and discussion issues Korea Scenario and FG IPTV-ID-16 for IP TV service scenario (Republic of) Driver Korea FG IPTV-ID-17 Technical issues on IP TV standardization all (Republic of) FG IPTV-ID-19 Definition of IP/TV Services France Telecom Scenario Classifications of IPTV service and its FG IPTV-ID-26 KT Scenario meaning FG IPTV-ID-27 Commercial billing model of IPTV KT Business model FG IPTV-ID-29 Architecture requirements for IPTV Global KT architecture Service Requirement Media Adaptation to Usage Environments and service FG IPTV-ID-36 ETRI for IPTV Services scenario (MPEG) FG IPTV-ID-38 IPTV: Mobile Scenario and Architecture Samsung scenario Multiple Service Provider Connectivity Samsung Requirement FG IPTV-ID-39 and Transparency of IPTV Service Electronics (transparency) CATR of MII, Service FG IPTV-ID-52 Proposal studying NGN-based IPTV Huawei scenario Proposal about CDN architecture based Requirement FG IPTV-ID-59 ZTE Corporation IPTV media delivery system (service) A discussion issue on the IMS-based IPTV Scenario FG IPTV-ID-65 ETRI service (Mobile)
    • - 12 - FG IPTV-MR-0001 Requirements on Metadata for IPTV Scenario FG IPTV-ID-75 ETRI Services Scenario FG IPTV-ID-91 Proposal on IPTV service classification China Telecom FG IPTV-ID-94 IPTV Service Architecture NTT, KDDI, Service Hitachi, scenario and Mitsubishi architecture Electric, Sharp, Sony, Toshiba • ID-08: Liaison from ATIS. This contributions provides the list of initial deliverables already produced by the ATIS IIF for IPTV services, namely: • IPTV Architecture Requirements (ATIS-0800002) • IPTV DRM Interoperability Requirements (ATIS-0800001) • IPTV DRM Interoperability Specification Issue Statement (IIF-Issue-007) • IPTV DRM Distributing of Content in the Subscriber's Authorized Service • Domain Issue Statement (IIF-Issue-008) • IPTV ARCH Roadmap Issue Statement (IIF-Issue-009) • IPTV ARCH Packet Loss Issue Statement (IIF-Issue-005). • ID-10: Starting point for IPTV requirements work. It proposes to start the work in the IPTV FG from ATIS IIF documents on architecture and DRM and to extend them with requirements from other parts of the world. • ID-12: presentation of ATIS IIF Architecture requirements report for the identification of service scenarios and TV Anytime phase 1 and phase 2 business models as a basis for use cases, considered to be relevant for our work. Reference to regional bodies may be problematic. Contains a list of interesting services to be considered in the FG IPTV activities. • ID-14: scenarios using NACF are proposed: Media gateway based IPTV Service and Terminal based IPTV Service. Far more technical than previous contribution Too detailed, more an issue for a technical group: architecture? Aspects as a draft recommendation. • ID-16: Identifying Business scenarios and main business drivers: (network, service, platform, content providers, consumer, application). Identifying roles. • ID-17: Technical issues on IP TV standardization. A part of this contribution identifies business drivers and a number of services. Same services are listed in ID-26, business drivers are also included in ID-16. • ID-19: Definition of IP/TV Services. Actors are identified.
    • - 13 - FG IPTV-MR-0001 • ID-26: Classifications of IPTV service and its meaning: a list of services classified in 3 categories: basic channel service, enhanced selective service and interactive data service. Use cases are proposed. • ID-27: Commercial billing model of IPTV (free, subscription, a la carte, etc.). • ID-29: Architecture requirements for IPTV Global Service. The same service classification was also included in ID-26, which was already presented. • ID-36: Media Adaptation to Usage Environments for IPTV Services. Focus on heterogeneity in networks, devices, sources, contents. • ID-38: IPTV: Mobile Scenario and Architecture. Mobile should not be forgotten • ID-39: Multiple Service Provider Connectivity of IPTV Service: Relevant multiple provider use cases • ID-52: Proposal studying NGN-based IPTV: 2 candidates: IMS-based and not IMS-based solutions • ID-59: Proposal about CDN architecture based IPTV media delivery system: More a solution and a list of requirements more in the scope of WG1-R. • ID-65: A discussion issue on the IMS-based IPTV service. Hope that the standardization for the IMS-based mobile IPTV service can start working based on the MBMS. • ID-75: Requirements on Metadata for IPTV Services. Interested use cases on metadata for which WG? • ID-91: Proposal on IPTV service classification. A list of services are presented for consideration in the FG, classified in Audio-visual services and extended services including telecommunication and information services. • ID-94: IPTV Service Architecture. Identification of services in two categories: content delivery and content navigation services. 3.4.2 Discussion on meeting outputs • To start a list of services to be included in IPTV services (e.g. Linear/Broadcast TV, Video/TV on Demand (VOD), near VOD, Interactive TV (iTV), Consumer Originated Video, etc.). • Identification & description of roles/players/drivers • Commercial/billing models (not limited to whatever exists in the existing contributions) • Structure of service scenarios and use cases starting from the end-user requirements and requirements for different players (content providers, service providers, network providers, consumers, regulators, etc.) Use cases for service combinations. • Call for contributions on these issues for next meeting: – to complete the list of services, their definition, – to ask for classification/grouping by importance, relevance, priority, etc. to maybe identify phases of work – to ask for use cases with a format suggestion – to ask for service scenarios with identification of flows between functions of players
    • - 14 - FG IPTV-MR-0001 3.4.3 Work on the proposed list of services for the IPTV FG activities Related contributions: FG IPTV-ID-0012, 26, 91 and 94 Proposed unordered list of services for the IPTV FG activities • Linear/Broadcast TV (audio, video and data) • Linear Broadcast TV with Trick Modes • Multi-angle service • Time-shift TV • Pay Per View (PPV) • Video/TV on Demand (VOD) – Near VoD (Video on Demand) broadcasting – Real VoD • Download Based Video Content Distribution Services (Push VOD) • Content download service • PVR service (network or client-based) • Interactive TV (iTV) • Consumer Originated content (Video, etc. and applications) • Consumer Originated broadcast TV (e.g. C2C hosting) • Linear Broadcast Audio • MoD (Music on Demand) including Audio book • Pictures • T-Learning (education for children, elementary, middle and high school student, languages and estate, etc.) • Games • Regulatory Information services • T-information (news, weather, traffic and advertisement etc.) • T-commerce (security, banking, stock, shopping, auction and ordered delivery, etc.) • T-communication (e-mail, instant messaging, SMS, channel chatting, VoIP, Web, multiple video conference and video phone, etc.) • T-entertainment (photo album, games, karaoke and blog, etc.) • Presence service • Advertising • Communications Messaging
    • - 15 - FG IPTV-MR-0001 • Service Information (EPG: Electronic Program Guide, ECG: Electronic Content Guide, etc.) • Portal services • Hybrid services • 3rd party content services Definitions: TBD 3.4.4 Work on identification & description of roles/players/drivers Related contributions: FGIPTV-ID-0016, 19 and 25 Identification & description of roles/players/drivers • Content providers • Application providers • Content aggregators • Service providers • Network providers • Consumers (subscriber, viewer, etc.) • Regulators Definitions extracted from ID-25 Content provider: The content provider is the entity owning contents or being licensed to sell content assets. Their role is contents production and delivery. Application provider: The application provider is the entity providing IPTV-related user interface applications. Content aggregator (from ID-19): aggregate contents a la TV channel for example. Service provider: The service provider is the entity providing a service to end-user through a procedure of receiving, manipulating, value-added processing and transmitting contents with security and management using an IPTV platform. Network provider: The network provider is the entity connecting customer and service providers with control and management for the secured delivery of contents in several layers such as core, distribution and access layer. Consumer: The customer is the entity that the IPTV services are consumed. Regulator: TBD. 3.4.5 Work on Business/Commercial models Related contributions: FG IPTV-ID-0027
    • - 16 - FG IPTV-MR-0001 There are a number of well-known business models for service providers to support IPTV service and to make profitable revenue by composing various service products. Generally, classified service products can be commercial model according to the service provider’s policy and marketing. Here is a proposed list of business/commercial models but other models and combinations might be possible. • Free A viewer can watch IPTV service or use it without paying for it. • Subscription A viewer should pay an amount of money regularly in order to watch or use IPTV service. • Pay per view (PPV) / Pay per use (PPU) A viewer can purchase each service, content or application to be seen on TV at any time and pay for the only item he buys. E.g. each service or content can be purchased using an on-screen guide, an automated telephone system, or through a live customer service representative. • A La Carte A viewer can buy whichever channels and contents he wants, and pay a price for each. In this time, the channel is composed not by the service provider but by the user. • Cash-back Point A cash-back point is prepaid e-money or ticket for IPTV service. With these cash-back points user can pay the service fee in IPTV service domain like real-money. User can acquire the cash- back points by buying it with real money or accumulating bonus cash-back point which accrues in a particular rate when they use the IPTV service. The cash-back point can be a unit of price of detailed service. (Similar to frequent flyers miles) • Package A viewer can select and use a set of products such as VOD (including channel) and T- entertainment (including game, karaoke and so forth) which are already organized by the service provider. Then, pay for the set of products which he or she chooses. • Etc. 3.4.6 Work on the draft output document A structure for the draft output document has been discussed and agreed and all the work done has been incorporated in the output document. Contributions are explicitly requested in some parts of the document. There are questions about work done in other working groups and possible overlap between the output documents.
    • - 17 - FG IPTV-MR-0001 4 Joint meeting with other WG There is no joint meeting to be arranged. 5 Outgoing liaisons From Destination Title Document # WG1 ATIS Liaison Statement to ATIS IIF FG IPTV-OD-0031 6 Output documents Document number Title FG IPTV-OD-0024 Working Document on Requirements for IPTV FG IPTV-OD-0025 WG 1 Living Lists (Requirements) FG IPTV-OD-0026 Working Document on Service Scenario for IPTV FG IPTV-OD-0027 Draft Architecture Document FG IPTV-OD-0028 Draft Gap Analysis Document FG IPTV-OD-0029 Draft Standard Reference Document FG IPTV-OD-0030 WG 1 Living List (Architecture) 7 Plan for next meeting activities • (Requirement) The outstanding issues on the requirements for IPTV services are contained at the living list. Specially, user requirements, network/service provider requirements, and content provider requirements will be discussed. The alignments with architecture and service scenario for IPTV service are needed at the next meeting. To produce relevant architecture and service scenarios for IPTV service, it requests to submit the specific requirements at the next meeting. • (Architecture) The group will continue to populate the output documents, and chiefly the architecture document, which table of contents is to be ready by the meeting’s end. The group will review input contributions to the output documents. The group will have joint meetings with other groups to align the considered architectures. The groups will be decided according to their results and associated architectural implications. • (Service/Scenario) To process contributions received after the call for contributions – To refine the list and definition of IPTV services – To group identified services and classify them by importance, relevance, priority, etc. to maybe identify phases of work (possibly core set, additional services and rejected services) – To work on requirements, use cases and service scenarios
    • - 18 - FG IPTV-MR-0001 8 Acknowledgements WG 1 leaders would like to thank all participants for their contribution and hard work during this meeting. Thank you to the editors. Special Thanks to Mr. Khalid Ahmad and Mr. Steven Wright who chaired the ad-hoc groups, and to the participants to those groups. ___________________