CN103139245A - 网元升级方法及装置 - Google Patents

Abstract

本发明公开了一种网元升级方法及装置，包括：对指定的需要升级的至少一个网元进行升级版本的下载；待至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。采用本发明能够解决相关技术中近端网元升级中的重启操作会导致以近端网元为起点的远端网元业务中断的问题以及充分利用网络带宽问题。

Description

网元升级方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种网元升级方法及装置。

背景技术

为适应运营商的需求多而且变化快的现状，设备制造商不得不经常更新网元软件版本来满足新的需求。

关于网元软件版本升级，目前已有的升级方案是采用下载版本后自动重启激活版本，即网元下载完待升级软件版本后，立即进行重启激活。但是，在微波传输网络中该方案存在很大的缺陷：由于微波设备通过无线链路连接，近端网元(NE)的重启将导致所有以NE为起点的远端网元业务中断，在批量升级中，如果近端网元先下载完即重启激活版本，所有远端网元的下载及业务将中断，这是运营商无法接受的。

针对相关技术中近端网元升级中的重启操作会导致以近端网元为起点的远端网元业务中断的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中近端网元升级中的重启操作会导致以近端网元为起点的远端网元业务中断的问题，本发明提供了一种网元升级方法及装置，以至少解决上述问题。

根据本发明的一个方面，提供了一种网元升级方法，包括：对指定的需要升级的至少一个网元进行升级版本的下载；待所述至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。

优选的，所述对指定的需要升级的至少一个网元进行升级版本的下载，包括：对所述至少一个网元按升级顺序依次进行升级版本的下载。

优选的，所述升级顺序按如下步骤确定：根据所述至少一个网元的网元列表、网络拓扑结构确定所述升级顺序。

优选的，所述升级顺序按如下步骤确定：根据所述至少一个网元的网元列表、网络拓扑结构和链路的带宽信息确定所述升级顺序。

优选的，确定所述升级顺序还包括：对所述至少一个网元按照网元与网管服务器的距离起点从远端到近端的顺序对所述至少一个网元的升级顺序进行排序。

优选的，所述升级顺序按如下步骤确定：由用户通过文件方式配置制定所述升级顺序。

优选的，所述对指定的需要升级的至少一个网元进行升级版本的下载之前，包括：根据对网元进行升级的***的资源配置信息设置升级任务管理列表容量大小，启动并发下载数量。

优选的，在下载过程中，网管服务器对各网元的升级任务进行实时调度，记录各网元的升级进度结果。

根据本发明的另一方面，提供了一种网元升级装置，包括：下载模块，用于对指定的需要升级的至少一个网元进行升级版本的下载；激活模块，用于待所述至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。

优选的，所述下载模块还用于对所述至少一个网元按升级顺序依次进行升级版本的下载。

优选的，所述下载模块还用于根据所述至少一个网元的网元列表、网络拓扑结构计算所述升级顺序；或者，根据所述至少一个网元的网元列表、网络拓扑结构和链路的带宽信息计算所述升级顺序；或者，由用户通过文件方式配置制定所述升级顺序。

在本发明实施例中，对指定的需要升级的至少一个网元进行升级版本的下载，待指定的至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。即在本发明实施例中，所有网元均下载完升级版本后才进行激活，而不是单个网元下载完升级版本后就进行激活，避免了远端网元的下载及业务中断，提高下载速度及业务质量。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的网元升级方法的第一种处理流程图；

图2是根据本发明实施例的网管、网元组网拓扑图；

图3是根据本发明实施例的网元升级方法的第二种处理流程图；

图4是根据本发明实施例的***软件架构；

图5是根据本发明实施例的任务管理列表的示意图；

图6是根据本发明实施例的实施例二的网元升级的处理流程图；

图7是根据本发明实施例的实施例三的网元升级的处理流程图；

图8是根据本发明实施例的实施例四的网元升级的处理流程图；

