NGOSS标准及其进展

陈颖慧

摘要：本文对TMF在电信运营支撑系统方面的标准现状进行介绍，对电信运营支撑系统标准中的关键问题研究现状进行阐述，最后对电信运营支撑系统标准尚存在的问题及下一步研究方向进行讨论。
关键词：NGOSS、eTOM、标准
1 引言
全球电信市场逐步走向开放化，电信用户的数量迅速增加，用户需求不断变化，新业务、新技术不断推陈出新，电信运营商面临着日益激烈和复杂的竞争环境。在新的环境下，电信运营商要立足于从提高自身竞争力出发，不断提高网络运营、业务供应、服务质量、企业管理和经营决策的水平。电信运营商的经营模式已经从传统的"面向网络"的经营模式逐步转变到"面向客户"的经营管理模式，不断向信息化、市场化和个性化的方向迈进。这种经营管理模式的转变使得对电信运营管理水平的高要求提到了重要日程上来。
国际电信联盟（ITU）提出的电信管理网（TMN）框架，长久以来一直指导着电信领域的网络管理建设。TMN在其信息体系结构模型中从逻辑分层、功能分布的角度出发定义了一个分层管理结构，这四个各有侧重而又互相关联的层次由底至上依次是：网元管理层（EML）、网络管理层（NML）、业务管理层（SML）和商务管理层（BML）。这个模型通过分层实施的管理功能、由下至上的信息综合来实现对电信网的管理。
在新的电信经营管理模式下，按照"面向客户"的经营原则，各层管理功能的规划都应贯彻以客户为中心的主线，把客户化需求、市场化需求切实反映到各个层次的管理功能实施中去。而这个过程则恰恰是一个基于商务视点的自顶向下的规划设计过程。不同于从技术/实现视点出发的自下而上构建的TMN分层结构，运营支撑系统（Operations Support System，OSS）则是在新的电信运营环境下提出的一种以TMN的分层结构为指导、结合自顶向下的商务设计原则、融合客户管理、业务运作和网络管理为一体的电信企业运营管理解决方案。
近些年来，国际民间组织TMF（电信管理论坛）一直致力于运营支撑系统（OSS）的相关研究。发展到现阶段，OSS已被在其基础上发展而来的NGOSS（New Generation Operations Support System或New Generation Operations Systems and Software ）体系所代替。TMF的成员由电信运营商、系统集成商、软件供应商和设备供应商组成，这些不同类型的成员分布在NGOSS供应链的不同位置。
本文将对TMF在电信运营支撑系统方面的标准现状进行介绍，对电信运营支撑系统标准中的关键问题研究现状进行阐述，最后对电信运营支撑系统标准尚存在的问题及下一步研究方向进行讨论。
2 TMF的运营支撑系统标准概览
2.1 TMF的标准文档形式和发布程序
TMF的技术研究和标准制定工作以工作组（working teams）为单位来进行开展，例如与NGOSS研究相关的工作组目前有四个，有研究基于eTOM的商务处理框架的，有着重研究共享信息数据建模的，有研究与技术无关的NGOSS体系构架的，也有研究NGOSS产品的一致性测试的。工作组的研究成果将以文档形式体现，以便TMF成员共享最新成果。TMF所认可的文档形式包括：
? 指南（Guidebooks）：定义框架和策略方向的指导性文档；
? 商务协定（Business Agreements）：描述商务需求的文档；
? 信息协定（Information Agreements）：定义特定信息模型的文档；
? 规范（Specifications）：描述需要遵照执行的要求的文件；
? 接口实现规范（Interface Implementation Specifications）：结合TMF中的一些合作实施项目输出的关于产品或接口实现方面的文档；
? 技术报告（Technical Reports）：对一些公共关注问题的阐述、评估、分析或建议性质的文档。
在TMF的工作流程中，以上任何一类文档的批准和释放均需经历以下过程：
1) 工作组草案（Team Draft）：工作组内产生的文档草案；
2) 成员草案（Member Draft）：在工作组草案稳定一段时间后，由工作组提交可供TMF所有成员访问的成员草案；
3) 成员评议版（Member Evaluation）：在提交成员草案的3～6个月内，工作组提交可供TMF策略管理组审议批准的成员评议版文档；
4a) TMF批准版（TM Forum Approved）：获TMF批准的文档；
4b) 成员公开版（Member Version）：未获TMF批准、但可向TMF所有成员公开的文档；
4c) 完全公开版（Public Version）：未获TMF批准但可公开的文档。
2.2 运营支撑系统标准概览
TMF提出了对NGOSS体系进行描述的四个视点，而这四个视点又恰恰与实现运营支撑系统的各个阶段是相对应的。1）商务视点：对应分解商务流程、定义需求模型的阶段；2）系统视点：对应设计逻辑系统构架、定义合约接口、建立数据模型阶段；3）实现视点：对应基于特定技术的实现、验证过程；4）运行视点：对应系统运行过程。
TMF与NGOSS相关的工作主要集中在以下几方面：
? 定义商务处理框架和处理流程模型；
? 在已定义的商务处理框架的基础上定义系统框架；
? 通过一系列的合作项目开展多供应商环境下系统解决方案的实现和展示；
? 向TMF成员提供NGOSS的研究成果和资源共享，如文档、模型、程序源码等。
表1是TMF现阶段公开的NGOSS相关标准一览表（注：已被新标准所替代的文档不再列出，如GB910电信运营图TOM已被GB921增强电信运营图eTOM所替代）。
表1 NGOSS相关标准一览

