1 说明

     目前EPON ONU软件升级主要有IP方式(如SNMP/TR069)和TFTP+OAM两种。前者需占用大量IP地址，且配置ONU的IP地址需要手工操作，给业务开通和系统维护带来较大不便；后者对每个ONU的升级都需要单独进行OAM报文的协议交互，因为OAM报文本身发送速度和长度的限制，不能较快地交互升级。

     对于海量终端的EPON OAM软件升级，为避免对维护的影响，要求尽量缩短升级时间，此外，为提升用户满意度，需要实现在业务不中断的情况下进行软件升级。最后，在软件层面上，版本下载异常中止时应及时回收版本内存。

     本文将基于电信EPON设备技术要求V3.0所规定的软件升级过程，提出上述三个问题的优化改进方案，以供开发和维护人员参考。

2 升级过程简介

     本节将简要介绍基于TFTP协议和OAM机制的ONU软件远程升级功能。该机制描述详见《中国电信EPON设备技术要求V3.0_201106》规范“ONU软件升级要求”一节。

     为便于描述问题，本文将软件升级过程分为“版本下载”和“激活加载”两个过程。

     ONU软件下载的交互流程如图2.1所示。

图2.1 ONU软件下载的消息交互示意图

     OLT通过GET命令获得ONU信息，当确定ONU需要更新软件/固件时先向ONU发送File Write Request消息。ONU返回File Transfer ACK消息(Block number=0)后，则OLT开始将要写入的文件分段通过File Transfer Data消息依次发送给ONU，并且只有当ONU返回File Transfer ACK确认消息(Block number>0)后，OLT才能发送下个分段。当OLT成功发送完所有的分段后，再通过End Download Request消息校验ONU下载软件的正确性，并判断该软件是否写入非易失性存储器。收到End Download Request消息时，ONU返回End Download Response消息作为应答。此时，软件下载过程结束。

     激活和加载软件镜像的消息交互流程如图2.2所示。

图2.2 ONU软件激活和加载的流程

     ONU成功下载了有效的软件镜像后，根据具体的应用策略，OLT可以立即发送Activate Image Request消息，激活所下载的软件镜像。正常情况下，ONU返回Activate Image Response以确认激活操作成功，然后ONU自动使用另一存储区的软件镜像重新启动。收到ONU返回Activate Image Response消息后， OLT发送Commit Image Request消息，要求ONU将该备用存储区的软件设置为ONU启动时的缺省加载软件。ONU被Commited以后，ONU以后的启动均使用该软件镜像，原有主用存储区的软件变为备用存储区。

     Activate Image Request/Response和Commit Image Request/Response消息分别是用来激活和设置缺省加载(Commit）新下载的软件。在实际应用中根据实际需求应可通过EMS灵活应用Activate Image Request/Response和Commit Image Request/Response。

3 升级优化

3.1 快速批量升级

     批量升级ONU时，最简单的策略就是按照下载、激活和加载的流程，依次ONU1、ONU2直至ONU n。不幸的是，这种升级策略将耗费大量时间，因此简单而不实用。

     若要加快批量升级速度，关键是尽可能逼近“并行化”升级。

     激活提交过程主要耗时在于Activate操作后的自动重启，但因其类似异步机制故优化空间不大；而版本下载过程主要耗时在于File Transfer Data消息的分块传输，因此本节也将集中讨论分块传输的“并行化”。

3.1.1 广播方案

     该方案中，OLT通过File Transfer Data(广播LLID)消息将Data Block发给PON口下所有在线ONU，除此之外的版本下载控制消息仍采用单播LLID方式，如图3.1所示。

图3.1 ONU批量升级加速示意图(广播方案)

     如图所示，广播方案可实现并行下载，从而极大地缩短批量升级时间。因为File Write Request等版本下载控制消息仍采用单播方式，因此可控制对哪些ONU进行升级。

     但这仅仅是个看上去很美的方案，还需注意：

     1) 考虑到ONU处理速度和链路时延存在差异，OLT分块传输时不需要等待所有ONU返回的File Transfer Ack消息；而在分块传输结束后根据ONU返回的End Download Response(单播LLID)消息，单独对下载失败(如丢包等)的ONU进行版本下载。

     2) 考虑到链路丢包或ONU读写差错，若OLT在分块传输过程中收到ONU返回的Error消息，可强制将上一分块重传3次(广播)。

3.1.2 流水线方案

     为简化图示，将OLT发送给ONU m分块n的File Transfer Data消息记为FTD_m/n，其File Transfer Ack应答消息记为FTA_m/n。OLT对PON口下某个数目的ONU并发发送FTD_m/n消息，在收到ONU k应答的FTA_k/n应答消息后立即发送FTD_k/(n+1)消息。此处“某个数目”取决于OLT支持的并发线程数目。

     流水线方案如下图所示：

图3.2 ONU批量升级加速示意图(流水线方案)

     如图所示，在File_Writing_OLT_Timer时间里，可以看作对3个ONU并行分段传输。进一步可以看出，该方案其实是减少了等待FTA消息的“闲余”时间，也就是所谓的流水线(pipeline)技术。

     该方案可实现准并行处理，且不需要修改电信规范定义的消息。

