iptv 서비스 구조 1. 표준의 목적 본 표준의 목적은 iptv의 서비스 요구사항과...

T T

A S

tandard

정보통신단체표준(영문표준) 제정일: 2010년 12월 23일

TTAE.IT-Y1910

IPTV 서비스 구조

(IPTV service architecture)

정보통신단체표준(영문표준) 제정일 : 2010년 12월 23일

TTAE.IT-Y1910



본 문서에 대한 저작권은 TTA에 있으며, 이 문서의 전체 또는 일부에 대하여 상업적 이익을

목적으로 하는 무단 복제 및 배포를 금합니다.

Copyrightⓒ Telecommunications Technology Associations(2010). All Rights Reserved.

정보통신단체표준(영문표준)

TTAE.IT-Y.1910 I

서 문

1. 표준의 목적

본 표준의 목적은 IPTV의 서비스 요구사항과 서비스 정의를 기반으로 IPTV 서비스의 기능적 구

조를 정의하는데 있다. 본 표준에서는 상위 수준의 IPTV 기능 모델을 정의하며 전송 네트워크에서

제공되는 기능을 적극 활용하여 서비스를 제공할 수 있는 IPTV 서비스 구조를 규정한다. 본 표준에

서는 상위 수준의 IPTV 기능 구조를 바탕으로 세 가지 IPTV 서비스 구조 즉, Non-NGN(Next Generati

on Network) 기반 IPTV 서비스 구조, NGN 기반의 IPTV 서비스 구조 및 NGN-IMS (IP Multimedia Sub

system ) 기반의 IPTV 서비스 구조를 각각 정의한다. 본 표준에서 정의한 IPTV 서비스 구조 표준은 I

TU-T SG13(Future networks including mobile and NGN)에서 정의한 ITU-T Y.1910(2008.9)의 IPTV func

tional architecture 표준을 기반으로 한 TTA 영문 표준이다.

2. 주요 내용 요약

본 표준은 IPTV 서비스 요구사항과 IPTV 서비스 정의를 기반으로 IPTV 서비스를 지원하기 위한

IPTV 기능적 구조를 정의한다. 우선, IPTV 영역(Domain)별로 IPTV 기능적 역할에 대해서 정의하고

상위 수준의 IPTV 기능적 모델을 규정한다. 상위 수준의 모델에 대해 보다 더 상세화하여 IPTV 서비

스 기능적 구조를 정의한다.

본 표준에서는 IPTV 서비스를 구축하는 네트워크 환경을 세 가지 즉, Non-NGN 기반 네트워크 환

경, NGN 기반 네트워크 환경, NGN-IMS 기반 네트워크 환경으로 구분하여 정의하였으며, 정의한 IP

TV 서비스 구조는 네트워크에서 제공되는 기능을 적극 활용하여 설계되었다. 본 표준에서는 이러

한 세 가지 환경에 대해 IPTV 서비스 구조를 정의하고 IPTV 서비스 구성의 차이점을 기술하고 있다.

또한, 세 가지 네트워크 환경에서 공통으로 정의되는 기능은 세부 기능 블록으로 나누어 각 블록

의 역할과 간단한 동작 및 기능에 대해 정의하며, 세부 기능 블록간의 인터페이스를 정의하고 설명

한다.

본 표준은 한 개의 부속서(Annex)와 여섯 개의 부록(Appendix)을 포함하고 있다. 부속서에서는 IP

TV 구조와 NGN 구조의 상관 관계를 기술하며, 부록에서는 IPTV 구조에서 IPTV 서비스 제공을 위

한 동작 절차 흐름도, 정의된 블록 간 인터페이스에서 사용할 수 있는 프로토콜 예시, 네트워크 계층

구조에 있는 IPTV 서비스 장비에서의 IPTV 기능 구성 예시, 중복(Overlay) 네트워킹 기능, 케이블

망에서 IPTV 구조 설계 예시 및 IPTV 로밍(Roaming) 서비스 제공과 제3자(3rd

본 표준의 여섯 개의 부록에 기술된 모든 내용은 IPTV 서비스와 IPTV 서비스 구조에 대해 이해를

돕기 위한 참고 자료로 이용 가능하나 국내 IPTV 서비스에 적용되어야 할 표준은 아니다. 또한, 이

영문표준의 참조표준인 Y.1910에 추가하여, ITU-T 이외의 다른 표준화 기구(ATIS(Alliance for Teleco

mmunications Industry Solutions), ETSI(European Telecommunications Standards Institute), OIPF(Open I

PTV Forum))에서 정의하고 있는 IPTV 구조를 소개하고, 본 표준에서 정의하고 있는 IPTV 구조와의

차이점을 부록 VII에 추가로 기술하여 포함시켰다.

party) 사업자 접속을

위한 IPTV 구조를 예시하고 있다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

본 표준은 IPTV 서비스를 제공하기 위하여 세 가지 네트워크 환경에서의 IPTV 서비스 구조를 정


TTAE.IT-Y.1910 II

의한다. 세부 기능 요소를 설계, 구현, 적용하고자 할 때 지침으로 활용할 수 있으며, 단말, 네트워크

사업자, 서비스 사업자, 콘텐츠 사업자 간 상호 호환이 가능하도록 국내 IPTV 서비스의 활성화 및 관

련 산업 발전에 기여할 것으로 기대된다.

4. 참조 표준(권고)

4.1 국외표준(권고)

- ITU-T Y.1910, “IPTV functional architecture” (2008)

4.2 국내표준

- 없음

5. 참조표준(권고)과의 비교

5.1 참조표준(권고)과의 관련성

본 표준은 참조표준(ITU-T Y.1910,2008)의 영문 전문 전체를 준용하는 표준이다.

5.2 참조한 표준(권고)과 본 표준의 비교표

TTAE.IT-Y1910 ITU-T Y.1910 비고

1. 범위 1. Scope 동일

2. 참고문헌 2. References 수정

3. 용어정의 3. Definitions 동일

4. 약어 정의 4. Abbreviations and acronyms 동일

5. 규약 5. Conventions 동일

6. IPTV 영역 6. IPTV domains 동일

7. IPTV 구조적 접근 7. IPTV architectural approaches 동일

8. IPTV 기능적 구조의 프레임워크 8. IPTV functional architecture

framework 동일

9. IPTV 구조 개요 9. IPTV architectural overview 동일

10. IPTV 기능적 구조 10. IPTV functional architectures 수정

11. 참조점 11. Reference points 동일

부속서 A. IPTV와 NGN 구조간의 관계 Annex A. Relationship between IPTV

and NGN architectures 동일

부록 I. IPTV 서비스에 대한 절차적

흐름도

Appendix I. Procedural flows relating

to IPTV services 수정

부록 II. IPTV 참조점에서 사용 가능한

프로토콜

Appendix II. Potential protocols that

could be used on IPTV reference

points

동일

부록 III. IPTV 물리적 네트워크 계층

구조

Appendix III. IPTV physical network

hierarchy 동일

부록 IV. IPTV 서비스와 멀티캐스트에

대한 중복 네트워킹 기능

Appendix IV. Overlay networking

function for IPTV services and

multicast

동일

부록 V. HFC 네트워크에서 IPTV 구조

적용

Appendix V. Adaptation of the IPTV

architecture for HFC networks 동일


TTAE.IT-Y.1910 III

부록 VI. IPTV 서비스에 대한 노마디즘 Appendix VI. Nomadism for IPTV

services 동일

부록 VII. 다른 SDO의 IPTV 구조 비교 - 추가

문헌 Bibliography 동일

6. 지적재산권 관련사항

본 표준의 '지적재산권 확약서‘ 제출 현황은 TTA 웹사이트에서 확인할 수 있다.

7. 적합인증 관련사항

7.1 적합인증 대상 여부

- 해당 사항 없음

7.2 시험표준제정여부(해당 시험표준번호)

- 해당 사항 없음

8. 표준의 이력

판수 제·개정일 제·개정내역

제1판 2010.12.23 제정


TTAE.IT-Y.1910 IV

Preface

1. The Purpose of Standard

The purpose of this standard is to define the IPTV functional architecture based on the IPTV service req

uirements and service definitions. This standard defines the basic description of IPTV roles and services an

d outlines the high level IPTV functional model. This model is then developed into a set of IPTV functional

architectures that utilize functions that are provided by the transport network. This standard defines three t

ypes of IPTV service architecture based on the supported transport network which are non-NGN(Next Gen

eration Network) based IPTV service architecture, NGN based IPTV service architecture, and NGN-IMS(I

P Multimedia Subsystem) based IPTV service architecture. This standard is a TTA standard on IPTV servic

e architecture which is based on ITU-T Y.1910(2008), “IPTV functional architecture” recommendation dev

eloped by ITU-T SG 13(Future networks including mobile and NGN).

2. The Summary of Contents

This standard specifies the IPTV functional architecture intended to support IPTV services based on the

IPTV service requirements and IPTV service definitions. Starting from a basic description of IPTV roles an

d services, a high level IPTV functional model is outlined. This model is then developed into a more detaile

d functional architecture. Specific cases are also described in more detail.

The IPTV functional architecture is based on use of existing network components and technologies, as w

ell as on NGN architectures. This leads to three possible options for the architectural representations, which

are IPTV functional architecture for non-NGN network components, IPTV functional architecture based o

n the NGN functional architecture, but not based on IMS, IPTV functional architecture based on NGN IMS

functional architecture. The common elements between these alternatives as well as the differences are des

cribed in this standard.

Also, this standard provided detailed description of the functions and functional blocks related to all thre

e IPTV architectural approaches along with reference points and its description.

This standard defines one Annex and six Appendixes. The Annex defines relationship between IPTV arc

hitecture and NGN architecture. The Appendixes provides information on procedural flow of IPTV services,

potential protocols that can be used in IPTV reference points, example mapping of IPTV functional elemen

t to physical network hierarchy, overlay networking function, adaptation of IPTV service architecture to HF

C network, and nomadism for IPTV service to support IPTV service roaming and interworking with 3rd

The six appendices in this standard is only a reference to assist readers in understanding IPTV service an

d IPTV service architecture and is not part of the standard to be complied by the domestic IPTV service. Al

so, this standard adds another appendix, i.e., appendix VII, to provide short description and difference of IP

TV architecture of other SDOs (i.e., ATIS(Alliance for Telecommunications Industry Solutions), ETSI(Euro

pean Telecommunications Standards Institute), OIPF(Open IPTV Forum)).

part

y service provider.


TTAE.IT-Y.1910 V

3. The Applicable fields of industry and its effect

This document defines IPTV service architecture based on three types of network environment. This doc

ument can be used in design, implementation, and deployment stage of IPTV service entities. This docume

nt defines interactivity between IPTV terminal, network operator, service provider, and contents providers t

o provide support for development of IPTV service and IPTV related industries.

4. The Reference Standards (Recommendations)

4.1 International Standards (Recommendations)

- ITU-T Y.1910, “IPTV functional architecture” (2008)

4.2 Domestic Standards

- None

5. The Relationship to Reference Standards (Recommendations)

5.1 The relationship of Reference Standards

This standard is fully equivalent to ITU-T Y.1910.

5.2 Differences between Reference Standard (recommendation) and this standard

TTAE.IT-Y1910 ITU-T Y.1910 Difference

1. Scope 1. Scope equals

2. References 2. References modified

3. Definitions 3. Definitions equals

4. Abbreviations and acronyms 4. Abbreviations and acronyms equals

5. Conventions 5. Conventions equals

6. IPTV domains 6. IPTV domains equals

7. IPTV architectural approaches 7. IPTV architectural approaches equals

8. IPTV functional architecture

framework

8. IPTV functional architecture

framework equals

9. IPTV architectural overview 9. IPTV architectural overview equals

10. IPTV functional architectures 10. IPTV functional architectures modified

11. Reference points 11. Reference points equals

Annex A. Relationship between IPTV and

NGN architectures

Annex A. Relationship between IPTV and

NGN architectures equals

Appendix I. Procedural flows relating to

IPTV services

Appendix I. Procedural flows relating to

IPTV services modified


could be used on IPTV reference points


could be used on IPTV reference points equals


hierarchy


hierarchy equals


function for IPTV services and multicast


function for IPTV services and multicast equals


TTAE.IT-Y.1910 VI


architecture for HFC networks


architecture for HFC networks equals

Appendix VI. Nomadism for IPTV

services

Appendix VI. Nomadism for IPTV

services equals

Appendix VII. Comparison of IPTV

architecture of other SDOs - added

Bibliography Bibliography equals

6. The Statement of Intellectual Property Rights

IPRs related to the present document may have declared to TTA. The information pertaining to these IPR

s, if any, is available on the TTA Website.

7. The Statement of Conformance Testing and Certification

7.1 The Object of Conformance Testing and Certification

- None

7.2 The Standards of Conformance Testing and Certification

- None

8. The History of Standard

Edition Issued date Contents

The 1st edition 2010.12.23 Established


TTAE.IT-Y.1910 VII

목 차

IPTV 서비스 구조 ································································································· 1

부록 VII. 다른 SDO의 IPTV 구조 비교 ········································································· 3

붙임 – ITU-T Y.1910 ·························································································· 6

1. 범위 ············································································································· 1

2. 참고문헌 ······································································································· 1

3. 용어정의 ······································································································· 2

3.1. 다른 문헌에서 정의된 용어 ············································································ 2

3.2. 본 표준에서 정의된 용어 ·············································································· 2

4. 약어 ············································································································· 3

5. 규약 ············································································································· 5

6 IPTV 영역 ······································································································· 5

7 IPTV 구조적 접근 ······························································································ 6

7.1 구조적 접근 ······························································································ 6

7.2 구조적 차이점 ···························································································· 7

8 IPTV 기능적 구조 프레임워크 ················································································ 7

8.1 이용자 기능 ······························································································ 8

8.2 응용 기능 ································································································· 8

8.3 서비스 제어 기능 ························································································ 8

8.4 콘텐츠 전달 기능 ························································································ 8

8.5 네트워크 기능 ···························································································· 9

8.6 관리 기능 ································································································· 9

8.7 콘텐츠 제공자 기능 ····················································································· 9

9 IPTV 구조 개요 ································································································· 9

9.1 이용자 기능 ·····························································································11

9.2 응용 기능 ································································································12

9.3 서비스 제어 기능 ·······················································································13

9.4 콘텐츠 전달 기능 ·······················································································13

9.5 네트워크 기능 ···························································································14

9.6 관리 기능 ································································································15

9.7 콘텐츠 제공자 기능 ····················································································15

10 IPTV 기능적 구조 ····························································································15

10.1 non-NGN기반 IPTV 기능 구조에 대한 설명 ······················································16

10.2 NGN기반 IPTV 기능 구조에 대한 설명 ·····························································18

10.3 세 가지 구조에서 공통되는 기능 설명 ·····························································23

10.4 상호 작용 ·······························································································32


TTAE.IT-Y.1910 VIII

11 참조점 ········································································································34

11.1 세 가지 IPTV 구조에 공통되는 참조점 ·····························································38

11.2 Non-NGN기반 IPTV 구조에서 사용되는 참조점··················································41

11.3 NGN기반 IPTV 구조에서 사용되는 참조점 ························································42

11.4 IMS기반 IPTV 구조에서 사용되는 참조점 ·························································43

부속서 A IPTV 와 NGN 구조간의 관계 ·······································································46

부록 I IPTV 서비스에 대한 절차적 흐름도 ···································································49

부록 II IPTV 참조점에서 사용이 가능한 프로토콜 ··························································77

부록 III IPTV 물리적 네트워크 계층 구조 ····································································81

부록 IV IPTV 서비스와 멀티캐스트에 대한 중복 네트워킹 기능 ··········································83

부록 V HFC 네트워크에서 IPTV 구조 적용 ··································································84

부록 VI IPTV 서비스에 대한 노마디즘 ········································································87

문헌 ···············································································································93

영문표준 해설서 ·································································································96


TTAE.IT-Y.1910 IX

Contents

IPTV service architecture ······················································································ 1

Appendix VII. Comparison of IPTV architecture of other SDOs ········································ 3

Attachment - ITU-T Y.1910 ··················································································· 6

1 Scope ··········································································································· 1

2 References ····································································································· 1

3 Definitions ······································································································ 2

3.1 Terms defined elsewhere ············································································· 2

3.2 Terms defined within this Recommendation ······················································ 2

4 Abbreviations and acronyms ··············································································· 3

5 Conventions ··································································································· 5

6 IPTV domains ·································································································· 5

7 IPTV architectural approaches ············································································· 6

7.1 Architectural approaches ············································································· 6

7.2 Architectural differences ·············································································· 7

8 IPTV functional architecture framework ·································································· 7

8.1 End-user functions ···················································································· 8

8.2 Application functions ·················································································· 8

8.3 Service control functions ············································································· 8

8.4 Content delivery functions ············································································ 8

8.5 Network functions ······················································································ 9

8.6 Management functions ················································································ 9

8.7 Content provider functions ··········································································· 9

9 IPTV architectural overview ················································································· 9

9.1 End-user functions ···················································································11

9.2 Application functions ·················································································12

9.3 Service control functions ············································································13

9.4 Content delivery functions ···········································································13

9.5 Network functions ·····················································································14

9.6 Management functions ···············································································15

9.7 Content provider functions ··········································································15

10 IPTV functional architectures ············································································15

10.1 Description of functions specific to the non-NGN IPTV functional architecture ········16

10.2 Description of functions specific to NGN IPTV functional architectures ··················18

10.3 Description of functions common to the three architectural approaches ·················23

10.4 Interworking ···························································································32


TTAE.IT-Y.1910 X

11 Reference points ···························································································34

11.1 Reference points with characteristics common to all three IPTV architectures ··········38

11.2 Reference points with characteristics specific to non-NGN IPTV architecture ··········41

11.3 Reference points with characteristics specific to NGN non-IMS IPTV architecture ·····42

11.4 Reference Points specific to NGN IMS IPTV Architecture ····································43

Annex A Relationship between IPTV and NGN architectures ··········································46

Appendix I Procedural flows relating to IPTV services ··················································49

Appendix II Potential protocols that could be used on IPTV reference points ·····················77

Appendix III IPTV physical network hierarchy ·····························································81

Appendix IV Overlay networking function for IPTV services and multicast ··························83

Appendix V Adaptation of the IPTV architecture for HFC networks···································84

Appendix VI Nomadism for IPTV services ·································································87

Bibliography ·····································································································93

Explanation for the English standard ······································································96


TTAE.IT-Y.1910 1

IPTV 서비스 구조 IPTV service architecture

이 표준은 “ITU-T Y.1910(2008): IPTV functional architecture” 권고표준의 내용에 아래 기술된 사항들

을 반영하여 영문 단체표준으로 수용한다.

2장 참고 문헌 (References)

• ITU-T Y.1910 표준에서 명시된 참고문헌을 국내 TTA 표준과 함께 표기함

[ITU-T M.3050.1] Recommendation ITU-T M.3050.1 (2007), Enhanced Telecom Operations Map (eTOM) – The business process framework, TTAE.IT-M3050.1 (2009.12).

[ITU-T Y.2012] Recommendation ITU-T Y.2012 (2006), Functional requirements and architecture of the NGN release 1, TTAE.IT-Y2012 (2006.12).

[ITU-T Y.2014] Recommendation ITU-T Y.2014 (2008), Network attachment control functions in next generation networks, TTAE.IT-Y2014 (2009.12).

[ITU-T Y.2021] Recommendation ITU-T Y.2021 (2006), IMS for Next Generation Networks, TTAE.IT-Y2021 (2007.12).

[ITU-T Y.2111] Recommendation ITU-T Y.2111 (2006), Resource and admission control functions in Next Generation Networks, TTAE.IT-Y2111 (2006.12).

10장 IPTV 기능적 구조 (IPTV functional architecture) 이 표준은 ITU-T Y.1910에서 정의된 내용을 기반으로, 권고표준의 해당 부분에서 변경하여 수용되

는 세부 사항들을 아래와 같이 정의한다.

• ITU-T Y.1910 표준의 “10.3.5 콘텐츠 제공자 기능(Content provider functions)”에서는 그림 10-4의 콘텐츠 제공자 기능 (Content provider functions) 부분에 대해 기술하고 있으며, 그림 10-4에서는 디지털 저작권 관리 (DRM: Digital Rights Management ) 저작권 소스(Right sources), 메타데이터 소스(Metadata sources), 콘텐츠 소스(Content sources)으로 구분하여 표기하고 있다. 또한, 10.3.5에서는 컨텐츠 보호 메타데이터 소스(Content protection metadata sources), 메타데이터 소스, 콘텐츠 소스로 구분하여 설명하고 있다.

그림10-4와 “10.3.5 콘텐츠 제공자 기능” 표준 내용을 일치시키기 위해 컨텐츠 보호 메타데이터 소스를 DRM right sources로 변경하여 수정함.

[변경내용]

10.3.5 Content provider functions

The content provider functions provide a number of different types of source to the content preparation functions, e.g., DRM Right sources, metadata sources and content sources. The physical interfaces and content formats can optionally be different depending on the type of the source. It can optionally include functions for access control based on the rating of the content.

10.3.5.1 DRM Right Sources


TTAE.IT-Y.1910 2

DRM Right Sources defines the usage rules and rights for protected IPTV content.

