基于面向对象技术的OMCI实体的实现方法

摘要

一种基于面向对象技术的OMCI实体的实现方法，涉及GPON光通信技术领域，其包括将OMCI实体划分为基类和继承基类的派生实体类，将所述基类和派生实体类分别用面向对象的方法封装，封装完成的OMCI实体，利用OMCI实体间关系，实现多个OMCI实体互联，通过类的继承实现OMCI实体的扩展。本发明不需要增加额外的处理流程，方便扩展并且现有功能不受影响。

说明书

技术领域

本发明涉及GPON(Gigabit-Capable PON，宽带无源光综合接入 标准)光通信技术，尤其涉及一种基于面向对象技术的OMCI(ONT  Management and Control Interface，ONT管理和控制接口)实体的实 现方法。

背景技术

GPON系统一般采用点到多点的网络结构，由局端的OLT (Optical Line Terminal，光线路终端)、用户侧的ONU(Optical  Network Unit，光网络单元)以及ODN(Optical Distribution Network， 光分配网络)组成。其中，OLT通过OMCI协议来管理ONU，并完 成相互间通信。在ITU-TG.988中定义了ME(Managed entity，管理 实体)，ME由实体属性、实体动作、通知以及实体间关系组成，是 ONU业务和资源的抽象。在OMCI中，与协议无关的MIB (Management information base，管理信息库)由OMCI实体的实例 组成，通过对ME的存取访问，实现对ONU的管理。

目前已公开的OMCI实现方案中，中国专利CN101764647A中 采用嵌入式数据库实现MIB管理模块，重点关注于对数据库的查询 和更新功能的实现。中国专利CN103354508A公开一种OMCI管理 方法，重点在于OLT和ONU之间通信的接口。在实际应用中，业务 需求是不断变化的，因此OMCI实体也需要不断的进行相应的增加或 修改。但在上述方案中，并未详细描述关于OMCI实体的设计方案， 如果OMCI实体的设计方案不合理，那么，对OMCI实体进行增加 和修改，除相关实体的定义和方法外，还可能需要增加或修改其他的 处理流程，甚至对现有功能产生影响，不能方便的满足当前实际业务 需求。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种基于面 向对象技术的OMCI实体的实现方法，不需要增加额外的处理流程， 方便扩展并且现有功能不受影响。

为达到以上目的，本发明采取的技术方案是：一种基于面向对象 技术的OMCI实体的实现方法，包括：将OMCI实体划分为基类和 继承基类的派生实体类，将所述基类和派生实体类分别用面向对象的 方法封装，封装完成的OMCI实体，利用OMCI实体间关系，实现 多个OMCI实体互联，通过类的继承实现OMCI实体的扩展。

在上述技术方案的基础上，所述OMCI实体包括实体属性、实体 操作和实体间关系，所述实体属性作为类的属性，即实体属性作为数 据成员；所述实体操作作为类的方法，即实体操作作为成员函数。

在上述技术方案的基础上，对OMCI实体的共性特征进行归纳， 构造一个基类，作为构造其他OMCI实体类的基础框架，该基类中包 含了实体的公共属性、以虚函数的形式实现规范中定义的所有的实体 可能支持的操作。

在上述技术方案的基础上，所述派生实体类分为告警实体基类、 性能采集实体基类和普通实体类。

在上述技术方案的基础上，所述告警实体基类是将告警的基本操 作抽象为一个类，作为所有告警实体的父类。

在上述技术方案的基础上，所述性能采集实体基类是将性能采集 的基本操作抽象为一个类，作为所有性能采集实体的父类。

在上述技术方案的基础上，所述类的继承包括子类继承自父类， 但是子类除继承自父类的方法外，允许根据需求对父类中的方法进行 重写。

在上述技术方案的基础上，所述OMCI实体间关系包括显式指向 关系和隐式指向关系。

在上述技术方案的基础上，所述显示指向关系体现为：类的一个 属性为被指向实体的指针，通过指针对实体进行关联，并且被指向的 实体为预先创建的实体。