3.2 业务无中断升级

     如前所述，普通的升级过程需要经历Download→Activate→Commit等操作。其中Activate操作会引起ONU自动重启，从而中断业务。因此，要实现升级过程中业务不中断，就不能在下载版本后立即Activate。

3.2.1 推荐方案

     电信规范里ONU软件激活和加载的状态迁移如图3.3所示。在图中，U1表示image 1是激活且缺省加载，image 2是未激活且非缺省加载；U2表示软件image 1是未激活且非缺省加载，image2是激活且缺省加载；U3表示image1是未激活且缺省加载，image2是激活且非缺省加载；U4表示image1是激活且非缺省加载，image2是未激活且缺省加载。

图3.3 ONU软件激活和加载的状态迁移图

     其中，U1和U2状态可视为初始状态，分别表示image 1和image 2为主用存储区。

     对于图中各箭头标记，说明如下(注意，图中Activate操作含重启操作)：

     1) U1状态Activate①后，迁移至U3状态。

     ONU挂起当前已激活的软件镜像image 1，使用未激活的有效的软件镜像image 2重新启动。此时，U3状态中运行镜像image 2。

     2) U3状态Reboot②后，迁移至U1状态。

     ONU重启时，因新加载的软件镜像image 2未曾commited，故仍然使用原有的软件镜像image 1。此时，U1状态中运行镜像image 1。

     3) U3状态Commit③后，迁移至U2状态。

     ONU将当前备用存储区的软件image 2变为主用存储区的软件，作为ONU启动时默认加载执行的软件，而主用区的软件镜像image 1变为备用区的软件(可视为主备区标志互换)。ONU以后重启，均将使用新主用存储区的软件镜像image 2。

     4) U1状态Commit⑤后，迁移至U4状态。

     备用存储区的软件image 2变为主用存储区的软件，作为ONU启动时默认加载执行的软件，而主用区的软件镜像image 1变为备用区的软件。

     5) U4状态Reboot⑥后，迁移至U2状态。

     ONU重启后使用新主用存储区的软件镜像image 2。

     6) 需注意重启后状态位的迁移，U4备用区image 1的Active状态位由Yes变为No，而主用区image 2的Active状态位由No变为Yes，表示image 2激活且缺省加载。

     可见，U1-->U3-->U2或U2-->U4-->U1为Download→Activate(自动Reboot)→Commit流程(普通升级)，记为流程一。U1-->U4-->U2或U2-->U3-->U1为Download→Commit→人工Reboot流程，记为流程二。

     进一步可见，流程一和流程二的最终状态及状态位完全相同，不同之处在于Reboot的时机。采用流程二，即Commit后等待用户手工断电重启，从而达到升级业务不中断的效果。

     进一步可见，软件升级后(Commited)，再次执行Activate(自动Reboot)→Commit或Commit→人工Reboot均可实现版本回滚的效果。注意，此处的“版本回滚”不同于因电力或链路故障等导致升级失败或ONU无法正常工作时的的“自动回滚(Back-Rolling)”功能。

3.2.2 对照方案

     作为对照，下面给出曾了解到的两种策略：

     1) 版本下载后，OLT不会自动下发Activate和Commit操作，而在需要采用新版本时手工或策略方式下发Activate和Commit操作；

     2) 版本下载后，OLT等待ONU再次上线时(如开关电或拔插光纤) 自动下发Activate和Commit操作，从而在不影响ONU业务的情况下自动控制ONU重启和更新版本。

     上述两种策略均可实现下载过程全天候进行。

     其中，策略1需要维护人员在合适的时间手工(批量)完成Activate和Commit操作，对于现网的海量FTTH终端而言不太方便；策略2待用户手工重启ONU终端或拔插尾纤时，OLT自动发起Activate和Commit操作，其优点在于“自动”，其缺点在于手动重启ONU后再次被重启(Activate)，从用户感知上业务开通较慢。

     对比策略1和2，上节所述的Download→Commit→Reboot(用户重启)策略可能更好，即先下载版本并执行Commit操作，待用户重启ONU时即可加载新版本。

3.3 下载异常时内存回收

     软件升级过程中，ONU在收到发送OLT的File Write Request消息后，通常会申请版本大小的内存空间，并在回送End Download Response消息后释放内存。

     若版本下载过程异常中止，ONU可能还未释放内存，此时将会就占据大量单板内存空间。如果OLT不再重新下载，则占用大块内存可能会影响语音等其他业务正常运行。

     现实中版本下载中断后长时间不再重新下载的概率应该不大，但不应排除其可能性。

     以下提供一种版本下载异常时ONU侧内存回收的参考方案：

     ONU在收到File Write Request消息后，启动一个定时器Td(暂定60s)。该定时器在ONU回送End Download Response消息后停止。

     1) 若在Td时长内收到File Write Request等下载消息，则重启定时器，且超时计数清零；

     2) 若在Td超时后仍未收到下载消息，则超时计数加1并重启定时器。

     3) 在连续超时3次后认为此次下载异常中止，停止定时器，清空超时计数并释放内存，退出升级状态。

     考虑到End Download Request消息处理可能存在的重传间隔，建议该定时器时长大于30s。