网管融合建模的思考

渠 凯 ，李 洪 ，彭志婷 ，申文俊

（1.中国电信股份有限公司网络运行维护事业部 北京 100032；2.中通服软件科技有限公司 上海 200127）

1 引言

电信运营商都经历了网络的快速发展期，在这个过程中为了满足快速发展的需要，运营商引入了很多不同的厂商以加快网络的部署建设，同时网络的不断发展也带来了网络设备、技术的不断革新和变化，导致电信网络普遍存在设备多、厂商多、技术多、专业多、网络多的现状。

网管系统是伴随着网络发展起来的，而运营商在建设网络时又往往要求厂商为一套设备提供一套网元管理系统，于是可以看到，在整个网管领域中网元管理系统（element management system，EMS）繁多，有的甚至一两个设备也建有一套EMS，这不仅带来了巨大的维护工作量，同时也给跨厂商、跨网络端到端的网络管理带来了难题。运营商很早就意识到了这个问题，因此，在过去一段时间里，从专业网管到综合网管也一直是其关注的重心。

随着电信的发展，集约化运营的诉求日益强烈，体现在网管领域，就是对网管的综合化和集中化的要求，这也是未来建设智能网管的基础。过去一直困扰于多专业、多厂商、多设备信息难以统一的问题，随着智能网管的到来，又增加了更多的难度和要求。因此必须要寻找更合理的方式，既能够刻画目前存在的多元网络，同时又能够适应未来不断变化的需求，即本文探讨的问题。

2 统一建模方法

2.1 传统的建模方式

网管信息首先是设备和网元信息，在IT系统中为描述这些信息，通常会通过数据建模的方法在数据库中保存，这种数据模型被称为实体（entity）-关系（relation）（ER）模型，即将所有的数据都归为两个大类：实体和关系。其中实体是物体存在的客观描述，关系是实体与实体之间的联系。

过去的网管建设中，由于EMS是分厂商建设，专业网管又归口相应的分专业管理部门建设，因此这些系统大多只关注本专业、本网络甚至本厂商的设备，在数据上也只考虑本系统内的数据，多采用简而化之、分而治之的建模思想，将每种设备都独立地映射为一类实体，分类和映射都由网管系统自行确定，有的分类甚至细分到型号。

通过传统的按专业分类的方式，可以得到如表1所示的示例。

表1 传统按专业分类示例

从示例可以看到，很多网管按专业—分类—类型将设备类型映射为一种独立的实体来进行管理，这种方式被称之为“硬建模”。“硬建模”的方式就是简单地将在自然世界中看到的事物分类直接映射为IT系统的一类实体，一一对应。这种建模方式更像一个对象枚举的过程，需要把现实世界中的事物穷举出来，否则很难保证分类的完整性。而且一旦有新的事物出现，无法归入现有的类别，就势必要增加一种实体才能描述。比如有轿车、货车、客车3类实体，当出现跑车的时候，发现它不能归到现有的实体里，必须得增加一类新的实体叫“跑车”，而如果在这一粒度上建立物理模型，就会发现每类实体都会建立一张实体表，多一类实体就会多一张表。

另一个方面从ER模型观察，由于关系是建立在实体与实体间的，对于N类实体来说，关系的种类理论上可以达到C2n+1=n(n+1)/2种，因此随着实体种类的增加，关系种类将呈二次幂级数增长，其直接后果就是数据表众多，模型极不稳定：只要增加一种新的实体，就要增加一张表，只要增加一张表，就要增加多种实体间关系；而按照对象关系映射（object relational mapping，ORM）原理，应用方面也必须同时增加对新实体、新关系的处理。

随着网络和业务的发展，这种建模方式将必然导致模型的不断膨胀，应用也会随着不断修改而增加。开发人员会觉得需求在不断变化，而客户则会觉得需求响应太慢。这样不断地修改、打补丁，不断增加实体和关系，在网络快速发展的今天，最终会引发实体和关系的爆炸，系统再也无法承担负荷，只能再建设新系统。如果不改变方法论，这样的场景会周而复始，不断出现。

2.2 统一建模方法论

在过去的几年中，笔者一直在探索一种更为灵活的物理建模方式，一方面能够适应不断变化的网络和应用的需求，另一方面又不至于产生实体和关系的爆炸，使得模型相对比较稳定。

从方法论上看，一般数据建模的过程分为4个步骤，如图1所示。

（1）识别目标场景的数据需求。

（2）以数据需求建立实体的概念模型，理清概念实体间的关系，形成ER图。

