GPON学习总结--mib upload设计

一：mib作用和实现基本思路

GPON开发难点

1：OMCI协议及业务的理解；

2：Mib upload表的设计。

OMCI协议以及业务的基础是G.98x标准的理解。

注：以下只涉及ME基本的配置或信息upload.

MIB(Management Information Base)GPON系统中以ME格式存储每个ONU信息，并保持和ONU本地信息一致。

MIB表的作用：

1：从mib中直接获取onu的部分基本信息；

2：保存用户配置信息。

MIB表的生成：ONU上线时完成ONU本地和OLT端MIB表同步。

在G.984.4/G.988中描述了MIB同步的多种情况，比如ONU冷启动上线，ONU掉线后上线以及MIB表异步时策略等。目前实现建议(参考华为实现思路)采用极其暴力但是容易实现的方式。

OLT端ONU每次上线时完成如下三步：(omci_mib_upload_routine)

1：删除当前OLT端保存的ONU的mib表；

2：复位ONU端本地信息；

3：mib upload/mib upload next消息完成ONU远端和OLT端mib的同步。

ONU掉线时不做任何处理；

ONU删除时清除对应的mib表。

优点：

1：流程简单，代码实现难度低，易于维护；

2：减少了实时同步。

缺点：

1：暴力，在每次ONU上线时都“重头再来”，但实测upload一个ONU MIB时间在1-2秒内，应可以接受此时间损耗；

2：如果出现了OLT端和ONU端数据异步，只能重启ONU.

二：MIB表软件设计

                                                         

图2.1  mib表软件设计关系图

如上图2.1，显示以单个ONU为索引的动态数据结构。所谓动态

1：系统中ONU的个数是动态的，前文提到只有上线的ONU才会分配Mib表内存；

2：每个ONU支持的ME(或用户配置需要支持)动态;

3：每个ME支持的inst个数不确定，有些ME只支持一个inst,有些ME支持多个inst. （inst概念难以理解，举个简单的例子。以ME 9.3.4:MAC Bridge Port Configuration data为例，

它要描述的是每个端口的config,因此每个端口就是这个ME的一个inst，比如说ONU有四个以太网口，那么这个ONU的ME至少包含四个inst).

这种动态业务的软件设计，我们常用的数据结构就是链表或者树。

1：ONU层的设计直接使用数组，预分配最大可支持ONU数；

2：考虑 G.988 常用ME的个数大概在50个左右(估计)，这个数量级使用哪种数据结构差别都不会太大；索引值ME ID,作为key值

3：inst属于ME的内部数据，inst个数相对比较少，链表开销比较少。

说明：这种设计不会影响添加/查找/删除效率，前提是你对内存的使用不那么在意。

对内存的影响

1：ME/ME-Inst内存动态分配/删除，需要考虑内存管理；

2：占用内存会比较大；

3：大量ONU上下线时会存在内存不断nallioc/free,避免内存泄露；

4：内存重入保护。mib软表上层会出现多个任务调用，可以对ME为单位进行信号量保护。

ME/ME-Inst数据结构设计

1：每个ME参数不同，对应的数据结构不同；

2：抽象出共性。

这一部分的设计比价麻烦，个人也没有想到更好的办法，后面再总结。

总结：如上只是个人一种软件设计思想，但绝对不是唯一和最好的。