ATIS 0800007-2007 IPTV High Level Architecture.pdf

《ATIS 0800007-2007 IPTV High Level Architecture.pdf》由会员分享，可在线阅读，更多相关《ATIS 0800007-2007 IPTV High Level Architecture.pdf（40页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0800007 IPTV HIGH LEVEL ARCHITECTURE The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical and operations standards for the communications and related informati

2、on technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are active in ATIS 23 industry committees and its Incubator Solutions Program. NOTE - The users attention is called to the possibility that compliance

3、 with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to whether use of an invention covered by patent rights will be required, and if any such use is required no position is taken regarding the validity of th

4、is claim or any patent rights in connection therewith. ATIS-0800007, IPTV High Level Architecture Is an ATIS standard developed by the Architecture (ARCH) Task Force under the ATIS IPTV Interoperability Forum (IIF). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, S

5、uite 500 Washington, DC 20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information co

6、ntact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-0800007 ATIS Standard on IPTV HIGH LEVEL ARCHITECTURE Secretariat Alliance for Telecommunications Industry Solutions Approved March 2007 Abstract This document provides a high level architectural framework

7、for end-to-end systems implementation and interoperability for the supporting network design. This will serve as reference architecture for the IPTV functional specifications to be defined in separate IIF Specification documents. ATIS-0800007 Contributors: Donald Crowe, Alcatel-Lucent Rajesh Jaganna

8、than, Alcatel-Lucent Randy Sharpe, Alcatel-Lucent TF Co-Chair Rick Townsend, Alcatel-Lucent Amit Kleinmann, Amdocs Al Morton, AT in this case, the delivery system of a network provider is a wireless wide area network (WAN). This domain is in scope for the IIF specifications. 2. Network Provider: The

9、 domain connecting customers and service providers. The delivery system usually is composed of access networks and core or backbone networks, using a variety of network technologies. The delivery network is transparent to the IP traffic, although there may be timing and packet loss issues relevant f

10、or IPTV content streamed on IP. This domain is in scope for the IIF specifications. 3. Service Provider: The domain providing a service to the subscriber. Different types of service providers may be relevant for television services on IP - e.g., simple Internet Service ATIS-0800007 7 Providers (ISPs

11、) and Content Service Providers (CSPs). In the context of television services on IP, the CSP acquires/licenses content from Content Providers and packages this into a service. In this sense, the service provider is not necessarily transparent to the application and content information flow. This dom

12、ain is in scope for the IIF specifications. 4. Content Provider: The domain that owns or is licensed to sell content or content assets. Although the Service Provider is the primary source for the customer at Home, a direct logical information flow may be set up between Content Provider and Home cust

13、omer - e.g., for rights management and protection. This domain is in scope for the IIF specifications, primarily for the aspect of acquisition of content by the service provider. Specifications related to the content development processes of the content provider are not considered in scope at this t

14、ime. 4.1.2 Interfaces between Logical Domains 5. Consumer/Network Provider: The Consumer/Network Provider logical interface is in scope. 6. Network Provider/Service Provider: The Network Provider/Service Provider logical interface is in scope. 7. Service Provider/Content Provider: The Service Provid

15、er/Content Provider logical interface is in scope. 8. Consumer/Service Provider: The Consumer/Service Provider logical interface is in scope. 9. Network Provider Content Provider: The Network Provider/Content Provider logical interface is not in scope. The Network Provider and Content provider may c

16、hoose to support a logical interconnection for a variety of purposes, but these are beyond the scope of IPTV. From the definition of IPTV as a secure, reliable, managed service, the Service Provider is required to be involved in the service delivery. An organization that is a Content Provider may al

17、so act as a Service Provider to deliver the service, but such an action would not require this interface, but rather be an example of interface #6. 10. Consumer/Content Provider: The Consumer/Content Provider logical interface is not in scope. The Consumer and Content Provider may choose to support

