1、 ATIS-0300092 HIGH LEVEL OSS/BSS FUNCTIONAL REQUIREMENTS AND REFERENCE ARCHITECTURE FOR IPTV TECHNICAL REPORT The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical an
2、d operations standards for the communications and related information 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
3、 - The users attention is called to the possibility that compliance 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 suc
4、h use is required no position is taken regarding the validity of this claim or any patent rights in connection therewith. ATIS-0300092, High Level OSS/BSS Functional Requirements and Reference Architecture for IPTV Is an ATIS Standard developed by the ATIS Ordering and Billing Forum (OBF) and the AT
5、IS Telecom Management and Operations Committee (TMOC). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reprod
6、uced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-0300092 Technical Report on HIGH LEVEL OSS/BSS FUNCTIONAL REQUIREME
7、NTS AND REFERENCE ARCHITECTURE FOR IPTV Secretariat Alliance for Telecommunications Industry Solutions Approved September 2007 American National Standards Institute, Inc. Abstract This document contains functional requirement and reference architecture for Operations Support System (OSS) solutions f
8、or Internet Protocol Television (IPTV). ATIS-0300092 ii FOREWORD The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The ATIS Ordering and Billing Forum (OBF) provides a forum for customers and
9、providers in the telecommunications industry to identify, discuss and resolve national issues which affect ordering, billing, provisioning and exchange of information about access services, other connectivity and related matters. The Telecom Management and Operations Committee (TMOC) - formerly T1M1
10、 -develops operations, administration, maintenance and provisioning standards, and other documentation related to Operations Support System (OSS) and Network Element (NE) functions and interfaces for communications networks - with an emphasis on standards development related to U.S.A. communication
11、networks in coordination with the development of international standards. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, OBF/TMOC Secretariat, 1200 G Street NW, Suite 500, Washington, DC 20005. Contributors OBF
12、 and TMOC contributors to this Technical Report included: AMIT KLEINMANN (AMDOCS) Brian Bearden (AT defined in a specification, or group of specifications, published as a package by OMA. 1.1.36 Service Resource7: Resource in the NGN service stratum. 1.1.37 Shared Information/Data model (SID): The TM
13、F NGOSS SID model provides a common industry vocabulary. It is a set of information/data definitions and relationships used in the definition of NGOSS architectures. It is the NGOSS information model. It provides an information/data reference model and a common information/data vocabulary from the p
14、erspective of the four major groups of constituents represented by the four NGOSS Views (Business, System, Implementation, and Deployment) defined in the NGOSS Lifecycle. The SID uses UML to formalize the expression of the needs of a particular view. Used in combination with the eTOM business proces
15、s and activity descriptions, it becomes possible to create a bridge between the business and Information Technology groups within an organization, providing definitions that are understandable by the business, but are also rigorous enough to be used for software development. The SID model takes insp
16、iration from a wide variety of industry sources, but its principal origins are the AT Personalization and IPTV Consumer self-service; Mass customization of IPTV Services; Flexible value network chains; and Easy accommodation of a (wide) range of resource types from a (wide) range of suppliers. IPTV
17、operators are looking to implement more flexible and cost effective operational platforms to support key business drivers such as the implementation of new IPTV Services and greater operational efficiencies. End-to-end monolithic silos incorporating hardwired business logic are being replaced by hor
18、izontal layers of end-to-end flow-through systems from customer facing systems at the top to the element management systems nearest the network, in which each layer manages its corresponding data and processes and communicates to the layers directly above or beneath it. This leads to the enormous bu
19、siness benefit of being able to separate the business logic from the massive technical complexity at the network level. IPTV operators also hope to take advantage of efficiencies inherent in management of a converged NGN that simultaneously supports voice, video, data, and mobility services. 2.3 Arc
20、hitecture and Service Context The physical and logical context for management transactions involving IPTV network and service resources described in this document is based entirely on the framework defined in ATIS-0800002, IPTV Architecture Requirements 2, and ATIS-0800007, IPTV High Level Architect
21、ure11. Figure 1, shown below, provides the physical network topology defined by IPTV Interoperability Forum (IIF), see reference 2. Hierarchical components include Super Head Ends (SHEs), Video Hub Offices (VHOs), Video Serving Offices (VSOs), and Delivery Network Gateways (DNGs). ATIS-0300092 Figur
22、e 1: IPTV Physical Topology The IIF IPTV Architecture Requirements document 2 introduces the notion of the “logical domains” typically shaped by the network or business boundaries of the IPTV system and the “sub-domains” representing the functional components inside each “domain”. The IIF High Level
23、 Architecture document 11 builds on these concepts, referring to them as “(logical) domains” (with “logical interfaces” between them) and “functional components” respectively. Figure 2 provides a view of logical domains and interfaces that are in scope when the OSS architecture for management of IPT
24、V Services is developed. Figure 2: IPTV Domains and Interfaces 11 ATIS-0300092 12 The four logical domains are shaped by the administrative boundaries of business entity roles. Although a reasonable and effective abstraction, this decomposition does not preclude that a single business entity impleme
25、nts more than one logical domain. In addition, business entities can span portions of these logical domains. More than one business entity may be involved in implementation of each logical domain when providing IPTV service to a customer. The logical interfaces between the domains are not always lin
26、ear and/or one to one as described below. For example, the IIF- IPTV Architecture Requirements document 2 includes several requirements (such as: IIF.ARCH.HOME.02, 04, and 03) that implies an ability for a single home network to have multiple NPs, multiple IPTV SPs, and separate NP and IPTV SP. Inte
27、rfaces between domains of the same type (such as between IPTV Service domain to another IPTV Service domain) are out of scope for this work. Following are the four logical domains as defined by the IIF: 1. Consumer: The domain where the IPTV Services are consumed. In the Consumer domain, a single te
28、rminal may be used for service consumption, but also a network of terminals and related devices may be present for this purpose. 2. Network: The domain connecting the Consumer domain and the Service domain. IPTV services usually transverse a core (or backbone) network, a metro aggregation network, a
29、nd an access network - all using a variety of IP-based technologies - to reach the Consumer domain. 3. Service: The domain providing an IPTV Service to the subscriber. 4. Content: The domain that owns or is licensed to sell content or content assets. Although the SP is the primary source for the Con
30、sumer domain, a direct logical information flow may be set up between Content domain and the Consumer domain - e.g., for rights management and protection. This interface is out of scope for this work. Following are the four logical interfaces used for management and operations between the logical do
31、mains: 5.oss Consumer/Network: The Consumer/Network logical interface. This interface is a subset of interface number 5 as depicted in Figure 1 of 11 addressing OSS aspects. 6.oss Network/Service: This interface is a subset of interface number 6 as depicted in Figure 1 of 11 addressing OSS aspects.
32、The network and the service roles can be provided by the same administrative entity or by different administrative entities (that are separated by external business boundaries). Consequently, the Network/Service logical interface is either of the following two interfaces: a. The external Network/Ser
33、vice logical interface - This is the Network/Service interface when the Network domain and the Service domain are managed by different administrative entities. b. The internal Network/Service logical interface - This is the Network/Service interface when the Network domain and the Service domain are
34、 managed by the same administrative entity. 7.oss Service/Content: This interface is a subset of interface number 7 as depicted in Figure 1 of 11 addressing OSS aspects. The service and the content roles can be provided by the same administrative entity or by different administrative entities (that
35、are separated by external business boundaries). Consequently, the Service/Content logical interface is either of the following two interfaces: a. The external Service/Content logical interface - This is the Service/Content interface when the Service domain and the Content domain are managed by diffe
36、rent administrative entities. ATIS-0300092 b. The internal Service/Content logical interface - This is the Service/Content interface when the Service domain and the Content domain are managed by the same administrative entity. 8.oss Consumer/Service: The Consumer/ Service logical interface. This int
37、erface is a subset of interface number 8 as depicted in Figure 1 of 11 addressing OSS aspects. Figure 2 of the IIF HLA specification 11 (see Figure 3 below) depicts Principal Functions within the IPTV Sub-Domains. Figure 3: IPTV Functional Decomposition Detailed description of the architectural comp
38、onents found in Figures 1, 2, and 3 can be found in documents published by the Architecture Task Force of the ATIS IPTV Interoperability Forum. 2.4 Scope The scope of this document encompasses development of a high-level OSS reference architecture for the IPTV SP. It addresses and describes all oper
39、ational processes that will be impacted significantly either by the business relationship context described above or by the implications of management of resources needed to deliver IPTV services to customers. It makes use of and is consistent with all standards-based definitions for converged NGN m
40、anagement, including those provided by ATIS, TMF, ITU-T, ETSI, DSL Forum, 3GPP, 3GPP2, IETF, and OASIS. Detailed functional requirements are derived from these descriptions. Table 1 provides a complete listing of these management aspects. 13 ATIS-0300092 14 The document scope also includes identific
41、ation and characterization of key management interfaces found at the 5.oss, 6.oss, 7.oss, and 8.oss logical interface points, and especially those involving an external business arrangement. 2.5 Overview of existing relevant specifications This section provides a brief overview of the current landsc
42、ape of OSS standards and IPTV specifications, as well as a brief overview of the evolving NGN architecture specification. In view of the emerging need for solid OSS for IPTV, a careful analysis of the current relevant specification activities in the industry is essential. In general, these activitie
43、s are undertaken in standardization bodies and industry forums, as well as by management-related research projects. 2.5.1 The NGN Architecture The NGN architecture as defined by ATIS-PP-1000018 5 borrows heavily from the IMS specification work done by 3GPP. A major concept in IMS and NGN is the prem
44、ise of removing any dependence of service delivery from the physical network itself (aside from the obvious physical constraints of bandwidth). This layered approach allows NGN to provide a truly access-independent service delivery mechanism that opens up the entire network for third-party service d
45、elivery and quickens the provision of a diverse set of NGN services. However, there has also been a lot of work put into service control in the network to ensure that NPs are not simply “bit-pipe“ providers, with all the service revenue going to SPs. It should be noted that the NGN Architecture allo
46、ws for multiple service control functions, not just Core IMS. As shown in Figure 4 (taken from 5), the NGN architecture is divided into the Transport Stratum and the Service Stratum. The Transport Stratum covers transport functions and associated control functions up to the IP layer. The Service Str
47、atum includes functions that handle the layers above the IP layer. Both the transport and service strata have relationships with End-User functions. The Application function group interacts via the Application-to-Network Interface, enabling the use of NGN capabilities to create enhanced services. AT
48、IS-0300092 Figure 4: NGN Architecture EndUser terminals that talk to the NGN will authenticate with the Network Attachment Control Function (NACF), receive an IP address, get configuration information, etc. Once attached to the network, terminals will communicate directly or indirectly with the RACS
49、 in order to accomplish functions including getting desired Quality of Service (QoS) for communication and getting permission to access certain resources. Application Support and Service Support functions within the Service Stratum include functions such as the gateway, registration, authentication, and authorization functions at the application level. These functions are available to Applications and End-User functional groups. Both the Service and Transport Strata contain functional User Profile databases that represent a combinatio