GB909描述技术集成图（TIM），从系统视点对OSS逻辑系统构建的原则、合约定义原则和可采用的技术方向进行了阐述。其第1部分描述了基于构件（Building Blocks）的分布式逻辑系统构架，构件间通过已注册的合约进行交互。构件的设计采用面向对象概念，将实现细节被隐藏在内部，只有合约是对外可见的。其第2部分阐述了TMN体系结构的借鉴意义，强调运营支撑系统着重于提供端到端运营流程自动化的解决方案，对在系统实现时可能采用的技术（如Web/JAVA、CORBA、CMIP/SNMP）及其应用场合进行了说明。TIM的研究成果已以适当的形式被NGOSS体系采纳，如基于构件的分布式结构，而TIM中的构件（Building Blocks）和NGOSS中的组件（components）是相当的。
GB914描述系统集成图（SIM），从系统视点给出了基于逻辑商务组件（LBC，Logical Business Components）的组件信息结构。SIM按功能划分定义了若干个管理域（Management Domain），而每个管理域由若干个逻辑商务组件组成。LBC通过相关的合约与其它组件进行交互，通过LBC的适当组合可为运营商提供针对特定商务流程的方案设计。SIM可看作是细化NGOSS组件的一个参考视图。
GB920给出了NGOSS体系框架的概览。NGOSS提供的是一套面向组件的、基于即插即用方式进行松耦合集成的分布式体系结构。NGOSS体系应定义具备标准合约接口的分布式组件、基于公共合约的组件特性、共享数据信息服务以及与技术无关的通用意义上的基础框架。
GB921中的增强商务运营图（eTOM）从商务视点描述了支持端到端运营流程自动化的商务处理框架。eTOM从TOM发展而来，GB921对商务流程进行了分解和细化，给出了eTOM的分层视图以及相关流程描述。
GB922及相关附件定义共享信息/数据（SID）模型。针对SIM中定义的管理域，采用UML类图对各管理域所用到的共享信息进行数据建模，定义了相关的数据对象、对象的属性及属性值类型。
TMF051针对NGOSS可能给NGOSS供应链的各方（服务提供商、系统集成商、独立软件供应商、设备供应商）带来的利益、成本和风险进行了分析，并提出了各方投入NGOSS建设应达到的目标以及决策模型。
TMF052提出了对NGOSS框架的需求，如互操作性、可扩展性、可移植性、后向兼容性、可靠性、灵活性、数据可达、易管理、易测试等需求，并从服务提供商、系统集成商、独立软件供应商、设备供应商四个主体的不同视角对需求进行了详述。关于对NGOSS功能组件的需求，TMF052建议参考SIM（GB914）中的描述。
TMF053描述了基于组件的分布式体系的构建原则，给出了与技术无关的NGOSS体系结构，并对NGOSS体系结构的关键要素（如合约、组件、分布透明性、流程控制、共享信息数据管理）作了细化阐述。其附件B“合约规范”利用UML类图和XML Schema对合约的内容和格式作了形式化的要求。
TMF050定义了NGOSS一致性测试的测试内容和测试原则。测试内容涉及对公共通信平台、合约接口定义和流程控制的要求以及SIM中定义的管理域的功能覆盖情况，测试范围应涵盖TMF052、TMF053即GB914中的相关要求。
TMF055和057分别对CORBA技术和XML技术以及它们的相关研究与应用现状进行了简单介绍，并对它们在NGOSS体系中的可能应用进行了简要分析。
3 运营支撑系统标准中的关键问题研究现状
3.1 NGOSS体系构架
前面已经提到，NGOSS结合了组件技术和分布式技术，提供基于分布式组件的松耦合体系构架。NGOSS体系构架应满足如下主要特征：
1）商务处理流程的抽象
将商务处理流程的抽象与组件相分离，达到单个组件与商务处理流程逻辑的无关性，使得组件的集成更灵活，也大大提高了组件的可用性和重用性。
2）NGOSS组件
NGOSS组件表示一个可配置的软件实体，NGOSS组件可分为两大类：应用组件和系统服务组件。组件间利用已定义好的合约接口进行交互。商务处理流程通过顺序调用一系列的应用组件的合约接口来实现，应用组件可通过调用系统服务组件来完成自身的部分功能。
3）共享信息服务
共享信息服务向各独立的组件提供共享信息，该服务通过提供统一的标准合约接口供各组件来访问。共享信息服务的接口不仅提供数据读、写、增、删等操作，还提供数据排序、访问控制等服务。
4）合约发现
合约用于描述组件的调用接口，合约的内容包括接口的语法和语义规定。商务处理流程通过调用组件的合约接口来实现。所有组件都要通过合约注册服务对其相关的合约进行注册，以便于其它组件的访问。合约交易服务则支持系统在运行时动态发现组件合约，以支持组件的即插即用。
5）公共通信平台
NGOSS体系采用分布式通信软总线作为公共通信平台。
基于以上特征，TMF053给出了与技术无关的NGOSS体系结构，该结构划分为基础框架服务、策略框架服务和商务服务三大组件域。商务服务通过合约规范提供可分解的商务功能单元以供商务处理流程调用，而框架服务提供商务应用组件间的交互能力，包括商务流程管理、共享数据管理、安全及支持分布透明性的命名服务、注册服务、目录服务、交易服务、调用服务等。
3.2 增强电信运营图（eTOM）
在多变的竞争环境下，能够迅速实现业务配置、客户入网及解决业务质量问题对运营商来说尤为重要。eTOM的提出旨在帮助业务/网络运营商将信息管理、业务管理、网络管理较好的集成在一起，以实现低成本的端到端运营流程自动化，并支持运营商之间的互联互通。
eTOM从电信运营图（TOM）发展而来，但它作为一个更宽泛意义上通用商务处理框架比TOM复杂得多。图1给出了eTOM的高层视图。