图9是根据本发明实施例的网元升级装置的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

相关技术中提到，近端网元的重启将导致所有以NE为起点的远端网元业务中断，在批量升级中，如果近端网元先下载完即重启激活版本，所有远端网元的下载及业务将中断，这是运营商无法接受的。

为解决上述技术问题，本发明实施例提供了一种网元升级方法，其处理流程如图1所示，包括步骤S102至步骤S104：

步骤S102、对指定的需要升级的至少一个网元进行升级版本的下载；

步骤S104、待指定的至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。

在本发明实施例中，对指定的需要升级的至少一个网元进行升级版本的下载，待指定的至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。即在本发明实施例中，所有网元均下载完升级版本后才进行激活，而不是单个网元下载完升级版本后就进行激活，避免了远端网元的下载及业务中断，提高下载速度及业务质量。

另外，相关技术中，网元需要下载的版本文件数据传输量非常大，小的上百KB，大的几十MB，甚至上百MB，这样在有限带宽和并发数资源条件下，如果该网管管理的网元数量比较多的时候，每次完成网元软件版本升级需要很长的时间。目前下载技术下载顺序是随机的，如图2中网络结构，假如每段链路的带宽都是5M，那么网元NE1、NE2同时升级的时候，每个网元获得的带宽都是5M。但是如果是NE1、NE11、NE12、NE13同时升级，那么他们将共享5M带宽；如果NE1、NE11、NE12、NE111、NE112、NE121等一起并发升级的时候，问题就更严重了，带宽显然是瓶颈。

此外，假如网管服务器内存配置最多可支持同时创建300个网元的升级任务，最多可支持50个连接数并行下载，而用户希望升级1000跳网元，此时更需要充分利用内存，进行任务的合理调度才能有效的提高升级效率。

为解决下载过程中带宽的瓶颈问题，在本发明实施例中，可以对至少一个网元进行排序，按升级顺序依次进行升级版本的下载，其具体流程如图3所示，包括步骤S302至步骤S306：

步骤S302、对指定的需要升级的至少一个网元进行排序；

步骤S304、按顺序对指定的需要升级的至少一个网元进行升级版本的下载；

步骤S306、待指定的至少一个网元的升级版本均下载结束后，按顺序激活各网元下载的升级版本，对各网元进行升级。

在本发明实施例中，对需要进行升级的网元进行排序，就能够避免多个网元同时进行下载，能够有效利用有限带宽和并发资源，避免多个网元同时下载导致的网络堵塞甚至崩溃的问题。

其中，升级顺序的确定方式可以有多种，例如，可以根据至少一个网元的网元列表、网络拓扑结构确定升级顺序，还可以根据至少一个网元的网元列表、网络拓扑结构和链路的带宽信息确定升级顺序。在具体实施过程中，还可以采用其他确定方式，例如，按升级所需下载文件包的大小进行排序，以及，由用户通过文件方式配置制定升级顺序，即，根据用户的指示信息指定待升级网元的升级顺序，等等。

在一个优选的实施例中，确定升级顺序还可以包括：对至少一个网元按照网元与网管服务器的距离起点从远端到近端的顺序对至少一个网元的升级顺序进行排序。该步骤充分考虑到网元与服务器的距离，也是一种优选的实施方式。

实施时，对指定的需要升级的至少一个网元进行升级版本的下载之前，根据对网元升级的***的资源配置信息设置升级任务管理列表容量大小，启动并发下载数量，即确认网管服务器能够容纳多少网元同时进行下载，并以此进行管理。在网管***中，通过设置网管服务器的资源配置信息进行管理，而在其他***中实施网元升级时，配置的就是该***的相应资源。

在下载过程中，网管服务器对各网元的升级任务进行监控，实现实时调度，记录各网元的升级进度结果，以供用户能够随时查询到操作进度和结果信息，减少人工干预。