부록 I IPTV 서비스에 대한 절차적 흐름도 (Procedural flows relating to IPTV services) 이 표준은 ITU-T Y.1910(2008. 9. 12)에서 정의된 내용을 기반으로 변경되는 세부 사항들을 아래와

같이 정의한다.

• ITU-T Y.1910 표준의 “I.2 NGN non-IMS IPTV 구조에 기반한 IPTV서비스에 대한 절차적 흐름도(Procedural flows for IPTV services based on NGN non-IMS IPTV architectures)”에서 “This is supported by most protocols, and if supported means that a single ITF implementation can communicate with ITPV services using either the proxy or the redirect method.” 문장에서 ‘ITPV’ 오류 사용으로 이를 ‘IPTV’로 수정함

[변경내용]

This is supported by most protocols, and if supported means that a single ITF implementation can communication to IPTV services using either the proxy or the redirect method.

• ITU-T Y.1910 표준의 “I.2.3 밀 결합 및 리다이렉트의 주문형 콘텐츠에 대한 절차적 흐름도(Procedural flows for content on-demand with tight coupling and redirect)”의 마지막 문단에서 “In the exception case where the ITF does not perform step 9, the IPTV application functions monitor the session and, if this fails, terminate the session and notifie the IPTV control functional block.” 부분에서 ‘notifie’ 오류 사용으로 이를 ‘notifies’로 수정함

[변경내용]

In the exception case where the ITF does not perform step 9, the IPTV application functions monitor the session and, if this fails, terminate the session and notifies the IPTV control functional block.

• ITU-T Y.1910 표준의 “I.2.4 밀 결합 및 프럭시의 주문형 콘텐츠에 대한 절차적 흐름도 (Procedural flows for content on-demand with tight coupling and proxy)”의 마지막 문단에서 “In the exception case where the ITF does not perform step 9, the IPTV application functions monitor the session and, if this fails, terminate the session and notifie the IPTV service control functional block.” 부분에서 ‘notifie’ 오류 사용으로 이를 ‘notifies’로 수정함

[변경내용]

In the exception case where the ITF does not perform step 9, the IPTV application functions monitor the session and, if this fails, terminate the session and notifies the IPTV service control functional block.

• ITU-T Y.1910 표준의 “I.2. 5 NGN 기반 실시간 IPTV의 로컬 프로그램 적응에 대한 절차적 흐름도 (Procedural flows for local programme adaptation for NGN-based linear IPTV)”의 첫 문단 아래 Note에서 “NOTE – Figue I.12 depicts optional behaviour when a programme is adapted to local constraints.” 부분에서 ‘Figue’ 오류 사용으로 이를 ‘Figure’로 수정함

[변경내용]

NOTE – Figure I.12 depicts optional behaviour when a programme is adapted to local constraints.


TTAE.IT-Y.1910 3

부록 VII 다른 표준 개발 기구(SDO: Standards Development Organization)와의 IPTV 구조 비교 (Comparison of IPTV architecture of other SDOs) 본 표준은 ITU-T Y.1910의 내용에 추가하여, ITU-T 이외에 IPTV 구조에 대한 표준을 다루고 있는 대

표적 다른 표준화 기구인 ATIS(Alliance for Telecommunications Industry Solutions), ETSI(European Telecommunications Standards Institute), OIPF(Open IPTV Forum)에서 정의하고 있는 IPTV 구조들에 대해 소개하고 본 표준에서 정의한 구조와의 차이점을 이 표준의 부록 VII로 간략히 기술한다.

VII.1 ATIS (Alliance for Telecommunications Industry Solutions)

ATIS에서는 IPTV High-level 구조를 “ATIS-0800007 (2007.6.29), IPTV High Level Architecture” 표준에서 정의한다. ((그림 VII-1) 참조).

(그림 VII-1) ATIS에서 정의한 IPTV High-level 구조

ATIS에서는 NGN 기반 IPTV High-level 구조를 정의하고 있으며, NGN 기반 IPTV High-level 구조는 NGN 기반 IPTV 구조와 NGN-IMS 기반 IPTV 구조 모두를 포함한다. (그림 VII-1)의 NGN 서비스 계층(NGN Service Stratum)에서 IPTV 서비스 제어 기능(IPTV Service Control Function)과 제어 클라이언트(Control Client)는 NGN 기반 IPTV 구조에서 적용되고, 코어 IMS(Core IMS)와 세션 클라이언트(Session Client)는 NGN-IMS 기반 IPTV 구조에서 적용된다.

ITU-T의 IPTV 구조는 ATIS의 IPTV 구조를 기반으로 정의되어 있어서 ITU-T의 IPTV 구조의 많은 기능 블록들이 ATIS의 IPTV 구조의 기능 블록과 매우 유사하다. 주요 차이점은 콘텐츠 전달과 관련하여 ITU-T에서는 콘텐츠 전달 기능(Content Delivery Functions)를 별도로 정의하였으나 ATIS에서는 미디어 전달 방송 및 주문형 비디오(Media Delivery Broadcast & VoD)을 정의하고 있다. 또한, 콘텐츠 보안은 ATIS에서 DRM 서버 키 관리(DRM Server Key Management)에서 담당하고 있으나, ITU-T에서는 서비스 및 콘텐츠 보호 (SCP: Service and Content Protection) 기능에서 담당한다.


TTAE.IT-Y.1910 4

VII.2 ETSI(European Telecommunications Standards Institute)

ETSI에서는 IPTV 기능적 구조를 “ETSI TS 182 028 (2008), Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV Architecture; Dedicated Subsystem for IPTV Functions, V2.0.0.” 표준에서 정의한다. ((그림 VII-2) 참조). ETSI에서는 NGN-IMS 기반 IPTV 구조를 “ETSI TS 182 027 (2008), Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS subsystem, V2.0.0.” 표준으로 정의하고 있다.

(그림 VII-2) ETSI에서 정의한 IPTV 기능적 구조

ETSI에서는 ETSI-NGN 기반 IPTV 구조를 정의하고 있으며 ETSI-NGN 기반 IPTV 구조에서의 전달

계층 (Transport Layer)은 ITU-T의 네트워크 접속 제어 기능(NACF: Network Attachment Control Function)의 네트워크 접속 서브 시스템(NASS: Network Attachment SubSystem )와 ITU-T의 리소스 및 접속 제한 기능(RACF: Resource and Admission Control Function)의 리소스 및 접속 제한 시스템(RACS: Resource and Admission Control System)로 구성되어 있다. 콘텐츠 전달 기능은 미디어 배포 기능(Media Distribution Function), 미디어 제어 기능(Media Control

Function) 및 미디어 전달 기능(Media Delivery Function)으로 나뉘어 정의되어 있으며, 이들은 콘텐츠 전달 기능(Content Delivery Functions)과 유사한 기능을 담당한다.

ETSI에서는 ITU-T와 달리 NGN 애플리케이션과 IPTV 애플리케이션과의 연동을 고려하였고 또한 IPTV 사용자 데이터 기능(UDF: User Data Function)와 사용자 데이터 접속 기능(UDAF: User Data Access Function)과의 연동도 고려하였다.


TTAE.IT-Y.1910 5

VII.3 OIPF (Open IPTV Forum)

OIPF에서는 IPTV High-level 구조를 “OIPF, Functional Architecture, V2.0, September 2009” 표준에서 정의한다. ((그림 VII-3) 참조).

(그림 VII-3) OIPF에서 정의한 IPTV High-level 구조

OIPF에서 정의한 IPTV high-level 구조는 네트워크, 서비스, 관리 계층 등에 대해 구분하지 않는 등 ITU-T, ATIS, ETSI 표준의 IPTV 구조와 매우 다른 모습으로 기술되어 있다. 그러나, OIPF의 IPTV 구조의 기능은 기본적으로 다른 표준기관에서 정의한 IPTV 구조의 기능과 크게 다르지 않으며, 서로 기능적으로 매핑이 가능하다. 예를 들면, ITU-T의 IPTV 애플리케이션 기능은 OIPF의 IPTV 애플리케이션, 서비스 제공자 전용 애플리케이션 (Provider specific applications), IPTV 서비스 탐색(Service Discovery) 및 IPTV 서비스 제공사업자 탐색(Service provider discovery) 등으로 기능적인 면에서 대응이 가능하다. 또한, ITU-T의 콘텐츠 전달(Content Delivery) 기능은 OIPF의 콘텐츠 전달 네트워크 제어(Content Delivery Network Control), 클러스터 제어기(Cluster Controller), 콘텐츠 전달 기능(Content Delivery Functions) 및 콘텐츠 저장(Content Storage) 등으로 기능적인 면에서 대응될 수 있다.

OIPF에서는 서비스 품질(QoS)보장 여부에 따라 관리 네트워크(Managed Network)과 비 관리 네트워크(Unmanaged Network)로 구분한다. ITU-T의 RACF는 OIPF의 리소스 및 접속제어 (Resource and Admission Control)로 기능적인 면에서 대응되고 ITU-T의 NACF는 OIPF의 네트워크 접속(Network attachment) 및 원격 접속 부호간 변환기 제어 및 게이트웨이(Remote Access Transcoder Control & Gateway) 등으로 기능적인 면에서 대응이 가능하다.

___________________


TTAE.IT-Y.1910 6

붙임 I

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T Y.1910 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU

(09/2008)

SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Internet protocol aspects – IPTV over NGN

IPTV functional architecture

Recommendation ITU-T Y.1910

ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-

GENERATION NETWORKS

GLOBAL INFORMATION INFRASTRUCTURE

General Y.100–Y.199 Services, applications and middleware Y.200–Y.299 Network aspects Y.300–Y.399 Interfaces and protocols Y.400–Y.499 Numbering, addressing and naming Y.500–Y.599 Operation, administration and maintenance Y.600–Y.699 Security Y.700–Y.799 Performances Y.800–Y.899

INTERNET PROTOCOL ASPECTS General Y.1000–Y.1099 Services and applications Y.1100–Y.1199 Architecture, access, network capabilities and resource management Y.1200–Y.1299 Transport Y.1300–Y.1399 Interworking Y.1400–Y.1499 Quality of service and network performance Y.1500–Y.1599 Signalling Y.1600–Y.1699 Operation, administration and maintenance Y.1700–Y.1799 Charging Y.1800–Y.1899 IPTV over NGN Y.1900–Y.1999

NEXT GENERATION NETWORKS Frameworks and functional architecture models Y.2000–Y.2099 Quality of Service and performance Y.2100–Y.2199 Service aspects: Service capabilities and service architecture Y.2200–Y.2249 Service aspects: Interoperability of services and networks in NGN Y.2250–Y.2299 Numbering, naming and addressing Y.2300–Y.2399 Network management Y.2400–Y.2499 Network control architectures and protocols Y.2500–Y.2599 Future networks Y.2600–Y.2699 Security Y.2700–Y.2799 Generalized mobility Y.2800–Y.2899 Carrier grade open environment Y.2900–Y.2999

For further details, please refer to the list of ITU-T Recommendations.

i Rec. ITU T Y.1910 (09/2008)



Summary Recommendation ITU-T Y.1910 describes the IPTV functional architecture intended to support IPTV services based on the IPTV service requirements and definitions. Starting from a basic description of IPTV roles and services, a high level IPTV functional model is outlined. This model is then developed into a set of functional architectures which support NGN and non-NGN transport networks, as well as operation modes with or without IMS.

Source Recommendation ITU-T Y.1910 was approved on 12 September 2008 by ITU-T Study Group 13 (2005-2008) under Recommendation ITU-T A.8 procedures.

ii Rec. ITU T Y.1910 (09/2008)

FOREWORD

The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.

The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.

The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.

In some areas of information technology which fall within ITU-T's purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.

NOTE

In this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.

Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other obligatory language such as "must" and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party.

INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.

As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http://www.itu.int/ITU-T/ipr/.

ITU 2009

All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU.

http://www.itu.int/ITU-T/ipr/�

iii Rec. ITU T Y.1910 (09/2008)

CONTENTS Page 1 Scope ............................................................................................................................. 1

2 References ..................................................................................................................... 1

3 Definitions .................................................................................................................... 2 3.1 Terms defined elsewhere ................................................................................ 2 3.2 Terms defined within this Recommendation .................................................. 2

4 Abbreviations and acronyms ........................................................................................ 3

5 Conventions .................................................................................................................. 5

6 IPTV domains ............................................................................................................... 5

7 IPTV architectural approaches ..................................................................................... 6 7.1 Architectural approaches ................................................................................ 6 7.2 Architectural differences ................................................................................ 7

8 IPTV functional architecture framework ...................................................................... 7 8.1 End-user functions .......................................................................................... 8 8.2 Application functions ..................................................................................... 8 8.3 Service control functions ................................................................................ 8 8.4 Content delivery functions ............................................................................. 8 8.5 Network functions .......................................................................................... 9 8.6 Management functions ................................................................................... 9 8.7 Content provider functions ............................................................................. 9

9 IPTV architectural overview ......................................................................................... 9 9.1 End-user functions .......................................................................................... 11 9.2 Application functions ..................................................................................... 12 9.3 Service control functions ................................................................................ 13 9.4 Content delivery functions ............................................................................. 13 9.5 Network functions .......................................................................................... 14 9.6 Management functions ................................................................................... 15 9.7 Content provider functions ............................................................................. 15

10 IPTV functional architectures ....................................................................................... 15 10.1 Description of functions specific to the non-NGN IPTV functional

architecture ..................................................................................................... 16 10.2 Description of functions specific to NGN IPTV functional architectures ..... 18 10.3 Description of functions common to the three architectural approaches ....... 23 10.4 Interworking ................................................................................................... 32

11 Reference points ........................................................................................................... 34 11.1 Reference points with characteristics common to all three IPTV

architectures .................................................................................................... 38

iv Rec. ITU T Y.1910 (09/2008)

Page 11.2 Reference points with characteristics specific to non-NGN IPTV

architecture ..................................................................................................... 41 11.3 Reference points with characteristics specific to NGN non-IMS IPTV

architecture ..................................................................................................... 42 11.4 Reference Points specific to NGN IMS IPTV Architecture ........................... 43

Annex A – Relationship between IPTV and NGN architectures ............................................. 46 A.1 IPTV-related components in the NGN architecture ....................................... 46 A.2 Functional mapping between NGN-based IPTV and NGN architectures ...... 47 A.3 Application support functions and service support functions .................. 47

Appendix I – Procedural flows relating to IPTV services ....................................................... 49 I.1 High level flows ............................................................................................. 49 I.2 Procedural flows for IPTV services based on NGN non-IMS IPTV

architectures .................................................................................................... 59 I.3 Procedural flows for IPTV services based on NGN IMS IPTV

architecture ..................................................................................................... 69 I.4 Procedural flows for IPTV interconnection between two NGN networks ..... 73

Appendix II – Potential protocols that could be used on IPTV reference points..................... 77 Appendix III – IPTV physical network hierarchy ................................................................... 81

Appendix IV – Overlay networking function for IPTV services and multicast ...................... 83

Appendix V – Adaptation of the IPTV architecture for HFC networks .................................. 84

Appendix VI – Nomadism for IPTV services .......................................................................... 87 VI.1 Interconnection with the visited network ....................................................... 87 VI.2 Interconnection with third party service providers ......................................... 91

Bibliography............................................................................................................................. 93

1 Rec. ITU-T Y.1910 (09/2008)



1 Scope This Recommendation describes the IPTV functional architecture intended to support IPTV services based on the IPTV service requirements and definitions [b-ITU-T IPTVFG]. Starting from a basic description of IPTV roles and services, a high level IPTV functional model is outlined. This model is then developed into a more detailed functional architecture. Specific cases are also described in more detail.

The IPTV functional architecture is based on the use of existing network components and technologies, as well as on NGN architectures. This leads to three possible options for the architectural representations: 1) IPTV functional architecture for non-NGN network components. 2) IPTV functional architecture based on the NGN functional architecture, but not based on

IMS. 3) IPTV functional architecture based on NGN and its IMS components.

The common elements between these alternatives, as well as the differences, are described in this Recommendation.

2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.

[ITU-T M.1400] Recommendation ITU-T M.1400 (2006), Designations for interconnections among operators' networks.

[ITU-T M.3050.1] Recommendation ITU-T M.3050.1 (2007), Enhanced Telecom Operations Map (eTOM) – The business process framework.

[ITU-T Q.1290] Recommendation ITU-T Q.1290 (1998), Glossary of terms used in the definition of intelligent networks.

[ITU-T Y.2012] Recommendation ITU-T Y.2012 (2006), Functional requirements and architecture of the NGN release 1.

[ITU-T Y.2014] Recommendation ITU-T Y.2014 (2008), Network attachment control functions in next generation networks.

[ITU-T Y.2021] Recommendation ITU-T Y.2021 (2006), IMS for Next Generation Networks.

[ITU-T Y.2111] Recommendation ITU-T Y.2111 (2006), Resource and admission control functions in Next Generation Networks.

2 Rec. ITU-T Y.1910 (09/2008)

3 Definitions

3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere:

3.1.1 application [b-ITU-T Y.101]: A structured set of capabilities, which provide value-added functionality supported by one or more services.

3.1.2 functional architecture [ITU-T Y.2012]: A set of functional entities and the reference points between them used to describe the structure of an NGN. These functional entities are separated by reference points, and thus, they define the distribution of functions. NOTE 1 – The functional entities can be used to describe a set of reference configurations. These reference configurations identify which reference points are visible at the boundaries of equipment implementations and between administrative domains. NOTE 2 – This definition is taken from [ITU-T Y.2012] and therefore relates to NGN. However, it is also valid for other networks, e.g., networks supporting IPTV.

3.1.3 functional entity [ITU-T Y.2012]: An entity that comprises an indivisible set of specific functions. Functional entities are logical concepts, while groupings of functional entities are used to describe practical, physical implementations.

3.1.4 reference point [ITU-T Y.2012]: A conceptual point at the conjunction of two non-overlapping functional entities that can be used to identify the type of information passing between these functional entities. NOTE – A reference point corresponds to one or more physical interfaces between pieces of equipment.

3.1.5 service provider [ITU-T M.1400]: A general reference to an operator that provides telecommunication services to customers and other users either on a tariff or contract basis. A service provider can optionally operate a network. A service provider can optionally be a customer of another service provider. NOTE – Typically, the service provider acquires or licenses content from content providers and packages this into a service that is consumed by the end-user.

3.1.6 subscriber [ITU-T M.3050.1]: The subscriber is responsible for concluding contracts for the services subscribed to and for paying for these services.

3.2 Terms defined within this Recommendation This Recommendation defines the following terms:

3.2.1 content provider: The entity that owns or is licensed to sell content or content assets. 3.2.2 delivery: In the context of IPTV architecture, "delivery" is defined as sending contents to the end user.

3.2.3 distribution: In the context of IPTV architecture, "distribution" is defined as sending the content to appropriate intermediate locations to enable subsequent delivery.

3.2.4 end user: The actual user of the products or services. NOTE – The end-user consumes the product or service. An end-user can optionally be a subscriber (see definition of "subscriber").

3.2.5 linear television (linear TV): A television service in which a continuous stream flows in real time from the service provider to the terminal device and where the user cannot control the temporal order in which contents are viewed.

3 Rec. ITU-T Y.1910 (09/2008)

3.2.6 network provider: The organization that maintains and operates the network components required for IPTV functionality. NOTE 1 – A network provider can optionally also act as service provider. NOTE 2 – Although considered as two separate entities, the service provider and the network provider can optionally be one organizational entity.

3.2.7 video on demand (VoD): A service in which the end user can, on demand, select and view video content and where the end user can control the temporal order in which the video content is viewed (e.g., the ability to start the viewing, pause, fast forward, rewind, etc.). NOTE – The viewing may occur some time after the selection of the video content.

4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: AS-FE Application Support Functional Entity

BGCF Breakout Gateway Control Function

CD&LCF Content Distribution and Location Control Function

CD&SF Content Delivery and Storage Function

CDF Content Delivery Function

CMTS Cable Modem Termination System

CP Content Protection

CPF Content Provider Function

CSCF Call Session Control Function

DNG Delivery Network Gateway DOCSIS Data Over Cable Service Interface Specifications

DRM Digital Rights Management

DSG DOCSIS Set-Top box Gateway

DVBSTP Digital Video Broadcast Service discovery and selection Transport Protocol

EPG Electronic Programme Guide

FB Functional Block

FE Functional Entity

FEC Forward Error Correction

FFS For Further Study

FLUTE File Delivery over Unidirectional Transport HFC Hybrid Fibre Coax

IGMP Internet Group Management Protocol

IMS Internet Protocol Multimedia Subsystem

IPTV Internet Protocol Television

ITF Internet Protocol Television Terminal Functions

4 Rec. ITU-T Y.1910 (09/2008)

IW Interworking

McCPF Multicast Control Point Functional block

McRf Multicast Replication Functional block

MGCF Media Gateway Control Function MLD Multicast Listener Discovery protocol

MRFC Multimedia Resource Function Controller

NACF Network Attachment Control Function

NGN Next Generation Network

OAM&P Operations, Administration, Maintenance and Provisioning

PIM Protocol Independent Multicasting

PVR Personal Video Recorder

QAM Quadrature Amplitude Modulation

QoE Quality of Experience

QoS Quality of Service RACF Resource and Admission Control Function

RF Radio Frequency

RTSP Real-Time Streaming Protocol