18、a logical interconnection for a variety of purposes, but these are beyond the scope of IPTV. From the definition of IPTV as a secure, reliable, managed service, the Service Provider is required to be involved in the service delivery. An organization that is a content provider may also act as a servi

19、ce provider to deliver the service, but such an action would not require this interface, but rather be an example of interface #8. 4.2 Applicable NGN Terminology Next Generation Network (NGN): The evolving NGN is defined in ITU-T Y.2001 3. It provides a QoS enabled packet-based infrastructure suppor

20、ting multiple service providers and access technologies. ITU-T Y.2011 5 provides a general reference model for NGNs. The Functional requirements and architecture of the NGN are specified in ITU-T Y.2012 6. The ATIS NGN Focus group has developed a framework for the NGN in three parts. ETSI TISPAN has

21、 also been working on specifications in the area of NGN. At the time of writing, ATIS/PTSC also has ongoing NGN work actively in ATIS-0800007 8 progress through several issue statements. In this document, unless otherwise specified, the term NGN refers to the evolving ITU-T version of NGN specificat

22、ions. IP Multimedia Sub System (IMS): The IMS provides a significant set of initial functions for the NGN infrastructure. The IMS was originally specified by 3GPP and is under continuing evolution by that group. At the time of writing, the latest complete set of specifications was Release 6, with wo

23、rk in progress for later releases. ETSI TISPAN has also been working on enhancements to the IMS. In this document, unless otherwise specified, the term IMS refers to the Release 6 IMS as defined by 3GPP. Core IMS: Core IMS is a subset of the 3GPP IMS which is restricted to the session control functi

24、onalities. For example, Application Servers (AS) are considered to be outside the Core IMS. In this document, unless otherwise specified, the term Core IMS refers to the ITU-T version of the Core IMS as specified in Y.2021 4. 5 IIF IPTV and NGN: Architectural Approach The ARCH Task Force has studied

25、 several options in consideration of a reference architecture. The two approaches are: 1. Core IMS Approach for IPTV in the NGN framework; and 2. Non-IMS Approach for IPTV in the NGN framework. Furthermore, the core IMS and non-IMS approaches shall be able to co-exist on the same NGN framework and s

26、hould use common components where possible. In addition to the co-existence mentioned above, there may be a coupling of the two systems. Such an architecture may appeal to an operator who has existing IPTV and IMS core systems and wishes to maximize the re-use of the features of each system, or wher

27、ever applications that are native to one system are deemed desirable in the other systems domain. One example contemplated is in the area of communications or conversational applications; when offered as part of an IPTV system, these applications might be enabled by native IMS applications. Converse

28、ly, web services - such as web-based alerts and information - may be best enabled in a core IMS IPTV deployment by access to elements that are native to the non-IMS IPTV system. The present document will identify the IPTV functional components in more details and map them into NGN strata. 6 IPTV Hig

29、h Level Functional Decomposition Figure 2 provides a high-level view of both IMS-based and non-IMS IPTV services coexisting in the same network. The services integrate via the application layer (for future study). Services should use common components whenever possible. All services are delivered to

30、 the consumer via the NGN Transport strata. The Figure shows many of the components and interfaces essential for any IPTV service in solid lines. The IMS client is required for IMS-based IPTV services, other IMS services, or both. Components and interfaces shown by dotted lines are optional. For exa

31、mple, Other IMS Services are not in the scope of the IIF, are not required for proper IPTV operation and are presented in the picture for illustration only. ATIS-0800007 9 The functional components are mapped into the IPTV logical domains as introduced earlier. Figure 2: IPTV Functional Decompositio

32、n 7 Common Components Overview Figure 2 identifies a number of specific common components in support of applications and services, while others are not specifically identified in the figure. This section describes those components and identifies additional common components or objects that may exist

33、 at this point in the architecture. Additional common components can be added to the architecture using the box labeled Others in the figure. The common functions and capabilities used an IPTV system can be classified in three broad categories: 1. Category A: IPTV Functional Components are component