图1 一般数据建模过程

（3）基于ER关系对实体进一步分解和细化，设计数据的逻辑模型，体现实体及关系的分类和继承。

（4）基于实体分解，建立实体的数据存储模型，设计数据库表结构。

分析过去的建模过程，可以发现对于目标场景的识别没有问题，以中国电信对网络的经验，理解场景需求基本没有偏差，但是从目标场景到概念模型、概念模型到逻辑模型、逻辑模型到物理模型的过程，就会发现以往缺乏合理的抽象，比如前面提到的“硬建模”，就是将目标场景直接映射到模型的结果。

其次，分析在电信业里比较成熟的模型，比如SID模型以及中国电信OSS 2.8规范模型。笔者发现这些模型虽然对网络的概念进行了抽象，在实体继承和分类上也给出了方法，但是这些模型都仅仅停留在逻辑模型这一个层次，对于从逻辑模型如何转换到物理模型既没有给出方法也没有给出指导原则，导致在具体实践中，人们往往依照自己的理解从逻辑模型中直接映射为物理模型，实际上是另一种程度的“硬建模”。

因此，在统一建模方法中，必须强调抽象的价值，将抽象与验证结合起来，如图2所示。

图2 统一建模方法过程

经过一定抽象后的模型将更具有代表性和普适性。但是也需要注意到目标场景的范围，抽象必须保留在合理的范围，高度的抽象将带来处理的复杂性，因此需要在抽象与现实之间选择一个平衡点，既提高模型的抽象度和稳定度，也考虑相当的易用性，而不至于过度泛化。

2.3 统一建模在网管领域的应用

网管领域的数据建模是电信网到IT系统的抽象过程。什么是电信网？按照百度百科的解释，电信网是构成多个用户相互通信的多个电信系统互连的通信体系，是人类实现远距离通信的重要基础设施，利用电缆、无线、光纤或者其他电磁系统，传送、发射和接收标识、文字、图像、声音或其他信号。从这个定义可以看出电信网络实际是由具备一定电信能力（传送、发射和接收信号）的设备、设施、系统等实体组成的可相互联通的网。

因此，基于以上对电信网的认识，笔者认为目前的分立网络是电信网按照不同的能力划分出来的，具有不同能力的设备、设施和系统。依照这个假设，可以放弃传统的“分而治之”的“硬建模”方式，基于一套抽象的模型统一管理各专业网络，按照能力的不同区分不同类型的实体，采用“从共性→个性”的分专业建模思想，先不分专业刻画共性，形成电信网的统一模型，再通过刻画个性，还原专业网络的现实复杂性，以此保证核心数据模型关系稳定、紧密且关系四通八达。

图3 实体与关系继承示意

对于电信网来说，其关键的特性是形成网络，而形成网络的基本元素是点和线，因此可以从点、线、网为基础扩展网络模型，这样可以将ER模型进行层次扩展，如图3所示。左边是实体的继承图，右边是关系的继承图，黑色加粗线条表明关系是建立在对等的两个实体之间。从E抽象实体出发，依据点、线、网扩展，可以得到点→设备→SDH设备这样的继承层次，同样也可以得到点—线→端口—电路→SDH端口—传输电路这样的R抽象关系的继承层次。这是两棵实体与关系继承树。

下一步，当把这两个继承的层次关系再进行表达，就得到另外两棵继承树，如图4所示。

图4的ET/RT两棵树就是用来描述实体与关系继承关系的，即元数据。进一步思考，实际上是将模型建立在树的叶子节点上，也就是“硬建模”的方式，不管是实体还是关系，节点数都非常多，而一旦将模型向上移一层，可以带来模型的巨大简化。但问题是模型抽象后，细粒度的差异化信息如何体现？这就需要用到ET/RT这两棵树来描述。

因此笔者的策略是在大类基础上，引入元模型建模，通过元数据的配置定义细粒度数据模型，使得细粒度数据模型灵活、可扩展。模型是对现实世界的抽象，而元模型是对模型的抽象和描述，软件可针对元数据编程，快速实现新需求。即通过大类+元数据的建模思路，根据网络共性，抽象出核心领域模型，通过元数据支持个性化特征，支持具体网元、链路的创建和配置。带来的好处显而易见：

·核心模型稳定，反映网络本质；

·信息查找全、速度快；

·外围模型可根据不同新业务、新技术进行配置，快速支持新客户、新业务。

3 电信融合建模

3.1 融合建模的目标场景