RTP Real-time Transport Protocol

SADS Service and Application Discovery and Selection

SC&DF Service Control and Delivery Function

SCF Service Control Function

SCP Service and Content Protection

SHE Super Head End

SIP Session Initiation Protocol SP Service Protection

TCP Transmission Control Protocol

UDP User Datagram Protocol

URL Universal Resource Locator

VCR Video Cassette Recorder

VHO Video Hub Office

VoD Video on Demand

VSO Video Serving Office

5 Rec. ITU-T Y.1910 (09/2008)

5 Conventions Functions: In the context of IPTV architecture, "functions" are defined as a collection of functionalities. It is represented by the following symbol:

Functional block: In the context of IPTV architecture, a "functional block" is defined as a group of functionalities that has not been further subdivided at the level of detail described in this Recommendation. It is represented by the following symbol:

NOTE – In the future, other groups or other Recommendations may possibly further subdivide these functional blocks.

Data source: In the context of IPTV architecture, "data sources" are defined as particular sources of content, metadata and content protection information. They are represented by the following symbol:

6 IPTV domains Figure 6-1 shows the main domains that are involved in the provision of an IPTV service. These domains do not define a business model. This decomposition does not preclude that one provider be involved in the support of any given IPTV service across more than one domain.

6 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F6-1

End user Network provider Service provider Content provider

Figure 6-1 – IPTV domains

NOTE – In Figure 6-1, the conventions defined in clause 5 are not used as this is not a functional architecture diagram.

The four IPTV domains, the definitions of which are provided in clause 3, are: • content provider; • service provider; • network provider; • end user. The functional elements constituting these above domains are described in more detail in clause 8.

7 IPTV architectural approaches

7.1 Architectural approaches This Recommendation identifies three IPTV architecture approaches that enable service providers to deliver IPTV services: 1) "Non-NGN IPTV functional architecture" (non-NGN IPTV): The non-NGN IPTV

architecture is based on existing network components and protocols/interfaces. The technology components, protocols and interfaces used in this IPTV architecture are already in use and hence this approach is a representation of typical existing networks providing IPTV services. This architectural approach can optionally be used as the basis for evolution towards the other IPTV architectures listed below.

2) "NGN-based non-IMS IPTV functional architecture" (NGN non-IMS IPTV): The NGN non-IMS IPTV architecture utilizes components of the NGN framework reference architecture as identified in [ITU-T Y.2012] to support the provision of IPTV services, in conjunction with other NGN services if required.

3) "NGN IMS-based IPTV functional architecture" (NGN-IMS IPTV): The NGN IMS-based IPTV architecture utilizes components of the NGN architecture including the IMS component to support the provision of IPTV services in conjunction with other IMS services if required.

In the following clauses, this Recommendation identifies the commonalities of the three architectural approaches identified above. This Recommendation also describes the main specifics

7 Rec. ITU-T Y.1910 (09/2008)

of each architectural approach. This allows to facilitate the interworking and to identify potential evolutionary paths between these architectural approaches. NOTE – The NGN strata used in this Recommendation refers to [ITU-T Y.2012].

7.2 Architectural differences

7.2.1 Differences between NGN-based and non-NGN-based IPTV architectures The NGN-based IPTV architecture is based on the NGN architecture defined in [ITU-T Y.2012] and uses the components and functions of the NGN. The non-NGN-based IPTV architecture does not necessarily require these components and functions and uses conventional and/or legacy network technologies for the delivery of IPTV services. The main differences are described below: • The NGN-based IPTV architecture uses network attachment control functions (NACF)

defined in [ITU-T Y.2014] to provide functions such as authentication and IP configuration.

• The NGN-based IPTV architecture uses resource and admission control functions (RACF) defined in [ITU-T Y.2111] to provide resource and admission control functions.

• The NGN-based IPTV architecture uses service control functions defined in [ITU-T Y.2012] to provide service control functions.

7.2.2 Differences between NGN non-IMS-based and NGN-IMS-based IPTV architectures The NGN-IMS-based IPTV architecture uses core IMS functions and associated functions such as the service user profile functional block defined in [ITU-T Y.2021] to provide service control functions. The NGN non-IMS-based IPTV architecture uses service control functions other than core IMS functions to provide service control functions.

8 IPTV functional architecture framework The IPTV functional architecture framework shown in Figure 8-1 identifies the principal functional groups for IPTV. These functional groups provide a more detailed breakdown of the IPTV domains that are defined in clause 6. The domains of content provider and end-user remain the same. The domains of service provider and network provider are not used in the architecture as commercial and operational boundaries are not appropriate to an architectural decomposition.

The functional groups in the architecture are derived by grouping related functions. How these functional groups are allocated across operational and organizational boundaries is out of the scope of this Recommendation.

Although accounting functionalities are necessary, they are not currently described in this Recommendation. These functionalities are for further study.

8 Rec. ITU-T Y.1910 (09/2008)

Content Delivery Functions

Manage-ment

Functions

Application Functions

Service Control Functions

End-UserFunctions

ContentProvider

Functions

Network Functions

Figure 8-1 – IPTV functional architecture framework

The following clauses give a description of each functional group. The related functions in each functional group are further decomposed in clause 9.

8.1 End-user functions The end-user functions perform mediation between the end user and the IPTV infrastructure.

8.2 Application functions The application functions enable the end-user functions to select and purchase or rent a content item.

8.3 Service control functions The service control functions (SCF) provide the functions to request and release network and service resources required to support the IPTV services.

The service control functions can request the content delivery functions to allocate resources and request the network functions to reserve required network bandwidth for the content stream. The service control functions can optionally obtain the end user's current location from the network functions.

8.4 Content delivery functions The content delivery functions (CDF) receive content from the application functions, store, process and deliver it to the end-user functions using the capabilities of the network functions, under control of the service control functions.

9 Rec. ITU-T Y.1910 (09/2008)

8.5 Network functions The network functions provide IP layer connectivity between the IPTV service components and the end-user functions. The network functions are shared across all services delivered by IP to an end user. The network functions contribute to the provision of the quality of service (QoS) required by the IPTV services.

8.6 Management functions The management functions perform overall system management (i.e., operations, administration, maintenance and provisioning (OAM&P)). The management functions do not include the functions that provision the behaviour within applications or the functions that gather accounting information within applications.

As an example, the installation of a software upgrade to a video on demand application would be a management function. However, the provisioning of the multicast addresses of linear TV channels within a linear TV application would not be a management function.

8.7 Content provider functions The content provider functions are provided by the entity that owns or is licensed to provide (i.e., sell, rent or give free usage permission) content or content assets (i.e., owner of the content, metadata and usage rights).

9 IPTV architectural overview Figure 9-1 provides an overview of the IPTV functional architecture. Functions and functional blocks described in this clause are common to all architectural approaches as detailed in clause 7.1 except where stated differently.

Key to figures: • The rectangular blocks represent functional blocks in the IPTV architecture, as indicated in

clause 5. • The rounded rectangular areas represent the particular grouping of functions, as indicated in

clause 5. • The solid lines represent direct relationships between either functions or functional blocks. • The dotted lines represent logical associations between end-user functions and either

functions or functional blocks located outside the end-user functions. • Crossed lines do not imply connections, unless explicitly stated.

10 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F9-1

IPTV applicationfunctionsApplication

client functions

SCP clientfunctions

Content deliveryclient functions

Transactionprotocol

Application profilefunctional block

SCP functions

Contentpreparationfunctions

Applicationmanagement

functional block

Service controlmanagement

functional block

Transportmanagement

functional block

Contentand metadata

sources

Content providerfunctions

Managementfunctions

Application functionsEnd-user functions

Authentication andIP allocation

functional block

Service userprofile functional

block

Content distributionand location

control functions

Content delivery functions

Content deliveryand storagefunctions

IPTV terminalfunctions

Control clientfunctional block Multicast

deliverycontrolprotocol

Home networkfunctions

Delivery networkgateway

functional blockAccess network

functions

Resource controlfunctional block

Edgefunctions

Core transportfunctions

Network functions

End-user devicemanagement

functional block

Delivery protocols

Authentication andconfiguration protocol

Content andcontrol

Transportfunctions

Content deliverymanagement

functional block

Content and metadataMetadata

Control Content

IPTV servicecontrol functional

block

Service control functions

Figure 9-1 – IPTV architectural overview

11 Rec. ITU-T Y.1910 (09/2008)

9.1 End-user functions The end-user functions are comprised of IPTV terminal functions and home network functions.

9.1.1 IPTV terminal functions The IPTV terminal functions (ITF) are responsible for collecting control commands from the end user and interacting with the application functions to obtain service information (e.g., EPG), content licenses and keys for decryption. They interact with the service control and content delivery functions to receive the IPTV services and also provide the capability for content reception, decryption and decoding.

9.1.1.1 Application client functions The application client functions exchange information with the IPTV application functions to support IPTV services and other interactive applications.

9.1.1.2 Service and content protection client functions The service and content protection (SCP) client functions interact with SCP functions to provide service protection and content protection. The SCP client functions verify the usage rights and decrypt and optionally watermark the content.

9.1.1.3 Content delivery client functions The content delivery client functions receive and control the delivery of the content from the content delivery and storage functions (CD&SF). After receiving the content, the content delivery client functions can optionally use the SCP client functions to decrypt and decode the content, and can also optionally support playback control.

9.1.1.4 Control client functional block The control client functional block allows the ITF to initiate service requests to the IPTV service control functional block in order to prepare for the connection to the content delivery functions. NOTE – Clause 10 provides more information on IPTV terminal functions related to NGN IMS IPTV architecture.

9.1.2 Home network functions The home network functions provide the connectivity between the external network (i.e., external to the home network) and each IPTV terminal device. These functions include IP connectivity, IP address allocation and configuration from the network functions to the IPTV terminal devices. All data, content and control traffic must pass through the home network functions in order to enter or exit the end-user's IPTV terminal device. The home network functions serve as the gateway between the IPTV terminal functions and the network functions. The home network functions are comprised of the following functional block.

9.1.2.1 Delivery network gateway functional block The delivery network gateway functional block provides IP connectivity between the external network (i.e., external to the home network) and the IPTV terminal device.

The delivery network gateway functional block manages IP connectivity, obtains IP addresses and configurations for the home network functions and IPTV terminal devices.

12 Rec. ITU-T Y.1910 (09/2008)

9.2 Application functions

9.2.1 IPTV application functions The IPTV application functions enable the IPTV terminal functions to select and purchase, if necessary, content.

When receiving requests from IPTV terminal functions, the IPTV application functions perform application authorization and execution of IPTV service logic based on user profile, content metadata and other information retrieved from relevant entities. The IPTV application functions also communicate with content delivery functions to prepare the delivery of media content to IPTV terminal functions through content delivery functions.

9.2.2 Application profile functional block The IPTV application profile can optionally include: • End-user settings which include information related to the capabilities of the end user's

IPTV terminal devices. An IPTV end user may be associated with one or more IPTV terminals with different capabilities.

• Global settings (e.g., language preference). • Linear TV settings. • List of subscribed linear TV service packages. • VoD settings (e.g., parental control level). • Personal video recorder (PVR) settings (PVR network/local preferences, PVR user

restrictions, PVR storage limit). • IPTV service action data which encompass information related to the actions the user can

optionally have taken while accessing services, e.g.: – list of linear TV services (or programmes) that the user has paused and is hence likely

to resume later, including the bookmark value associated with the pause; – list of VoDs that the user has ordered, and associated status; – list of PVR contents that the user has asked to be recorded.

9.2.3 Content preparation functions The content preparation functions control the preparation and aggregation of the contents such as VoD programme, TV channel streams, metadata and EPG data, as received from the content provider functions. The content preparation functions can optionally pre-process (e.g., transcode or edit) the content in advance of passing it to the content delivery, IPTV application and SCP functions.

Content preparation may optionally include the insertion of a watermark for the purpose of content tracing. Additionally, it may create content tracing metadata to facilitate subsequent embedding, into the content, of a content-tracing watermark. The content-tracing metadata is appropriate when multiple copies of the protected content will be created and distributed to end users.

9.2.4 Service and content protection (SCP) functions The SCP functions control the protection of the services and content. Content protection includes control of access to contents and the protection of contents using methods such as encryption. Service protection includes authentication and authorization of access to services and optionally protection of the services using methods such as encryption.

13 Rec. ITU-T Y.1910 (09/2008)

9.3 Service control functions

9.3.1 IPTV service control functional block The IPTV service control functional block provides the functions to handle service initiation, modification and termination requests, perform service access control, establish and maintain the network and system resources required to support the IPTV services requested by the IPTV terminal functions.

The IPTV service control functional block can optionally: • provide registration, authentication and authorization functions for the end-user functions; • process requests from IPTV application functions and forward them to the content delivery

functions in order that the content delivery functions select the most appropriate content delivery and storage functions, for delivering content to the end-user functions;

• request the content delivery functions or application functions to collect charging information.

9.3.2 Service user profile functional block The service user profile functional block: • stores end-user service profile (i.e., IPTV services subscribed to); • stores subscriber-related data (e.g., who pays the incurred charges); • stores end-user location data; • stores end-user presence status (e.g., online/offline); • performs basic data management and maintenance functions:

– updating and storage of "user subscription data" or "network data" (e.g., the current network access point and network location);

• responses to queries for user profiles for: – authentication; – authorization; – service subscription information; – subscriber mobility; – location; – presence.

9.4 Content delivery functions The content delivery functions (CDF) perform cache and storage functionalities and deliver the content according to the request from the end-user functions. The content delivery functions can optionally process the content.

Multiple instances of storage and delivery functionalities can optionally exist. The content delivery functions select the suitable one(s). To maintain the same content at the multiple instances, the content delivery functions control the distribution of content to multiple instances of storage and delivery functionalities.

Content is distributed to the content delivery functions before or during the service offering process.

Content delivery functions interact with end-user functions (e.g., trick mode play functionality).

Content delivery functions support unicast, multicast or both mechanisms.

14 Rec. ITU-T Y.1910 (09/2008)

The content delivery functions are comprised of the following functions: • content distribution and location control functions (CD&LCF) • content delivery and storage functions (CD&SF).

9.4.1 Content distribution and location control functions The content distribution and location control functions include, but are not limited to: • Handling interactions with the IPTV service control functional block. • Controlling the distribution of content from the content preparation functions to the content

delivery and storage functions. • Gathering the information regarding content delivery and storage functions, e.g., resource

utilization, resource status (e.g., in-service and out-of-service), content distribution information and load status.

• Performing the selection of suitable content delivery and storage functions to serve end-user functions according to certain criteria, e.g., the gathered information and the terminal capability.

NOTE – This selection request can optionally be triggered by the IPTV service control functions or the IPTV applications functions.

9.4.2 Content delivery and storage functions The content delivery and storage functions store and cache the content, process it under the control of content preparation functions and distribute it among instances of content delivery and storage functions based on the policy of content distribution and location control functions.

The content delivery and storage functions are responsible for delivering content to the content delivery client functions using the network functions (e.g., unicast and/or multicast mechanisms).

The content delivery and storage functions include, but are not limited to: • Handling interaction with the IPTV service control functional block. • Handling content delivery to end-user functions. • Caching and storing content and associated information. • Insertion, watermarking, transcoding and encryption of the content. • Distributing content within the content delivery and storage functions. • Managing interaction with the content delivery client functions (e.g., trick mode

commands). • Reporting status (e.g., load status and availability) to content distribution and location

control functions. • Generating charging information.

9.5 Network functions The network functions are shared across all services delivered by IP to end-user functions. The network functions provide the IP layer connectivity to support IPTV services. NOTE – The conventions defined in clause 5 are not used in clause 9.5.3 in order to maintain alignment with the terminology used in the NGN framework.

9.5.1 Authentication and IP allocation functional block The authentication and IP allocation functional block provides the functionality to authenticate the delivery network gateway functional block which connects to the network functions, as well as

15 Rec. ITU-T Y.1910 (09/2008)

allocation of IP addresses to the delivery network gateway functional block and optionally to the IPTV terminal functions.

9.5.2 Resource control functional block The resource control functional block provides control of the resources which have been allocated for the delivery of the IPTV services through the access network, edge and core transport functions.

9.5.3 Transport functions The transport functions provide IP layer connectivity between the content delivery functions and the end-user functions. The transport functions include access network functions, edge functions, core transport functions and gateway functions.

9.5.3.1 Access network functions Access network functions are responsible for: 1) aggregating and forwarding the IPTV traffic sent by the end-user functions into the edge of the core network: and 2) forwarding the IPTV traffic from the edge of the core network towards the end-user functions.

9.5.3.2 Edge functions Edge functions are responsible for forwarding the IPTV traffic aggregated by the access network functions (as defined in clause 9.5.3.1) towards the core network, and also to forward the IPTV traffic from the core network to the access network functions.

9.5.3.3 Core transport functions Core transport functions are responsible for forwarding IPTV traffic throughout the core network.

9.6 Management functions The management functions handle overall system status monitoring and configuration. This set of functions can optionally be deployed in a centralized or a distributed manner.

Management functions are comprised of the following functional blocks: • Application management functional block. • Content delivery management functional block. • Service control management functional block. • End-user device management functional block. • Transport management functional block.

9.7 Content provider functions Content provider functions provide the content and associated metadata to content preparation functions, which contain the following sources.

9.7.1 Content and metadata sources The content and metadata sources include content protection rights sources, content sources and metadata sources for the IPTV services.

10 IPTV functional architectures The functional architectures, shown in Figures 10-1 to 10-3, are based on Figure 9-1. These functional architectures are expected to provide functionality for IPTV services. Figure 9-1 provides a high level IPTV functional architecture overview, while Figures 10-1, 10-2 and 10-3, respectively,

16 Rec. ITU-T Y.1910 (09/2008)

provide a non-NGN IPTV functional architecture, an NGN-based non-IMS IPTV functional architecture and an NGN IMS-based IPTV functional architecture.

10.1 Description of functions specific to the non-NGN IPTV functional architecture Clause 9 provides a description of the functions and functional blocks related to all three IPTV architectural approaches. This clause provides descriptive text for the functions and functional blocks which are specific to the non-NGN IPTV functional architecture.

Figure 10-1 shows the non-NGN IPTV functional architecture. NOTE – This figure is identical to Figure 9-1.

17 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F10-1


client functions

SCP clientfunctions


Transactionprotocol


SCP functions



functional block


functional block

Transportmanagement

functional block

Contentand metadata

sources


Managementfunctions



functional block


block


control functions

Content delivery functions



Control clientfunctional block Multicast





functions


Edgefunctions


Network functions


functional block

Delivery protocols


Content andcontrol

Transportfunctions


functional block


Control Content


block


Figure 10-1 – Non-NGN IPTV architecture

18 Rec. ITU-T Y.1910 (09/2008)

10.1.1 Control client functional block See clause 9.1.1.4 for descriptive text. NOTE – This functional block is common with its counterpart in NGN non-IMS IPTV functional architecture.

10.1.2 IPTV service control functional block See clause 9.3.1 for descriptive text. NOTE – This functional block is common with its counterpart in NGN non-IMS IPTV functional architecture.

10.1.3 Service user profile functional block See clause 9.3.2 for descriptive text.

10.1.4 Authentication and IP allocation functional block See clause 9.5.1 for descriptive text.

10.1.5 Resource control functional block See clause 9.5.2 for descriptive text.

10.2 Description of functions specific to NGN IPTV functional architectures

10.2.1 Description of functions specific to NGN non-IMS IPTV functional architecture Clause 9 provides a description of the functions and functional blocks related to all three IPTV architectural approaches. This clause provides descriptive text for the functions and functional blocks which are specific to the NGN non-IMS IPTV functional architecture. Figure 10-2 shows the NGN non-IMS IPTV functional architecture.

19 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F10-2

IPTV applicationfunctions

Transactionprotocol


SCP functions



functional block


functional block

Transportmanagement

functional block

Contentand metadata

sources


Managementfunctions


Network attachmentcontrol functions (NACF)


block


control functions

Service support functionsContent delivery functions


Multicastdeliverycontrolprotocol




functions

Resource and admissioncontrol functions (RACF)

Edgefunctions


NGN transport stratum functions


functional block

Delivery protocols


Content andcontrol

Transportfunctions


functional block


Control Content


block

NGN service stratum functions

Service control functionsControlprotocol

Transport control functions


Applicationclient functions

SCP clientfunctions


Control clientfunctional block

Figure 10-2 – NGN non-IMS IPTV architecture

20 Rec. ITU-T Y.1910 (09/2008)

10.2.1.1 Control client functional block See clause 9.1.1.4 for descriptive text.

This functional block is common with its counterpart in non-NGN IPTV functional architecture.

10.2.1.2 IPTV service control functional block See clause 9.3.1 for descriptive text.

This functional block is common with its counterpart in non-NGN IPTV functional architecture.

10.2.1.3 Service user profile functional block This functional block corresponds to the service user profile functional entity as defined in [ITU-T Y.2012], see also clause 9.3.2.

10.2.2 Description of functions specific to NGN IMS IPTV functional architecture Clause 9 provides a description of the functions and functional blocks related to all three IPTV architectural approaches. This clause provides descriptive text for the functions and functional blocks which are specific to the NGN IMS IPTV functional architecture. Figure 10-3 shows the NGN IMS IPTV functional architecture.