由上述分析可见，本发明实施例提供的网元升级方法的核心思想是用户根据网管服务器软硬件资源配置情况，设置升级任务管理列表容量大小、启动并发下载数量，网管进而根据用户指定的网元列表、网络拓扑结构(还可以利用链路的带宽信息)计算出最优的升级顺序，然后按顺序启动升级任务，并由任务管理调度模块对升级任务进行实时调度，从而最大限度的利用服务器软硬件资源和整个网络的带宽，最大限度减少业务中断时间，保证升级的安全性，高效完成网元软件版本的升级，并自动实时监控记录升级进度结果报告，使用户能够随时查询到操作进度和结果信息，减少人工干预。

为将本发明实施例提供的网元升级方法阐述地更清楚更明白，现以具体实施例进行说明。

实施例一

本发明实施例分离版本下载和激活流程，在用户确保正常下载完版本文件后启动激活任务，在传统的网元版本升级上实现了根据拓扑结构优化升级顺序，采用远端优先按序升级，网管服务器可以实时调度网元的版本升级过程。本发明实施例中由以下几个模块实现网元升级方法，各模块的连续关系请参见图4。

1：M1版本管理人机交互模块：本模块部署在网管客户端。本模块提供一个人机交互界面，用户导入版本文件到M5模块，选择需要进行版本升级的网元发送至M2模块，并设置M3模块的控制参数。M1接收来自M4模块的升级进度和结果信息，呈现给用户。

2：M2升级顺序优化模块：本模块部署在网管服务器。本模块根据网管中存储的网络拓扑结构信息，该网络拓扑结构为以网管服务器为起点的图结构(例如图2所示的网络拓扑图)，在升级前采用广度优先排序方案(可以结合链路的带宽信息加权)，将从M1模块接收到的用户选择的网元按距离起点从远端到近端的顺序进行排序，计算出最优的升级顺序，将待升级的网元信息优化后的升级顺序转发到M3模块。

3：M3版本升级任务管理调度模块：本模块部署在网管服务器，维护一个任务管理列表，参考图5，任务列表总容量TASKtotal＝TASKwait+TASKmax。本模块接收来自M2模块的信息，创建对应任务对象，将任务对象加入到任务列表中，由任务调度线程根据当前任务线程执行状态(任务状态信息说明如表一所示)、线程执行最大并发数对任务进行监控调度管理。启动的任务线程将下载/激活命令发送到M6模块。

4：M4版本升级进度结果监控模块：本模块部署在网管服务器端。该模块为每个升级任务(包括下载和激活)维护了一条记录。该记录包括网元标识(名称、IP等)、下载/激活版本号、进度/结果、开始时间、结束时间等。任务结束前监控进度和结果，并将进度结果信息发到M1模块处理。任务结束则将信息持久化至文件或数据库，以备用户查询。

5：M5文件库管理模块：本模块部署在网管服务器上，可能是FTP服务器构成的逻辑模块。本模块负责维护版本文件：接受来自M1模块的版本文件入库请求，将版本文件入库管理；接受来自M1模块的版本文件删除请求，将版本文件删除管理；接受来自M6模块的版本文件下载请求，由M6模块从本库下载版本文件。

6：M6命令/文件接收模块：本模块部署在网元上。本模块接受来自M3模块的指示，向M5模块发起数据下载请求，接收数据到网元，或者根据激活命令指示执行加载激活版本。

M3模块任务管理列表中的任务状态主要为Ready、Executing状态，根据需要，如果需要设定定时任务还可增设Scheduled状态等。当任务(Task)结束，包括成功、失败、取消后，调度线程将Task从任务列表中移出，释放内存。任务状态说明如表一所示：

表一任务状态信息表