在上述技术方案的基础上，所述隐式指向关系体现为：相关联的 实体类具有相同的实例号属性值，每个实体类将维护一个关联实例表， 存储与其关联的实体，在创建实体时，需要检查是否存在关联实体， 若存在则将其加入关联实例表。

本发明的有益效果在于：

1、可扩展性。OMCI协议是允许扩展和自定义的，因此当需要 增加新的功能时，只需要在现有系统的基础上，增加新的实体的定义 及实现，就可以完成子功能增加，而不需要增加额外的处理流程，方 便扩展并且现有功能不受影响。

2、可维护性。当前系统的某个功能需要修改时，由于类的封装 特性，只需要对该功能涉及的部分类的属性及方法进行修改，降低了 系统的耦合性。

3、可重用性。当芯片方案进行改变时，由于OMCI协议是不变 的，因此，通过对芯片适配部分代码的抽象和剥离，可以极大的复用 原有代码，甚至可以使用同一套代码通过编译选项的控制以支持不同 芯片方案的设备，达到降低维护成本的目的。

附图说明

图1是本发明的实体类继承关系图；

图2是本发明的实体关系示意图。

附图标记：

101－基类；111－告警实体基类；112－性能统计实体基类；121 －告警实体类；122－普通实体类；123－性能统计实体类。

具体实施方式

以下结合附图及实施例对本发明作进一步详细说明。

封装是将数据和处理该数据的方法封装为一个整体，体现于类的 抽象，是面向对象的重要特性。OMCI协议将所有的管理量抽象成了 OMCI实体的形式，每个实体作为一个受管理量成为OMCI MIB信息， 因此将每个OMCI实体抽象为一个类；根据实体间的指向关系，将多 个实体类关联，最终实现OMCI业务模型的创建。

一种基于面向对象技术的OMCI实体的实现方法，包括：用面向 对象的方法封装OMCI实体，所述OMCI实体包括实体属性、实体 操作和实体间关系，所述实体属性作为类的属性，即实体属性作为数 据成员；所述实体操作作为类的方法，即实体操作作为成员函数。具 体的，将OMCI实体划分为基类和继承基类的派生实体类，对OMCI 实体的共性特征进行归纳，构造一个基类，作为构造其他OMCI实体 类的基础框架，该基类中包含了实体的公共属性、以虚函数的形式实 现规范中定义的所有的实体可能支持的操作。实例是同一个实体的不 同个体，因此采用类的实例化进行抽象。所述派生实体类可能有多种 分类方法，本实施例中，所述派生实体类分为告警实体基类、性能采 集实体基类和普通实体类。所述告警实体基类是将告警的基本操作抽 象为一个类，该告警实体基类继承自基类，作为所有告警实体的父类； 所述性能采集实体基类是将性能采集的基本操作抽象为一个类，该性 能采集实体基类继承自基类，作为所有性能采集实体的父类；所述普 通实体类直接继承自基类。

将所述基类和派生实体类分别用面向对象的方法封装，封装完成 的OMCI实体，通过类的继承实现OMCI实体的扩展，类的继承包 括子类继承自父类，但是子类除继承自父类的方法外，允许根据需求 对父类中的方法进行重写。并且，利用OMCI实体间关系，实现多个 OMCI实体互联。OMCI实体间关系包括显式指向关系和隐式指向关 系。所述显示指向关系体现为：类的一个属性为被指向实体的指针， 通过指针对实体进行关联，并且被指向的实体要首先创建；所述隐式 指向关系体现为：相关联的实体类具有相同的实例号属性值，每个实 体类将维护一个关联实例表，存储与其关联的实体，在创建实体时， 需要检查是否存在关联实体，若存在则将其加入关联实例表。

上述过程中，将每个OMCI实体抽象为“类”，如表1所示，为 OMCI实体的组成和类的组成部分的对应关系：实体的属性抽象为类 的数据成员；动作和通知抽象为类的成员函数。例如在ITU-TG.988 协议定义了实体MAC bridge port configuration data，该实体包含： Managed entity id、Bridge id pointer等14个属性，这14个属性抽象 为其相应实体类的数据成员；该类支持4个基本操作Create，delete， get，set，这4个操作相应的抽象为实体类的4个成员函数；并且该 实体支持Port blocking等告警操作，则在其实体类中需要定义告警 Port blocking的检测、上报等处理函数。而其与其他实体的关系体现 为两种，一种是隐式关联，通过相同的Managed entity id属性值与其 他实体关联；另一种为显式关联，例如其Bridge id pointer属性则确 定了其指向的MAC bridge service profile实体。