34、s that must made available for any IPTV application for proper operation. These components are implemented in such a way that the same service logic could be used by an IPTV system irrespective of whether it is an IPTV system using IMS or an IPTV system not using IMS within NGN. Some components may

35、expose their functionality through multiple protocols as specified by the IIF. Core IMS Service Provider Domain ITF DNGF Content Distribution from preparation to delivery servers; Unicast Content Delivery (including CoD); and Linear Broadcast Server Function (multicast content delivery). Linear Broa

36、dcast Server receives content, which may be analog or digital, from a broadcaster or other source of linear content. This content may be encoded or re-encoded and then encapsulated for delivery over an IPTV network. 7.1.4 Media Source Function For Linear Broadcast Service, this function includes ove

37、r the air transmission of linear program content and other sources. For other services, this function is for further study. ATIS-0800007 11 7.2 Category B: Common Application and Service Support Components and Functions 7.2.1 Service User Profile (SUP) The Service User Profile (SUP) provides a struc

38、tured persistent data repository covering multiple service domains that can be accessed from both IMS and non-IMS applications. The SUP may be implemented in centralized or distributed mechanisms as required for system performance. The major contribution of the SUP is to provide a shared repository

39、and common structure for data elements related to users. These data elements are intended to be reusable between different applications. There may be multiple types of identities with profiles stored in the SUP (refer to 7.2.2, Identity Management). Example SUP data elements include: Type of user id

40、entity; User identifier (name, URI); Account information; and User service subscription information. The SUP is derived from the TISPAN UPSF and 3GPP HSS, with extensions to be described in the subsequent IIF documents. Some differences include, but are not limited to: The availability of a web serv

41、ices interface; and Some additional data elements driven by the IPTV service suite. Service or application specific data, such as Parental control settings, has traditionally been stored locally on the application server. SUP should contain common profile data. The same high capacity, highly availab

42、le data storage infrastructure may also be used for application data beyond the scope of the common profile. 7.2.2 Identity Management Identities must be handled in a secured and authenticated manner in a multi-network and service provider environment. A harmonized approach to address Identity manag

43、ement related issues in the ATIS NGN architecture and related specifications is needed to allow service providers and network providers to offer services efficiently and securely in a converged environment. It is noted that ATIS/PTSC currently has an active issue statement to identify ATIS NGN Ident

44、ity Management Requirements. This emerging Identity Management standardization activity is expected to lead to an architecture for Identity Management services that is potentially common between IMS and non-IMS NGN applications. The IIF expects to work closely with ATIS/PTSC to provide input on Iden

45、tity Management requirements from an IPTV perspective. The ATIS-0800002, Architecture Requirements, provides preliminary information regarding a number of identities that are relevant to IPTV services. These notions include: User; Device; Subscriber; ATIS-0800007 12 Network Provider; Service Provide

46、r; and Content Provider. Identities may be used in IPTV services for a number of purposes including: Authentication/Authorization for Service Access; Service Consumption; Service Customization; and Targeted Advertising. The IMS provides a set of public and private identities that may be used in conj

47、unction with IPTV services. To be consistent with our general approach above, these identity management services are expected to be accessible from both IMS and non-IMS entities. 7.2.3 User Authentication Common user credentials are desired for single sign on, multi-client service blending, and serv

48、ice mobility. This function needs to work for IMS and non-IMS (e.g., Web services) systems as appropriate. The common credentials should be stored securely as part of the user profile. A harmonized approach to address Identity Management-related issues in the NGN architecture and related specificati

49、ons is needed to allow service providers and network providers to offer services efficiently and securely in a converged environment. The approach needs to meet the IPTV identity requirement identified within IIF Architecture Requirements. For core IMS based solutions, the authentication architecture is based on the ISIM and GBA mechanisms. For applicable work refer to: 3GPP: Reference ISIM and GBA work; DSL Forum Model; and PTSC Identity Management. 7.2.4 User Policies User policies are maintained as persistent rules th