采用本发明实施例能够解决如下技术问题：现有技术中的大批量网元进行版本下载时带宽成为瓶颈，以及近端网元重启导致远端网元业务中断缺点，解决现有技术中存在的升级风险和升级时间问题。本发明实施例将版本的下载和激活分开，先下载完版本再激活重启网元，最大限度降低升级风险。本发明实施例根据用户指定的网元列表、网络拓扑结构(还可利用链路的带宽信息)计算出最优的升级顺序，或者由用户配置好最优的升级顺序，然后按顺序调度启动升级任务。用户根据网管服务器软硬件资源配置情况，设置升级任务管理列表容量大小、启动并发下载数量，由任务管理调度模块对升级任务按最有顺序进行实时调度，从而最大限度的利用服务器软硬件资源和整个网络的带宽，最大限度减少业务中断时间，高效完成网元软件版本的升级，并自动实时监控记录升级进度结果报告，使用户能够随时查询到操作进度和结果信息，减少人工干预。

实施例二

本实施例是网元升级的一个具体实施例，本例中网元升级的升级顺序由网管服务器确定，具体流程如图6所示，包括：

步骤S602、用户根据网管服务器软硬件配置资源情况，在M1模块配置网管服务器的升级任务管理列表容量、最大并发数等参数，将这些配置的参数转发到M3模块；在M1模块导入版本文件，选择需要进行升级的网元，将版本信息和待升级网元标识转发到M2模块，启动本次升级操作。

步骤S604、M2模块采用广度优先排序方案(可以结合链路的带宽信息加权)，将从M1模块接收到的用户选择的网元按距离网管服务器从远端到近端的顺序进行排序，计算出最优的升级顺序，将待升级的网元信息优化后的升级顺序转发到M3模块。假设计算优化n个网元构成的网络拓扑升级顺序耗时T(n)，该时间依赖于采用的算法复杂度和网管服务器的处理能力，一般T(n)远小于激活n个网元所需要的时间。

步骤S606、M3模块根据M1模块设置的升级任务管理列表容量TASKtotal、最大并发数TASKmax等参数，对升级任务线程进行实时监控调度管理。M3模块接收M2模块得请求升级信息，检测当前任务列表为空，按照升级顺序立即创建TASKtotal条任务加入到任务列表中，并启动列表末端最高优先级的TASKmax条Ready状态任务。调度线程实时监控任务列表中的任务状态，任务执行完立即移出释放内存空间，并启动列表最末端的Ready状态任务。对于下载操作，假设TASKmax，网元下载版本文件平均需要时间Tdownload，基于本专利调度方法，除最后少于TASKmax个待执行任务外，每个时刻同时并行执行的下载任务均为TASKmax个。n个网元的下载相当于分为n/Tmax批，所有网元完成下载耗时T＝Tdownload*n/Tmax，加上优化排序时间T(n)，总耗时为T(n)+T。当检测到当前任务列表为TASKtotal个任务时，M3不再创建任务对象，而是等待一段时间Twait后在继续检测任务管理列表，以判断是否可以继续创建新的任务对象。其中Twait的计算方法如下：假设下载命令响应超时时间为Tack，则Twait＝Tack*(TASKtotal/TASKmax-1)。启动的线程将命令发送到M6模块。对于激活操作，假设TASKmax，网元对激活命令的响应超时时间为Tack秒，网元完成重启加载版本文件使版本生效平均需要时间Tacitve，基于本专利调度方法，除最后少于TASKmax个待执行任务外，每个时刻同时并行执行的激活任务均为TASKmax个。n个网元的激活操作可分为n/Tmax批，激活耗时T＝Tack*n/Tmax+Tacitve，加上优化升级顺序处理时间，总耗时T(n)+T分钟。当检测到当前任务列表为TASKtotal个任务时，M3不再创建任务对象，而是等待一段时间Twait后在继续检测任务管理列表，以判断是否可以继续创建新的任务对象。其中Twait的计算方法如下：则Twait＝Tack*(Ttotal/Tmax-1)。启动的线程将激活命令发送到M6模块。

