说明
本文基于某GPON MDU产品的当前情况，提出OMCI升级的加速方案。
因时间仓促和水平限制，文中难免存在错漏和不足之处，敬请指正。
一 问题提出
根据G.988标准相关描述，软件升级过程可分为版本下载(Download)和激活提交(Activate&Commit)两个过程。
激活提交过程主要耗时在于激活操作后的自动重启，但其优化空间不大；而版本下载过程主要耗时在于分片传输，因此本文也将集中讨论分片传输的加速。
目前某MDU软件升级过程中，子卡首先接收OLT下发的版本镜像分片(Section)并写入内存，收到End Software Download消息后对内存版本进行CRC校验，校验通过后再将版本通过2000字节的分块(Block)发送给主控板。主控板接收完所有分块后进行本地校验，校验通过后将版本写入Flash，完成版本下载过程。
该产品主控版本的下载实测结果表明：ONU子卡约每50ms(Avg:53.6ms)接收一个Window，计31*32=992字节。子卡接收到完整版本后，约每60ms(Avg:68.7ms)向主控板发送一个Block，计2000字节。从开始下载到写入Flash共耗时约8.5分钟。
为便于说明，当前方案记为“串行”下载。可以看出，除去CRC校验过程，版本其实被重复下载两遍(虽然分块传输比分片传输耗时稍短)。下文将介绍“准并行”的下载加速方案。
二 解决方法
“准并行”下载，即ONU子卡每接收到N个下载窗口(Windows)，向主控板发送N×Win字节的Block，从而实现接收和发送的“准并行”，以加快下载过程。
基于Block的度量方式，“准并行”下载可细分为分块粒度和分片粒度。
2.1 窗口粒度
假设OLT和ONU协商每个窗口含32个分片(Section)，每个分片恒为31字节。则当N=2时升级加速过程如下图所示：
图2.1 OMCI升级加速窗口粒度示意图
为突出重点，图中未示出ONU对OLT升级消息的响应，也未体现本地消息交互所必须的进程协作。
START DOWNLOAD消息中携带初次计算的Block额定数目(也可由SEND BLOCK消息携带)。SEND BLOCK消息中携带Block当前序号，Block字节数以及根据窗口尺寸而调整的Block额定数目。该Block序号对应OLT下发的两个完整窗口。
关键的处理逻辑如下：
- 若(当前序号≤前次序号)或(当前序号>额定序号)，打印错序提示及前次、当前和额定序号值。
- 若收到SEND_BLOCK消息，则依次发送(当前序号-前次序号)个Block。
- 若收到END_DOWNLOAD消息，则依次发送(额定序号-当前序号)个Block。
可以看出，若当前序号始终等于前次序号，则“准并行”下载退化为“串行”下载。
注意，从OLT接收Section的代码段应确保发往主控的内存版本和Block序号正确性，亦即该代码段应根据下载窗口尺寸来调整Block大小。Block Interval时长应大于单个分块传输的处理时间。对于该产品，N≥2，即Block大小至少为2×32×31＝1984≈2000字节，但也不宜过大。
2.2 分片粒度
假设OLT和ONU协商每个窗口含32个分片(Section)，每个分片恒为31字节。则当N=2时升级加速过程如下图所示：
图2.2 OMCI升级加速分片粒度示意图
为突出重点，图中未示出ONU对OLT升级消息的响应，也未体现本地消息交互所必须的进程协作。
START DOWNLOAD消息中携带初次计算的Section额定数目(也可由SEND BLOCK消息携带)。SEND BLOCK消息中携带Section当前序号，该Section序号对应OLT下发的两个完整窗口。
关键的处理逻辑如下：
- 若(当前序号≤前次序号)或(当前序号>额定序号)，打印错序提示及前次、当前和额定序号值。
- 若收到SEND_BLOCK消息，则依次发送(当前序号-前次序号)个Section的Block。
- 若收到END_DOWNLOAD消息，则依次发送(额定序号-当前序号)个Section的Block。
- Block大小应维持在2000字节左右，过大则需强制分多块传输。
可以看出，若当前序号始终等于前次序号，则“准并行”下载退化为“串行”下载。
注意，从OLT接收Section的代码段应确保发往主控的内存版本和Section序号正确性。因分片长度固定，故Section额定数目固定，无需调整。Block Interval时长应大于单个分块传输的处理时间。对于该产品，N≥2，即Block大小至少为2×32×31＝1984≈2000字节，但也不宜过大。
三 效果评价
根据“串行”下载实测值，可估算“准并行”下载将缩短升级过程近3分钟，即加速约30%。该加速对于Flash较小下载较慢的ONU更为明显。
此外，“串行”下载向主控发送版本分块时，可能由于消息发送过快，主控CPU提包限速导致收到的消息存在未剥除消息头的概率。因而该产品子卡在向主控分块传输时进行30ms延迟。而“准并行”下载时，接收Block速度低于发送Block速度，因此不需要分块延迟。