表1

由图1所示，为OMCI实体类的继承关系。由于OMCI实体具 有相似的结构，每个OMCI实体都由实体属性、实体方法、以及实体 间关系几部分组成，进而不同实体类的成员函数中必然会有部分的方 法具有相似的操作，因此直接为每个OMCI实体构造一个类，会产生 大量的冗余代码。而面向对象的继承性很好的增加了代码的重用性， 它由类的派生功能体现，子类可以直接继承其父类的全部描述，并且 可以进行修改和扩充。基于以上描述，设计一种实体类的继承层次结 构，包括以下步骤：

步骤S101：创建基类。基类101是所有OMCI实体类的父类， 其是所有实体一般方法的抽象，即将OMCI实体的一些共有属性如： ME ID归纳在此类中作为该类的数据成员；将OMCI协议中规定的 基本操作如：create、delete、set、get等操作作为该类的成员函数， 以虚函数的形式实现这些方法；以及每个实体内部可能用到的共同的 操作方法归纳在此类中。

步骤S102：基于基类101派生实体类。根据OMCI实体的功能 不同，将OMCI实体分为3类来处理：普通实体、含告警操作的实体， 以及性能统计相关实体。普通实体：普通实体类122直接继承自基类 101，其除了可继承基类101的属性及方法以外，还可以根据自身的 功能特性，定义特有的属性及方法。含告警操作的实体：相比普通实 体，含告警操作的实体需要进行告警相关的一系列操作。因此，定义 告警实体基类111作为告警操作实体的共同父类，该类直接继承自基 类101，共享基类101的所有方法，并且定义告警实体的共同操作： 告警的产生、上报、消除等基本操作。告警实体类121是一个具有告 警操作的实体的抽象，其是告警实体基类111的子类，并在此基础上， 增加该实体的特有属性及方法的定义。性能统计相关实体：与含告警 操作的实体类似，性能统计相关的实体需要进行性能采集、统计等一 系列操作。因此相似的，性能统计实体基类112作为含性能统计功能 的实体的父类，在基类101的基础上增加了性能采集、统计的相关基 本操作；性能统计实体类123是具有性能统计功能的实体的抽象，其 是性能统计实体基类112的子类，并且定义自己特有的方法和特性。 在上述的过程中，子类除继承自父类的方法外，允许根据需求对父类 中的方法进行重写，这样当发送一个通用消息时，可以根据接收消息 的对象不同，实施不同的处理方法。

OMCI业务需要通过多个实体共同实现，实体间关系也是OMCI 实体描述的一个重要组成，通过实体间的关系将实体进行关联组成了 业务模型。实体之间的关系可分为两大类：显示指向关系和隐式指向 关系。

如图2所示，显示指向关系：显示指向关系由箭头表示，实体A 显式指向实体B。显示指向关系在代码中体现为实体A存储一个指向 实体B的指针。因此，应该首先创建实体B的实例，然后再创建实 体A的实例，并且设置实体A的属性为实体B的指针，根据OMCI 协议规定，实体删除与创建的顺序相反，则本实施例中，在删除实体 A的实例时，应该首先检查是否已经删除与其关联的实体B的实例。 隐式指向关系：实体C和实体D通过实例号隐性关联，如创建实体 C的实例时，需要检查是否存在一个与其实例号相同的实体D的实例， 如存在则将此实例加入其关联实例列表中。

OMCI业务模型的下发过程只要不违反上述实体关系规则即可， 因此方式不是唯一的，只要下发的模型完整，则认为配置就是正确。

本发明不局限于上述实施方式，对于本技术领域的普通技术人员 来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰， 这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细 描述的内容属于本领域专业技术人员公知的现有技术。