2. 术语定义和缩略语
|
英文缩写 |
英文全称 |
中文全称 |
|
OneCM |
One ChinaMobile |
“一个中国移动” |
|
OneOSS |
Open Next_Generation oriented Evolutional Operational Support System |
开放下一代网络运维支撑系统 |
|
BSS |
Business Support System |
业务支撑系统 |
|
OSS |
Operation Support System |
网络运维支撑系统 |
|
OSI |
Open System Interconnection |
开放系统互联（模型） |
|
eTOM |
enhanced Telecom Operation Map |
增强电信运营模型图 |
|
TMF |
Telecom Management Forum |
电信管理论坛 |
|
NGOSS |
New Generation Operation Systems & Software |
新一代运营系统和软件 |
|
BPM |
Business Process Management |
业务流程管理 |
3. 引言
中国移动在规范中按照“OneOSS”思路，引入TMF的相关概念，希望在3G网管建设中改变原来按专业进行建设为跨专业综合建设，面向全网进行集中监控、集中维护和集中管理，采用标准化技术体系和EAI技术提供综合解决方案，以提高运营效率、提升整体效能、发挥最大效益，从而获取竞争优势、打造世界级运营服务能力。
4. CMCC-3G网管架构介绍
4.1.技术背景
4.1.1. 中国移动OSS运维背景
中国移动作为世界上最多用户的运营商，网络结构非常复杂，涉及到设备厂商相当多，根据中国移动“OneCM”战略，今后中国移动的网管建设方式，将由3级改为2级，如下图所示：
同时目前情况网管OSS大部分是按专业建设，存在多种OSS,每一种OSS都同网络紧密相联，并且相当程度上延迟于网络发展，无法应对当前快速变化的网络产品和服务。
4.1.2. NGOSS TNA技术介绍
4.2.OneOSS框架图
中国移动提出的技术架构是以NGOSS TNA为指导，基于总线和组件构建的技术中立架构，统称为OneOSS（Open Next_Generation oriented,Evolutional Operational Support System）架构，如下图所示：
OneOSS技术架构具有如下特点：
Ø 基于已存在的系统
Ø 统一的流程调度、接口、数据模型、和访问门户
Ø 结构化、共享、层次化、合约、客户化
Ø 由系统功能结构转化系统技术结构
Ø 不直接面向被管网元
在每一个子系统中又定义如下三层技术架构：
4.3.技术选型
4.3.1. EAI总线
规范针对以前遗留下来的异构系统、应用、商务流程以及数据源构成，要求将这些应用软件和硬件有机的整合在同一个平台系统上实现信息的交互和共享，建议使用EAI技术在初级的单元式的企业应用系统建设的基础上实现更高级的企业信息系统。
EAI进行应用集成分为以下几个集成类型：
|
集成名称 |
集成说明 |
适用场合 |
|
数据集成（D2D） |
数据的规范化和标准化是数据集成的基础，数据集成的目的是形成统一的数据视图，也就是说数据模型在逻辑上必须是统一，物理上可以分布存储，即通过周期性的同步各数据库的数据来实现统一。
|
对所有的应用而言，只需通过相同的数据模型访问数据库，而无需关心各个物理数据库的模型和结构的不同，实现容易，扩展困难。 |
|
应用集成（A2A） |
以流程驱动技术为核心，通过流程与服务的有机配合达到在不同系统直接的分工合作 |
有效的解决不同系统的数据模型的一致性、技术路线的不同、软硬件平台的异构，并使企业可以快速推出新业务，以客户为中心实现个性化定制服务。 |
|
商业逻辑层集成（B2B） |
基于A2A，直接面向分布式商业对象等商业流程服务。 |
|
|
用户接口层集成（I/I） |
使用一些遗留下来接口协议 |
老系统 |
EAI实施的通常的有四个技术方案：
1) 点到点消息技术
采用点到点的客户化接口定义（API）或基于消息的中间件工具（MQ），系统间为松耦合。
2) MessageBus 集成平台技术
以交换中心或平台（对各个专业子系统的应用间的请求消息进行路由等处理）和适配器（负责连接到各个专业子应用系统），用来解决企业内部应用系统间的信息共享，系统采用基于消息总线的框架结构，集成平台完成数据转换、规则处理及交易完整性控制功能。
3) Process Integration
将工作流管理器（或流程编排系统或服务编排系统）作为业务支撑系统的核心，将业务系统构造于标准的工作流基础上，实现业务逻辑和应用逻辑的剥离。
4) WWW Integration
一般不适合于网管架构。暂不说明
4.3.2. 系统平台基础架构
规范对这一块未进行清晰定义，规范中要求整个平台按NGOSS TNA（如下图）提供基础服务，但对每一个子系统，除了三层架构之个，还要求提供一些公用服务，如日志管理、权限管理和自身管理，因此，未来在这两块之间是否需要进行互通，或者由什么系统来提供系统平台基础架构支持，还未进行清楚定义。
4.3.3. 接口实现技术比较
|
技术名称 |
技术说明 |
适用场合 |
|
WebService |
基于Http，数据以xml或Infoset方式以Soap协议进行传递，标准开放，安全性差，不保证可靠 |
非实时大数据量交换 |
|
Corba |
跨平台、跨系统、跨语言、性能高，稳定，扩展性好，系统耦合度高 |
实时大数据量 |
|
MQ/JMS |
基于MOM，可靠，成熟商业，有事务支持， |
数据可靠性要求较高或实时大数据量 |
|
FTP |
文件传输协议 |
文件数据 |
|
Socket |
基于TCP/IP协议进行点对点传输 |
实时或者大数据量 |
|
中间表 |
同步到某一个数据库 |
不同平台的应用 |
4.3.4. 接口OSS/J可行性
OSS/J（OSS Through Java）是以JAVA技术为动力的新一代的OSS/BSS解决方案。是由OSS Through Java Initiative的工作组提出，这个工作组由众多的业界新技术的倡导者（例如Motorola，Nokia，Sun, BEA, IBM）派出的专家于2000年组成，工作组利用JAVA技术，为OSS/BSS定义实现了一系列的开放的标准API，提供给OSS/BSS的开发者使用。同时，OSS/J并不是要定义另一个通用的OSS/BSS集成框架。OSS/J的API定义遵守了NGOSS eTOM （enhanced Telecom Operations Map）的规定，并以该框架为基础，提出了采用JAVA技术的实现方案，因此，对所有接口统一采用OSS/J规范中的接口保证相互调用。