受控网元的软件更新方法及受控网元、操作维护中心

1.一种受控网元的软件更新方法，其特征在于，包括：
步骤A1，操作维护中心OMC根据受控网元的上报信息确定为受控网元更新升级软件包，所述升级软件包为高于受控网元现有软件版本的软件包；
步骤A2，OMC建立升级软件包对应的多播组，并通知受控网元；
步骤A3，受控网元加入升级软件包对应的多播组，与OMC基于组播协议进行通信，从OMC接收升级软件包；
步骤A6，没有完整接收到升级软件包的受控网元与IP域内其他对等的且完整接收到升级软件包的受控网元建立点对点连接，从对等的且完整接收到升级软件包的受控网元获取升级软件包。
2.根据权利要求1所述的方法，其特征在于，所述步骤A6之后还包括：
步骤A4，受控网元完整接收到升级软件包后，覆盖原有软件包，重新引导系统，完成远程升级。
3.根据权利要求2所述的方法，其特征在于，所述组播协议为可靠性组播相关协议。
4.根据权利要求2所述的方法，其特征在于，所述受控网元的上报信息包括受控网元的类型信息以及受控网元现有软件版本的信息，所述步骤A1中，升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本的软件包。
5.根据权利要求4所述的方法，其特征在于，所述受控网元的上报信息进一步还包括能力信息，所述步骤A1中，升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本，且受控网元能力所能支持的软件包。
6.根据权利要求2所述的方法，其特征在于，所述升级软件包在OMC和受控网元之间分段传输，受控网元得到升级软件包的所有分段后，重组分段数据得到升级软件包。
7.根据权利要求1所述的方法，其特征在于，所述步骤A6具体包括：
步骤A61，受控网元判断出没有完整接收到升级软件包，直接或根据OMC指示在IP域内广播包括网元类型信息和版本信息的软件包请求消息，并等待域内的已完整接收升级软件包的受控网元的响应；
步骤A62，受控网元从响应的受控网元中选择目标受控网元，并与该目标受控网元建立点对点连接，接收升级软件包。
8.根据权利要求1所述的方法，其特征在于，所述升级软件包分段传输时，所述步骤A6具体包括：
步骤A61’，受控网元判断出没有完整接收到升级软件包，直接或根据OMC指示在IP域内广播包括网元类型信息、版本信息和缺失分段标识的软件包请求消息，并等待域内的已完整接收升级软件包的受控网元的响应；
步骤A62’，受控网元从响应的受控网元中选择目标受控网元，并与该目标受控网元建立点对点连接，接收升级软件包的缺失分段。
9.根据权利要求7或8所述的方法，其特征在于，建立点对点连接的协议为文件传输协议或轻量级文件传输协议。
10.根据权利要求7或8所述的方法，其特征在于，所述步骤A6还包括：
步骤A63，预定时间内，没有任何响应的受控网元，或还是没有成功接收到升级软件包时，没有完整接收升级软件包的受控网元向OMC发送软件包重传请求消息；
步骤A64，OMC接收到软件包重传请求消息后组织升级软件包对应的多播组进行轮播，重传升级软件包。
11.根据权利要求2到8中任意一项权利要求所述的方法，其特征在于，还包括：
步骤A7，软件更新成功的受控网元向OMC上报包括当前软件版本标识的更新成功消息。
12.根据权利要求2到8中任意一项权利要求所述的方法，其特征在于，还包括：
步骤A8，OMC管理软件包对应的多播组。
13.一种受控网元，其特征在于，包括：
上报信息发送模块，用于向操作维护中心发送上报信息；
多播组加入模块，用于根据操作维护中心的通知加入升级软件包对应的多播组；
升级软件包接收模块，用于与操作维护中心基于组播协议进行通信，利用软件包对应的多播组接收对应的升级软件包；
软件包请求消息广播模块，用于在IP域内广播包括网元类型信息和版本信息的软件包请求消息；
软件包请求消息响应模块，用于在接收到其他受控网元广播的软件包请求消息，且判断出自身保存有软件包请求消息请求的软件包时，向发出软件包请求消息的受控网元发送软件包请求消息响应；
点对点连接建立模块，用于与发送软件包请求消息响应的其他受控网元建立点对点连接；
第二软件包接收模块，用于利用建立的点对点连接接收对应的软件包。
14.根据权利要求13所述的受控网元，其特征在于，受控网元的上报信息包括受控网元的类型信息、能力信息及现有软件版本的信息，所述升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本，且受控网元能力所能支持的软件包。
15.根据权利要求13所述的受控网元，其特征在于，升级软件包分段传输时，所述软件包请求消息中还包括缺失分段的分段标识，所述软件包请求消息响应模块，判断出自身保存有软件包请求消息中的软件包缺失分段时，才向发出软件包请求消息的受控网元发送软件包请求消息响应；所述第二软件包接收模块，用于利用建立的点对点连接从其他受控网元接收对应的软件包的缺失分段。
16.一种操作维护中心，其特征在于，包括：
上报信息接收及保存模块，用于接收并保存受控网元发送的上报信息；
软件包选择模块，用于根据上报信息为受控网元选择升级软件包；
多播组建立及通知模块，用于建立跟软件包对应的多播组并通知受控网元；
没有完整接收到升级软件包的受控网元与IP域内其他对等的且完整接收到升级软件包的受控网元建立点对点连接，从对等的且完整接收到升级软件包的受控网元获取升级软件包。
17.根据权利要求16所述的操作维护中心，其特征在于，受控网元的上报信息包括受控网元的类型信息、能力信息及现有软件版本的信息，所述升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本，且受控网元能力所能支持的软件包。