从图1可看出，运营商需要和一些外部实体及内部实体进行交互，这些实体在eTOM中被分为五大类（图1中的椭圆图例）：客户（运营商的销售对象）；供应商或合作方(运营商的购买或合作对象)；运营商的股东；运营商内部职员；其他相关方 (包括政府、媒体、竞争者等)。
图1给出了一个水平分层、垂直分块的商务处理框架视图。总体上eTOM包括了三大处理域：策略、基础设施与产品域（Strategy, Infrastructure & Product）；运营域（Operations）；企业管理域（Enterprise Management）。运营域是eTOM的核心；策略、基础设施与产品域侧重于策略及生命周期的管理，为运营域提供功能性的支持；企业管理属于通用性交叉领域，并不是eTOM的重点。
图1中所示的运营域以及策略、基础设施与产品域，水平划分为四个管理层：市场、产品及客户管理层；业务管理层；资源管理层；供应商/合作方管理层。与TOM相比，eTOM融合了电子商务的概念，提出了与其他供应商/合作方的关系管理以及供应链的发展和管理（供应商/合作方管理层）。
在eTOM的运营域中，垂直分割为四类端到端的处理流程服务。其中FAB（业务指配Fufillment、业务保障Assurance和计费Billing）三类服务是从TOM继承而来的，而运营支持准备（Operations Support & Readiness）包括为支持FAB实时实现的系列准备活动。
在eTOM新提出的策略、基础设施与产品域中，垂直分割为三类端到端的处理流程服务：策略与调配（Strategy & Commit）、基础设施生命周期管理（Infrastructure Lifecycle Mgmt）、产品生命周期管理（Product Lifecycle Mgmt）。
基于eTOM的商务处理流程框架是独立于被管网络、被管业务和企业组织结构的，GB921中还给出了更低层次的流程分解与分析，运营商可根据自身特定需求套用这个框架来进行自身NGOSS系统的商务处理流程映射。
3.3 合约（Contract）定义
NGOSS中的合约提供组件间进行交互的规范接口，是实现商务处理流程自动化的基础。NGOSS体系中所使用的合约均应有标准定义，以实现即插即用的分布式组件集成。目前TMF并没有定义具体合约的相关规范，但TMF053B中对合约的内容和格式作了要求：
? 合约应具有名称和版本号以被识别；
? 合约可被继承和扩展；
? 合约可包括一个或多个操作；
? 合约应具备文本的行为描述；
? 合约可包括一系列参数，每个参数应有名字、类型和用法说明（如输入参数、输出参数、返回参数等）；
? 合约可规定一系列的前置条件、后置条件以及适当条件下应产生的异常。
4 结语
TMF现有的规范在NGOSS体系结构、商务处理流程框架、高层需求及共享数据模型方面都给出了较详细的描述和定义，为电信运营商构建新一代运营支撑系统提供了宝贵的方向性指导，具有可贵的借鉴意义。但TMF现有的NGOSS规范间相互关系较为零散，不同规范对某些相同概念或相似概念所采用的术语描述也不一致，还不足以形成一套自成体系的规范来保证NGOSS系统的设计与实现。
因此，为保证NGOSS规范的实用性，相关的研究工作还需作进一步开展。首先，NGOSS旨在提供端到端的运营流程自动化支持，GB921对商务处理流程需求进行了细化，GB920中规定了商务处理流程通过顺序调用一系列的应用组件的合约接口来实现的规则。这就需要对应用组件进行细化，对应用组件的合约接口进行定义，对特定商务处理流程与相关合约接口的顺序调用关系进行映射。目前TMF仅在GB914中提出了对LBC（逻辑商务组件，可看作NGOSS体系中的应用组件）的简单功能性描述，而在应用组件的合约接口定义以及商务处理流程的控制和映射方面还是空白。另外，TMF053提出了与技术无关的通用意义上的NGOSS体系结构，但还需定义和实现相关的基于特定技术的体系构架，如基于CORBA和EJB技术的映射。

参考文献：
[1] 陈颖慧，电信运营支撑系统的标准及其进展[J]，中兴通讯技术，2003.3
[2] TMF相关标准（见表1）