21 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F10-3


client functions

SCP clientfunctions


Transactionprotocol


SCP functions



functional block


functional block

Transportmanagement

functional block

Contentand metadata

sources


Managementfunctions


Network attachmentcontrol functions (NACF)


block


control functions

Service support functionsContent delivery functions



Session clientfunctional block Multicast





functions

Resource and admissioncontrol functions (RACF)

Edgefunctions




functional block

Delivery protocols


Content andcontrol

Transportfunctions


functional block


Control Content

Core IMSfunctions


Service control functionsSessionprotocol


Figure 10-3 – NGN IMS IPTV architecture

22 Rec. ITU-T Y.1910 (09/2008)

10.2.2.1 Session client functional block The session client functional block provides the functions to handle service requests, such as session initiation, modification and termination.

This functional block communicates with IPTV application functions via core IMS functions to prepare for the connection to the content delivery functions. In the VoD case, the session client functional block initiates requests to the IPTV application functions to select suitable content delivery and storage functions which can provide the required content. For the linear TV case, the session client functional block initiates requests to the IPTV application functions for the relevant network parameters, (e.g., multicast address and port), to enable delivery of the required linear TV content.

10.2.2.2 Core IMS functions Functionalities related to and described for the IPTV service control functional block in clause 9.3.1 are supported by core IMS functions. Core IMS functions offer a session control mechanism, and provide functions for the authentication and authorization of IPTV terminal functions based on the user profile. Core IMS functions also provide functions for the interaction with RACF for resource reservation.

Core IMS functions also provide interactions between IPTV terminal functions, IPTV application functions and content delivery functions. The core IMS functions can be used for service discovery. Functions such as charging and roaming can also be supported by IMS mechanisms. NOTE – IMS for NGN is described in [ITU-T Y.2021]. Core IMS functions are the call session control function (CSCF), media gateway control function (MGCF), multimedia resource function controller (MRFC) and breakout gateway control function (BGCF).

10.2.2.3 Service user profile functional block This functional block corresponds to the service user profile functional entity as defined in [ITU-T Y.2012], see also 9.3.2.

10.2.3 Functions specific but common to both NGN IMS and non-IMS IPTV architectures

10.2.3.1 NGN service stratum functions The NGN service stratum functions described in [ITU-T Y.2012] are comprised of "service control functions" and "application support functions and service support functions". In the NGN-based IPTV architectures, application functions correspond to the application support functions in NGN and the service stratum is comprised of: • Service support functions – These include gateway functions to the IPTV service control

functions. However, these are not shown at this level of decomposition. • Service control functions – These include the functions for the control of the network to

ensure the delivery of the media content from the source to the IPTV terminal functions.

10.2.3.2 NGN transport stratum functions NGN transport stratum functions described in [ITU-T Y.2012] are comprised of "transport functions" and "transport control functions". This functional decomposition is also applicable to IPTV NGN-based architectures.

23 Rec. ITU-T Y.1910 (09/2008)

10.2.3.2.1 Transport control functions The transport control functions include resource and admission control functions (RACF) described in [ITU-T Y.2111] as well as network attachment control functions (NACF) described in [ITU-T Y.2012] and [ITU-T Y.2014].

10.2.3.2.2 Transport functions The NGN transport functions provide connectivity for all components and physically separated functions within the NGN. These functions provide support for the transfer of content information, as well as the transfer of control and management information.

The NGN transport functions include "access network functions", "edge functions", "core transport functions" and "gateway functions" all of which are described in [ITU-T Y.2012].

10.3 Description of functions common to the three architectural approaches Functions and functional blocks described in this clause are common to the three architecture approaches described in this Recommendation. Figure 10-4 shows further decomposition of functions into their constituent functional blocks.

24 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F10-4


SCP client functions


Content preparation functions


functional block


functional block

Transportmanagement

functional block

DRM rightssources


Managementfunctions


Authentication and IP allocation functional block

Service user profilefunctional block

Content distribution and location control functions

Service control functions Content delivery functions

Content delivery and storage functions


Multicastdeliverycontrolprotocol



functional block

Access network functions

Resource control functional block

Edge functions Core transport functions

Network functions


functional block

Unicast delivery control protocols

Authenticationand

configurationprotocol

Multicast transport functions


functional block

IPTV service controlfunctional block

Controlprotocol

Service and application discoveryand selection client

functional block

Linear TV clientfunctional block

On-demand clientfunctional block

Other clientfunctional block(s)

Content protectionclient functional

block

Service protectionclient functional

block

Control client functional block


Error recoveryclient functional

block

Unicast contentdelivery client

functional block

Multicast contentdelivery client

functional block


Service and application discovery

and selectionfunctional block

Linear TV applicationfunctional block

On-demand applicationfunctional block

Other applicationfunctional block(s)

SCP functions

Content protectionfunctional block

Service protectionfunctional block

Content processingcontrol functional block

Content managementfunctional block

Metadata processingfunctional block

Location controlfunctional block

Content pre-processingfunctional block

Application provisioningfunctional block

Distribution controlfunctional block

Cache/storagefunctional block

Distributionfunctional block

Content delivery control functional block

Error recoveryfunctional block

Content processingfunctional block

Unicast deliveryfunctional block

Multicast deliveryfunctional block

Multicast control point functional block

Multicast replication functional block

Unicast transport functions

Error recovery control protocol

Metadatasources

Contentsources

Multicastcontrol

Multicastpath

Unicast path

Metadata

Content

ControlContent, metadata and control

NOTE 1 – For NGN IPTV architectures, "authentication and IP allocation functional block" is replaced by "network attachment control functions (NACF)". NOTE 2 – For NGN IPTV architectures, "resource control functional block" is replaced by "resource and admission control functions (RACF)". NOTE 3 – For NGN IMS IPTV architecture, "IPTV service control functional block" is replaced by "core IMS functions". NOTE 4 – For NGN IMS IPTV architecture, "control client functional block" is replaced by "session client functional block".

Figure 10-4 – Detailed IPTV functional architecture

25 Rec. ITU-T Y.1910 (09/2008)

10.3.1 Application functions

10.3.1.1 IPTV application functions The IPTV application functions allow the IPTV terminal functions to select and purchase the content if desired.

When receiving requests from IPTV terminal functions, the IPTV application functions perform application authorization and execution of IPTV service logic based on user profile, content metadata and other information retrieved from relevant entities. The IPTV application functions also communicate with content functions to prepare the delivery of media content to IPTV terminal functions.

Application functions make use of a set of underlying support functions that provide common facilities, for example, content delivery functions and service control functions. These functions are built from functional blocks, for example, the unicast delivery functional block.

An end-user can optionally have access to IPTV services from different service providers and depending on the services to which the end-user is subscribed, the end-user can optionally select applications from the same or a different service provider.

10.3.1.1.1 Service and application discovery and selection functional block The service and application discovery and selection (SADS) functional block provides for the discovery and selection of IPTV services and applications. This can include the discovery and selection of services from multiple service providers.

The ordering of service selection and application selection is out of the scope of this Recommendation. Clause I.1.5 provides an example of high level procedural flows for initialization of IPTV application access.

The SADS functional block generates and provides the service discovery information to the SADS client functional block. The service discovery information consists of one or more entry points to service selection. The entry points can optionally be in the form of a URL. Service discovery can optionally be performed using the IPTV service control functions.

The SADS functional block generates and provides the description information about the available applications, for example, linear TV and video on demand, to the SADS client functional block. The SADS client functional block presents this information to the end user for browsing and selection. The SADS functional block receives metadata information about services and applications from the metadata processing functional block.

10.3.1.1.2 On-demand application functional block The on-demand application functional block performs session management, service authorization, presentation of the content metadata and execution of the service logic for on-demand applications.

10.3.1.1.3 Linear TV application functional block The linear TV application functional block performs session management, service authorization, presentation of the content metadata and execution of the service logic for linear TV applications.

10.3.1.1.4 Other application functional blocks These functional blocks provide for the delivery and presentation of additional IPTV services and their content, e.g., games, distant learning.

All the IPTV application functions can optionally communicate with the application profile functional block to support the customization of IPTV services.

26 Rec. ITU-T Y.1910 (09/2008)

10.3.1.2 SCP functions The service and content protection (SCP) functions control the protection of the services and content. Content protection includes control of accessing the content and the protection of content using methods such as encryption. Service protection includes authentication and authorization to access the services and optionally protection of the services using methods such as encryption.

10.3.1.2.1 Content protection functional block The content protection functional block controls the protection of the content and is responsible for the management of the content rights and the keys used to encrypt and decrypt the content. It acquires the content rights (or content license, originated from the content provider) indication from the content preparation functions, generates and distributes this security information (rights object or keys) to the SCP client functions. It can optionally provide keys for content encryption. For example, when it receives a request for security information from IPTV terminal functions, it interacts with the application profile functional block for user-related security subscription information (e.g., time limited, whether fast forward/fast rewind are allowed), generates the rights object and delivers it to the IPTV terminal functions.

It also provides keys for service and content protection to IPTV application functions, which then deliver the keys to relevant functions, e.g., IPTV terminal functions and the content encryption function.

10.3.1.2.2 Service protection functional block The service protection functional block controls the protection of services. Service protection includes authentication and authorization of access to services and the protection of the services using methods such as encryption.

10.3.1.3 Application profile functional block See clause 9.2.2 for the relevant information associated with the application profile functional block.

10.3.1.4 Application provisioning functional block The application provisioning functional block manages the life-cycle of IPTV applications, e.g., adding or withdrawing them from service.

10.3.1.5 Content preparation functions The content preparation functions are comprised of content management, metadata processing, content processing control and content pre-processing functional blocks. These functional blocks may be used to control the preparation and/or combination of the content, as delivered by the content owner(s), into the required delivery format.

The content preparation functions may be subject to commercial agreements with content owners, note that not all contents are subject to the functions described below: • The metadata and rights information are delivered to the metadata processing functional

block. Content can optionally be watermarked, transcoded and encrypted by the content pre-processing functional block before being delivered to content delivery functions. The programme related metadata is delivered to IPTV application functions. If the original content from the content owner is modified or transcoded in any way, it may be necessary to also edit the programme-related metadata.

27 Rec. ITU-T Y.1910 (09/2008)

10.3.1.5.1 Content management functional block The content management functional block manages the life-cycle of the content in compliance with commercial agreements with the content owner. This management function can optionally be triggered by requests from the IPTV application functions. The content management functional block directs the other content preparation functions to prepare the content, e.g., to perform packaging, scheduling or transcoding.

10.3.1.5.2 Metadata processing functional block The metadata processing functional block obtains, manages and processes the programme-related metadata from the metadata sources, via the content pre-processing functional block, and provides it to the IPTV application functions. The metadata can optionally include title, brief introduction and content-tracing information (such as watermark), etc., from the content provider, as well as price, time schedule, etc., from the service provider.

10.3.1.5.3 Content processing control functional block The content processing control functional block controls transcoding and other functions such as tracing, packaging, advertising-insertion into streams, format conversion, resolution conversion, editing, etc. It controls the content pre-processing functions within content preparation and the content processing functions within content delivery functions.

10.3.1.5.4 Content pre-processing functional block The content pre-processing functional block performs all or some of the following functions: • Transcoding: In order to achieve bandwidth efficiency, content encoded in one compression

format is recommended to be encoded into a more efficient format, e.g., content encoding based on [b-ITU-T H.262] as opposed to content encoding based on [b-ITU-T H.264].

• Content packaging: Content packaging is the selection and combination of multiple items of content into a single item of content for delivery (e.g., packaging a movie with different subtitles).

• Content scheduling: Content scheduling is the provision of timing information for advertising-insertion or for the scheduling of content delivery.

• Content aggregation: Aggregation of content and metadata delivered by the content provider functions.

• Content encryption: Encryption of the content under the control of the content protection functional block.

• Content tracing: Conditioning for content tracing watermark embedding and creation of content tracing metadata.

• Other functions such as advertising-insertion, format conversion, resolution conversion, editing, etc.

10.3.2 Application client functions

10.3.2.1 Service and application discovery and selection client functional block The SADS client functional block provides for the end user's discovery and selection of IPTV services and applications.

28 Rec. ITU-T Y.1910 (09/2008)

10.3.2.2 On-demand client functional block The on-demand client functional block interacts with the on-demand application functional block to perform session management, service authorization, presentation of the content metadata and execution of the service logic for the on-demand applications.

10.3.2.3 Linear TV client functional block The linear TV client functional block interacts with the linear TV application functional block to perform session management, service authorization, presentation of the content metadata and execution of the service logic for the linear TV applications.

10.3.2.4 Other client functional blocks These functional blocks interact with the other application functional blocks for the delivery and presentation of additional IPTV services and their content, e.g., games, distant learning.

10.3.2.5 Service and content protection client functions

10.3.2.5.1 Content protection client functional block The content protection client functional block performs integrity checking, usage rights verification, content decryption and content tracing.

10.3.2.5.2 Service protection client functional block The service protection client functional block performs the authentication and authorization of access to services and, optionally, protection of the services using methods such as encryption.

10.3.3 Content delivery functions The following clauses describe decomposition of the content delivery functions into their constituent functional blocks (see Figure 10-4). The detailed functional architecture of content delivery functions applies to all three architectural approaches, and extends the IPTV functional architecture to include the detailed functional blocks that relate to content delivery functions and their relationship to the network functions. The details for unicast delivery and multicast delivery are considered.

10.3.3.1 Content distribution and location control functions The content distribution and location control functions (CD&LCF) control the content delivery and storage functions to optimize content distribution, selection and delivery of content to the IPTV terminal functions. If there are many instances of content distribution and location control functions, one instance must be chosen according to some criteria such as location, load status of content distribution and location control functions to process the request from content preparation functions or the IPTV service control functional block.

The content distribution and location control functions (CD&LCF) are comprised of two functional blocks: distribution control functional block and location control functional block.

10.3.3.1.1 Distribution control functional block The distribution control functional block coordinates the delivery and storage resources of content delivery and storage functions and establishes the optimal distribution policy for distributing content from content preparation functions to content delivery and storage functions. It also controls the distribution of content among the instances of content delivery and storage functions.

The distribution policy for content distributed as files or streams can optionally be different.

29 Rec. ITU-T Y.1910 (09/2008)

The distribution control functional block uses and maintains the distribution information about how the content is distributed among the instances of content delivery and storage functions. The distribution control functional block can optionally use the information obtained from the location control functional block to optimize the distribution policy. The distribution control functional block can optionally use information such as load status of content delivery and storage functions to optimize the distribution policy.

10.3.3.1.2 Location control functional block The location control functional block is used to process requests from the IPTV service control functional block or IPTV application functions to select a suitable content delivery and storage functions which can provide the required content. Then the selected content delivery and storage functions can deliver the content to the content delivery client functions. The selection criteria include the distribution information and load status of content delivery and storage functions, the terminal information, e.g., terminal location and capability, and other possible criteria. The IPTV service control functional block or IPTV application functions then request the identified content delivery and storage functions to allocate resources for content delivery.

The location control functional block resolves the application information, such as logical content identifier, into the content location information, such as the address of the content delivery and storage functions which can provide the requested content.

In the case where multicast is used, the location control functional block can optionally: • manage and allocate multicast network parameters (e.g., multicast address); • associate and maintain the mapping between logical channel identifiers and multicast

network parameters; • provide mapping, explained in the previous bullet, to IPTV application functions or IPTV

service control functional block when requested.

10.3.3.2 Content delivery and storage functions The content delivery and storage functions are described in clause 9.4.2. The detailed functional blocks contained in these functions are described below.

10.3.3.2.1 Content delivery control functional block The content delivery control functional block handles control functions related to the content delivery and storage functions, such as control of the media resources, and handling of recoding commands, such as for video cassette recorders (VCRs).

10.3.3.2.2 Unicast delivery functional block The unicast delivery functional block is responsible for streaming and delivering (e.g., via RTP over UDP) content streams to the content delivery client functions via the network functions based on the use of the unicast protocols and mechanisms.

It reports status information to content distribution and location control functions (e.g., reporting on an established IPTV media session).

It can optionally provide other functions, such as file downloading and uploading to and from the content delivery client functions and embedding of content tracing information.

30 Rec. ITU-T Y.1910 (09/2008)

10.3.3.2.3 Multicast delivery functional block The multicast delivery functional block is responsible for streaming and delivering (e.g., via RTP over UDP) content streams to the content delivery client functions via the network functions based on the use of the multicast protocols and mechanisms.

10.3.3.2.4 Cache and storage functional block The cache and storage functional block is responsible for caching the content, e.g., in order to support time-shifted linear TV. It is also responsible for storing the content, e.g., in order to support VoD or other IPTV services.

10.3.3.2.5 Distribution functional block The distribution functional block receives the content from the content preparation functions. It distributes the content, which includes live streams or files, residing among the separate instances of content delivery and storage functions.

10.3.3.2.6 Content processing functional block The content processing functional block processes the content under the control of the content processing control functional block. The main functionalities are: • transcoding; • other functions, such as watermarking, advertising-insertion into streams, format

conversion, resolution conversion, editing, etc.; • encryption.

10.3.3.2.7 Error recovery functional block The content delivery functions can optionally include an error recovery functional block. This functional block serves to improve reliability in the case where IPTV network functions cannot provide sufficient QoS. The error recovery functional block generates additional information for a content stream, either proactively or on request, such that the error recovery client functional block in the content delivery client functions can recover the content.

The error recovery functional block relies on other content delivery functions to deliver the additionally generated information.

The error recovery functional block relies on the availability of an error recovery client functional block in the content delivery client functions. The error recovery functional block can optionally be realized by forward error correction (FEC) or by retransmission.

10.3.3.3 Content delivery client functions The content delivery client functions are responsible for the content reception in the IPTV terminal functions.

10.3.3.3.1 Multicast content delivery client functional block The multicast content delivery client functional block receives the content from the multicast delivery functional block within the content delivery and storage functions. This functional block communicates with the multicast control point functional block for the selection of the multicast stream.

10.3.3.3.2 Unicast content delivery client functional block The unicast content delivery client functional block receives the content from the unicast delivery functional block within the content delivery and storage functions. This functional block

31 Rec. ITU-T Y.1910 (09/2008)

communicates with the content delivery control functional block within the content delivery and storage functions for the control of the unicast stream.

10.3.3.3.3 Error recovery client functional block The content delivery client functions can optionally include an error recovery client functional block. This functional block performs error recovery on the content streams in conjunction with the error recovery functional block within the content delivery functions.

10.3.4 Network functions The network functions are described in clause 9.5. The detailed functional blocks contained in these functions are described below. Multicast control point functional blocks and multicast replication functional blocks can optionally exist in access network functions, edge function, or core transport functions.

10.3.4.1 Multicast transport functions

10.3.4.1.1 Multicast control point functional block The multicast control point functional block is responsible for the selection of the individual multicast streams to be delivered, over the access network, to the IPTV end-user functions. The request for a multicast stream can optionally be authorized before it is accepted.

10.3.4.1.2 Multicast replication functional block The multicast replication functional block is responsible for replicating multicast streams from a multicast delivery functional block to all the instances of the multicast control point functional blocks.

10.3.4.2 Unicast transport functions The unicast transport functions are responsible for the transport of unicast content streams from the unicast delivery functional block to the end-user functions.

10.3.5 Content provider functions The content provider functions provide a number of different types of source to the content preparation functions, e.g., content protection metadata sources, metadata sources and content sources. The physical interfaces and content formats can optionally be different depending on the type of the source. It can optionally include functions for access control based on the rating of the content.

10.3.5.1 Content protection metadata sources Content protection metadata defines the usage rules and rights for protected IPTV content.

10.3.5.2 Metadata sources A metadata source is an entity that provides content provider metadata associated with the IPTV content.

10.3.5.3 Content sources A content source is an entity that provides IPTV content.

32 Rec. ITU-T Y.1910 (09/2008)

10.4 Interworking

10.4.1 Interworking between IPTV architectures IPTV services can optionally be supported by either non-NGN or by NGN-based architectures, using either non-IMS or IMS-oriented approaches. Interworking between these various architectures can be achieved by means of interworking functions or interworking gateways, as shown in Figure 10-5.

Y.1910(08)_F10-5

Service controlfunctions

Application functions

Content deliveryfunctions

End-userfunctions

Network functions

IPTV architecture 1

Interworkinggateway

Service controlfunctions

Application functions

Content deliveryfunctions

End-userfunctions

Network functions

IPTV architecture 2

Figure 10-5 – Interworking between IPTV architectures

The detailed interworking functions required within the interworking gateway depend on whether the interworking is desired to be carried out at one or more layers, and the specifics of the service provided as well as the detailed protocols used by the non-IMS and IMS-based IPTV domains. Consequently, the details of these interworking (IW) functions are for further study. Here it is necessary to establish that the concept of IW functions/gateways can be used to enable interworking between the IPTV services provided by any of the three IPTV architectures described in this Recommendation.

10.4.2 Third party application interworking The third party application gateway functional block is responsible for the support of third party application functions as shown in Figure 10-6.

33 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F10-6





Content preparationfunctions

Third partyapplication gateway

functional block

Third partyapplicationfunctions

Contentand metadata

sources



Authentication and IPallocation functional block


block


block

Content distribution andlocation control functions


Content delivery andstorage functions





functional block Access network functions



Network functions

Delivery protocols


