INTERNATIONAL TELECOMMUNICATION UNION
FOCUS GROUP ON IPTV
TELECOMMUNICATION
STANDARDIZATION SECTOR
FG IPTV-C-0266
English only
STUDY PERIOD 2005-2008
3rd FG IPTV meeting:
Mountain View, USA, 22-26 January 2007
WG(s): ALL
CONTRIBUTION
Source: NGN-GSI (Geneva, 24 October – 3 November 2006)
Title:
SG 13 Rapporteur Groups Input to FG IPTV
1
Architectural issues
1.1
Discussions
NGN-GSI/C- 178 (Consideration on a new FRA for streaming services of NGN release 2 scope)
from Korea proposed that work commence on FRA release 2 to accommodate IPTV. Figure 5
proposed additions to the general architecture figure in FRA.
NGN-GSI/C – 205 (ATIS IPTV architecture requirements), supplied by the Rapporteur, was
available for information to complement other contributions which refererence the ATIS materials.
NGN-GSI/C – 210 (IP-TV support in ITU-T NGN release 2), from France Telecom, provided
proposals for mapping FRA FEs for the IMS and non-IMS NGN architectures. This contribution
assumes that Q.3/13 is responsible for architectural matters and seeks to clarify the Q.3/13 to IPTV
Focus Group relationship, and establish appropriate coordination of work and deliverables.
With regard to NGN-GSI/C – 246 (Excerpt from the meeting report of the Chairman, FG IPTV), the
three architectures (non-NGN, non-IMS NGN, and IMS NGN) proposed by the IPTV Focus Group
were examined.
On the subject of NACF, Q.3/13 participants considered that the enhancement of NACF depended
on what the IPTV Focus Group’s requirements for multicast were, given the availability of various
access networks with various possible multicast arrangements. Q.3/13 requests to the full extent of
multicast requirements deemed necessary by the IPTV Focus Group.
1.2
Results
Question 3/13 (dealing with architectural issues) thanks the IPTV Focus Group for its recent
communications. Q.3/13 would like to inform you of our view on how to incorporate IPTV
architecture in the NGN architecture. In addition Q.3/13 would like to share some comments on
your initial communications.
Q.3/13 agreed on the following points:

Contact:
Q.3/13 is quite happy to see FG IPTV’s initial study on IPTV including architectural
aspects. The intent of Q.3/13 is of course to take into account your work and corresponding
TSB
Tel:
Fax:
Email: tsbsg13@itu.int
Attention: This is a document submitted to the work of ITU-T and is intended for use by the participants to the activities of ITU-T's
Focus Group on IPTV, and their respective staff and collaborators in their ITU-related work. It is made publicly available for
information purposes but shall not be redistributed without the prior written consent of ITU. Copyright on this document is owned by
the author, unless otherwise mentioned. This document is not an ITU-T Recommendation, an ITU publication, or part thereof.
-2FG IPTV-C-0266
output deliverables when preparing SG13 draft Recommendations in the area of IPTV
architecture.

Q.3/13 is interested in your study regarding IPTV requirements, as well as how these
requirements can be satisfactorily supported from the viewpoint of the architecture, and in
particular the enhancements to the NGN architecture. Q.3/13 is also willing to cooperate
with you in resolving specific issues with significant architectural implications.

Q.3/13 has agreed to add and develop a new IPTV service component as shown in Figure 1.
Note that Figure 2 is the current figure as contained in last call version of Recommendation
Y.2012. The IPTV service component is expected to be described in detail, at the same
level of the existing Rec. Y.2021 and Y.2031. The relationship between service
components and their descriptions is shown in Figure 3. Again, Figure 4 shows the
proposed documentation structure incorporating the IPTV service component. As Q.3/13’s
intent is to make use of your possible output, which is currently titled as “IPTV
architecture”, Q.3/13 suggests that the FG IPTV keeps in mind the proposed documentation
structure when preparing its deliverables. After investigating the service-specific
architecture descriptions newly developed for IPTV, we may also need to revise the
generalized Y.2012 architecture and add or revise relevant Functional Entities, if necessary.

Architectural requirements identified by FG IPTV are particularly important to Q.3/13 in
that they can guide us in our work on general, over-arching architecture. Even preliminary
general architectural requirements will be helpful.

For the sake of our understanding, Q.3/13 would like to ask the following questions under
the assumption that the target capability could be separated into two delivery mechanisms:
o
o
Multicast:
1.
What if one party in a multicast group wants to pause and restart a video? Do
you want users to be able to pause and resume communications without losing
any information when they are a part of a multicast group?
2.
What are the QoS requirements for multicast?
3.
What are the interactions for and between the Service Stratum and the
Transport Stratum in terms of channel selection?
4.
Should receiver location information be provided to achieve regional-specific
content control?
5.
Are multicast replication points intended to be only in the core network or also
in the access network? Are you considering only Layer 3 multicast, or also
Layer 2? If so, are you considering using them together?
6.
Is a capability to provide pay per view required? Is it a requirement to monitor
usage on a per-channel, per-time basis?
Unicast:
1.