步骤S608、M6模块从M3模块接收到命令，如收到的是下载命令，则向M5模块申请下载版本文件，并将下载进度和结果上报M4模块；如收到的是激活命令，则校验参数和备用版本，并将校验结果上报M4模块，如校验正确后指示网元加载版本文件，重启生效。

步骤S610、M4发送网元版本下载/激活进度和结果信息到M1模块，M1模块将相关信息显示给用户，用户也可以通过M1模块监控升级进度和结果，并且根据进度和结果信息进行相应的管理操作，比如取消下载，下载完后进行激活等。

实施例三

实施例二在S604中对升级顺序的优化方式是由网管服务器根据网络拓扑结构信息自动计算最优升级顺序，本实施例与实施例二的区别在于，对网元版本进行升级前，可以由用户通过文件方式配置制定好最优的升级顺序，通过文件导入升级信息，这些信息包含了升级顺序，升级时按照文件中描述指定的顺序执行。

本实施例的具体流程如图7所示，包括：

步骤S702、用户根据网管服务器软硬件配置资源情况，在M1模块配置网管服务器的升级任务管理列表容量、最大并发数等参数，将这些配置的参数转发到M3模块；在M1模块导入版本文件，选择需要进行升级的网元，将版本信息和待升级网元标识转发到M2模块，启动本次升级操作。

步骤S704、对网元版本进行升级前，可以由用户通过文件方式配置制定好最优的升级顺序，通过文件导入升级信息，这些信息包含了升级顺序，升级时按照文件中描述指定的顺序执行，将待升级的网元信息优化后的升级顺序转发到M3模块。假设计算优化n个网元构成的网络拓扑升级顺序耗时T(n)，该时间依赖于采用的算法复杂度和网管服务器的处理能力，一般T(n)远小于激活n个网元所需要的时间。

步骤S706、M3模块根据M1模块设置的升级任务管理列表容量TASKtotal、最大并发数TASKmax等参数，对升级任务线程进行实时监控调度管理。M3模块接收M2模块得请求升级信息，检测当前任务列表为空，按照升级顺序立即创建TASKtotal条任务加入到任务列表中，并启动列表末端最高优先级的TASKmax条Ready状态任务。调度线程实时监控任务列表中的任务状态，任务执行完立即移出释放内存空间，并启动列表最末端的Ready状态任务。对于下载操作，假设TASKmax，网元下载版本文件平均需要时间Tdownload，基于本专利调度方法，除最后少于TASKmax个待执行任务外，每个时刻同时并行执行的下载任务均为TASKmax个。n个网元的下载相当于分为n/Tmax批，所有网元完成下载耗时T＝Tdownload*n/Tmax，加上优化排序时间T(n)，总耗时为T(n)+T。当检测到当前任务列表为TASKtotal个任务时，M3不再创建任务对象，而是等待一段时间Twait后在继续检测任务管理列表，以判断是否可以继续创建新的任务对象。其中Twait的计算方法如下：假设下载命令响应超时时间为Tack，则Twait＝Tack*(TASKtotal/TASKmax-1)。启动的线程将命令发送到M6模块。对于激活操作，假设TASKmax，网元对激活命令的响应超时时间为Tack秒，网元完成重启加载版本文件使版本生效平均需要时间Tacitve，基于本专利调度方法，除最后少于TASKmax个待执行任务外，每个时刻同时并行执行的激活任务均为TASKmax个。n个网元的激活操作可分为n/Tmax批，激活耗时T＝Tack*n/Tmax+Tacitve，加上优化升级顺序处理时间，总耗时T(n)+T分钟。当检测到当前任务列表为TASKtotal个任务时，M3不再创建任务对象，而是等待一段时间Twait后在继续检测任务管理列表，以判断是否可以继续创建新的任务对象。其中Twait的计算方法如下：则Twait＝Tack*(Ttotal/Tmax-1)。启动的线程将激活命令发送到M6模块。