Content andcontrol

Transportfunctions

Figure 10-6 – Third party application gateway functional block in IPTV architecture

34 Rec. ITU-T Y.1910 (09/2008)

Third party application functions invoke application interfaces to make use of IPTV functionality. The reference point between the third party application gateway functional block and third party application functions is intended to support the development of third party applications.

Third party application gateway functional block The third party application gateway functional block provides a controlled interface to enable third party application functions to utilize the IPTV-related capabilities and resources. The functions of the third party application gateway functional block are: • Policy control. • Access to user profiles. • Access to IPTV presence and status information (e.g., the requested service status, channel

currently accessed, content currently accessed). • Content play control. • Access to the status and position within a content stream. • Translation of protocols between the IPTV service control functional block and third party

applications in cases where the protocols adopted by the two sides are different.

11 Reference points Figures 11-1, 11-2 and 11-3, respectively, identify the IPTV reference points for the non-NGN, NGN non-IMS and NGN IMS architectures.

Appendices I and II add informative complements to the reference point descriptions of this clause.

35 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F11-1




Authentication and IP allocation functional block


Content distribution and location control functionsService control functions Content delivery functions





Resource control functional block


Network functions

Multicasttransport functions



IPTV application functions

SADS functional block

IPTV application functional block

SCP functions

Location control functional block


Distribution control functional block

Cache/storage functional block Distribution functional block


Error recovery functional block Content processing functional block

Unicast delivery functional block Multicast delivery functional block




SADS clientfunctional block

IPTV applicationclient functional

block

SCP clientfunctions



block


functional block


functional block


functional block

E0

E1

T1

D1

E2

E3

E4

E5

E6

A1 A2

A3

A4A5

A6

M1

C1C2C3

S1

E7

H1

H2

H3

R1

NOTE – The IPTV application functional block at any instance can be any of the following:

• on-demand application functional block as defined in clause 10.3.1.1.2: • linear TV application functional block as defined in clause 10.3.1.1.3; or • other application functional blocks as defined in clause 10.3.1.1.4.

Figure 11-1 – Reference points of non-NGN IPTV architecture

36 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F11-2




Network attachment control functions (NACF)


NGN service stratum functions Content delivery functions





Resource and admission control functions (RACF)







IPTV application functional block

SCP functions













block

SCP clientfunctions



block


functional block


functional block


functional block

E0

E1

T1

D1

E2

E3

E4

E5

E6

A1 A2

A3

A4A5

A6

M1

C1C2

C3

S1

E7

H1

H2

H3

R1



Service support functions


Control functions

Transportfunctions

NOTE – The IPTV application functional block at any instance can be any of the following: • on-demand application functional block as defined in clause 10.3.1.1.2; • linear TV application functional block as defined in clause 10.3.1.1.3; or • other application functional blocks as defined in clause 10.3.1.1.4.

Figure 11-2 – Reference points of NGN non-IMS IPTV architecture

37 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_F11-3




Network attachment control functions (NACF)







Resource and admission control functions (RACF)





SCP functions













block

SCP clientfunctions

Session client functional block


block


functional block


functional block


functional block

E0

E1

T1

D1

E2

E3

E4

E5

E6

A3

A4A5

A6

M1

C1C2

C3

S1

E7

H1

H2

H3

R1


Core IMSfunctions

Service support functions


Control functions

A1 A2



IPTV application functional blockA0

Transportfunctions

NOTE – The IPTV application functional block at any instance can be any of the following: • on-demand application functional block as defined in clause 10.3.1.1.2; • linear TV application functional block as defined in clause 10.3.1.1.3; or • other application functional blocks as defined in clause 10.3.1.1.4.

Figure 11-3 – Reference points of NGN IMS IPTV architecture

38 Rec. ITU-T Y.1910 (09/2008)

11.1 Reference points with characteristics common to all three IPTV architectures The reference points identified in Figures 11-1, 11-2 and 11-3, common to all three IPTV architectures, are discussed below.

11.1.1 Reference point A2 The A2 reference point is between the IPTV applications functional block and content distribution and location control functions (CD&LCF).

This reference point is used by the IPTV applications functional block to request service parameters from CD&LCF.

For a linear TV application, the A2 reference point is used by the corresponding IPTV application functional block to request multicast network parameters, e.g., multicast address. For an on-demand application, the A2 reference point is used by the corresponding on-demand application functional block to request the CD&LCF to identify a suitable CD&SF for content delivery.

11.1.2 Reference point A3 The A3 reference point is between the IPTV application functional block and content preparation functions.

This reference point is used to transmit the metadata stored in content preparation functions to the IPTV application functional block.

11.1.3 Reference point A4 The A4 reference point is between the SADS functional block and the application profile functional block.

This reference point is used by the SADS functional block to retrieve application profiles. The application profile can optionally include end-user subscription information, e.g., when there is a need for the SADS functional block to obtain personalized profiles.

11.1.4 Reference point A5 The A5 reference point is between the IPTV application functional block and the application profile functional block.

This reference point is used by the IPTV application functional block to retrieve application profiles. The application profile can optionally include end-user subscription information, e.g., when there is a need for the IPTV application functional block to obtain personalized application profiles.

11.1.5 Reference point A6 The A6 reference point is between the IPTV application functional block and SCP functions.

This reference point is used for transferring keys related to service and content protection information from SCP functions to the IPTV application functional block.

11.1.6 Reference point C1 The C1 reference point is between the content preparation functions and content distribution and location control functions (CD&LCF).

This reference point is used to facilitate content preparation functions to configure policies such as content distribution rules, selection criteria, etc., in the CD&LCF.

39 Rec. ITU-T Y.1910 (09/2008)

11.1.7 Reference point C2 The C2 reference point is between content preparation functions and content delivery and storage functions (CD&SF).

This reference point is used to transfer content from content preparation functions to CD&SF.

11.1.8 Reference point C3 The C3 reference point is between content preparation functions and SCP functions.

This reference point is used by the SCP functions to acquire the content rights or licenses from the content preparation functions. SCP functions can optionally also provide generated keys to content preparation functions.

11.1.9 Reference point E0 The E0 reference point is between the ITF SADS client functional block and the SADS functional block.

This reference point is used by the ITF to discover and select IPTV services and applications. NOTE – In the NGN IMS-based IPTV architecture, use of the E0 reference point may be limited to service selection, since service discovery can optionally be performed via the IMS core using the E3 and A0 reference points.

11.1.10 Reference point E1 The E1 reference point is between the ITF application client functional block and IPTV application functional block.

This reference point is used by the ITF to support service and application configuration.

11.1.11 Reference point E2 The E2 reference point is between SCP client functions and SCP functions.

This reference point is used for delivering security information (e.g., rights object or keys) from SCP functions to SCP client functions.

11.1.12 Reference point E4 The E4 reference point is between error recovery functional block and error recovery client functional block.

This reference point is used to exchange messages for requesting and delivering error recovery information, for example FEC repair data or retransmission data.

11.1.13 Reference point E5 The E5 reference point is between the multicast content delivery client functional block and the multicast control point functional block.

This reference point is used to exchange messages for joining multicast channels, e.g., IGMP messages.

11.1.14 Reference point E6 The E6 reference point is between the unicast content delivery client functional block and the content delivery control functional block. This reference point is used to exchange content control messages, e.g., video recording commands.

40 Rec. ITU-T Y.1910 (09/2008)

NOTE – The information exchanged between the unicast content delivery client functional block and the content delivery control functional block can optionally be transferred via the IPTV service control functions, e.g., in the case where the IPTV service control functions proxy all requests between the unicast content delivery client functional block and the content delivery control functional block.

11.1.15 Reference point E7 The E7 reference point is between content delivery client functions and the delivery network gateway functional block. This reference point is used to deliver control messages and content streams.

11.1.16 Reference point D1 The D1 reference point is between content distribution and location control function (CD&LCF) and content delivery and storage functions (CD&SF).

This reference point is used by the CD&LCF to get status information from the CD&SF, such as load status, the contents catalogue on each CD&SF, etc.

11.1.17 Reference point H2 The H2 reference point is between the multicast replication functional block and delivery network gateway functional block.

This reference point provides multicast-based IP connectivity between the delivery network gateway functional block and access network functions in order to deliver control messages and content streams.

11.1.18 Reference point H3 The H3 reference point is between unicast transport functions and delivery network gateway functional block.

This reference point provides unicast-based IP connectivity between the delivery network gateway functional block and access network functions in order to deliver control messages and content streams.

11.1.19 Reference point M1 The M1 reference point is between SCP functions and the application profile functional block.

This reference point is used by SCP functions to get security-related information from the application profile functional block.

11.1.20 Reference point Mc The Mc reference point is between the multicast delivery functional block and multicast control point functional block.

This reference point is used to pass information to allow for the dynamic computation, establishment and maintenance of multicast trees.

11.1.21 Reference point Md The Md reference point is between the multicast delivery functional block and the multicast replication functional block.

This reference point is used by the CD&SF to deliver content streams in multicast mode.

41 Rec. ITU-T Y.1910 (09/2008)

11.1.22 Reference point Ud The Ud reference point is between the unicast delivery functional block and the unicast transport functions.

This reference point is used by the CD&SF to deliver content streams in unicast mode.

11.2 Reference points with characteristics specific to non-NGN IPTV architecture The reference points below are specific to the non-NGN IPTV architecture which is depicted in Figure 11-1.

11.2.1 Reference point A1 The A1 reference point is between the IPTV application functional block and the IPTV service control functional block.

This reference point is used for: • forwarding service signalling information between the IPTV service control functional

block and the IPTV application functional block; • forwarding signalling information between the IPTV application functional block and other

functions, such as the ITF, CD&LCF.

Service requests from the ITF are forwarded to the appropriate IPTV application functional block, and service responses, including service parameters, are sent from the corresponding IPTV application functional block and forwarded to the ITF via the A1 reference point.

11.2.2 Reference point E3 The E3 reference point is between the control client functional block and the IPTV service control functional block.

This reference point is used to exchange session signalling information, e.g., session establishment, modification and termination. It can optionally be used to exchange: – content control messages, such as content recording commands; – service and application discovery information.

11.2.3 Reference point H1 The H1 reference point is between the delivery network gateway functional block and the authentication and IP allocation functional block.

This reference point is used to perform authentication, and obtain necessary network parameters, e.g., IP address, etc., when the ITF within end-user functions attaches to the network.

11.2.4 Reference point R1 The R1 reference point is between the resource control functional block and the network transport functions (e.g., access network functions).

This reference point is used by the resource control functional block to control network resources within the transport functions.

11.2.5 Reference point S1 The S1 reference point is between the IPTV service control functional block and the CD&LCF.

This reference point is used to forward the service signalling messages, e.g., service requests, content resource requests, between the ITF/IPTV application functions and the CD&LCF.

42 Rec. ITU-T Y.1910 (09/2008)

11.2.6 Reference point S2 The S2 reference point is between the IPTV service control functional block and the service user profile functional block.

This reference point is used by the IPTV service control functional block to access service user profiles.

The service user profile includes end-user information, e.g., end-user identity, security information, etc., and can optionally include a service user profile specific to an IPTV application.

11.2.7 Reference point S3 The S3 reference point is between the IPTV service control functional block and the resource control functional block.

This reference point is used by the IPTV service control functional block for requesting control of network resources.

11.2.8 Reference point S4 The S4 reference point is between the IPTV service control functional block and the authentication and IP allocation functional block.

This reference point is used by the IPTV service control functional block to get information from the authentication and IP allocation functional block such as the ITF location.

11.2.9 Reference point S5 The S5 reference point is between the IPTV service control functional block and the content delivery control functional block.

This reference point is used to exchange messages for session management, e.g., session establishment, modification, or termination.

It can optionally be used to exchange content control messages, e.g., content recording commands.

11.2.10 Reference point T1 The T1 reference point is between the authentication and IP allocation functional block and the access network functions.

This reference point is used for management of network configuration parameters as well as authentication of data.

11.3 Reference points with characteristics specific to NGN non-IMS IPTV architecture The reference points below are specific to NGN non-IMS IPTV architecture which is depicted in Figure 11.2.

11.3.1 Reference point A1 The A1 reference point is the same as the A1 reference point in the non-NGN architecture (see clause 11.2.1).

11.3.2 Reference point E3 The E3 reference point is the same as the E3 reference point in the non-NGN architecture (see clause 11.2.2).

43 Rec. ITU-T Y.1910 (09/2008)

11.3.3 Reference point H1 The H1 reference point is between the delivery network gateway functional block and NACF.

This reference point is used to perform authentication, and get necessary network parameters, e.g., IP address, when the ITF within the end-user functions attaches to the network.

11.3.4 Reference point R1 The R1 reference point is between RACF and the transport functions. The R1 reference point corresponds to the Rw reference point in [ITU-T Y.2111].

11.3.5 Reference point S1 The S1 reference point is the same as the S1 reference point in the non-NGN architecture (see clause 11.2.5).


11.3.7 Reference point S3 The S3 reference point is between the IPTV service control functional block and RACF.

The S3 reference point corresponds to the Rs reference point in [ITU-T Y.2111].

11.3.8 Reference point S4 The S4 reference point is between the IPTV service control functional block and NACF.

The S4 reference point corresponds to the S-TC1 reference point in [ITU-T Y.2014].


11.3.10 Reference point T1 The T1 reference point is between NACF and the access network functions.

The T1 reference point corresponds to the TC-T1 reference point in [ITU-T Y.2014].

11.4 Reference Points specific to NGN IMS IPTV Architecture The reference points below are specific to NGN IMS IPTV architecture which is depicted in Figure 11-3.

11.4.1 Reference point A0 The A0 reference point is between the SADS functional block and core IMS functions.

This reference point can optionally be used for exchanging service and application discovery information towards the ITF. This exchange of information can be performed in push mode or pull mode. • Push mode: the SADS functional block actively sends the service and application discovery

information to the ITF. • Pull mode: the ITF actively requests the service and application discovery information from

the SADS functional block.

44 Rec. ITU-T Y.1910 (09/2008)

This reference point corresponds to the ISC reference point referred to in [ITU-T Y.2021].

11.4.2 Reference point A1 The A1 reference point is between the IPTV application functional block and the core IMS functions.

This reference point is used for: • forwarding service signalling information between the core IMS and IPTV application

functional block; • forwarding signalling information between the IPTV application functional block and other

functions, such as the ITF, CD&LCF.

Service requests from the ITF are forwarded to the appropriate IPTV application and service responses, including service parameters, are sent from the IPTV application functions and forwarded to the ITF via this reference point.

This reference point corresponds to the ISC reference point defined in [ITU-T Y.2021].

11.4.3 Reference point E3 The E3 reference point is between the session client functional block and the core IMS functions.

This reference point is used by the session client functional block to initiate a service request to the IPTV application functions via the core IMS functions, to identify and prepare for the connection to the content delivery functions, e.g., request for suitable content delivery and storage functions in a VoD case, and request for network parameters in a linear TV case, etc. It can optionally be used for exchanging service and application discovery information.

This reference point corresponds to the Gm reference point defined in [ITU-T Y.2021].

11.4.4 Reference point H1 The H1 reference point is the same as the H1 reference point in the NGN non-IMS architecture (see clause 11.3.3).

11.4.5 Reference point R1 The R1 reference point is between the RACF and network transport functions. This reference point corresponds to the Rw reference point in [ITU-T Y.2111]. NOTE – This reference point is the same as the R1 reference point in the NGN non-IMS architecture (see clause 11.3.4).

11.4.6 Reference point S1 The S1 reference point is between the core IMS functions and CD&LCF.

This reference point is used to forward the service signalling messages, e.g., service requests, content resource requests, between the ITF/IPTV application functions and CD&LCF.

11.4.7 Reference point S2 The S2 reference point is between the core IMS functions and service user profile functional block.

This reference point is used by core IMS functions to store and get service user profiles. The profile includes end-user information, e.g., end-user identity, security information, etc., as well as a service profile specific to an IPTV application.

This reference point corresponds to the Cx reference point defined in [ITU-T Y.2021].

45 Rec. ITU-T Y.1910 (09/2008)

11.4.8 Reference point S3 The S3 reference point is between the core IMS functions and RACF.

This reference point is used by the core IMS functions to request RACF for the control of transport resources. This reference point corresponds to the Rs reference point as defined in [ITU-T Y.2111].

11.4.9 Reference point S4 The S4 reference point is between core IMS functions and NACF.

This reference point is used by core IMS functions to interact with NACF in order to retrieve information related to the IP connectivity access information (e.g., physical location of the ITF).

This reference point corresponds to the S-TC1 reference point as defined in [ITU-T Y.2012].

11.4.10 Reference point S5 The S5 reference point is between the core IMS functions and the content delivery control functional block.

This reference point is used to exchange messages for session management, e.g., session establishment, modification or termination.

It can optionally be used to exchange content control messages, e.g., content recording commands.

11.4.11 Reference point T1 The T1 reference point is between the NACF and access network functions. This reference point corresponds to the TC-T1 reference point as defined in [ITU-T Y.2012]. NOTE – This reference point is the same as the T1 reference point in NGN non-IMS architecture (see clause 11.3.10).

46 Rec. ITU-T Y.1910 (09/2008)

Annex A

Relationship between IPTV and NGN architectures (This annex forms an integral part of this Recommendation)

A.1 IPTV-related components in the NGN architecture It is useful to relate the IPTV architecture to the general NGN framework architecture and other networks to clarify the similarities and differences, as well as provide a reference for the more detailed description of IPTV-specific components. The "NGN-based" architecture indicates that the IPTV architecture is in accordance with NGN architecture as defined in [ITU-T Y.2012]. The NGN components described in [ITU-T Y.2012] are shown in Figure A.1.

As the non-NGN IPTV functional architecture mentioned in the scope and detailed in the main body of this Recommendation does not necessarily require NGN components, and uses conventional and/or legacy technology networks for delivery of IPTV services, Figure A.1 should not be construed as the only basis for providing IPTV services.

Y.1910(08)_FA.1

IPTV service component

Applications

S. userprofile

functionsOther NGN service

components

PSTN/ISDN emulationservice component

IP multimediaservice component

Resource and admissioncontrol functions

(RACF)

Network attachmentcontrol functions

(NACF)

T. userprofile

functions

Access networkfunctions


Legacyterminals

Customernetworks

Legacyterminals

NGNterminalsEnd-userfunctions

GW

GW

Service stratum

Oth

er n

etw

orks

Transport stratum

Edgefunctions

Servicecontrol

functions

Application support functions and service support functions

Figure A.1 – Transport and service configuration of the NGN

NOTE – In diagram A.1: service components are not purely service control but also comprise service delivery functions. For the purposes of adding support for IPTV, the diagram from [ITU-T Y.2012] is considered to have a service control function box that stops halfway into the underlying components, with another "service delivery functions" box covering the remaining space.

47 Rec. ITU-T Y.1910 (09/2008)

A.2 Functional mapping between NGN-based IPTV and NGN architectures The NGN-based IPTV architecture is defined in accordance with [ITU-T Y.2012] for providing IPTV services. Therefore, its functionalities have a corresponding relationship with the NGN architecture. Application functions in IPTV architecture can optionally be included in application support functions and service support functions of NGN shown in Figure A.1. Service control functions and content delivery functions can optionally be included in the IPTV service component of NGN of Figure A.1. Thus, application functions, service control functions and content delivery functions are included in the service stratum of the NGN architecture. NOTE – In Figure A.1 it is assumed that the IPTV service components contain both a service control and a service delivery part.

Table A.1 provides the relationships between the functions of NGN-based IPTV and NGN architectures.

Table A.1 – Functional mapping between NGN-based IPTV and NGN functional architectures

No. IPTV

functional architecture

NGN functional architecture Remarks

1 Network functions

Transport stratum These correspond to each other.

2 End-user functions

End-user functions These correspond to each other.

3 Management functions

Management functions These correspond to each other.

4 Service control functions

Service control functions (in service stratum)

IPTV service control functional block corresponds to NGN service control functions. However, NGN service control functions can optionally include other functionalities.

5 Content delivery functions

Allocation of content delivery functions to NGN is for further study

Content delivery functions can optionally reside outside the NGN in cases such as a third party service provider.

6 Application functions

Application support functions and service support functions (in service stratum)

Application functions can optionally reside outside the NGN in cases such as a third party service provider

NOTE – Content provider functions are out of scope and not included in this mapping table.

A.3 Application support functions and service support functions The application support functions and service support functions which are defined in [ITU-T Y.2012] include four functional entities: • application support functional entity (AS-FE); • application gateway functional entity (APL-GW-FE); • application service coordination manager functional entity (APL-SCM-FE) and; • service switching functional entity (SS-FE).

48 Rec. ITU-T Y.1910 (09/2008)

Among these functional entities, the AS-FE has the closest relationship with the application functions of the IPTV architecture. The guidelines for selecting functions as the AS-FE are as follows: • A function that is used in common in two or more applications is recommended to be

included in the AS-FE. • From the viewpoint of personal information and privacy protection, a function that handles

the user profile managed within NGN is recommended to be included in the AS-FE. • From the viewpoint of security, a function that handles the inside information of network,

such as network control signalling, is recommended to be included in the AS-FE. • A function that can be located in application support functions and service support

functions to provide an efficient service is recommended to be included in the AS-FE to improve QoE.

