Download 1 Goals of the meeting

INTERNATIONAL TELECOMMUNICATION
UNION
TELECOMMUNICATION
STANDARDIZATION SECTOR
FOCUS GROUP ON IPTV
FG IPTV-MR-0001
Original: English
STUDY PERIOD 2005-2008
1st FGIPTV meeting: Geneva,
10 – 14 July 2006
1
WG(s)
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:
Contact:
Contact:
Jun Kyun Choi
Korea (Republic of)
Julien Maisonneuve
Alcatel SA
France
Christian Bertin
Tel:
+82-42-866-6233
Fax:
+82-42-866-6226
Email [email protected]
Tel:
+33 1 4076 1145
Fax:
+33 1 4076 1259
Email: [email protected]
Tel:
+33 2 99 12 40 16
Fax:
+33 2 99 12 40 98
Email [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.
-2FG 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-OD0025, 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).
-3FG 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
FG IPTV-ID-15
Proposal of Terms of Reference on
architecture and requirements of IP TV
Korea (Republic
of)
ToR
FG IPTV-ID-67
Architecture Working Group proposed
orientations
Alcatel
ToR
Sources
WGs
ATIS IPTV
Interoperability
Forum (IIF)
all
Siemens AG
all
Term of References of WG1 are contained at FG IPTV-OD-0001.
3.2 Requirements
Input contributions are as follows.
Doc. No.
Titles
FG IPTV-ID-8
ATIS IIF Initial Deliverables
FG IPTV-ID-10
Starting point for IPTV requirements work
FG IPTV-ID-17
Technical issues on IP TV standardization
all
Service
scenario
MII, China
Work method
(stage process)
Work on Requirements of IPTV Service
ETRI
Requirement
(work method)
A Framework Architecture and Work
Items for IPTV standards
Cisco
Framework
architecture
Proposal studying NGN-based IPTV
FG IPTV-ID-56
Suggestion to IPTV standardization
FG IPTV-ID-71
FG IPTV-ID-85
FG IPTV-ID-21
(Republic of)
CATR of MII,
Huawei
FG IPTV-ID-52
FG IPTV-ID-94
Korea
IPTV Service Architecture
Proposal to request of AVS video standard
to be the must IPTV video format
NTT, KDDI,
Hitachi,
Mitsubishi
Electric, Sharp,
Sony, Toshiba
China Netcom,
PCCW
Service
scenario and
architecture
requirements
-4FG IPTV-MR-0001
FG IPTV-ID-28
Interactive control Requirements for IPTV
Service
KT
requirements
FG IPTV-ID-31
proposal of IMS-based IPTV architecture
on NGN
Huawei, CATR
requirements
FG IPTV-ID-34
requirement for P2P-based IPTV media
delivery system
Huawei, Inc.
P2p
requirements
FG IPTV-ID-35
Study of bearer network for the IPTV
Huawei
Technologies
Requirements
and architecture
FG IPTV-ID-36
Media Adaptation to Usage Environments
for IPTV Services
ETRI
Requirement
and service
scenario
(MPEG)
FG IPTV-ID-38
IPTV: Mobile Scenario and Architecture
SAMSUNG
Electronics.
Requirement
(mobile)
FG IPTV-ID-39
Multiple Service Provider Connectivity and
Transparency of IPTV Service
Samsung
Electronics
Requirement
FG IPTV-ID-41
IPTV features required for accessibility for
people with disabilities
Omnitor
Requirement
(disability)
FG IPTV-ID-43
IPTV Service Requirement
CATR, China
requirements
FG IPTV-ID-49
Proposed requirements for IP access
network in IPTV
MII, Alcatel
Shanghai Bell
Requirements
(access)
FG IPTV-ID-53
Functional Requirements and Architecture
of the IMS-based IPTV
CATR of
MII,Huawei
Requirement
and architecture
FG IPTV-ID-54
Functional Requirements and Architecture
of the non-IMS based IPTV
CATR of
MII,Huawei
Requirement
and architecture
FG IPTV-ID-58
Architecture and Requirement of IPTV
Network Management
ZTE Corporation
Requirement
(management)
FG IPTV-ID-59
Proposal about CDN architecture based
IPTV media delivery system
ZTE Corporation
Requirement
(service)
FG IPTV-ID-65
A 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-76
Proposal on Feature Interactions in Overlay
Networks for IPTV Services
(transparency)
Requirements
ETRI
(overlay
multicast)
-5FG IPTV-MR-0001
FG IPTV-ID-77
Proposal on Feature Interactions in Overlay
Networks for IPTV Services
Requirements
ETRI
(overlay
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
-6FG 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
-7FG 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 IMSbased 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.
-8FG 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).
-9FG 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
Interoperability
Forum (IIF)
all
all
FG IPTV-ID-8
ATIS IIF Initial Deliverables
FG IPTV-ID-10
Starting point for IPTV requirements work
Siemens AG
FG IPTV-ID-12
Some discussion issues on the IPTV
service scenario
Korea
FG IPTV-ID-14
FG IPTV-ID-16
FG IPTV-ID-17
IPTV service scenarios using NACF over
NGN
Some classifications and discussion issues
for IP TV service scenario
Technical issues on IP TV standardization
FG IPTV-ID-19
Definition of IP/TV Services
FG IPTV-ID-26
(Republic of)
Korea
(Republic of)
Korea
(Republic of)
Korea
(Republic of)
Scenario
Scenario
Scenario and
Driver
all
France Telecom
Scenario
Classifications 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
ETRI
Requirement
and service
scenario
(MPEG)
Samsung
scenario
Samsung
Electronics
Requirement
(transparency)
CATR of MII,
Huawei
Service
scenario
Requirement
(service)
FG IPTV-ID-36
Media Adaptation to Usage Environments
for IPTV Services
FG IPTV-ID-38
IPTV: Mobile Scenario and Architecture
FG IPTV-ID-39
Multiple Service Provider Connectivity
and Transparency of IPTV Service
FG IPTV-ID-52
Proposal studying NGN-based IPTV
FG IPTV-ID-59
Proposal about CDN architecture based
IPTV media delivery system
ZTE Corporation
FG IPTV-ID-65
A discussion issue on the IMS-based IPTV
service
ETRI
Scenario
(Mobile)
- 12 FG IPTV-MR-0001
FG IPTV-ID-75
Requirements on Metadata for IPTV
Services
FG IPTV-ID-91
Proposal on IPTV service classification
China Telecom
FG IPTV-ID-94
IPTV Service Architecture
NTT, KDDI,
Hitachi,
Mitsubishi
Electric, Sharp,
Sony, Toshiba

ETRI
Scenario
Scenario
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.
- 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 cashback 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 Tentertainment (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.

3.4.6
Etc.
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
WG1
6
ATIS
Title
Document #
Liaison Statement to ATIS IIF
FG IPTV-OD-0031
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

(Service/Scenario) To process contributions received after the call for contributions
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.
–
–
–
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.
___________________