ITU IPTV Definition

INTERNATIONAL TELECOMMUNICATION UNION

FOCUS GROUP ON IPTV

TELECOMMUNICATIONSTANDARDIZATION SECTOR

STUDY PERIOD 2005-2008

FG IPTV-MR-0001Original: 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

Contact: Jun Kyun Choi Korea (Republic of)

Tel: +82-42-866-6233Fax: +82-42-866-6226Email [email protected]

Contact: Julien MaisonneuveAlcatel SAFrance

Tel: +33 1 4076 1145Fax: +33 1 4076 1259Email: Julien.Maisonneuve@ a lcatel.com

Contact: Christian Bertin Tel: +33 2 99 12 40 16Fax: +33 2 99 12 40 98Email [email protected]

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.

mailto:[email protected]

mailto:[email protected]

- 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 Detailed Results

3.1 Term of References

Related contributions: FG IPTV-ID-0015, FG IPTV-ID-67

Doc. No. Titles Sources WGs

FG IPTV-ID-15Proposal of Terms of Reference on architecture and requirements of IP TV

Korea (Republic of)

ToR

FG IPTV-ID-67Architecture Working Group proposed orientations

Alcatel ToR

Term of References of WG1 are contained at FG IPTV-OD-0001.

3.2 Requirements

Input contributions are as follows.


FG IPTV-ID-8 ATIS IIF Initial DeliverablesATIS IPTV

Interoperability Forum (IIF)

all

FG IPTV-ID-10 Starting point for IPTV requirements work Siemens AG all

FG IPTV-ID-17 Technical issues on IP TV standardizationKorea

(Republic of)all

FG IPTV-ID-52 Proposal studying NGN-based IPTVCATR of MII,

HuaweiService scenario

FG IPTV-ID-56 Suggestion to IPTV standardization MII, ChinaWork method (stage process)

FG IPTV-ID-71 Work on Requirements of IPTV Service ETRIRequirement

(work method)

FG IPTV-ID-85A Framework Architecture and Work Items for IPTV standards

CiscoFramework architecture

FG IPTV-ID-94 IPTV Service Architecture

NTT, KDDI, Hitachi,

Mitsubishi Electric, Sharp, Sony, Toshiba

Service scenario and

architecture

FG IPTV-ID-21Proposal to request of AVS video standard to be the must IPTV video format

China Netcom, PCCW

requirements


FG IPTV-ID-28Interactive control Requirements for IPTV Service

KT requirements

FG IPTV-ID-31proposal of IMS-based IPTV architecture on NGN

Huawei, CATR requirements

FG IPTV-ID-34requirement for P2P-based IPTV media delivery system

Huawei, Inc.P2p

requirements

FG IPTV-ID-35 Study of bearer network for the IPTVHuawei

TechnologiesRequirements

and architecture

FG IPTV-ID-36Media Adaptation to Usage Environments for IPTV Services

ETRI

Requirement and service

scenario (MPEG)

FG IPTV-ID-38 IPTV: Mobile Scenario and ArchitectureSAMSUNG Electronics.

Requirement (mobile)

FG IPTV-ID-39Multiple Service Provider Connectivity and Transparency of IPTV Service

Samsung Electronics

Requirement

(transparency)

FG IPTV-ID-41IPTV features required for accessibility for people with disabilities

OmnitorRequirement (disability)

FG IPTV-ID-43 IPTV Service Requirement CATR, China requirements

FG IPTV-ID-49Proposed requirements for IP access network in IPTV

MII, Alcatel Shanghai Bell

Requirements (access)

FG IPTV-ID-53Functional Requirements and Architecture of the IMS-based IPTV

CATR of MII,Huawei

Requirement and architecture

FG IPTV-ID-54Functional Requirements and Architecture of the non-IMS based IPTV

CATR of MII,Huawei

Requirement and architecture

FG IPTV-ID-58Architecture and Requirement of IPTV Network Management

ZTE CorporationRequirement

(management)

FG IPTV-ID-59Proposal about CDN architecture based IPTV media delivery system


(service)

FG IPTV-ID-65A discussion issue on the IMS-based IPTV service

ETRI requirements

FG IPTV-ID-70

Desirable feature of IPTV system for DTTB re-transmission platform and an introduction of experimental IPTV system for ISDB-T

Nippon Hoso Kyokai (Japan Broadcasting Corporation)

Requirements

FG IPTV-ID-76Proposal on Feature Interactions in Overlay Networks for IPTV Services

ETRI

Requirements

(overlay multicast)


FG IPTV-ID-77Proposal on Feature Interactions in Overlay Networks for IPTV Services

ETRI

Requirements

(overlay multicast)

The requirements for IPTV services which are accepted or adopted at this meeting are contained atFG 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


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


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.


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).


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


FG IPTV-ID-8 ATIS IIF Initial DeliverablesATIS IPTV

Interoperability Forum (IIF)

all

FG IPTV-ID-10 Starting point for IPTV requirements work Siemens AG all

FG IPTV-ID-12Some discussion issues on the IPTV service scenario

Korea

(Republic of)Scenario

FG IPTV-ID-14IPTV service scenarios using NACF over NGN

Korea

(Republic of)Scenario

FG IPTV-ID-16Some classifications and discussion issues for IP TV service scenario

Korea

(Republic of)

Scenario and Driver

FG IPTV-ID-17 Technical issues on IP TV standardizationKorea

(Republic of)all

FG IPTV-ID-19 Definition of IP/TV Services France Telecom Scenario

FG IPTV-ID-26Classifications of IPTV service and its meaning

KT Scenario

FG IPTV-ID-27 Commercial billing model of IPTV KT Business model

FG IPTV-ID-29 Architecture requirements for IPTV Global Service

KT architecture

FG IPTV-ID-36Media Adaptation to Usage Environments for IPTV Services

ETRI

Requirement and service

scenario (MPEG)

FG IPTV-ID-38 IPTV: Mobile Scenario and Architecture Samsung scenario

FG IPTV-ID-39Multiple Service Provider Connectivity and Transparency of IPTV Service

Samsung Electronics

Requirement

(transparency)

FG IPTV-ID-52 Proposal studying NGN-based IPTVCATR of MII,

HuaweiService scenario

FG IPTV-ID-59Proposal about CDN architecture based IPTV media delivery system


(service)

FG IPTV-ID-65A discussion issue on the IMS-based IPTV service

ETRIScenario

(Mobile)

- 12 -FG IPTV-MR-0001

FG IPTV-ID-75Requirements on Metadata for IPTV Services

ETRIScenario

FG IPTV-ID-91 Proposal on IPTV service classification China TelecomScenario

FG IPTV-ID-94 IPTV Service Architecture NTT, KDDI, Hitachi,

Mitsubishi Electric, Sharp, Sony, Toshiba

Service scenario and

architecture

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.

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.

- 13 -FG IPTV-MR-0001

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

Service Information (EPG: Electronic Program Guide, ECG: Electronic Content Guide, etc.)

- 15 -FG IPTV-MR-0001

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.

___________________