49 Rec. ITU-T Y.1910 (09/2008)

Appendix I

Procedural flows relating to IPTV services (This appendix does not form an integral part of this Recommendation)

The functional architecture in clause 10 describes the functions and functional blocks of the IPTV functional architecture. The following clauses describe the interactions between the functions and functional blocks by illustrating the related procedural flows. NOTE – These procedural flows are intended as illustrative examples of interactions between functional blocks and functions, and should not be taken as mandatory when implementing the IPTV functional architectures defined in this Recommendation.

I.1 High level flows The high level procedural flows describe the high level interactions between the functions in the IPTV architecture. In this description, the content delivery functions and service control functions are combined, represented as a single group of functions called "content delivery and service control functions", so that the different interaction between the application functions and these functions can be illustrated. Detailed breakdown of the functions, and their associated procedural flows, are described later.

In general, a transactional protocol is used between the ITF and the application functions, this protocol is used for the selection and, if required, purchase of content. A streaming control protocol is used between the ITF and the content delivery and service control functions to establish the delivery and control the content. A delivery protocol is used to carry the content from a delivery function to the ITF.

There are two main approaches to timing of the allocation resources: Tightly coupled: The delivery and network resources are allocated at the request of the application during the transactional phase of the service. They are released by a request from the application after viewing has been completed. This requires a session to be maintained with the transaction protocol. This approach is called "tightly coupled" as the application layer is tightly coupled to the control and delivery layer.

Loosely coupled: The delivery and network resources are allocated in response to the establishment of the streaming protocol session. They are released when this streaming protocol session is terminated. This approach is called "loosely coupled" as the application layer is only loosely coupled to the control and delivery layer.

The principal differences between tight and loose coupling of the application with the service control functions are the timing of the allocation of delivery and network resources. Tight coupling can optionally be more appropriate for the immediate consumption of content as delivery can be guaranteed. Loose coupling can optionally be more appropriate for delayed consumption of content as resources are not allocated until actually needed.

Although the event sequences for the tightly coupled content on-demand and loosely coupled content on-demand operations are different, the sequences of messages sent by the ITF are the same. The same is true for the two linear TV cases. This can optionally allow an ITF to interoperate with either style of application to service delivery and control operations.

50 Rec. ITU-T Y.1910 (09/2008)

NOTE – In cases where there is no clear distinction between the application functions and the content delivery and service control functions, the following figures may not accurately represent the procedural flows. For specific IMS-based procedural flows, refer to clause I.3.

I.1.1 High level procedural flows for loosely coupled content-on-demand The following procedural flows represent the high level sequence of flows for a content-on-demand application that uses the unicast content delivery functions where the application is loosely coupled to the service control functions.

Pre-conditions: It is assumed that provisioning, network attachment and service selection have been completed.

Y.1910(08)_FI-1

IPTVTF

Applicationfunctions Network functionsContent delivery and

service control functions

Request network resources

Allocate CD&SFcapabilities

Allocate networkresources

Connect

Consume (Service URL)Get current ITF location (Note)

Location (Note)

OK

Content flow

OK

Browser and select

OK (Service URL)

Establish authority

OK

OK

Play

Close

OK

Release CD&SFcapabilities

Release network resources

Release networkresources

OK

OK Can be triggered by abnormaltermination or timeout ofstreaming session

Disconnect

OK

Tran

sact

ion

prot

ocol

Stre

am c

ontro

l pro

toco

l

Sele

ctC

onsu

me:

Set

-up

Play

Con

sum

e: C

lose

NOTE – Optional procedure.

Figure I.1 – High level procedural flows for loosely coupled content-on-demand

51 Rec. ITU-T Y.1910 (09/2008)

1) IPTV terminal functions (ITF) connect to and interact with the application functions to select the content item that the end user wishes to receive.

2) The application functions connect to the content delivery and service control functions to establish the authority for the ITF to consume the content.

3) The application functions return the URL of the content delivery and service control functions and content item.

4) ITF connects to the content delivery and service control functions to request the delivery of the content item.

5) The content delivery and service control functions determine the location of the ITF, for example by querying the network control function. This procedure is not necessary in the case of a fixed network because the location is already known.

6) The content delivery and service control functions determine which delivery function has the requested content and can be connected to the ITF and allocate this delivery function.

7) The content delivery and service control functions request the allocation of the network resources needed to support the network path from the delivery function to the ITF.

8) The ITF issues a play request. 9) The content delivery and service control functions facilitate the content flow to the ITF. 10) At the end of the viewing session, the ITF closes the content flow. 11) The content delivery and service control functions release the delivery resources. 12) The content delivery and service control functions request the release of network resources. 13) The content delivery and service control functions confirm that the session is closed.

I.1.2 High level procedural flows for tightly coupled content-on-demand The following procedural flows represent the high-level sequence of flows for a content-on-demand application that uses the unicast content delivery functional block, where the application is tightly coupled to the service control functions.


52 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-2

IPTVTF






Connect

OK

OK

OK

Browser and select

Location (Note)

Establish authority and resourceGet current ITF location (Note)

OK

OK service (URL)

Play

OK

Content flow

Close

OK

Disconnect

Release authority and resource




OK

Consume (service URL)

Can be triggered by abnormaltermination or timeout oftransaction session

OKOK

Tran

sact

ion

prot

ocol

Stre

am c

ontro

l pro

toco

l

Sele

ctC

onsu

me:

Set

-up

Play

Con

sum

e: C

lose

Tran

sact

ion

prot

ocol


Figure I.2 – High level procedural flows for tightly coupled content-on-demand

1) The IPTV terminal function (ITF) interacts with the application functions to select the content item that the end user wishes to receive.

2) The application functions connect to the content delivery and service control functions to establish the authority for the ITF to consume the content and reserve the delivery and network resources.

3) The content delivery and service control functions determine the location of the ITF, for example by querying the network control functions. This procedure is not necessary in the case of a fixed network because the location is already known.

53 Rec. ITU-T Y.1910 (09/2008)

4) The content delivery and service control functions determine which content delivery function has the requested content and can optionally be connected to the ITF, and allocate this delivery function.

5) The content delivery and service control functions request the allocation of the network resources needed to support the network path from the content delivery functions to the ITF.

6) The application functions return the URL of the content delivery and service control functions and content item.

7) The ITF connects to the content delivery and service control functions to request the delivery of the content item.

8) The ITF issues a play request. 9) The content delivery and service control functions stream the content to the ITF. 10) At the end of the viewing session, the ITF closes the streaming session. 11) The ITF closes the transaction session with the application functions. 12) The application functions inform the content delivery and service control functions that the

session has ended. 13) The content delivery and service control functions release the delivery resources. 14) The content delivery and service control functions request the release of network resources.

I.1.3 High level procedural flows for loosely coupled linear TV The following procedural flows represent the high-level sequence of flows for a linear TV application that uses the multicast delivery functions where the application is loosely coupled to the service control functions.


54 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-3

IPTVTF





Connect

Consume (service URL)Get current ITF location (Note)

Location (Note)

OK

Content flow

OK

Browser and select

OK (service URL)

Establish authority

OK

OK

IGMP join

Close

OK



OK

Can be triggered by abnormaltermination or timeout ofstreaming session

Disconnect

OK

Tran

sact

ion

prot

ocol

Stre

am c

ontro

l pro

toco

l

Sele

ctC

onsu

me:

Set

-up

Play

Con

sum

e: C

lose


Figure I.3 – High level procedural flows for loosely coupled linear TV

1) The IPTV terminal function (ITF) connects to and interacts with the linear TV application to obtain the list of channels that the customer wishes to receive.

2) The application connects to the content delivery and service control functions to establish the authority for the ITF to consume the channels.

3) The application returns the URL of the content delivery and service control functions and the list of multicast addresses.

4) The ITF connects to the content delivery and service control functions to request the network resources for the reception of the channels.


6) The content delivery and service control functions request the allocation of the network resources needed to support the network path from the delivery function to the ITF.

7) The ITF issues a multicast group join request to receive the channel. 8) At the end of the viewing session, the ITF closes the streaming session.

55 Rec. ITU-T Y.1910 (09/2008)

9) The content delivery and service control functions request the release of network resources. 10) The content delivery and service control functions confirm that the session is closed.

I.1.4 High level procedural flows for tightly coupled linear TV The following procedural flows represent the high-level sequence of flows for a linear TV application that uses the multicast delivery functional block where the application is tightly coupled to the service control functions.


Y.1910(08)_FI-4

IPTVTF





Connect

OK

OK

Browser and select

Location (Note)

Establish authority and resourceGet current ITF location (Note)

OK

OK (service URL)

Content flow

Disconnect

Release authority and resource



OK

IGMP join

Can be triggered by abnormaltermination or timeout oftransaction session

OKOK

Tran

sact

ion

prot

ocol

Sele

ctC

onsu

me:

Set

-up

Play

Con

sum

e: C

lose

Tran

sact

ion

prot

ocol


Figure I.4 – High level procedural flows for tightly coupled linear TV

1) The IPTV terminal function (ITF) connects to and interacts with the linear TV application to obtain the list of channels that the customer wishes to receive.

2) The application connects to the content delivery and service control functions to establish the authority for the ITF to consume the channels and reserve the network resources.


56 Rec. ITU-T Y.1910 (09/2008)

4) The content delivery and service control functions request the allocation of the network resources needed to support the network path from the content delivery function to the ITF.

5) The application returns the URL of the content delivery and service control functions and the list of multicast addresses.

6) The ITF issues a multicast group join request to receive the channel. 7) At the end of the viewing session, the ITF closes the application session. 8) The application informs the content delivery and service control functions that the session

has ended. 9) The content delivery and service control functions request the release of network resources.

I.1.5 High level procedural flows for initialization of IPTV application access

Figure I.5 – High level procedural flow for initialization of IPTV application access

1) The user first selects a network provider and a network access mode, and the end-user functions execute the network attachment operation with the network functions.

2) After the user accesses the network, the service control functions provide the user the initial information of the available IPTV service providers, and the user selects an IPTV service provider. The network functions can optionally be involved in this procedure.

3) The service and application discovery and selection functional block finds available applications (such as linear TV, VoD, etc.), and provides these to the user for selection.

4) The user accesses the selected application.

57 Rec. ITU-T Y.1910 (09/2008)

I.1.6 High level procedural flows for content distribution

I.1.6.1 Procedural flows for file-based content distribution File-based content distribution is mainly used in VoD services.

The procedures above the dotted line of Figure I.6 refer to file-based content distribution from the content preparation functions to the content delivery and storage functions.

The procedures below the dotted line of Figure I.6 refer to file-based content distribution from content delivery and storage functions which already have received the required file-based content, and hence can distribute it to other content delivery and storage functions.

The procedures below the dotted line are intended for the case when efficiency can be enhanced for the content delivery.

Pre-conditions: It is assumed that content metadata and content protection rights information have been delivered from the content provider functions to the content preparation functions.

CD&SFContent Preparation Functions

CD&LCF CD&SF

4) Indicate file-based content is available for distribution

5) acknowledge file-basedcontent distribution

1) file-based content preparation

6) acknowledge file-basedcontent distribution

2) Indicates file-based content is available for distribution

3) enforces distribution policy and allocates resources

8) periodically request status related information

9) reply status related information

10) schedules content to CD&SF according to distribution policy

11) enable file-based content distributionfor (a) pull mode, (b) push mode

7) file-based media transfer, for (a) pull mode, (b) push mode

12) file-based content transfer among

CD&SF Instances

Figure I.6 – Procedural flows for file-based content distribution

58 Rec. ITU-T Y.1910 (09/2008)

1) File-based content preparation procedures include content aggregation, content management, metadata processing, content processing and content encryption, which can optionally be completed before file-based content is distributed.

2) Content preparation functions indicate file-based content is available for distribution to the CD&LCF.

3) CD&LCF enforces distribution policy and allocates resources (i.e., select suitable CD&SF to receive file-based content).

4) CD&LCF indicate to the CD&SF that file-based content is available for distribution. 5) CD&SF provides an acknowledgement to the CD&LCF that file-based content can be

distributed. 6) CD&LCF provides an acknowledgement to the content preparation functions that file-based

content can be distributed. 7) Content preparation functions proceed to transfer the file-based content to CD&SF.

a) The file-based content transport method can be PULL mode, i.e., the CD&SF downloads the file-based content initially from the content preparation functions.

b) The file-based content transport method can be PUSH mode, i.e., content preparation uploads the file-based content initiatively to CD&SF.

8) In order to maintain information such as file-based content distribution information, load status of CD&SF, the CD&LCF periodically send "status" request messages to the CD&SF.

9) The CD&SF returns status-related information back to the CD&LCF. 10) CD&LCF schedules content to CD&SF according to a distribution policy. 11) Enable file-based content distribution for (a) push mode, (b) pull mode. 12) File-based content is transferred among CD&SF instances.

I.1.6.2 Procedural flows for stream-based content distribution Stream-based content distribution is mainly used in linear TV and time-shifted linear TV.

Pre-conditions: It is assumed that content metadata and content protection rights information have been delivered from the content provider functions to the content preparation functions.

59 Rec. ITU-T Y.1910 (09/2008)

Content Preparation Functions

CD&LCF CD&SF

4) Indicates stream-based content

is available for distribution

1) stream-based content preparation

2) Indicates stream-based content

is available for distribution

3) enforces distribution policy and allocates resources

5) acknowledges stream-based

content distribution6) acknowledges stream-based

content distribution

7) stream-based content transfer

Figure I.7 – Stream-based content distribution flow

1) Stream-based content preparation procedures include content aggregation, content management, metadata processing, content processing and content encryption, which can optionally be completed before stream-based content is distributed.

2) Content preparation functions indicate stream-based content is available for distribution to the CD&LCF.

3) CD&LCF enforces distribution policy and allocates resources (i.e., select suitable CD&SF to receive stream-based content).

4) The CD&LCF indicates to the CD&SF that stream-based content is available for distribution.

5) The CD&SF provides an acknowledgement to the CD&LCF that stream-based content can be distributed.

6) The CD&LCF provides an acknowledgement to the content preparation functions that stream-based content can be distributed.

7) Content preparation functions proceed to transfer the stream-based content to CD&SF.

I.2 Procedural flows for IPTV services based on NGN non-IMS IPTV architectures The following clauses provide detailed descriptions of the procedural flows in the case of the NGN non-IMS IPTV architecture.

60 Rec. ITU-T Y.1910 (09/2008)

There are two ways in which the IPTV control and the content delivery functions interoperate: • Proxy: One approach is for IPTV service control functional block to proxy all requests

between the ITF and the content functions. In this way, IPTV control can request the allocation of delivery and network resources, track the progress of the streaming session and request the release of resources at the end of the session.

• Redirect: The other approach is for the IPTV service control functional block to request the allocation of delivery and network resources and then redirect the ITF to communicate directly with the actual content storage and delivery functions that have been allocated.

The proxy approach has the advantage that a single function, the IPTV service control functions, keeps track of the allocated resources. The redirect approach has the advantage that the ITF communicates directly with the content storage and delivery function, reducing latency and resource usage.

The redirect approach requires that the streaming control protocol can be redirected during session establishment. This is supported by most protocols, and if supported means that a single ITF implementation can communicate with ITPV services using either the proxy or the redirect method.

The following figures show the procedural flows for the four use-cases resulting from the combination of loose and tight coupling with proxy and redirect methods. In all cases, the content on-demand application is shown making use of the unicast content delivery functions.


I.2.1 Procedural flows for content on-demand with loose coupling and redirect The following procedural flows show the interaction between the ITF and the IPTV application functions, the IPTV service control functions and the content delivery functions. In these flows, the application functions and the IPTV service control functional block do not communicate with each other, and the IPTV service control functional block redirects the ITF to the allocated content storage and delivery functions.

61 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-8

Connect toapplication


Service authorization

OKOK

Browse andselect

Purchase content

Personalize

Content authorization and record purchase

OK

Establish content authority

OK

OK (service URL)

Consume (service URL) Contentauthorization

OKGet current ITF location (Note)

Location (Note)

Request CD&SF for content and location

OK (delivery URL)

Request network resources between endpoints


OKRedirect (delivery URL)

Consume (delivery URL)

Content authorization

OKOK

Play

OK

Media flow

Close (delivery URL)

OK

End


IPTVTF RACF

Applicationprofile

functionalblock

IPTVapplicationfunctions

IPTV servicecontrol

functionalblock

Serviceprofile

functionalblock

CD&LCF CD&SF NACF

Session end

Release network resources between endpoints


OK

Sele

ctCo

nsum

e: S

et-u

pCo

nsum

e: P

lay

Purc

hase

Cons

ume:

Clo

se

Tran

sact

ion

prot

ocol

Stre

am co

ntro

l pro

toco

l

Stre

am d

eliv

ery


Figure I.8 – On-demand procedural flows with loose coupling and redirect

62 Rec. ITU-T Y.1910 (09/2008)

1) The ITF runs the on-demand client which connects, using a transactional protocol, to the on-demand application to obtain the URL of the IPTV service control functional block with a reference to the content item that the customer wishes to receive. During this interaction, the application will authorize the ITF's connection, it can optionally use the application profile to personalize the service and it can optionally record the transaction and any associated purchase in the application profile. The application will establish, within the service profile, the authority for the ITF to subsequently consume the content.

2) The ITF connects to the IPTV service control functional block, using a session control protocol, and passes to it the reference for the content item to be consumed. The IPTV service control functional block authorizes the ITF's connection request against the authority that has been established.

3) The IPTV service control functional block determines the location of the IPTV device, for example by querying the NACF. It passes this information and the content reference to the unicast delivery control functional block so that the allocation of delivery resources can be requested. This procedure is not necessary in the case of a fixed network because the location is already known.

4) The content delivery control function determines which unicast delivery functional block has the requested content and can optionally be connected to the IPTV device. It queries, or maintains, the state of the unicast delivery functional block to identify one that has available capacity and allocates this to the ITF. It returns the URL of the physical server containing the allocated content item to the IPTV service control functional block.

5) The IPTV service control functional block requests the network resources needed to support the network path from the unicast delivery functional block to the IPTV device. The IPTV service control functional block returns the ITF a redirect command containing the URL of physical server and content item.

6) The ITF redirect its session control connection to the identified unicast delivery functional block to control and receive the content.

7) The unicast delivery functional block uses a delivery protocol to send the content to the ITF.

8) At the end of the viewing, the ITF terminates the streaming control session with the unicast delivery functional block.

9) The unicast delivery functional block informs the unicast delivery control function that the session has ended.

10) The unicast delivery control function releases the delivery resources and informs the IPTV control function that the session has ended.

11) The IPTV service control function requests the release of network resources that were allocated to the network path from the unicast delivery functional block to the ITF.

In the exception case where the ITF does not perform step 8, the unicast delivery functional block monitors the session and, if this fails, performs step 9. Steps 10 and 11 would also follow.

I.2.2 Procedural flows for content on-demand with loose coupling and proxy The following procedural flows show the interaction between the ITF, the IPTV application functions, the IPTV service control functions and the content delivery functions. In these flows, the application functions and the IPTV service control functional block do not communicate with each other and the IPTV service control functional block proxies the communication between the ITF and the allocated content storage and delivery function.

63 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-9



Validate connect

OKOK

Browse andselect

Purchase content

Personalize

Validate and record purchase

OK

Establish authority

OK

OK (service URL)

Consume (service URL)Validate

OKGet current ITF location (Note)

Location (Note)


OK (delivery URL)



OKOK

Play

OKOK

Media flow

Close

Close

OK

Request for releasing CD&SF capabilities


IPTVTF RACF

Applicationprofile

functionalblock


IPTV servicecontrol

functionalblock

Serviceprofile

functionalblock

CD&LCF CD&SF NACF

OK



OK

Sele

ctCo

nsum

e: S

et-u

pCo

nsum

e: P

lay

Purc

hase

Cons

ume:

Clo

se

Tran

sact

ion

prot

ocol

Stre

am co

ntro

l pro

toco

l

Stre

am d

eliv

ery

Play

OK


Figure I.9 – On-demand procedural flows with loose coupling and proxy

64 Rec. ITU-T Y.1910 (09/2008)

1) The ITF runs the on-demand client which connects, using a transactional protocol, to an on-demand application to obtain the URL of the IPTV service control functional block with a reference to the content item that the customer wishes to receive. During this interaction, that application will authorize the ITF's connection, it can optionally use the application profile to personalize the service, it can optionally record the transaction and any associated purchase in the application profile. The application will establish, within the service profile, the authority for the ITF to subsequently consume the content.

2) The ITF connects to the IPTV service control functional block, using a session control protocol, and passes to it the reference to the content item to be consumed. The IPTV service control functional block authorizes the ITF's connection request against the authority that has been established.

3) The IPTV service control functional block determines the location of the IPTV device, for example by querying the NACF. It passes this information and the content reference to the unicast delivery control function to request the allocation of delivery resources. This procedure is not necessary in the case of a fixed network because the location is already known.

4) The content delivery control function determines which unicast delivery functional block has the requested content and can optionally be connected to the IPTV device. It queries, or maintains, the state of the unicast delivery functional block to identify one that has free capacity and allocates this to the ITF. It returns the URL of the physical server containing the allocated content item to the IPTV service control functional block.

5) The IPTV service control functional block requests the network resources needed to support the network path from the unicast delivery functional block to the IPTV device.