统一建模方法论是理论基础，有了这个理论基础，如何将网管要管理的对象抽象出大类来呢？

正如综合资源的大类建模经历了一系列归纳的过程一样，其现有的模型是值得借鉴的，除此以外，需要描绘综合网管的主要应用场景，分析在应用场景中综合网管提供的基础功能。例如局数据的作用场景，网管配置是一个过程，局数据体现为配置到网元上的所有配置数据。下面以网元为例，简单描述一下网元的生命周期以及局数据的作用场景，如图5所示。

·工程：综合网管里，资源系统作用于工程建设，在工程建设中创建设备，设备上电后，EMS建好，形成网元。出厂的局数据配置在上电的时候配好。上电时，综合网管采集到的非结构化数据，便是设备的出厂配置。资源和网元的关联关系可在工程建设结束的时候，把网元回填回资源。

·建设：即内部组网，从资源系统下工单到网管施工。在组网的时候要保证资源和网元已经对应上了。网元的组网在资源系统完成。网元的施工就是在网管里面完成网元的配置过程，再下发给EMS完成网元的开通。工单所带的局数据，最终的结果体现为结构化数据——在综合网管中新增的实体和实体关系。

图4 类型继承示意

图5 网元—场景流程示例

·配置：即外部组网，其过程和内部组网类似。

·割接：老的设备断电后，将新的设备上电，局数据没有在新的设备配置，这时要恢复局数据，需从综合网管获取原来的局数据，下发数据到EMS执行。

以此类推，可分析出电路、系统等的应用场景。

3.2 大类建模的建议模型

在考虑模型之前，首先需要分析需要建模的数据有哪些，除网管本身管理的业务对象外，在统一建模方法论的基础上，业务对象对应到业务模型中已经过高度的抽象，业务对象和物理存储并不是“硬建模”方式的一一对应，物理模型只能反映出实体抽象后的结果，因而还需要元数据刻画实体的定义以及实体的存储，即通过元数据的刻画，反映出在物理模型高度抽象和稳定后，各类实体及规格的差异，对于代码来说，只要通过访问元数据就能够知道不同规格的定义以及存储，可以屏蔽业务对象的各种差异提供标准的元数据服务。另外，对于业务数据，有些是可以规范定义的，例如可以枚举的属性值，这些约束需要通过主数据来定义。除此以外，要建设一个应用系统，有其必不可少的系统数据和应用数据来支撑系统的完整功能应用。

因此，网管所要管理的数据范畴有以下几种。

·元数据：与实体定义、存储有关的类型数据。

·主数据：与规格有关的可规范定义的枚举、约束数据。

·网管数据：存量数据、增量数据。

·系统数据：系统用户、权限、审计、功能相关数据。

·应用数据：表现层数据，与界面、操作相关的对象。由于篇幅有限，本文针对网管数据的建模来探讨。

3.2.1 大类继承关系

建模的顶层即为上文描述过的网管的管理对象：实体和关系。实体和关系都可以继承。树上的一个节点决定了一类对象，具备特定的存储位置。从数据的几何结构往下分，实体可以有点、线、集合，关系可以分为点—点关系、线—线关系、点—线关系以及集合和点、线、子集合的关系。在此思路之下，从实体的功能本质以及大类间关系的收敛出发，定义出第3层的大类。数据建模在第3层上，因此需保证第3层的大类的抽象合理、收敛、稳定，并和实践论证切合。

另外，根据前述现实依据的梳理，需知哪些数据的生命周期是在网管域中管理的、其主数据是在网管维护的，哪些数据的生命周期是在其他域中管理的、其主数据是在其他域中维护的，而网管只是因为一些应用需要，将数据同步过来供上层应用使用。例如机架、机框这类硬件数据，又或是站点、子区域这类区域数据以及机房这样的设施数据。

抽象出的网管对象如图6所示。

3.2.2 大类之间关系

如上述方法论所提到的，关系的建模是从第3层开始，在继承图（图6）的第3层之间建立稳定的关系模型。图7中的网元核心、事件、配置这三大块为网管着重关注的模型，资源关联域和产品服务域属于关联域。关联域表现为从各域视角观察网管存量所得到的投影，通过此投影可以关联存量实体在不同域的视图。

3.3 技术验证说明

上文对数据模型进行了抽象，在方法论中提到抽象的结果需要进行验证，下面对抽象的结果进行简单的验证。这里只做合理性验证，复杂的、完备性的验证需要全面的网络数据，本文就不再深入。

