一：mib作用和实现基本思路
GPON开发难点
1：OMCI协议及业务的理解；
2：Mib upload表的设计。
OMCI协议以及业务的基础是G.98x标准的理解。
注：以下只涉及ME基本的配置或信息upload.
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：抽象出共性。
这一部分的设计比价麻烦，个人也没有想到更好的办法，后面再总结。
总结：如上只是个人一种软件设计思想，但绝对不是唯一和最好的。