6) The IPTV service control functional block starts to proxy the ITF's session control connection to the identified unicast delivery functional block to control and receive the content.


8) At the end of the viewing, the ITF terminates the streaming control session which the IPTV service control functional block proxies to the unicast delivery functional block.

9) The IPTV service control functions inform the unicast delivery control function that the session has ended.

10) The unicast delivery control function releases the CD&SF capabilities. 11) The IPTV service control function requests the release of network resources that were

allocated to the network path from the unicast delivery functional block to the ITF.

In the exception case where the ITF does not perform step 8, the IPTV service control functions monitor the session and, if this fails, terminate the connection to the unicast delivery functional block and perform step 9. Steps 10 and 11 would also follow.

I.2.3 Procedural flows for content on-demand with tight coupling and redirect The procedural flows show the interactions between the ITF, the IPTV application functions, the IPTV service control functional block and the content delivery functions. In these flows, the application communicates with the IPTV service control functional block to pre-allocate resources. As the delivery resources have already been allocated, the ITF communicates directly to the allocated content storage and delivery functions.

65 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-10


Allocate CD&SF

Validate connect

OKOK

Browse andselect

Purchase content

Personalize


OK

Establish authority

OK

SetupGet current ITF location (Note)

Location (Note)


OK (delivery URL)



OKOK (URL)

OK

Play

OK

Media flow

Close

OKEnd


IPTVTF RACF

Applicationprofile

functionalblock


IPTV servicecontrol

functionalblock

Serviceprofile

functionalblock

CD&LCF CD&SF NACF

Session end



OK

Sele

ctCo

nsum

e: S

et-u

pCo

nsum

e: P

lay

Purc

hase

Cons

ume:

Clo

se

Tran

sact

ion

prot

ocol

Stre

am c

ontro

l pro

toco

l

Stre

am d

eliv

ery

OK (URL)Consume (URL)

Validate

OK


Figure I.10 – Procedural flows for content on-demand with tight coupling and redirect

66 Rec. ITU-T Y.1910 (09/2008)

1) The ITF runs the on-demand client which connects, using a transactional protocol, to an on-demand application to obtain the URL of the IPTV service control functional block with a reference to the content item that the customer wishes to receive. During this interaction, that application will authorize the ITF's connection, it can optionally use the application profile to personalize the service, it can optionally record the transaction and any associated purchase in the application profile. The application will establish, within the service profile, the authority for the ITF to subsequently consume the content.

2) The application connects to the IPTV service control functional block passing it the reference to the content item to be consumed and the ITF.

3) The IPTV service control functional block determines the location of the ITF, for example by querying the NACF. It passes this information and the content reference to the unicast delivery control function to request the allocation of delivery resources. This procedure is not necessary in the case of a fixed network because the location is already known.

4) The content delivery control function determines which unicast delivery functional block has the requested content and can optionally be connected to the IPTV device. It queries, or maintains, the state of the unicast delivery functional block to identify one that has free capacity and allocates this to the ITF. It returns the URL of the physical server containing the allocated content item to the IPTV service control functional block.

5) The IPTV service control functional block requests the network resources needed to support the network path from the unicast delivery functional block to the IPTV device. The IPTV service control functional block returns to the application the URL of the physical server and content item, which in turn passes this to the ITF.

6) The ITF establishes the session control connection to the identified unicast delivery functional block to control and receive the content. The unicast delivery functional block authorizes this request by checking with the service profile.


8) At the end of the viewing, the ITF terminates the streaming control session with the unicast delivery functional block.

9) The ITF then terminates that connection to the application, which in turn informs the IPTV service control functions that the session has ended.

10) The IPTV service control functional block informs the unicast delivery control function that the session has ended so that it can release the delivery resources.

11) The IPTV service control function requests the release of network resources that were allocated to the network path from the unicast delivery functional block to the ITF.

In the exception case where the ITF does not perform step 9, the IPTV application functions monitor the session and, if this fails, terminate the session and notifie the IPTV control functional block. Steps 10 and 11 would also follow.

I.2.4 Procedural flows for content on-demand with tight coupling and proxy The following flow shows the interaction between the ITF, the IPTV application functions, the IPTV service control functions and the content delivery functions elements. In these flows, the application calls the IPTV service control functions to pre-allocate resources. The IPTV service control functions act as a proxy for the communication between the ITF and the allocated content storage and delivery function.

67 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-11


Allocate CD&SF

Validate connect

OKOK

Browse andselect

Purchase content

Personalize


OK

Establish authority

OK

SetupGet current ITF location (Note)

Location (Note)


OK (delivery URL)



OKOK (URL)

OK

PlayPlay

OK

OKMedia flow

CloseClose

OKRelease CD&SF

Release CD&SF

IPTVTF RACF

Applicationprofile

functionalblock


IPTV servicecontrol

functionalblock

Serviceprofile

functionalblock

CD&LCF CD&SF NACF

OK



OK

Sele

ctCo

nsum

e: S

et-u

pCo

nsum

e: P

lay

Purc

hase

Cons

ume:

Clo

se

Tran

sact

ion

prot

ocol

Stre

am co

ntro

l pro

toco

l

Stre

am d

eliv

ery

OK (URL)Consume (URL)

Validate

OK

OK


Figure I.11 – Procedural flows for on-demand procedural flows with tight coupling and proxy

68 Rec. ITU-T Y.1910 (09/2008)

1) The ITF runs the on-demand client which connects, using a transactional protocol, to an on-demand application to obtain the URL of the IPTV service control functional block with a reference to the content item that the customer wishes to receive. During this interaction, the application will authorize the ITF's connection, it can optionally use the application profile to personalize the service, it can optionally record the transaction and any associated purchase in the application profile. The application will establish, within the service profile, the authority for the ITF to subsequently consume the content.

2) The application connects to the IPTV service control functional block, passing it references to the content item to be consumed and the ITF.

3) The IPTV service control functional block determines the location of the IPTV device, for example by querying the NACF. It passes this information and the content reference to the unicast delivery control function to request the allocation of delivery resources. This procedure is not necessary in the case of a fixed network because the location is already known.

4) The content delivery control function determines which unicast delivery functional block has the requested content and can optionally be connected to the IPTV device. It queries, or maintains, the state of the unicast delivery functional block to identify one that has available capacity and allocates this to the ITF. It returns the URL of the physical server containing the allocated content item to the IPTV service control functional block.

5) The IPTV service control functional block requests the network resources needed to support the network path from the unicast delivery functional block to the IPTV device. The IPTV service control functional block returns to the application the URL of the physical server and content item, which in turn passes this to the ITF.

6) The ITF starts the session control connection to the IPTV service control functional block which proxies the request to the selected unicast delivery functional block.


8) At the end of the viewing, the ITF terminates the streaming control session which the IPTV service control functions are still proxying to the unicast delivery functional block.

9) The ITF then terminates the connection to the application, which in turn informs the IPTV service control functions that the session has ended.

10) The IPTV service control functions request that the unicast delivery control function releases the session.

11) The IPTV control function requests the release of network resources that were allocated to the network path from the unicast delivery functional block to the ITF.

In the exception case where the ITF does not perform step 9, the IPTV application functions monitor the session and, if this fails, terminate the session and notifie the IPTV service control functional block. Steps 10 and 11 would also follow.

I.2.5 Procedural flows for local programme adaptation for NGN-based linear IPTV The following diagram illustrates how location-specific content can be proposed to end-users after determining the location of the terminal. NOTE – Figue I.12 depicts optional behaviour when a programme is adapted to local constraints.

69 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FI-12


Validate connect

OKOK Get current

ITF location(Note)

Get current ITF location

LocationLocation(Note)

Browse andselect

Purchase content

Personalize


OK

Establish authority

OK

IPTVTF RACF

Applicationprofile

functionalblock


IPTV servicecontrol

functionalblock

Serviceprofile

functionalblock

CD&LCF CD&SF NACF

Sele

ctPu

rcha

se

Tran

sact

ion

prot

ocol

OK (service URL)

NOTE ? Optional procedure.

Figure I.12 – Procedural flows of local programme adaptation for NGN-based linear IPTV

I.3 Procedural flows for IPTV services based on NGN IMS IPTV architecture The following clauses provide detailed descriptions of the procedural flows in the case of NGN IMS IPTV architecture.

70 Rec. ITU-T Y.1910 (09/2008)

I.3.1 Procedural flows for VoD service

Y.1910(08)_FI-13

2. Service request

3. Get current ITF location

4. Location

5. Network resource request

RACFOn-demandapplication

IPTVTF Core IMS CD&LCF CD&SF NACF

1. ITF acquisition ofservice parameters, e.g.,content identifier, logicalURL of a content item,bandwidth, codec, etc.

Network resourcereservation

6. Response

7. Service request

Serviceauthorization, etc.

8. CD&SF request

9. CD&SF request

Select CD&SF10. CD&SF response

11. CD&SF response

12. CD&SF capabilities request

13. CD&SF capabilities request


14. CD&SF capabilities response

15. CD&SF capabilities response

16. Service response

17. Network resource request

Network resourceallocation

18. Network resource response

19. Service response

20. Establishment of content control channel and/or content delivery channel. Delivery of media content

Figure I.13 – Procedural flows for VoD service

Preconditions: It is assumed that provisioning and network attachment has been completed. 1) The IPTV terminal functions obtain the content identifier, logical URL, bandwidth, and

codec information for a content item that the end-user wishes to receive. This is achieved by interaction with the programme guide function or by other means. In this step, the IPTV

71 Rec. ITU-T Y.1910 (09/2008)

terminal functions can optionally obtain content delivery parameters such as bandwidth, codec, etc., by using content control messages.

2) The IPTV terminal functions initiate a service request to the core IMS functions. 3-4) The core IMS functions optionally determine the location of the IPTV terminal functions,

for example by querying the NACF. NOTE – Steps 3 and 4 are not necessary in the case of a fixed network because the location is already known.

5) The core IMS functions send a network resource request to the RACF in order to reserve network resources for content control and content delivery.

6) The RACF performs network resource reservation and sends the response to the core IMS functions.

7) The core IMS functions send the service request with content identifier and logical URL to the on-demand IPTV application functional block.

8) The on-demand application functional block performs service authorization. If the IPTV terminal functions are allowed to access the content, the on-demand IPTV application functional block sends the request to the CD&LCF via core IMS functions in order to select the CD&SF.

9) The core IMS functions forward the request to the CD&LCF. 10) The CD&LCF selects a suitable CD&SF based on some criteria, e.g., the state of the

CD&SF (e.g., load state, etc.), the knowledge of distributed content among the CD&SF, etc. The CD&LCF resolves the logical URL of content into the physical URL of an allocated CD&SF, and responds with the URL of the selected CD&SF to the on-demand application functional block via the core IMS functions.

11) The core IMS functions forward the response to the on-demand application functional block.

12) The on-demand application functional block sends the content resource request to the selected CD&SF via the core IMS functions in order to allocate content resources.

13) The core IMS function forwards the content resource request to the selected CD&SF. 14) The CD&SF performs content resource allocation and sends the response to the core IMS

functions. 15) The core IMS functions forward the response to the on-demand application functional

block. 16) The on-demand application functional block sends the service response to the core IMS

functions. 17) The core IMS functions send a network resource request to the RACF. 18) The RACF performs network resource allocation and sends the response to the core IMS

functions. 19) The core IMS functions send the service response to the IPTV terminal functions. 20) The ITF connects to the identified CD&SF to receive the content.

72 Rec. ITU-T Y.1910 (09/2008)

I.3.2 Linear TV service procedural flows in NGN IMS IPTV

Y.1910(08)_FI-14

2) Service request(logical ChID)

3) Get current ITF location (Note)

4) Location (Note)

5) Service request (logical ChID)

RACFLinear TVapplication

functional blockIPTV

TFCore IMSfunctions CD&LCF CD&SF NACF

1) ITF acquisition ofservice parameters,e.g., logical channel

identifiers

6) Request for multicast network parameters

7) Response for multicastnetwork parameters

8) Service response(multicast network parameters)

9) Network resources reserve and/or commit

10) Service response(multicast network parameters)

11) Content control and content delivery McCPF/McRF


Figure I.14 – Linear TV service procedural flows in NGN IMS IPTV

Pre-conditions: It is assumed that provisioning and network attachment has been completed, and that the channel streams have been delivered to multicast replication functional block (McRF)/multicast control point functional block (McCPF). NOTE 1 – Only multicast mechanism is assumed in Figure I.14. 1) The ITF acquires linear TV service parameters (such as a logical channel identifier or a list

of logical channel identifiers), e.g., by a service selection procedure. 2) The ITF initiates a service request with logical channel identifier(s) to the core IMS. 3-4) The core IMS functions determine the location of the IPTV device, for example by

querying the NACF. NOTE 2 – Steps 3 and 4 are not necessary in the case of a fixed network because the location is already known.

5) The core IMS functions forward the request to the LTV application with ITF location and logical channel identifier(s).

6) The linear TV application passes the ITF location and the logical channel identifier(s) to the content delivery control function.

73 Rec. ITU-T Y.1910 (09/2008)

7) The content delivery control function determines the multicast addresses and which content delivery and storage function uses to output the required channels and has multicast network paths to the IPTV terminal based on the association between logical channel identifiers and multicast addresses. It returns the corresponding multicast addresses to the linear TV application.

8) The linear TV application returns the multicast network parameters to the core IMS. 9) The core IMS functions request the network resources to support the network path from the

content delivery and storage function to the IPTV device. 10) Core IMS functions forward response to ITF. 11) The ITF receives the one or a list of logical channels and their multicast addresses and

maintains this mapping for the duration of the multicast session. After that, the ITF initiates channel control request by sending a multicast join request and receiving the multicast stream. When the user exits the linear TV application, i.e., they stop watching TV, the ITF will request the session be ended and will release any requested resources.

I.4 Procedural flows for IPTV interconnection between two NGN networks The following scenarios show how the network attachment process and service session establishment process can be coordinated in order to realize the roaming case in Figure VI.2, where the service control function in the visited network is not used. Some NGN-related interfaces (e.g., RACF-RACF interaction, NACF-NACF interaction) require further standardization work in the future. Figure I.15 illustrates a session set-up procedure specific for VoD in the NGN IMS-based IPTV in the case of a visited network without IMS control function (as in Figure VI.2).

The network attachment procedure can optionally be independent from the service establishment procedure.

74 Rec. ITU-T Y.1910 (09/2008)

IPTV TF NACFUser Profile Functional

Block

Application FunctionsRACF Core IMS

FunctionsAccess Network

Functions

Connection Request

Access User Authentication

NACF RACF

Visited Network

1)

2)

4)

5)

6)

7)

8)

Home Network

User Profile

3)

Policy Rules Policy Rules

SIP INVITE

IP Address Assignment

Gate Open and Resource AllocationGate Open and Resource AllocationGate Open and Resource Allocation



SIP Registration

SIP INVITE

9)

Resource Request

Resource Allocation

IPTV Media

IPTV Media Request

Media Request10)

11)

Figure I.15 – Basic set-up procedure for IMS-based IPTV in Figure VI.2

1) The IPTV terminal attaches to the access network and requests the user authentication and authorization in order to obtain the valid IP address and establish the link.

2) The access network sends the user authentication request to the home NACF through the visited NACF.

3) After the completion of the user authentication and authorization, the access network assigns the valid IP address to the IPTV terminal and establishes the link.

4) The access network obtains the user policy rules from the home RACF through the visited RACF and opens the gate for signalling messages (e.g., SIP port number) based on the provider's agreement.

5) The IPTV terminal executes the SIP registration mechanism with the core IMS functions, including the user profile.

6) The IPTV terminal sends a SIP INVITE message to the core IMS functions in order to request the IPTV application session. The core IMS functions then send it to the application functions.

7) The application functions request the resource allocation for the IPTV terminal to the content delivery functions.

75 Rec. ITU-T Y.1910 (09/2008)

8) The content delivery functions request the resource allocation for the IPTV terminal to the core IMS. The core IMS functions then send the IPTV content information (e.g., IP address, port number, content type and bandwidth) to the home RACF so that the home RACF can request the visited RACF to open the gate on the access network for the IPTV content. Policy rules can optionally be allocated to the access network.

9) The IPTV terminal requests the application functions to send the content. 10) The application functions request the content delivery functions to start sending the content. 11) The IPTV terminal receives the IPTV content from the content delivery functions. Figure I.16 illustrates the basic VoD session set-up procedure for NGN non-IMS-based IPTV in the case of a visited network without IPTV service control functions (as in Figure VI.2).

The network attachment procedure can optionally be independent from the service establishment procedure.

IPTV TF NACFUser Profile Functional

Block

Application FunctionsRACF

IPTV Service Control

Functional Block

Access Network Functions

Connection Request


NACF RACF

Visited Network

1)

2)

4)

5)

6)

7)

8)

Home Network

User Profile

3)

Policy Rules Policy Rules

IPTV Application Request

IP Address Assignment

Gate Open and Resource AllocationGate Open and Resource AllocationGate Open and Resource Allocation



IPTV Application Request

9)

Resource Request

Resource Allocation

9)

IPTV Media

IPTV Media Request

Media Request10)

11)

Figure I.16 – Basic setup procedure for non-IMS-based IPTV in Figure VI.2

1) The IPTV terminal attaches to the access network and requests the user authentication and authorization in order to obtain the valid IP address and establish the link.

2) The access network sends the user authentication request to the home NACF through the visited NACF.

76 Rec. ITU-T Y.1910 (09/2008)

3) After the completion of the user authentication and authorization, the access network assigns the valid IP address to the IPTV terminal and establishes the link.

4) The access network obtains the user policy rules from the home RACF through the visited RACF and opens the gate for signalling messages (e.g., IPTV control port number) based on the provider's agreement.

5) The IPTV terminal requests the IPTV content to the IPTV service control functions, including the user profile.

6) The IPTV service control functions request the IPTV application session to the application functions.

7) The application functions request the resource allocation for the IPTV terminal to the content delivery functions.

8) The content delivery functions request the resource allocation for the IPTV terminal to the IPTV service control functions. The IPTV service control functions then send the IPTV content information (e.g., IP address, port number, content type and bandwidth) to the home RACF so that the home RACF can request the visited RACF to open the gate on the access network for the IPTV content. Policy rules can optionally be allocated to the access network.

9) The IPTV terminal requests the application functions to send the content. 10) The application functions request the content delivery functions to start sending the content. 11) The IPTV terminal receives the IPTV content from the content delivery functions.

77 Rec. ITU-T Y.1910 (09/2008)

Appendix II

Potential protocols that could be used on IPTV reference points (This appendix does not form an integral part of this Recommendation)

This appendix provides examples of the potential protocols that could be used on the IPTV reference points as defined in clause 11.

Table II.1 describes the potential protocols that could be used on the reference points common to the three architectural approaches (non-NGN, NGN non-IMS and NGN IMS).

Table II.2 describes the potential protocols that could be used on the reference points specific to the three architectural approaches (non-NGN, NGN non-IMS and NGN IMS). For the NGN architecture, the reference points already defined are indicated in brackets.

78 Rec. ITU-T Y.1910 (09/2008)

Table II.1 – Protocols on reference points common to all three IPTV architectures

Ref. Point Entity 1 Entity 2 Non-NGN NGN non-MS NGN IMS

A2 IPTV application FB CD&LCF FFS FFS FFS A3 IPTV application FB Content preparation

functions FFS FFS FFS

A4 SADS FB Application profile FB FFS FFS (e.g., Diameter) Diameter (Sh) A5 IPTV application FB Application profile FB FFS FFS (e.g., Diameter) Diameter (Sh) A6 IPTV application FB SCP functions FFS FFS FFS C1 Content preparation

functions CD&LCF FFS FFS FFS

C2 Content preparation functions

CD&SF FFS FFS FFS

C3 Content preparation functions

SCP Functions FFS FFS FFS

D1 CD&LCF CD&SF FFS FFS FFS E0 SADS client FB SADS FB HTTP or DVBSTP HTTP or DVBSTP HTTP or DVBSTP, or

FLUTE E1 IPTV application client FB IPTV application FB HTTP HTTP HTTP E2 SCP client functions SCP Functions FFS FFS FFS E4 Error recovery client FB Error recovery FB FFS FFS FFS E5 Multicast content delivery

client FB Multicast control point FB

IGMP or MLD IGMP or MLD IGMP or MLD

E6 Unicast content delivery client FB

Content delivery control FB

RTSP RTSP RTSP

E7 IPTV terminal functions Delivery network gateway FB

FFS FFS FFS

79 Rec. ITU-T Y.1910 (09/2008)

Table II.1 – Protocols on reference points common to all three IPTV architectures

Ref. Point Entity 1 Entity 2 Non-NGN NGN non-MS NGN IMS

H2 Delivery network gateway FB

Multicast replication FB RTP over UDP RTP over UDP RTP over UDP

H3 Delivery network gateway FB


RTP over UDP or RTP over TCP



M1 SCP functions Application profile FB FFS FFS FFS Mc Multicast delivery FB Multicast control point

FB PIM PIM PIM

Md Multicast delivery FB Multicast replication FB RTP over UDP RTP over UDP RTP over UDP Ud Unicast delivery FB Unicast transport

functions RTP over UDP RTP over UDP RTP over UDP

80 Rec. ITU-T Y.1910 (09/2008)

