一种光纤连接的树形网络结构中设备软件批量升级方法
技术领域
本发明属于电信通信技术领域,涉及以光纤为物理连接介质的嵌入式设备之间,尤其是分布式光纤直放站通信系统中设备软件的批量升级方法,具体是一种光纤连接的树形网络结构中设备软件批量升级方法。
背景技术
随着现代建筑特点的变化,日益密集的高层钢筋混凝土建筑结构给传统直放站的室内信号覆盖带来了很大影响,信号覆盖深度和质量亟待提高,原有的以一个近端设备AU通过光纤直接拖挂多个较大功率远端RRU设备为特征的宽范围、粗覆盖方式,已很难满足用户实际使用环境的需求,由此作为主流的分布式光纤通信系统覆盖方式逐渐演变为每个近端AU通过光纤拖拉多个扩展端设备EU,EU通过光纤拖挂多个微功率的拉远单元RRU,同时EU还可以继续通过光纤级联多级EU。此覆盖方式采用的树形网络结构,作为树叶的远端设备均为小体积、微功率的RRU单元,通过增加RRU的个数实现了室内高密度的无死角深度覆盖。但RRU数量的增加同时给全网设备的管理,特别是对于全网设备的升级管理带来了挑战,已有的很多批量升级方案均基于以太网连接的物理设备,设备组网及在TCP\IP协议基础上开发的各种升级应用非常丰富,实现方法较多,对于分布式光纤通信系统中AU、EU和RRU设备,自身软硬件资源有限,特别是有些模块级的RRU受成本管控在系统规划之初便无网口规划,升级管理方法根本无法像普通网络设备那样便捷,且EU和RRU设备都放于室外,分布环境复杂,不易直接接触,全网设备管理全部在AU端依靠光纤链路实现简单的数据通信,包括对EU和RRU的升级,多数情况下只能依靠先给AU上传升级包后,再由AU给EU或RRU升级,现有的很多批量升级方案不能满足系统要求,因此急需提出一种相对高效而稳定的升级方案来满足这类光纤分布式通信系统的设备升级需求。
发明内容
针对背景技术存在的问题,本发明提供一种光纤连接的树形网络结构中设备软件批量升级方法,用以解决对分布式光纤通信中简单嵌入式设备进行升级。
本发明的技术方案包括一种光纤连接的树形网络结构中设备软件批量升级方法,所述树型网络结构包括接入设备AU,扩展单元EU,射频拉远微功率单元RRU,此方案实施例中的AU与EU之间,EU与RRU之间数据交互通信采用广播方式,且这种数据广播为分层广播,AU仅能广播给所有EU,EU有两条广播通路,一条属于与AU之间互通的广播路,另外一条为与RRU互通的广播通路,此方法涉及AU给所有拖挂的EU升级和EU给所有拖挂的RRU升级,两种升级情况下的拖挂端统称为主端,被拖挂端称为从端,主端给从端批量升级包括两大步骤,
步骤1,主端批量升级开关处理,实现方式如下,
主端设置自身的批量升级开关,开关只有开启和关闭两种;主端判断自身批量升级开关由关闭变为开启或由开启变为关闭定义为有效改变状态,此时主端需以广播方式下发批量升级开关状态给所有从端,其他非有效改变状态不广播下发到从端;主端在有效改变状态出现后开启一个定时器,用于在主端和从端无交互数据后关闭批量升级;
步骤2,从端定期检查升级开关是否开启,在开关开启后开始执行与主端的升级数据交互流程,实现方式如下:
从端收到主端广播的批量升级开关为关闭状态时,结束交互,处理升级停止的各项后续服务工作;当主端广播的批量升级开关为开启状态时,由从端主动发起和主端的升级交互步骤,完成升级包的下载及处理。
主端发起对从端升级的命令之后,升级主动权交由从端,自身充当服务器功能。
主端充当服务器后,开启定时器,在定时器预先设定的时间内没有任何从端的请求后,主端自行关闭服务状态;否则定时器清空重新计时。
主端发出批量升级需求后,不用等待所有从端设备的应答数据,直接进入被动需求状态。
从端主动发起升级控制流程,根据自身运行状态决定自身的升级流程的继续和终止,不用告知主端自身已终止升级的状态。
所述从端主动发起的升级控制流程,包括准备工作的控制流程及数据传输过程的控制两大部分流程。
所述步骤2中从端的具体流程如下;
流程节点200、检查是否收到主端广播来的升级开关需求,有就进入下一个流程节点,否则继续延时一段后重新检查判断;
流程节点210、根据主端设置过来的升级开关状态进行判断分别进入下一层流程节点;
流程节点220、从端判断出主端升级开关要求为开启时进入该流程节点,此流程节点判断自身是否已经处于升级状态,自身处于升级状态时不需要进行其他动作,直接跳回流程节点200,否则进入下一个流程节点240开始升级;
流程节点230、主端升级开关要求为关闭时进入该流程节点,此流程节点判断自身是否已经处于关闭状态,在自身已处于关闭情况下直接跳转回流程节点200,否则执行下一个流程节点250;
流程节点240、由从端发起的从主端下载所需升级包文件的控制流程、升级包文件数据传输交互处理流程;
流程节点250、从端执行关闭升级的各种服务,包括保存临时升级文件,升级状态变为关闭。
所述流程节点240的具体执行流程是主端充当服务器特征后,从端从服务器下载所需文件的控制流程及数据传输处理流程,具体包括以下流程:
流程节点300、从端主动向主端发起查询升级前的准备信息,包括文件名,文件大小,文件类型,同时作为发起方在此数据包中提供与主端交互的唯一ID号,避免主端无法区分和回应从端;
流程节点310、从端延时判断主端是否对自己发起的查询回应,无回应时进入流程节点320,有回应进入流程节点330;
流程节点320、从端判断查询主端次数是否超过3次,未到3次跳转到300继续发起对主端查询,超过3次,进入流程节点360;
流程节点330、从端根据主端回应数据获取升级包的相关信息,包括大小,文件名,文件类型;
流程节点340、从端根据获取的升级包文件大小信息进行判断是否包大小异常,包过大,或包大小为0,则进入流程节点350,否则进入流程节点370进一步作判断;
流程节点350、关闭自身升级,将升级结果赋值为升级包文件大小异常;
流程节点360、关闭自身升级,将升级结果赋值为主端不应答;
流程节点370、从端根据获取的升级包文件头进行判断是否正确文件头,文件头错误则进入流程节点380,否则进入流程节点390进行实质性的数据传输;
流程节点380、关闭自身升级,将升级结果赋值为升级文件不匹配;
流程节点390、从端发起的数据传输控制流程;
流程节点400、升级数据传输完成后判断文件的校验码是否正确,校验通过进入流程节点410,校验不通过执行流程节点420;
流程节点410、关闭自身升级,将升级结果赋值为升级成功,之后根据文件类型做升级的处理,包括新文件的转移,命令等;
流程节点420、关闭自身升级,将升级结果赋值为文件保存错误。
所述流程节点390的具体执行流程如下;
流程节点500、从端数据传输开始前的准备工作;
流程节点510、从端主动请求主端发升级文件数据,请求数据中包含所需文件的数据偏移地址;
流程节点520、从端判断主端是否回应请求,无回应进入流程节点550,有回应进入流程节点530;
流程节点530、从端判断数据是否取完,取完进入流程节点540,未取完跳转到510继续请求主端发数据;
流程节点540、从端取完数据后进入相应的数据处理;
流程节点550、从端判断主端无回应次数是否超过3次,未到3次跳转到510继续发起对主端查询,超过3次,进入流程节点560;
流程节点560、关闭自身升级,将升级结果赋值为数据传输失败。
所述流程节点520和流程节点310中,从端根据主端发送数据的内容判断是否回应主端请求的具体执行流程,具体流程如下;
流程节点600、从端采用定时阻塞方式等待接收主端数据,采用该方式当真实数据到来时会立即退出执行下一步,否则会一直等待超时后执行下一步;
流程节点610、从端根据流程节点600的执行结果判断是否收到数据;
流程节点620、从端判断数据内容是否为主端发过来的终止升级要求;
流程节点630、从端判断出不是终止升级要求后进入本节点,本节点继续判断收到数据是否为本从端需要的回应数据,是则认为受到了回应,否则认为没有回应;
流程节点640、关闭自身升级,将升级结果赋值为取消升级。
本发明所提供技术方案的升级方法是在分层树形结构中特有的被动式升级,特别适合非总线结构下一对多的升级,特别是在本方案实施例的分层广播系统中。本发明稳定可靠、升级过程不影响设备的查询设置控制功能;本发明可解决不具备因特网连接特性的嵌入式设备尤其是分布式数字光纤直放站领域的近远端设备之间批量升级的问题,其操作步骤简便、成功率高、方案可延展性强,可以应用到类似的一对多批量升级需求中去。
附图说明
图1是本发明实施例的拓扑框图。
图2是本发明实施例的主端批量开关控制流程图。
图3是本发明实施例的从端批量开关控制流程图。
图4是本发明实施例的从端升级控制交互流程图。
图5是本发明实施例的从端升级数据交互流程图。
图6是本发明实施例的从端阻塞等待主端数据并对不同的内容做不同回应的流程图。
具体实施方式
以下结合附图和实施例说明本发明技术方案。
实施例中构成树形结构的设备包括:
近端信源接入单元(AU),扩展单元(EU),射频拉远单元(RRU),图1给出了整个系统组成的简要树形拓扑框图,图中AU(10)与EU(20,30,40)构成主从关系,AU(10)为主端,EU(20,30,40)为从端。EU(40)与RRU(70,80)构成主从关系,EU(40)为主端,RRU(70,80)为从端,同样EU(30)与RRU(60), EU(20)与RRU(50)同样构成主从关系,主从端与EU(40)判断相同,值得注意的是EU(20)与EU(40)不构成主从关系,两者从逻辑上平级。
实施例提供的主端给从端升级的方法包括以下步骤:
步骤1,主端批量升级开关处理,实现方式如下,
主端判断批量升级开关状态,根据有效改变状态广播给从端开关状态。
结合图2本步骤中,主端创建有一个专用任务用于升级处理,任务运行流程如下:
流程节点100、开始进行初始化的一些工作(“一些工作”:为本实施例中软件代码所需的变量进行初始化,由于本发明不具体指定特定的变量,所以初始化的一些工作由具体实施者根据自身编写代码决定);
流程节点110、判断批量开关是否有效变化,无变化就延时1秒再进行判断;
流程节点120、主端通过广播链路将新设置的开关状态广播给所有从端;
本步骤根据批量升级开关状态的有效改变发起对从端的升级要求,在发起要求完成后主端直接进入被动状态或服务器状态,此时主端开启一个定时器,在定时时间(本实施例中选取1分钟)到后检查本时段内是否有从端的数据或命令请求,有则重新设定定时器有效继续等待下一个定时时间到,否则关闭定时器,主端退出服务器状态,不再对后续从端请求响应。
步骤2,从端定期检查升级开关是否开启,在开关开启后开始执行与主端的升级数据交互流程,实现方式如下,
实施例中从端也创建有专用任务用于升级处理,结合图3说明任务的总体流程如下:
流程节点200、检查是否收到主端广播来的升级开关需求,有就进入下一个流程节点,否则继续延时一段后重新检查判断;
流程节点210、根据主端设置过来的升级开关状态进行判断分别进入下一层流程节点;
流程节点220、从端判断出主端升级开关要求为开启时进入该流程节点,此流程节点判断自身是否已经处于升级状态,自身处于升级状态时不需要进行其他动作,直接跳回流程节点200,否则进入下一个流程节点240开始升级;
流程节点230、主端升级开关要求为关闭时进入该流程节点,此流程节点判断自身是否已经处于关闭状态,在自身已处于关闭情况下直接跳转回流程节点200,否则执行下一个流程节点250;
流程节点240、由从端发起的从主端下载所需升级包文件的控制流程、升级包文件数据传输交互处理流程
流程节点250、从端执行关闭升级的各种服务,包括保存临时升级文件,升级状态变为关闭;
图4为流程节点240的具体执行流程,流程如下:
流程节点300、从端主动向主端发起查询升级前的准备信息,包括文件名,文件大小,文件类型,同时作为发起方在此数据包中提供与主端交互的唯一ID号,避免主端无法区分和回应从端;
流程节点310、从端延时判断主端是否对自己发起的查询回应,无回应时进入流程节点320,有回应进入流程节点330;
流程节点320、从端判断查询主端次数是否超过3次,未到3次跳转到300继续发起对主端查询,超过3次,进入流程节点360;
流程节点330、从端根据主端回应数据获取升级包的相关信息,包括大小,文件名,文件类型;
流程节点340、从端根据获取的升级包文件大小信息进行判断是否包大小异常,包过大(本方案实施例定义大于2M byte为过大)或包大小为0,则进入流程节点350,否则进入流程节点370进一步作判断;
流程节点350、关闭自身升级,将升级结果赋值为升级包文件大小异常;
流程节点360、关闭自身升级,将升级结果赋值为主端不应答;
流程节点370、从端根据获取的升级包文件头进行判断是否正确文件头,文件头错误则进入流程节点380,否则进入流程节点390进行实质性的数据传输;
流程节点380、关闭自身升级,将升级结果赋值为升级文件不匹配;
流程节点390、从端发起的数据传输控制流程;
流程节点400、升级数据传输完成后判断文件的校验码是否正确,校验通过进入流程节点410,校验不通过执行流程节点420;
流程节点410、关闭自身升级,将升级结果赋值为升级成功,之后根据文件类型做升级的处理,包括新文件的转移,命令等;
流程节点420、关闭自身升级,将升级结果赋值为文件保存错误;
整个240流程是主端充当服务器特征后,从端从服务器下载所需文件的控制流程及数据传输处理流程。
图5为流程节点390的具体执行流程,流程如下:
流程节点500、从端数据传输开始前的准备工作;
流程节点510、从端主动请求主端发升级文件数据,请求数据中包含所需文件的数据偏移地址;
流程节点520、从端判断主端是否回应请求,无回应进入流程节点550,有回应进入流程节点530;
流程节点530、从端判断数据是否取完,取完进入流程节点540,未取完跳转到510继续请求主端发数据;
流程节点540、从端取完数据后进入相应的数据处理;
流程节点550、从端判断主端无回应次数是否超过3次,未到3次跳转到510继续发起对主端查询,超过3次,进入流程节点560;
流程节点560、关闭自身升级,将升级结果赋值为数据传输失败;
图6为流程节点520和流程节点310中从端根据主端发送数据内容,判断是否回应主端请求的具体执行流程,流程如下:
流程节点600、从端采用定时阻塞方式等待接收主端数据,采用该方式当真实数据到来时会立即退出执行下一步,否则会一直等待超时后执行下一步;
流程节点610、从端根据流程节点600的执行结果判断是否收到数据;
流程节点620、从端判断数据内容是否为主端发过来的终止升级要求;
流程节点630、从端判断出不是终止升级要求后进入本节点,本节点继续判断收到数据是否为本从端需要的回应数据,是则认为受到了回应,否则认为没有回应;
流程节点640、关闭自身升级,将升级结果赋值为取消升级;
除以上图解说明流程节点外,还需明确流程节点350、360、380、410、420、560功能均为关闭升级后对升级过程中涉及的变量及升级文件包数据缓存的保存,处理过程一样,仅升级结果由具体所处流程节点不同而不同,在从端关闭升级后无需告知主端已关闭升级,且不用主动上报关闭升级的原因。
以上对本发明实施例所提供的主从批量升级方法进行了详细介绍,本文中应用了具体个例对本发明的原理及实施例方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。