3G网管架构研究报告

 

2.      术语定义和缩略语

英文缩写

英文全称

中文全称

OneCM

One China Mobile

“一个中国移动”

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为指导,基于总线和组件构建的技术中立架构,统称为OneOSSOpen 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,数据以xmlInfoset方式以Soap协议进行传递,标准开放,安全性差,不保证可靠

非实时大数据量交换

Corba

跨平台、跨系统、跨语言、性能高,稳定,扩展性好,系统耦合度高

实时大数据量

MQ/JMS

基于MOM,可靠,成熟商业,有事务支持,

数据可靠性要求较高或实时大数据量

FTP

文件传输协议

文件数据

Socket

基于TCP/IP协议进行点对点传输

实时或者大数据量

中间表

同步到某一个数据库

不同平台的应用

 

4.3.4. 接口OSS/J可行性

OSS/JOSS Through Java)是以JAVA技术为动力的新一代的OSS/BSS解决方案。是由OSS Through Java Initiative的工作组提出,这个工作组由众多的业界新技术的倡导者(例如MotorolaNokiaSun, BEA, IBM)派出的专家于2000年组成,工作组利用JAVA技术,为OSS/BSS定义实现了一系列的开放的标准API,提供给OSS/BSS的开发者使用。同时,OSS/J并不是要定义另一个通用的OSS/BSS集成框架。OSS/JAPI定义遵守了NGOSS eTOM enhanced Telecom Operations Map)的规定,并以该框架为基础,提出了采用JAVA技术的实现方案,因此,对所有接口统一采用OSS/J规范中的接口保证相互调用。

 
<think>嗯,用户这次明确询问网管架构图的绘制方法,结合提供的引用资料来看,ta需要的是实用指导而非理论阐述。用户可能是IT运维人员或系统设计师,正在搭建或优化网络管理系统。 引用[1]强调了架构图的价值——图形化呈现比文字快6万倍的理解速度,这解释了用户为什么跳过资产表直接关注绘图方法。引用[4]提到的终端定位技术其实暗含了架构图需要呈现的关键要素:终端设备、链路关系、安全分区。有趣的是,用户特意排除引用[2]的百度Echarts工具,说明需要专业拓扑工具而非通用图表库。 上次对话讨论过快速排序,但当前问题完全转向IT架构领域,需要重置上下文。用户没有追问细节,可能希望获得可直接落地的步骤,因此回复要结构化: 第一步工具选型要突出专业网络绘图工具(如Visio)与自动发现工具的区别,引用[2]失败的Echarts尝试恰好佐证这点。第二步的数据采集需要呼应引用[4]的终端定位案例,把IP地址、设备类型等抽象字段具体化。特别要注意分层设计原则,因为引用[3]提到WLAN网管平台时强调"理论架构到实施"的递进关系,这提示架构图必须体现逻辑层到物理层的映射。 安全要素单独成步是因为引用[3][4]都强调安全策略,需要展示防火墙位置、隔离区等。最后的版本控制则是引用[1]"知识传承"主张的延伸——老专家的图为什么有价值?关键在于持续更新迭代。 最后的参考范例采用树形拓扑而非环形,因为引用[4]三次提到"交换机端口模块",证明企业网常见层级结构。用户没提云架构,所以暂时不引入AWS等图标库。 相关问题设计成阶梯式:从工具选择(实操)到标准规范(理论),最后落点到故障定位场景(应用),这样既呼应引用内容又形成完整学习路径。用户若对自动化工具有兴趣,可能会接着问"如何用Python生成架构图",当前先埋下CMDB的钩子。 </think>以下是网管架构图的系统化绘制方法及关键要素,结合行业实践和引用内容整理: --- ### **一、核心绘制流程** 1. **工具选型** - 专业工具:Visio(分层拓扑)、Draw.io(免费协作)、Lucidchart(云架构) - 自动化工具:NetBrain(自动发现网络拓扑)、SolarWinds Network Topology Mapper *注:需规避纯关系型工具(如ECharts桑基图),专注拓扑表达能力[^2]* 2. **数据采集** 通过网管平台获取: ```mermaid graph LR A[设备发现协议] --> B(SNMP/NetFlow) C[终端定位数据] --> D(IP-MAC-端口绑定表)[^4] E[配置库CMDB] --> F(设备型号/链路关系) ``` 3. **分层设计原则(关键!)** | 层级 | 要素 | 示例组件 | |------|------|----------| | **物理层** | 硬件位置 | 机柜/光纤/交换机端口[^4] | | **逻辑层** | 网络分区 | VLAN/安全域/云可用区 | | **服务层** | 应用交互 | API网关/负载均衡器[^3] | | **监控层** | 运维视图 | 告警链路/性能探针[^3] | 4. **动态信息集成** - 用颜色标记设备状态(红-故障/黄-预警/绿-正常) - 叠加实时流量热力图(参考ECharts热力图层[^2]) --- ### **二、架构图必备要素** ```plaintext 1. 系统边界 ──►[互联网]── │ 2. 关键节点 ▼ ──►[防火墙]──[核心交换机]←─▶[备份链路] │ 3. 冗余设计 ├─[接入交换机A]─▶终端组1 ├─[接入交换机B]─▶终端组2(故障隔离区[^4]) │ 4. 监控触点 └─[性能探针]→●→网管平台[^3] ``` --- ### **三、行业最佳实践** 1. **故障定位辅助** - 在架构图中嵌入设备定位功能(点击交换机→显示所连终端列表[^4]) - 标注历史故障点(如:“2024-06 端口模块异常导致办公室断网”[^4]) 2. **安全策略可视化** ```mermaid graph TB 互联网 -- 访问控制 --> 防火墙 防火墙 -- 策略组1 --> DMZ区 防火墙 -- 策略组2 --> 内网数据库 内网数据库 -. 审计告警 .-> SOC[安全运维中心[^3]] ``` 3. **版本管理** - 使用Git保存架构图迭代历史(对应“老专家图纸传承”需求[^1]) - 添加变更记录: `v2.1 新增云服务区 | 2024-05-01 | 修订人:李工` --- ### **四、参考范例** ![简化架构图](https://via.placeholder.com/400x200?text=核心层-汇聚层-接入层+树形拓扑) *图:典型三层网络架构(箭头标明数据流向)* ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值