步骤S708、M6模块从M3模块接收到命令，如收到的是下载命令，则向M5模块申请下载版本文件，并将下载进度和结果上报M4模块；如收到的是激活命令，则校验参数和备用版本，并将校验结果上报M4模块，如校验正确后指示网元加载版本文件，重启生效。

步骤S710、M4发送网元版本下载/激活进度和结果信息到M1模块，M1模块将相关信息显示给用户，用户也可以通过M1模块监控升级进度和结果，并且根据进度和结果信息进行相应的管理操作，比如取消下载，下载完后进行激活等。

实施例四

本实施例与实施例二及实施例三的区别在于，对网元版本进行升级前，用户可以通过人机界面操作模块，配置好升级顺序。升级时按照配置的顺序执行。

本实施例的具体流程如图8所示，包括：

步骤S802、用户根据网管服务器软硬件配置资源情况，在M1模块配置网管服务器的升级任务管理列表容量、最大并发数等参数，将这些配置的参数转发到M3模块；在M1模块导入版本文件，选择需要进行升级的网元，将版本信息和待升级网元标识转发到M2模块，启动本次升级操作。

步骤S804、对网元版本进行升级前，用户可以通过人机界面操作模块，配置好升级顺序。升级时按照配置的顺序执行。将待升级的网元信息优化后的升级顺序转发到M3模块。假设计算优化n个网元构成的网络拓扑升级顺序耗时T(n)，该时间依赖于采用的算法复杂度和网管服务器的处理能力，一般T(n)远小于激活n个网元所需要的时间。

步骤S806、M3模块根据M1模块设置的升级任务管理列表容量TASKtotal、最大并发数TASKmax等参数，对升级任务线程进行实时监控调度管理。M3模块接收M2模块得请求升级信息，检测当前任务列表为空，按照升级顺序立即创建TASKtotal条任务加入到任务列表中，并启动列表末端最高优先级的TASKmax条Ready状态任务。调度线程实时监控任务列表中的任务状态，任务执行完立即移出释放内存空间，并启动列表最末端的Ready状态任务。对于下载操作，假设TASKmax，网元下载版本文件平均需要时间Tdownload，基于本专利调度方法，除最后少于TASKmax个待执行任务外，每个时刻同时并行执行的下载任务均为TASKmax个。n个网元的下载相当于分为n/Tmax批，所有网元完成下载耗时T＝Tdownload*n/Tmax，加上优化排序时间T(n)，总耗时为T(n)+T。当检测到当前任务列表为TASKtotal个任务时，M3不再创建任务对象，而是等待一段时间Twait后在继续检测任务管理列表，以判断是否可以继续创建新的任务对象。其中Twait的计算方法如下：假设下载命令响应超时时间为Tack，则Twait＝Tack*(TASKtotal/TASKmax-1)。启动的线程将命令发送到M6模块。对于激活操作，假设TASKmax，网元对激活命令的响应超时时间为Tack秒，网元完成重启加载版本文件使版本生效平均需要时间Tacitve，基于本专利调度方法，除最后少于TASKmax个待执行任务外，每个时刻同时并行执行的激活任务均为TASKmax个。n个网元的激活操作可分为n/Tmax批，激活耗时T＝Tack*n/Tmax+Tacitve，加上优化升级顺序处理时间，总耗时T(n)+T分钟。当检测到当前任务列表为TASKtotal个任务时，M3不再创建任务对象，而是等待一段时间Twait后在继续检测任务管理列表，以判断是否可以继续创建新的任务对象。其中Twait的计算方法如下：则Twait＝Tack*(Ttotal/Tmax-1)。启动的线程将激活命令发送到M6模块。

步骤S808、M6模块从M3模块接收到命令，如收到的是下载命令，则向M5模块申请下载版本文件，并将下载进度和结果上报M4模块；如收到的是激活命令，则校验参数和备用版本，并将校验结果上报M4模块，如校验正确后指示网元加载版本文件，重启生效。