Table II.2 – Protocols on reference points specific to IPTV architectures

Ref. Point Non-NGN NGN non-IMS NGN IMS

A0 – – NA – – NA SADS FB Core IMS functions

SIP (ISC)

A1 IPTV application FB

IPTV service control FB

HTTP IPTV application FB


HTTP IPTV application FB

Core IMS functions

SIP (ISC)

E3 Control client FB


RTSP Control client FB


RTSP Session client FB

Core IMS functions

SIP (Gm)

H1 Delivery network

gateway FB

Authentication and IP allocation

FB

FFS Delivery network

gateway FB

NACF FFS (TC-U1)

Delivery network

gateway FB

NACF FFS (TC-U1)

R1 Resource control FB

Network transport functions

FFS RACF Network transport functions

Diameter (Rw)

RACF Network transport functions

Diameter (Rw)

S1 IPTV service control FB

CD&LCF FFS IPTV Service Control FB

CD&LCF ffs Core IMS Functions

CD&LCF SIP


Service user profile FB

FFS IPTV service control FB

Service user profile FB

Diameter (Cx)

Core IMS functions

Service profile FB

Diameter (Cx)


Resource control FB


RACF Diameter (Rs)

Core IMS functions

RACF Diameter (Rs)


Authentication and IP allocation

FB


NACF Diameter (S-TC1)

Core IMS functions

NACF Diameter (S-TC1)



RTSP IPTV service control FB


RTSP Core IMS functions

Content delivery

control FB

SIP

T1 Authentication and IP allocation

FB


FFS NACF Access network functions

FFS (TC-T1)

NACF Access network functions

FFS (TC-T1)

81 Rec. ITU-T Y.1910 (09/2008)

Appendix III

IPTV physical network hierarchy (This appendix does not form an integral part of this Recommendation)

The IPTV architecture needs to allow for IPTV network, service and application components to exist at different physical and logical points in a network. This is common for many operators where the network and service components are hierarchically distributed.

An example of mapping IPTV functional elements to a physical network hierarchy for linear TV is shown in Figure III.1.

Figure III.1 shows an example of a network hierarchy as content and control flows from content provider to the end-user. This hierarchy is an example, with larger networks having more levels and smaller networks having fewer. The figure shows the components and flows for a linear TV service example. The access network functions must be located between the video serving office (VSO) and end-user, and the IP multicast replication functions can optionally be located in the VSO: however, they are not illustrated in the figure.

Super head end (SHE) network node(s) with the broadest content scope: The SHE sources content to an entire IPTV network. Intended uses include primary storage for off-line content and transmission of region-independent off-air content (e.g., premium and specialty programming).

Video hub office (VHO) network node(s) with a local/regional content scope: The VHO sources region-dependent off-air content (e.g., local programming) and houses local off-line storage of content.

Video serving office (VSO) network node(s) that connect end users (via access systems) to the IPTV network: The VSO (typically a local exchange office) hosts or connects all access systems for interconnection to end users. In addition, the VSO contains aggregation equipment to enable efficient interconnection of access systems to the IPTV network. The option to locate content interconnection and/or content processing equipment is shown, though perhaps not typical. NOTE – SHEs may be referred to as central servers, VHOs may be referred to as regional or metro servers, and VSOs may be referred to as local servers.

82 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FIII-1

DNG

IPTVterminal device

Accessnetwork

VSO VHO SHE

IPTVservice control

functional block


al blockfunction


Content delivery client functions

Linear TVapplication

functional block

TransactionprotocolApplication

client functions


Multicastreplication

functional block




Deliveryprotocol


Resource andadmission controlfunctions (RACF)


control functions

Contentand metadata

sources

HN Content

Content preparationfunctions

CD&SF CD&SF CD&SF


functional block

Multicast control point

functional block

Network attachment control functions

(NACF)


functional block


functional block


functional block

protocolControl

Figure III.1 – Network hierarchy for an IPTV network (linear TV example)

83 Rec. ITU-T Y.1910 (09/2008)

Appendix IV

Overlay networking function for IPTV services and multicast (This appendix does not form an integral part of this Recommendation)

An optional way for an overlay networking function to support IPTV services and QoS-enabled multicast delivery can be performed using the content delivery control function capabilities.

The following functions can optionally be present in the content delivery control function: a) Control overlay networking configuration and topology management and overlay multicast

tree management. The overlay network will be created virtually with the control of "content delivery control".

b) Provide multi-homed "content delivery control function" through constructed overlay networks to meet efficient content delivery with high quality service requirements for IPTV services.

c) Support overlay network configurations to ensure that clients are not connected/disconnected from the delivery function in case of failures. In addition, the "content delivery control function" provides control functions that support redundancy in case of multiple servers in order to reduce the impact of server delivery failures.

84 Rec. ITU-T Y.1910 (09/2008)

Appendix V

Adaptation of the IPTV architecture for HFC networks (This appendix does not form an integral part of this Recommendation)

Figure V.1 shows the high-level functional architecture for IPTV where the network layer is provided by a hybrid fibre coax (HFC) cable network. Detailed decomposition of the diagram is shown in [b-ITU-T J.700].

85 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FV-1



SCP clientfunctions


Transactionprotocol


SCP functions



functional block


functional block

Transportmanagement

functional block

Contentand metadata

sources


Managementfunctions



functional block


block


block


control functions





Cable modem HFC accessnetwork functions


CMTS functions Core transportfunctions

Network functions


functional block

Delivery protocolsControl delivery

managementfunctional block

Content and metadata


Residentialgateway

Figure V.1 – High-level functional architecture for cable-delivered IP

86 Rec. ITU-T Y.1910 (09/2008)

The descriptions of the functional elements that are common to all IPTV architectures are presented in clause 10. The cable-specific functions are described below. It is noted that the nature of the interfaces to the common functional elements can optionally differ between cable-delivered IPTV and NGN- or non-NGN-delivered IPTV.

HFC access network The hybrid fibre coax (HFC) access network is defined as the network between the cable modem termination system (CMTS) and the cable modem. Attributes of the HFC access network include: • Supported or required data over cable service interface specifications (DOCSIS) versions. • DOCSIS set top box gateway (DSG). • Edge QAMs. • Modular CMTS. • Optical distribution network. • Radio-frequency (RF) network.

CMTS The cable modem termination system (CMTS) provides support for IP-based data services, such as Internet or voice over IP.

87 Rec. ITU-T Y.1910 (09/2008)

Appendix VI

Nomadism for IPTV services (This appendix does not form an integral part of this Recommendation)

This appendix describes examples of roaming between two NGN networks to offer IPTV services. These examples cover: 1) roaming (nomadism); 2) access to third party service providers.

All interconnection scenarios in this appendix assume VoD service and unicast delivery method. Linear TV transmission with multicast delivery is out of scope of this appendix.

Roaming in this appendix means nomadism of the terminal device. In order to realize network interworking, various business arrangements are required among service provider, network provider and content provider, which are beyond the scope of this appendix.

Note that in this appendix the use of the terms "home network" and "visited network" is based on the context of mobile (e.g., cellular) networks or networks supporting nomadism. These terms are not to be confused with the use of the term "home network" as used in the context of residential (home) networks.

VI.1 Interconnection with the visited network Figure VI.1 illustrates the case where IPTV terminal functions are connected to the visited network and are accessing the application functions in the home network. In this figure, either the core IMS functions or the IPTV service control functional block is used depending on the capabilities of the home network and the visited network, respectively. The service control functions of each network request network resources via its own RACF. Network functions in each network can optionally be interconnected to other networks and the RACF-to-RACF reference point can optionally be used to request resource and admission control. NOTE 1 – The detailed procedures and information related to RACF-to-RACF communication are for further study.

88 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FVI-1


client functions


Transaction protocolContent

preparationfunctions


IPTV service controlfunctional block/core

IMS functions


block


control functions




Control/sessionclient functional

block



functional blockBorder

functional blockEdge

functionsCore transport

functions


Delivery protocols

Authentication andconfigurationprotocol

NGN transport functions



(NACF)



Home network


IMS functions




Edgefunctions



Networkattachment controlfunctions (NACF)



Borderfunctional block

Visited network

Control/sessionprotocol Control/session protocol

Resource control protocol

Resource controlprotocol

Figure VI.1 – Interconnection with the visited network

89 Rec. ITU-T Y.1910 (09/2008)

Figure VI.2 illustrates the case where IPTV terminal functions are connected to a visited network and access the application functions in the home network without using service control functions in the visited network. In this figure, either the core IMS functions or the IPTV service control functional block is used, depending on the capabilities of the home network. The RACF of the home network requests the network resources from the visited network via the RACF-to-RACF reference point.

If no service control functions are applicable due to the absence of compatible service control functions or mutual agreement between network providers, the RACF-to-RACF reference point is used to request network resources in the visited network. NOTE 2 – The detailed procedures and information related to RACF-to-RACF communication is for further study.

90 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FVI-2


client functions






IMS functions


block


control functions





block






functions


Delivery protocols

Authenticationand configuration

protocol




(NACF)



Home network



Edgefunctions







Visited network

Control/session protocol



Figure VI.2 – Interconnection with the visited network without service control functions

91 Rec. ITU-T Y.1910 (09/2008)

VI.2 Interconnection with third party service providers Figure VI.3 illustrates the interconnection with a third party service provider. In this figure, either core IMS functions or the IPTV service control functional block is used, depending on the architecture variants used in the home network and the third party service provider, respectively. The application functions and content delivery functions of the third party service provider are involved in providing IPTV services. The service control functions of each provider request the network resources from their respective RACF.

92 Rec. ITU-T Y.1910 (09/2008)

Y.1910(08)_FVI-3


client functions






IMS functions


control functions





block






functions


Delivery protocols

Authenticationand configuration

protocol




(NACF)



Third party service provider


IMS functions




Edgefunctions







Home network

Control/sessionprotocol Control/session protocol



block

Resource controlprotocol

Figure VI.3 – Interconnection with the third party service provider


93 Rec. ITU-T Y.1910 (09/2008)

Bibliography

[b-ITU-T H.262] Recommendation ITU-T H.262 (in force) | ISO/IEC 13818-2:in force, Information technology – Generic coding of moving pictures and associated audio information: Video.

[b-ITU-T H.264] Recommendation ITU-T H.264 (in force), Advanced video coding for generic audiovisual services.

[b-ITU-T J.700] Recommendation ITU-T J.700 (2007), IPTV service requirements and framework for secondary distribution.

[b-ITU-T Y.101] Recommendation ITU-T Y.101 (2000), Global Information Infrastructure terminology: Terms and definitions.

[b-ITU-T IPTVFG] ITU-T IPTV Focus Group Proceedings (2008). <http://www.itu.int/publ/T-PROC-IPTVFG-2008/en>

http://www.itu.int/publ/T-PROC-IPTVFG-2008/en�


95 Rec. ITU-T Y.1910 (09/2008)


96 Rec. ITU-T Y.1910 (09/2008)

SERIES OF ITU-T RECOMMENDATIONS

Series A Organization of the work of ITU-T

Series D General tariff principles

Series E Overall network operation, telephone service, service operation and human factors

Series F Non-telephone telecommunication services

Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems

Series I Integrated services digital network

Series J Cable networks and transmission of television, sound programme and other multimedia signals

Series K Protection against interference

Series L Construction, installation and protection of cables and other elements of outside plant

Series M Telecommunication management, including TMN and network maintenance

Series N Maintenance: international sound programme and television transmission circuits

Series O Specifications of measuring equipment

Series P Telephone transmission quality, telephone installations, local line networks

Series Q Switching and signalling

Series R Telegraph transmission

Series S Telegraph services terminal equipment

Series T Terminals for telematic services

Series U Telegraph switching

Series V Data communication over the telephone network

Series X Data networks, open system communications and security

Series Y Global information infrastructure, Internet protocol aspects and next-generation networks

Series Z Languages and general software aspects for telecommunication systems


９７ Rec. ITU-T Y.1910 (09/2008)

1. Scope (범위)

영문표준 해설서

본 표준의 범위와 구성에 대해 기술하며 네트워크 환경에 따라 세 가지 IPTV 구조에 대해

정의하고 있다.

2. References (참고문헌)

참조 문서들을 기술한다. 본 표준에서 참조 문서들을 정의하며 ITU-T Y.2012 (TTAE.IT-

Y2012), Y.2014 (TTAE.IT-Y2014), Y.2021 (TTAE.IT-Y2021), Y.2111 (TTAE.IT-Y2111)

표준을 직접 참조한다.

3. Definitions (용어정의)

본 표준에서 사용되는 주요 용어들을 정의하고 있으며 다른 표준에서 6 개의 용어를

참조하고 본 표준에서는 7개의 새로운 용어를 추가 정의하였다.

4. Abbreviations and acronyms (약어 정의)

본 표준에서 사용되는 약어 57개를 정의하고 있다.

5. Conventions (규약)

본 표준에서 사용하고 있는 기능 (Functions), 기능 블록(Functional block) 및 데이터

소스(Data source)에 대한 개념과 본문에 표기되는 형태를 정의하고 있다.

6. IPTV domains (IPTV 영역)

IPTV 서비스에 관계가 있는 네 가지 영역 즉 콘텐츠 제공자(Content provider), 서비스

제공자(Service provider), 네트워크 사업자(Network provider) 및 최종 사용자(End user)에

대한 구조를 정의하고 있다.

7. IPTV architectural approach (IPTV 구조적 접근)

IPTV 서비스를 구축하는 세 가지 네트워크 환경 즉, Non-NGN 기반, NGN 기반 및 NGN

IMS 기반 환경에 대해 설명한다.

또한, Non-NGN 기반 구조와 NGN 기반 구조에 대한 차이점 및 NGN 기반 구조와 NGN

IMS 기반 구조에 대한 차이점에 대해서 기술한다.


９８ Rec. ITU-T Y.1910 (09/2008)

8. IPTV functional architecture framework (IPTV 기능적 구조의 프레임워크)

IPTV 구조의 프레임워크에 대해 설명한다. IPTV 구조의 프레임워크는 최종 사용자

기능(end-user functions), 애플맄ㅔ이션 기능 (application functions), 서비스 제어 기능

(service control functions), 콘텐츠 전달 기능(content delivery functions), 네트워크

기능(network functions), 관리 기능(management functions) 및 콘텐츠 제공자

기능(content provider functions)으로 구분하여 각 기능들의 역할과 기능에 대해 간략히

기술하고 있다.

9. IPTV architectural overview (IPTV 구조 개요)

IPTV 프레임워크에 따른 non-NGN기반 IPTV 세부 구조에 대해 정의하고 그 세부 구조를

구성하고 있는 세부 기능 블록에 대해 기술한다. 이는 Non-NGN 기반, NGN 기반 및 NGN

IMS 등 세 가지 네트워크 환경에서 공통적으로 적용되는 기능에 대해 설명하고 있다.

10. IPTV functional architecture (IPTV 기능적 구조)

Non-NGN 기반, NGN 기반 및 NGN IMS 기반 등 세 가지 네트워크 환경에 따른 IPTV 구조

IPTV 구조를 정의한다. Non-NGN 기반 IPTV 구조는 이미 9 장에서 기술하였으나 보다

명확히 하기 위해 본 장에서 구조를 다시 세부적으로 정의하였고 내용은 9장을 참조한다.

NGN 기반 IPTV 구조를 정의하고 제어 클라이언트 기능 블록과 IPTV 서비스 제어 기능

블록은 9장을 참조하였고 서비스 이용자 프로파일 기능 블록은 ITU-T Y.2012 (Functional

requirements and architecture of next generation networks,2010.4.30) 표준을

준수하도록 정의한다.

NGN IMS 기반 IPTV 구조를 기술하고 또한 세션 클라이언트 기능 블록과 Core IMS 기능이

NGN IMS 기반 IPTV 구조에 추가되어 이에 대해 추가로 정의 한다. 서비스 이용자 프로파일

기능 블록은 ITU-T Y.2012 표준을 준수하도록 정의한다.

NGN 기반 IPTV 구조와 NGN IMS 기반 IPTV 구조에서 공통적으로 적용되는 기능을

정의하는데 NGN 서비스 계층 기능, NGN 전달 계층 기능 및 NGN 전송 기능 은 ITU-T

Y.2012 표준을 준수하도록 정의한다.

세 가지 네트워크 환경에서 공통적으로 적용되는 기능을 블록 수준으로 더 세분화하여

상세 기능 구조를 정의하고 각 기능 블록에서의 역할과 동작 기능에 대해 기술한다.

IPTV 구조를 구성하고 있는 IPTV 서비스 사업자간의 연동(interworking) 구조와 제 3

자(3rd Party) 애플리케이션 기능을 제공하는 구조에 대해 정의한다.

11. Reference points (참조점)

세 가지 네트워크 환경에서의 IPTV 구조에서 인터페이스(참조점)에 대해 정의하고 각

인터페이스의 기능과 역할에 대해 설명한다.


９９ Rec. ITU-T Y.1910 (09/2008)

부속서 A. Relationship between IPTV and NGN architectures (IPTV와 NGN 구조간의 관계)

ITU-T Y.2012에서 정의한 NGN 구조상에서 IPTV 기능을 추가한 NGN 구조를 정의하고

추가된 내용에 대해 기술한다. 그리고 NGN 구성요소와 IPTV 기능의 매핑 관계도 설명한다.

부록 I. Procedural flows relating to IPTV services (IPTV 서비스에 대한 절차적 흐름도)

IPTV 구조는 다양한 형태로 구현될 수 있으며, IPTV 구조에 대한 이해를 돕기 위해 IPTV

서비스 중에서 주문형 콘텐츠(CoD:Content on Demand)과 실시간 TV (linear TV) 서비스를

제공하기 위한 동작 절차 흐름도를 예시로 기술하고 있다. 또한, 콘텐츠 분배 방식, NGN

기반 IPTV 구조에서 IPTV 서비스 제공 방안, IMS 기반 IPTV 구조에서 IPTV 서비스 제공

방안에 대한 흐름도와 두 개의 NGN네트워크간의 IPTV 서비스 제공을 위한 절차 흐름도도

예시로 보여주고 있다.

부록 II. Potential protocols that could be used on IPTV reference points (IPTV 참조점에서

사용 가능한 프로토콜)

본 표준에서 IPTV 구조에서의 참조점(Reference points)를 정의하고 있으며 본

부록에서는 참조점에서 사용할 수 있는 프로토콜을 예시로 보여주고 있다.

부록 III. IPTV physical network hierarchy (IPTV 물리적 네트워크 계층 구조)

IPTV 서비스를 제공하기 위해 네트워크는 크게 SHE(Super head end) 네트워크,

VHO(Video hub office) 네트워크, VSO(Video serving office) 네트워크 노드로 구성될 수

있으며 각 네트워크에서 제공되어야 하는 IPTV 기능에 대해 예시로 보여주고 있다.

부록 IV. Overlay networking function for IPTV services and multicast (IPTV 서비스와

멀티캐스트에 대한 중복 네트워킹 기능)

IPTV 서비스와 멀티캐스트를 중복 네트워킹 형태로 제공하기 위해 필요한 기능을

설명하고 있다.

부록 V. Adaptation of the IPTV architecture for HFC networks (HFC 네트워크에서 IPTV

구조 적용)

광동축 혼합망(HFC: Hybrid Fiber Coax) 망에서 IPTV 구조를 적용하는 방법에 대해

예시로 보여주고 있다.

부록 VI. Nomadism for IPTV services (IPTV 서비스에 대한 노마디즘)


１００ Rec. ITU-T Y.1910 (09/2008)

IPTV 서비스 로밍 방안 및 제 3자(3rd party) 서비스 제공자를 위한 IPTV 구조를 예시로

보여주고 있다.

부록 VII. Comparison of IPTV architecture of other SDOs (다른 SDO의 IPTV 구조 비교)

ITU-T 이외의 다른 표준화 기구(ATIS, ETSI, OIPF)에서 정의한 IPTV 구조를 소개하고 본

표준에서 정의한 구조와의 차이점을 간략히 기술한다.

Bibliography (문헌)

본 표준에서 참조하고 있는 문헌들을 나열하였다.


１０１ Rec. ITU-T Y.1910 (09/2008)

표준 번호 : TTAE.IT-Y1910

표준작성 공헌자

이 표준의 제․ 개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

구분 성명 위원회 및 직위 연락처 소속사

과제 제안 강신각 전송통신기술위원회

부의장 [email protected] ETRI

표준 초안 제출 김성혜 IPTV PG 위원 [email protected] ETRI

표준 초안 검토

및 작성

이근구 IPTV 프로젝트그룹 의장 [email protected] TTA

외 IPTV 프로젝트그룹

위원

표준안 심의

민경선 전송통신 기술위원회

의장 [email protected] KT CS

외 기술위원회 위원

사무국 담당 박정식 통신융합부 부장 031-724-0080 TTA

오구영 통신융합부 과장 031-724-0081 TTA

mailto:[email protected]�

mailto:[email protected]�




발행인 : 한국정보통신기술협회 회장

발행처 : 한국정보통신기술협회

463-824, 경기도 성남시 분당구 서현동 267-2

Tel : 031-724-0114, Fax : 031-724-0019

발행일 : 2010.12

iptv 서비스 구조 1. 표준의 목적 본 표준의 목적은 iptv의 서비스 요구사항과...

Documents