Besides content play controls such as forwarding and rewinding, is session
control (IMS-based or non-IMS-based) enough?
Regarding WG4 contribution 126 “Multicast control function for IPTV service in the
NACF” requesting additions to NACF, we believe that the assumption regarding the use of
IGMP/MLD for group membership control is premature, because the interactions between
group control in the Transport Stratum and service control in the Service Stratum need to be
-3FG IPTV-C-0266
investigated. We intend to consider issues in this area in order to answer regarding C-126,
and invite your inputs as well. This relates to question 3 for multicast.
Q.3/13 would like to collaborate closely with FG IPTV in order to prepare Recommendations in a
timely and efficient manner based on your output deliverables. As IPTV architecture has
implications for NGN architecture in general, we request that you continue to send us your key
output documents from each meeting so that we can comment. In this way we can work
synergistically.
Applications
Service Stratum
Application Support
Functions and
Service Support Functions
Application
Functions
S. User
Profile
Functions
Other NGN
Service Components
Service
Control
Functions
IPTV Service
Component
IP Multimedia
Component
IP Multimedia
&PSTN/ISDN
Simulation
Service Component
GW
Legacy
Terminals
Legacy
Terminals
GW
Network Access
T.User
User Network Attachment
Control Functions
Profile
ProfileAttachment
Functions
(NACF)
Functions
Functions
Customer
Networks
Access
Network
Access Transport
Functions
Functions
NGN
Terminals
End-User
Functions
Edge
Functions
Resource and Admission
Control Functions
(RACF)
Other Networks
PSTN / ISDN Emulation
Service Component
Core
Transport
Core
transport
Functions
Functions
Transport Stratum
Figure 1.
Future revision of Figure 8/Y.2012: NGN components including IPTV service component
-4FG IPTV-C-0266
Applications
Service Stratum
Application Support
Functions and
Service Support Functions
Application
Functions
S. User
Profile
Functions
Other NGN Service
Components
Service
Control
Functions
IP Multimedia
Component
IP Multimedia
&PSTN/ISDN
Simulation
Service Component
Legacy
Terminals
Legacy
Terminals
GW
GW
Network Access
T. User
User Network Attachment
Control Functions
Profile
ProfileAttachment
Functions
(NACF)
Functions
Functions
Customer
Networks
Access
Network
Access Transport
Functions
Functions
NGN
Terminals
End-User
Functions
Edge
Functions
Resource and Admission
Control Functions
(RACF)
Other Networks
PSTN / ISDN Emulation
Service Component
Core
Transport
Core
transport
Functions
Functions
Transport Stratum
Figure 2.
The current revision of Figure 8/Y.2012: NGN components
Service
Service components
components
In
In Y.2012
Y.2012
The
The way
way to
to realize
realize
each
each service
service components
components
Current
In the future
IPTV(Y.20xx)
IPTV
Service Component
IMS based
Non-IMS
PIEA(Y.2031)
PSTN/ISDN Emulation
Service Component
Non-NGN ?
(Note)
IMS based
Call server
Note: Inclusion of Non-NGN
aspect in Y.20xx needs further
study.
IFN(Y.2021)
IP Multimedia
Service Component
IMS based
Figure 3. Service components and their realization
-5FG IPTV-C-0266
Current
Current
In
In the
the future
future
Generic
Generic
FRA
FRA(Y.2012)
(Y.2012)
FRA
FRARevised
Revised(Y.2012)
(Y.2012)
Service specific
Service specific
IFN
IFN(Y.2021)
(Y.2021)
IFN
IFN(Y.2021)
(Y.2021)
PIEA
PIEA(Y.2031)
(Y.2031)
PIEA
PIEA(Y.2031)
(Y.2031)
IPTV
IPTVArchitecture
Architecture
(Y.20xx)
(Y.20xx)
Figure 4. Document structure to incorporate IPTV architecture
2
Security requirements (Release 2)
Considering NGN-GSI/C – 211 (Proposal of the IPTV security for NGN release 2 security), from
France Telecom, it was agreed that the Q.15/13 Rapporteur request that his counterparts in charge
of Qs.1, 2, and 3/13 give a readout on the scope of NGN release 2, specifically on the subject of
IPTV, and that the text of the contribution be added to the Living List document for NGN R2 (a
new document).
3
RACF (Release 2)
Considering NGN-GSI/C – 92 (RACF Release 2 priorities), from France Telecom, Q.4/13 agreed
that the specification of Ri, Rd, and Rc and IPTV support are of priority in the RACF R2 effort.
Regarding the reference point between RACF and CPE/CPN, the meeting felt that it may be in R2
scope and needs to be studied in coordination with Q.3/13 and with consideration of related efforts
in DSLF, home gateway initiative, etc.
______________