步骤S810、M4发送网元版本下载/激活进度和结果信息到M1模块，M1模块将相关信息显示给用户，用户也可以通过M1模块监控升级进度和结果，并且根据进度和结果信息进行相应的管理操作，比如取消下载，下载完后进行激活等。

无论哪种实施方式，方案符合本发明实施例的本质思想，升级分离下载和激活流程，升级调度顺序依据网络拓扑结构优化，升级任务调度管理按照服务器配置资源进行优化，均属于本发明实施例的保护范围。

基于同一发明构思，本发明实施例还提供了一种网元升级装置，其结构示意图如图9所示，包括：

下载模块901，用于对指定的需要升级的至少一个网元进行升级版本的下载；

激活模块902，与下载模块901耦合，用于待至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。

在一个优选的实施例中，下载模块901还可以用于对至少一个网元按升级顺序依次进行升级版本的下载。

在一个优选的实施例中，下载模块901还可以用于根据至少一个网元的网元列表、网络拓扑结构计算升级顺序；或者，根据至少一个网元的网元列表、网络拓扑结构和链路的带宽信息计算升级顺序；或者，由用户通过文件方式配置制定升级顺序。

从以上的描述中，可以看出，本发明实现了如下技术效果：

在本发明实施例中，对指定的需要升级的至少一个网元进行升级版本的下载，待指定的至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。即在本发明实施例中，所有网元均下载完升级版本后才进行激活，而不是单个网元下载完升级版本后就进行激活，避免了远端网元的下载及业务中断，提高下载速度及业务质量。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种网元升级方法，其特征在于，包括：

对指定的需要升级的至少一个网元进行升级版本的下载；

待所述至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。

2.根据权利要求1所述的方法，其特征在于，所述对指定的需要升级的至少一个网元进行升级版本的下载，包括：对所述至少一个网元按升级顺序依次进行升级版本的下载。

3.根据权利要求2所述的方法，其特征在于，所述升级顺序按如下步骤确定：根据所述至少一个网元的网元列表、网络拓扑结构确定所述升级顺序。

4.根据权利要求2所述的方法，其特征在于，所述升级顺序按如下步骤确定：根据所述至少一个网元的网元列表、网络拓扑结构和链路的带宽信息确定所述升级顺序。

5.根据权利要求3或4所述的方法，其特征在于，确定所述升级顺序还包括：对所述至少一个网元按照网元与网管服务器的距离起点从远端到近端的顺序对所述至少一个网元的升级顺序进行排序。

6.根据权利要求2所述的方法，其特征在于，所述升级顺序按如下步骤确定：由用户通过文件方式配置制定所述升级顺序。

7.根据权利要求1至4、6中任一项所述的方法，其特征在于，所述对指定的需要升级的至少一个网元进行升级版本的下载之前，包括：根据对网元进行升级的***的资源配置信息设置升级任务管理列表容量大小，启动并发下载数量。

8.根据权利要求1至4、6中任一项所述的方法，其特征在于，在下载过程中，网管服务器对各网元的升级任务进行实时调度，记录各网元的升级进度结果。

9.一种网元升级装置，其特征在于，包括：

下载模块，用于对指定的需要升级的至少一个网元进行升级版本的下载；

激活模块，用于待所述至少一个网元的升级版本均下载结束后，激活各网元下载的升级版本，对各网元进行升级。

10.根据权利要求9所述的装置，其特征在于，所述下载模块还用于对所述至少一个网元按升级顺序依次进行升级版本的下载。

11.根据权利要求10所述的装置，其特征在于，所述下载模块还用于根据所述至少一个网元的网元列表、网络拓扑结构计算所述升级顺序；或者，根据所述至少一个网元的网元列表、网络拓扑结构和链路的带宽信息计算所述升级顺序；或者，由用户通过文件方式配置制定所述升级顺序。

Images