首先，以交换网管为例，交换网元、交换板卡、交换端口可分别对应到模型中的网元、模块、端口大类中，而交换网管中的平台属于系统的范畴，可对应到模型中的网这个大类。两台交换网元中的信令、中继链路都是线形实体，可统统归到链路这个大类当中。中继群、信令链路组作为链路集合仍然呈线性，依然可以放在链路实体中。而中继群和中继链路的管理则体现为链路和链路大类中的并联关系。交换网管中，网元上配置的码号数据是局数据中的一种，可放到码号大类中统一管理。

然后分析数据网管，数据网元、数据板卡、数据端口依然可以对应到模型中的网元、模块、端口大类中，而数据网中的ATM电路、DDN电路、FR电路等也都是线形实体，可统统归到链路这个大类当中。而数据网管中的各种ATM网络、DDN等属于管理网络，另外VPN属于虚拟网范畴，仍然是点—线集合，都可放在网这个实体中统一管理。还有一类用于实现用户和业务的隔离、标识、管理和控制的数据，像VLAN，实际标识了一条链路或一个网络划分出来的数据通道标识，若管理上要求细化，可作为网实体管理，若管理上只需要管到VLAN号，可作为像码号一样的局数据放在码号这个大类中管理。

在此基础上，如果有交换和数据合一的网元，需要融合建模，建模方法也是一样。例如，一个既有宽带板又有语音板的ONU设备，当网管融合后，依然可以作为一个融合的网元放在网元大类中建模，而其中的宽带和语音板只是作为网元所具有的两个模块建模，而无需像传统的网管分专业，在交换网管和数据网管中分别建立各自的网元实体。

以此类推，传输网管、EPON网管抑或是基于IP技术的传输网管都可以用类似的方法建模，因为这是高度抽象了网络的几何本质的大类，不因为网络技术发生改变而改变，只要分析实体在网络中的存在本质就可以找到模型中对应的大类，非常稳定可靠。

4 资源域和网元域的关注点

在OSS领域中，对于网络数据方面，不管是数据的规模还是数据的重要性，资源域和网元域都是最关键的部分。从数据的整个生命周期来看，这两者是密不可分的，但也各有侧重点。

资源域管理资源数据的整个生命周期，用于支撑整个电信网络从设计、施工到开通、运行和退网完整的过程，希望在IT系统里再现真实网络的生命过程，并支持它的变化，因此资源域重在描述网络组成。

图7 网管对象关系

网管域是网络能力的体现，更关注网络的现态。网管的操作直接即时反映到现实网络，同时现实网络的变化也即时反馈到网管，引发网管数据的变化，因此网管域重在描述网络能力。

过去更倾向于关注资源域和网管域的差异，因此这两个部分的建设和管理都是分离的，一定程度上导致了这两部分数据的不一致，包括数据模型不一致。

在智能网管发展的今天，网管需要从综合化到自动化再到最终实现智能化，OSS数据综合化已成为智能化建设的基础，而融合建模使这一目标成为可能，这里的融合不仅包括专业融合，而且站在OSS的高度看跨域也需要进一步融合。

5 结束语

从核心模型的稳定性为主出发，笔者建议建模时应从网络结构出发考虑网管的管理对象在网络组成中的本质差异，避免将业务因素混淆到建模的本质要求中去，区分哪些是组网的基础，哪些是应用的需要。

在对网管融合的模型建议中，笔者着重描述了网管数据的模型建议。对于元数据、主数据、系统数据、应用数据的建模没有关注。特别是元数据的建模，是支撑网管融合后的统一建模的基础。

网管融合后的统一建模，模型中的大类和大类关系趋于稳定，不稳定的部分如大类细分后的细粒度类型的属性及细粒度实体间关系约束等可通过元数据的灵活配置来体现。元数据模型是对实体模型的建模，考虑元数据模型的建模时，需明确实体构成，例如类型、规格、组件、扩展等。元数据的本质是关于数据的数据，元数据的内容包含了数据范围、数据部署和数据结构。

总的来说，建模思路是指导模型建立的方向，网管融合建模更需要从以往纷繁复杂的多个凌乱的管理对象中跳脱出来，从网络构成本质出发，抽象出稳定的数据模型。

1 TMF.The Information Framework(SID)V13,2013

2 中国电信集团公司.CTG-MBOSS OSS网络资源管理系统规范 V2.8，2009

3 周三保.浅谈数据仓库建设中的数据建模方法.http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0803zhousb/,2008