受控网元的软件更新方法及受控网元、操作维护中心\n技术领域\n[0001] 本发明涉及移动通信领域中系统的软件更新，特别是一种移动通信领域中，受控网元的软件更新方法及受控网元、操作维护中心。\n背景技术\n[0002] 现有的移动通信系统中，如图1所示，受控网元(如基站、中继台等)通过RNC(Radio Network Controller，无线网络控制器)与实施管理功能的网元OMC(Operation and Maintenance Center，操作维护中心)交互，实现软件版本的更新。\n[0003] 如图2所示，以受控网元为NB(Node B，节点B)为例，其软件版本管理方法包括：\n[0004] 步骤21，NB作为客户端向提供服务端功能的OMC发送版本文件下载请求消息，请求版本文件；\n[0005] 步骤22，OMC通过版本文件下载请求响应消息应答；\n[0006] 步 骤 23，NB 通 过 FTP/TFTP(File Transfer Protocol/Trivial Transfer Protocol，文件传输协议/轻量级文件传输协议)从OMC下载相应软件包；\n[0007] 步骤24，NB获得版本文件后，覆盖原有单板的软件包，并重新引导系统，完成该网元的远程升级。\n[0008] 从上述的描述可以看出，现有的受控网元的软件更新办法简单直观，然而，上述的基于客户/服务器式的集中型版本分发及更新机制，对大规模网络来讲，在受控网元数目较多时，OMC的负荷压力较大，同时，使用点对点单播方式，带宽利用率低。\n发明内容\n[0009] 本发明的目的是提供一种受控网元的软件更新方法及受控网元、操作维护中心，降低操作维护中心的负荷。\n[0010] 为了实现上述目的，本发明提供了一种受控网元的软件更新方法，其中，包括：\n[0011] 步骤A1，操作维护中心OMC根据受控网元的上报信息确定为受控网元更新升级软件包，所述升级软件包为高于受控网元现有软件版本的软件包；\n[0012] 步骤A2，OMC建立升级软件包对应的多播组，并通知受控网元；\n[0013] 步骤A3，受控网元加入升级软件包对应的多播组，与OMC基于组播协议进行通信，从OMC接收升级软件包。\n[0014] 上述的方法，其中，还包括：\n[0015] 步骤A4，受控网元完整接收到升级软件包后，覆盖原有软件包，重新引导系统，完成远程升级。\n[0016] 上述的方法，其中，所述组播协议为可靠性组播相关协议。\n[0017] 上述的方法，其中，所述受控网元的上报信息包括受控网元的类型信息以及受控网元现有软件版本的信息，所述步骤A1中，升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本的软件包。\n[0018] 上述的方法，其中，所述受控网元的上报信息包括能力信息，所述步骤A1中，升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本，且受控网元能力所能支持的软件包。\n[0019] 上述的方法，其中，所述步骤A3和A4之间还包括：\n[0020] 步骤A5，受控网元没有完整接收升级软件包，OMC从多播组删除完整接收升级软件包的受控网元后，组织升级软件包对应的多播组进行轮播，重传升级软件包。\n[0021] 上述的方法，其中，所述升级软件包在OMC和受控网元之间分段传输，受控网元得到升级软件包的所有分段后，重组分段数据得到升级软件包。\n[0022] 上述的方法，其中，受控网元之间为对等节点时，，所述步骤A3和A4之间还包括：\n[0023] 步骤A6，没有完整接收到升级软件包的受控网元与IP域内其他对等的且完整接收到升级软件包的受控网元建立点对点连接，从对等的且完整接收到升级软件包的受控网元获取升级软件包。\n[0024] 上述的方法，其中，所述步骤A6具体包括：\n[0025] 步骤A61，受控网元判断出没有完整接收到升级软件包，直接或根据OMC指示在IP域内广播包括网元类型信息和版本信息的软件包请求消息，并等待域内的已完整接收升级软件包的受控网元的响应； \n[0026] 步骤A62，受控网元从响应的受控网元中选择目标受控网元，并与该目标受控网元建立点对点连接，接收升级软件包。\n[0027] 上述的方法，其中，所述升级软件包分段传输时，所述步骤A6具体包括：\n[0028] 步骤A61’，受控网元判断出没有完整接收到升级软件包，直接或根据OMC指示在IP域内广播包括网元类型信息、版本信息和缺失分段标识的软件包请求消息，并等待域内的已完整接收升级软件包的受控网元的响应；\n[0029] 步骤A62’，受控网元从响应的受控网元中选择目标受控网元，并与该目标受控网元建立点对点连接，接收升级软件包的缺失分段。\n[0030] 上述的方法，其中，建立点对点连接的协议为文件传输协议或轻量级文件传输协议。\n[0031] 上述的方法，其中，所述步骤A6还包括：\n[0032] 步骤A63，预定时间内，没有任何响应的受控网元，或还是没有成功接收到时，没有完整接收升级软件包的受控网元向OMC发送软件包重传请求消息；\n[0033] 步骤A64，OMC接收到软件包重传请求消息后组织升级软件包对应的多播组进行轮播，重传升级软件包。\n[0034] 上述的方法，其中，还包括：\n[0035] 步骤A7，软件更新成功的受控网元向OMC上报包括当前软件版本标识的更新成功消息。\n[0036] 上述的方法，其中，还包括：\n[0037] 步骤A8，OMC管理软件包对应的多播组。\n[0038] 为了更好的实现上述目的，本发明还提供了一种受控网元，包括：\n[0039] 上报信息发送模块，用于向操作维护中心发送上报信息；\n[0040] 多播组加入模块，用于根据操作维护中心的通知加入升级软件包对应的多播组；\n[0041] 升级软件包接收模块，用于与操作维护中心基于组播协议进行通信，利用软件包对应的多播组接收对应的升级软件包。\n[0042] 上述的受控网元，其中，受控网元的上报信息中受控网元的类型信息、能力信息及现有软件版本的信息，所述升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本，且受控网元能力所能支持的软件包。\n[0043] 上述的受控网元，其中，还包括：\n[0044] 软件包请求消息广播模块，用于在IP域内广播包括网元类型信息和版本信息的软件包请求消息；\n[0045] 软件包请求消息响应模块，用于在接收到其他受控网元广播的软件包请求消息，且判断出自身保存有软件包请求消息请求的软件包时，向发出软件包请求消息的受控节点发送软件包请求消息响应；\n[0046] 点对点连接建立模块，用于与发送软件包请求消息响应的受控节点建立点对点连接；\n[0047] 第二软件包接收模块，用于利用建立的点对点连接与其他受控节点，接收对应的软件包。\n[0048] 上述的受控网元，其中，升级软件包分段传输时，所述软件包请求消息中还包括缺失分段的分段标识，所述软件包请求消息响应模块，判断出自身保存有软件包请求消息中的软件包缺失分段时，才向发出软件包请求消息的受控节点发送软件包请求消息响应；所述第二软件包接收模块，用于利用建立的点对点连接与其他受控节点，接收对应的软件包的缺失分段。\n[0049] 为了更好的实现上述目的，本发明还提供了一种操作维护中心，包括：\n[0050] 上报信息接收及保存模块，用于接收并保存受控网元发送的上报信息；\n[0051] 软件包选择模块，用于根据上报信息为受控网元选择升级软件包；\n[0052] 多播组建立及通知模块，用于建立更软件包对应的多播组并通知受控网元。\n[0053] 上述的操作维护中心，其中，受控网元的上报信息中受控网元的类型信息、能力信息及现有软件版本的信息，所述升级软件包为受控网元类型对应的软件包集合中，软件版本高于受控网元现有软件版本，且受控网元能力所能支持的软件包。\n[0054] 上述的操作维护中心，其中，还包括：重传模块，用于在受控网元没有完整接收到升级软件包，组织升级软件包对应的多播组进行轮播。\n[0055] 本发明具有以下有益效果：\n[0056] 1、OMC与受控网元之间通过多播组传输升级软件包，不用针对每一个受控网元进行点对点传输，降低了操作维护中心的负荷，提高了网络带宽的使用效率；\n[0057] 2、在多播传输的基础上，作为同等节点的受控网元之间以点对点方式互传升级软件包，进一步降低了操作维护中心的负荷；\n[0058] 3、多播与点对点单播方式结合，受控网元可以通过多种方式获取软件包，提高了软件包升级的成功率，提升了系统的可靠性。\n附图说明\n[0059] 图1为受控网元实现软件版本的更新的网络架构示意图；\n[0060] 图2为现有受控网元软件版本管理方法的流程示意图；\n[0061] 图3为本发明的受控网元的软件更新方法的流程示意图；\n[0062] 图4为单独利用组播的本发明方法的详细流程示意图；\n[0063] 图5为组播和点对点单播相结合的本发明方法的详细流程示意图；\n[0064] 图6为本发明的受控网元和OMC的结构示意图。\n具体实施方式\n[0065] 本发明中，由OMC建立多播组，受控网元加入对应软件包的多播组，实现软件包的接收。\n[0066] 如图3所示，本发明的受控网元的软件更新方法包括：\n[0067] 步骤31，OMC接收受控网元发送的上报信息后，根据上报信息确定升级软件包，所述升级软件包为高于受控网元现有软件版本的软件包；\n[0068] 步骤32，OMC建立升级软件包对应的多播组，并将升级软件包对应的多播组通知受控网元；\n[0069] 步骤33，受控网元加入多播组，与OMC基于组播协议进行通信，从OMC接收升级软件包。\n[0070] 在此，该受控网元可通过版本文件下载请求消息发送上报信息，也可以通过另外的消息进行发送。\n[0071] 在此，本发明方法所使用的组播协议可以是各种类型的组播协议，但为了保证移动通信系统的传输可靠性，本发明的具体实施例中使用RM(ReliableMulticast，可靠性组播)相关协议。\n[0072] 步骤32中，需要根据受控网元的上报信息来确定供受控网元升级的升级软件包，在此，该上报信息至少包括受控网元现有软件版本的信息，此时，根据该受控网元现有软件版本的信息(软件版本序列号)，从软件包中选择高于受控网元现有软件版本的升级软件包即可。\n[0073] 然而，随着接入网技术的不断演进，其架构发生了巨大的变化。\n[0074] 如LTE系统中，基站可分为Macro-BS和Home-BS两种类别(Macro-BS主要用于户外覆盖，而Home-BS则用于室内覆盖)，这两种基站的设计目标和特性有着较大的差异，因而其运行的支持软件会是不同的两种类型，即用于Macro-BS的类型和用于Home-BS的类型。\n[0075] 作为LTE系统的演进的B3G系统中，为了进一步增强系统的覆盖性能和吞吐量性能，在其BS和移动台之间引入了通过空口连接的中继台，而中继台作为受控节点，其软件同样需要升级，以便保证系统整体性能的最优。\n[0076] 因此，如果仅仅靠受控网元现有软件版本的信息来确定升级软件包，有可能出现错误，因此本发明的方法中，受控网元的上报信息中进一步包括受控网元的类型信息，以区别不同的受控网元。\n[0077] OMC根据受控网元的类型信息以及受控网元现有软件版本的信息，从受控网元对应的软件包集合中选择版本高于受控网元现有软件版本的升级软件包。\n[0078] 同时，现有的受控网元在功能相同的情况下，其能力(如硬件平台能力)具有差异，即同一OMC下的相同类型的受控网元中，一部分受控网元的能力支持比较高版本的软件，而另外一部分受控网元的能力无法支持高版本的软件。\n[0079] 因此，为了避免由于受控网元的能力差异带来的软件更新问题，本发明的具体实施例中，受控网元的上报信息中进一步包括受控网元的能力信息，OMC根据受控网元的类型信息、能力信息及现有软件版本的信息，从受控网元对应的软件包集合中选择其能力所能支持的，且版本高于受控网元现有软件版本的升级软件包。\n[0080] 在受控网元的上报信息中包括受控网元类型信息及现有软件版本的信息时，OMC存储的软件包根据受控网元类型以及软件版本进行保存，并根据受控网元类型和软件版本建立相应的多播组。\n[0081] 受控网元的IP地址信息可通过DHCP(Dynamic Host ConfigurationProtocol，动态主机配置协议)过程获取；\n[0082] 而受控网元指向OMC的寻址，可以是通过缺省配置，或通过“邮政编码”类型的信息基于地域约束来间接地得到相关服务OMC的地址。\n[0083] 下面对受控网元的完整软件升级过程进行详细描述。\n[0084] 受控网元为基站时，利用本发明方法的受控网元完整软件升级过程包括：\n[0085] 步骤401，BS加入网络并通电启动；\n[0086] 步骤402，BS发送上报信息，并由OMC接收并保存BS的上报信息，该上报信息包括：硬件版本信息，网元类型信息，现有软件版本信息；\n[0087] 步骤403，OMC进行一段时间的BS上报信息收集之后(尽量减少零星响应场景的出现)，OMC基于BS的上报信息进行综合判决，确定是否为BS升级软件包，如果需要更新，则进入步骤404，否则返回步骤402；\n[0088] 在步骤403中，OMC基于BS的上报信息来决策是否为该BS提供适当版本的软件包，其更新所需要满足的条件如下：\n[0089] BS的网元类型所对应的软件包集合中，包括版本高于BS现有软件版本，且BS的硬件能力能支持的软件包。\n[0090] 步骤404，OMC为BS选择适当版本的软件包，在此，OMC从BS的网元类型所对应的软件包集合中选取硬件能力所能支持的，且版本高于BS现有软件版本的最新版的软件包；\n[0091] 步骤405，判断为BS选择的软件包对应的多播组是否已经建立，如果是，进入步骤\n407，否则进入步骤406；在此，如果软件包是第一次传输，则会为其建立相应的多播组；\n[0092] 步骤406，OMC建立该软件包对应的多播组后进入步骤407；\n[0093] 步骤407，OMC指示BS加入相应的多播组；\n[0094] 步骤408，BS加入软件包对应的多播组，并进行软件包的接收；\n[0095] 步骤409，一次多播传输过程结束后，OMC等待BS回应；\n[0096] 步骤410，BS判断是否完整接收到软件包，如果是则覆盖原有软件包，并重新引导系统，完成该BS自身的远程升级，并通知OMC升级成功，否则向OMC发送软件包重传请求消息；\n[0097] 步骤411，OMC将成功更新的BS从对应的多播组中删除后，组织该多播组进行轮播，重传软件包，直至所有BS升级成功。\n[0098] 在上述的处理过程中，如果OMC有新版的软件包加入，此时这需要根据已经保存的BS的上报信息来判断现有BS是否需要并能够进行相应的软件包升级，如果是，则进入步骤407，执行软件包更新。\n[0099] 在步骤410中，BS通知OMC升级成功的消息中包括当前软件版本标识。\n[0100] 同时，OMC还对软件包对应的多播组进行控制管理，如：\n[0101] 设置多播组的空闲时间，在多播组空闲时间超过一预设阈值时(没有加入此多播组的BS请求组播)，对该多播组执行删除处理；\n[0102] 设置多播组个数的管理，对同一软件包的不同版本的多播组设置一预设数值，当同一软件包的不同版本的多播组个数达到该预设数值后，释放最低版本的软件包对应的多播组，提供地址空间供最新版本的软件包使用。\n[0103] 同时考虑到各受控网元很多时候都采用分布式架构，各受控网元是对等节点，如LTE系统和B3G中的基站，因此，如果仅靠OMC建立组播来实现软件包的下发，没有完全利用分布式架构所具有的多节点网络负荷分担特性。\n[0104] 对于分布式架构的受控网元，本发明进一步设置如下步骤：\n[0105] 没有完整接收到软件包的受控网元与域内其他对等的且完整接收到软件包的受控网元建立点对点连接，从对等的且完整接收到软件包的受控网元获取软件包。\n[0106] 下面以受控网元为BS为例，对组播结合受控网元点对点传输软件包的更新方法进行详细描述，如图5所示，其包括：\n[0107] 步骤501，BS加入网络并通电启动；\n[0108] 步骤502，BS发送上报信息，并由OMC接收并保存BS的上报信息，该上报信息包括：硬件版本信息，网元类型信息，现有软件版本信息；\n[0109] 步骤503，OMC进行一段时间的BS上报信息收集之后(尽量减少零星响应场景的出现)，OMC基于BS的上报信息进行综合判决，确定是否为BS升级软件包，如果需要更新，则进入步骤504，否则返回步骤502；\n[0110] 步骤504，OMC为BS选择适当版本的软件包，在此，OMC从BS的网元类型所对应的软件包集合中选取硬件能力所能支持的，且版本高于BS现有软件版本的最新版的软件包；\n[0111] 步骤505，判断为BS选择的软件包对应的多播组是否已经建立，如果是，进入步骤\n507，否则进入步骤506；在此，如果软件包是第一次传输，则会为其建立相应的多播组；\n[0112] 步骤506，OMC建立该软件包对应的多播组后进入步骤507；\n[0113] 步骤507，OMC指示BS加入相应的多播组；\n[0114] 步骤508，BS加入软件包对应的多播组，并进行软件包的接收；\n[0115] 步骤509，一次多播传输过程结束后，OMC等待BS回应；\n[0116] 步骤510，BS判断是否完整接收到软件包，如果是则覆盖原有软件包，并重新引导系统，完成该BS自身的远程升级，并通知OMC升级成功，否则在域广播包括网元类型信息和版本信息的软件包请求消息，并等待域内的已完整接收软件包的BS的响应；\n[0117] 步骤511，BS从响应的BS中选择目标BS，并与该目标BS建立点对点连接，接收软件包，该建立点对点连接的协议可采用FTP/TFTP；\n[0118] 步骤512，BS覆盖原有软件包，并重新引导系统，完成该BS自身的远程升级，并通知OMC升级成功。\n[0119] 当然，如果一段时间内，没有任何响应的BS，或者还是没有成功接收到软件包时，则该未完整接收软件包的BS会向OMC发送软件包重传请求消息，而OMC则会组织该多播组进行轮播，重传软件包。\n[0120] BS通知OMC升级成功的消息中包括当前软件版本标识。\n[0121] 在图5所示的软件升级过程中，未完整接收软件包的BS直接广播软件包请求消息，当然也可以由OMC控制，下面对OMC控制方式进行详细说明。\n[0122] OMC获取成功更新BS的上报信息，同时OMC向请求更新的BS指示启用分布式点对点方式，此时，BS就直接开始向其它BS的广播请求过程，而不必等待OMC的组播。\n[0123] 当然，OMC可在成功更新的BS数目超过预设阈值时，向请求更新的BS指示启用分布式点对点方式，保证软件包的成功获取。\n[0124] 步骤511中，需要从响应的BS中选择，其选择策略可以根据响应消息到达的顺序来进行选择。\n[0125] 一般来讲，受控节点的软件包都比较大，为了进一步提高升级软件包的传输效率，本发明方法的具体实施例中将待传输的软件包分为多个部分，并对各个部分进行编号(即设置分段的序号标识)后进行传输。\n[0126] 在对软件包设置分段后，BS可能会由于加入多播组较晚等原因，错过了某些分段的多播内容，因此，对本发明方法的改变针对多播以及多播和点对点传输结合两种方式分别进行说明。\n[0127] 对于OMC建立多播组进行软件包传输，并利用多播组进行轮播，重传软件包实现软件升级的方式来讲(即图4所示的流程)，将软件包设置分段后，结合图4所示，其主要涉及两个步骤：\n[0128] 步骤407，OMC指示BS加入相应的多播组的同时，还需要指示组播中所需接收的软件包的分段数目，以便于BS判断是否收到所有的分段；\n[0129] 步骤410，BS根据该分段数目来判断是否接收到完整的软件包，其他过程没有区别，在此不再赘述。\n[0130] 而对于多播和点对点传输结合的升级方式(即图5所示的流程)来讲，涉及面较广，下面结合图5进行详细说明。\n[0131] 当然，步骤507和步骤510与步骤407和步骤410对应，OMC指示BS加入相应的多播组的同时，还需要指示组播中所需接收的软件包的分段数目，而BS根据该分段数目来判断是否接收到完整的软件包。\n[0132] 同时，在步骤510中，BS判断出没有完整接收到软件包后，广播的软件包请求消息中还应该包括其缺失分段的序号标识。\n[0133] 当然，可以一个软件包请求消息中携带所有的缺失分段的序号标识，也可以对每一个缺失分段构造一个软件包请求消息。\n[0134] 在一个BS缺失一个软件包的多个分段时，可以从响应的BS中包括所有缺失分段的一个BS接收该缺失分段，也可以从多个响应的BS分别接收缺失分段。\n[0135] 如BS1缺失3个软件包分段，而BS2包括该3个软件包分段，而BS3、BS4和BS5分别具有其中的一个软件包分段，BS2、BS3、BS4和BS5都进行了响应，此时，BS1可以选择从BS3接收所有软件包分段，此时，只需要建立一个点对点连接，也可以分别从BS3、BS4和BS5接收软件包分段，此时速度较快，但需要建立三个点对点连接。\n[0136] 考虑到在此广播的软件包请求消息不同于BS指向OMC的软件包重传请求消息，为便于OMC和域内的其他BS能够有区别地应对，可通过以下方式区分上述的消息：\n[0137] 消息名称，通过不同的消息名称来区分；\n[0138] 特定字段的值，对特定字段赋不同值，如1表示广播的软件包请求消息，而2表示指向OMC的软件包重传请求消息；\n[0139] 携带参数，如指向OMC的软件包重传请求消息中不携带软件包分段的序号标识，而广播的软件包请求消息则包括指示分段的序号标识。\n[0140] 在域中的BS接收到广播的软件包请求消息后，需要判断是否进行响应，此时通过以下方式判断：\n[0141] 当拥有软件包请求消息中所指示的软件包的全部分段时，才进行响应；\n[0142] 当拥有软件包请求消息中所指示的缺失分段时，就进行响应，但响应消息中应该携带自身所拥有分段的序号标识。\n[0143] BS与响应的BS建立点对点连接，从目标BS接收其缺失的软件包分段。\n[0144] 而在步骤512，还需要对接收到的所有软件包分段进行数据重组，得到最终的升级软件包，并使用该软件包进行升级。\n[0145] 当然，上述受控网元请求的软件包可以不是用于自身的升级，也可以是其下辖的受控网元的升级软件包。\n[0146] 在本发明的方法用于受控网元下辖的其他受控网元的软件包升级时，其区别仅仅在于以下几点：\n[0147] 受控网元(如BS)上报的信息中包括其下辖受控网元(如RS)的信息；\n[0148] 受控网元得到的软件包不是用于自身升级，其需要将得到的软件包发送给下辖的其他受控网元进行升级。\n[0149] 其详细过程在此不再进行详细描述。\n[0150] 本发明的操作维护中心如图6所示，包括：\n[0151] 上报信息接收及保存模块，用于接收并保存受控网元发送的上报信息；\n[0152] 软件包选择模块，用于根据上报信息为受控网元选择软件包；\n[0153] 多播组建立及通知模块，用于建立软件包对应的多播组并通知受控网元。\n[0154] 本发明的受控网元如图6所示，包括：\n[0155] 上报信息发送模块，用于向操作维护中心发送上报信息；\n[0156] 多播组加入模块，用于根据操作维护中心的通知加入对应的软件包多播组；\n[0157] 升级软件包接收模块，用于与操作维护中心基于组播协议进行通信，利用升级软件包对应的多播组接收对应的软件包。\n[0158] 为了保证移动通信系统的传输可靠性，组播协议使用RM(ReliableMulticast，可靠性组播)相关协议。\n[0159] 受控网元的上报信息中受控网元的类型信息、能力信息及现有软件版本的信息，软件包选择模块根据上报信息从受控网元对应的软件包集合中选择其能力所能支持的，且版本高于受控网元现有软件版本的升级软件包。\n[0160] 同时，在受控网元为对等节点时，其还包括：\n[0161] 软件包请求消息广播模块，用于在IP域内广播包括网元类型信息和版本信息的软件包请求消息；\n[0162] 软件包请求消息响应模块，用于在接收到其他受控网元广播的软件包请求消息，且判断出自身保存有软件包请求消息请求的软件包时，向发出软件包请求消息的受控节点发送软件包请求消息响应；\n[0163] 点对点连接建立模块，用于与发送软件包请求消息响应的受控节点建立点对点连接；\n[0164] 第二软件包接收模块，用于利用建立的点对点连接与其他受控节点，接收对应的软件包。\n[0165] 当软件包分段传输时，所述软件包请求消息中还包括缺失分段的分段标识，该软件包请求消息响应模块，用于在接收到其他受控网元广播的软件包请求消息，且判断出自身保存有软件包请求消息请求的软件包的缺失分段时，向发出软件包请求消息的受控节点发送软件包请求消息响应；第二软件包接收模块，用于利用建立的点对点连接与其他受控节点，接收对应的软件包的缺失分段。\n[0166] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。