EPON ONU软件升级的若干优化方案

 

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被Committed以后,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未曾Committed,故仍然使用原有的软件镜像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后等待用户手工断电重启,从而达到升级业务不中断的效果。

     进一步可见,软件升级后(Committed),再次执行Activate(自动Reboot)→CommitCommit→人工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。

 

 

posted @ 2014-05-20 12:09  clover_toeic  阅读(1137)  评论(0编辑  收藏  举报