CN102315960B - 一种性能数据上报的方法和系统 - Google Patents

Abstract

本发明公开了一种性能数据上报的方法和系统，包括：上报粒度到来时，基站采用均匀法计算上报时间点、或者基站采用保存的上次上报性能文件的上报时间点；上报时间点到来时，基站向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报；通过本发明，能够解决由于链路资源的限制、通讯链路稳定、可靠性限制、上传失败的性能数据保护不足、以及基站自适应能力不足等问题造成的上报的性能数据不完整的问题。

Description

一种性能数据上报的方法和系统

技术领域

本发明涉及数据传输技术，特别是指一种性能数据上报的方法和系统。

背景技术

在电信系统中，基站的性能数据反映了基站的运行质量，对于大规模商用网络的网络优化、故障排查等方面起着不可替代的作用。

性能统计周期性地采集基站性能数据，然后汇总到网管系统中进行整理和统计。对于性能统计来说，主要完成的功能有以下几个方面：

1、性能数据的采集：性能数据是基站运行情况的真实反映，如果需要了解网络的运行情况，就必须在基站上进行原始数据、即性能数据的采集工作。

2、性能数据的存储和上报：将采集得到的性能统计数据进行短时本地保存，并且及时上报到网管系统进行保存，性能数据可以保存在任意能够存储数据的介质中。

3、性能数据的统计和分析：性能数据保存的目的还在于能够随时对性能数据进行统计和分析。统计工作主要是将性能数据直接或者经过简单的计算后显示出来，体现网络的运行状况；分析工作主要根据统计的结果对设备的运行情况进行分析，以便指导当前的操作和长远的规划。

一份完整的性能数据的分析结果才能保证对于网络优化和长远规划的正确性。性能数据的上传必需建立在可靠、稳定的基础上，由于性能统计模块完成功能的特殊性和重要性，而且现有性能统计模块中，会存在以下几方面的不足：

1、链路资源的限制：一个网管系统的FTP资源是有限的，当网管系统管理下的基站数量达到一定规模时，如果所有基站在同一时间通过FTP资源进行性能数据上报，则必然造成大批基站性能数据上报失败，造成大量性能数据丢失。

2、通讯链路稳定、可靠性限制：通常情况下，电信网络性能数据的上报时间几乎覆盖全天24小时，所以对于通讯链路的稳定、可靠性要求较高，如果基站与网管系统间的链路发生异常，即使时间短暂也会导致大量基站的性能数据丢失。

3、上传失败的性能数据保护不足：目前流程中，性能数据在上报失败以后，基站会自动放弃再次上传，对于网管系统来讲，即使基站仍在一定时间内保留上传失败的性能数据，则网管系统仍无法获取。

4、基站自适应能力不足：性能数据上报集中在上报粒度来临时间点，对于基站来讲，每次性能数据上报都是一次链路资源抢占的过程，成功或失败无法预测，同时在上报失败后无法对上报时间点进行自适应的调整。

发明内容

有鉴于此，本发明的主要目的在于提供一种性能数据上报的方法和系统，能够解决现有技术中由于链路资源的限制、通讯链路稳定、可靠性限制、上传失败的性能数据保护不足、以及基站自适应能力不足等问题造成的上报的性能数据不完整的问题。

为了实现上述目的，本发明的技术方案是这样实现的：

一种性能数据上报的方法，该方法包括：

上报粒度到来时，基站采用均匀法计算上报时间点；或者基站采用保存的上次上报性能文件的上报时间点；

所述上报时间点到来时，基站向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报。

所述采用均匀法计算上报时间点，具体为：

根据基站的组（group）号、系统（system）号和所述上报粒度开始的时间，通过函数PMP_CalculateReportTimer计算出上报定时器时长；

从所述上报粒度开始时启动上报定时器，所述上报定时器到时时，即为上报时间点。

所述上报的性能文件为：基站将文件上传列表中的所有性能文件进行压缩，形成的性能文件压缩包。

所述基站向网管系统上报性能文件成功时，该方法进一步包括：所述基站保存所述上报时间点，将所述文件上传列表清空，并删除所述性能文件压缩包。

所述对上报失败的性能文件进行重新上报时，该方法还包括：所述基站判断重新上报的次数是否超过三次，如果是，则结束上报，并重新采用所述均匀法计算上报时间点，并保存；如果否，则直接重新上报所述性能文件。

上报粒度到来之前该方法还包括：所述基站在采集粒度内采集性能数据；在所述采集粒度结束时，将所述性能数据写入性能文件，并将所述性能文件添加到所述文件上传列表。

所述文件上传列表满时，该方法还包括：将所述性能文件替换所述文件上传列表中存储时间最久的性能文件。

一种性能数据上报的系统，该系统包括：上报时间点确定模块和上报模块，其中：

所述上报时间点确定模块，用于在上报粒度到来时，采用均匀法计算上报时间点、或者采用保存的上次上报性能文件的上报时间点；

上报模块，用于在所述上报时间点到来时，向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报。

所述上报时间点确定模块，还用于根据基站的组（group）号、系统（system）号和所述上报粒度开始的时间，通过函数PMP_CalculateReportTimer计算出上报定时器时长；并从所述上报粒度开始时启动上报定时器，所述上报定时器到时时，即为上报时间点。

该系统进一步包括：存储模块，用于将所述性能文件保存在文件上传列表中，并将所述文件上传列表中的所有性能文件进行压缩，形成性能文件压缩包，提供给所述上报模块。

所述存储模块，还用于当所述文件上传列表满时，将所述性能文件替换所述文件上传列表中存储时间最久的性能文件。

所述存储模块，还用于在所述上报模块向网管系统上报性能文件成功时，保存所述上报时间点，将所述文件上传列表清空，并删除所述性能文件压缩包。

所述上报模块，还用于在对上报失败的性能文件进行重新上报时，判断重新上报的次数是否超过三次，如果是，则结束上报，并通知所述上报时间点确定模块重新采用所述均匀法计算上报时间点，保存在所述存储模块中；如果否，则直接重新上报所述性能文件。

本发明性能数据上报的方法和系统，通过自适应均匀机制和重传机制，当电信系统中存在大规模基站时间，如果FTP链路资源短缺，或通讯链路出现异常后，性能管理仍然可以尽可能完整、有效的完成性能数据的采集、上报，并且能够按照用户的要求，完成性能数据的统计和分析，为网络优化、故障排查提供可靠的数据支持。

附图说明

图1为本发明性能数据上报的方法流程示意图图；

图2为本发明一实施例上报性能数据的流程图；

图3为本发明性能数据上报的系统结构示意图。

具体实施方式

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

在传统的性能管理流程中，基站按照网管系统设置好的上报时间点开始上报性能数据，由网管系统对性能数据进行统计和分析。本发明在传统流程的基础上，在基站一侧增加自适应均匀上报和失败重传机制，以提高上报的性能数据的完整性。需要指出的是，性能数据是以文件的方式进行上报的，本发明称之为性能文件。基站在采集粒度内采集性能数据，采集粒度结束后，将采集的性能数据写入性能文件；在上报粒度内使用FTP资源上报所述性能文件。

如图1所示，本发明确保大规模基站性能数据完整性的方法，包括：

步骤101，上报粒度到来时，基站采用均匀法计算上报时间点、或者基站采用保存的上次上报性能文件的上报时间点。

步骤102，上报时间点到来时，基站向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报。

下面介绍一下本发明在基站侧增加的自适应均匀上报和失败重传机制。

一、自适应均匀上报机制。

首先介绍一下均匀上报机制：对于有限的FTP资源，最理想的使用方式是：网管系统根据基站个数将所有基站均匀分组，然后再把每一组基站的上报时间均匀分布在上报粒度内，并且将每一组基站的上报时间均匀分配给该组的每个基站，这样每个基站只要在规定的时间点上报性能文件，就不会造成链路冲突。但是，这种实现方式需要网管系统不断刷新并统计基站个数，计算基站的分组方式和分组时间，处理相对复杂。为了降低网管系统的负担，本发明将均匀上报的机制完全设置在基站侧，然而，由于单个基站并不知道网络里面总的基站数，因此是无法做到真正的均匀上报的。在具体实现时，本发明采用以组（group）号、系统（system）号以及上报粒度开始的时间为种子的方式（本发明将这种方式称为均匀法），来对基站的上报时间点做随机处理，以实现统计意义的均匀上报。其中，在网管系统中，每个基站都对应一个group号和一个system号，group号+system号用以唯一标识一个基站。

另外，由于实际通信链路情况并不能保证每一次FTP上传性能文件均可成功，并且网管系统后台对于上报的大量性能文件需要进行入库处理，如果发生文件堆积，则会对下一个时间粒度的文件处理造成影响，因此，本发明限定上报粒度的前2/3时间为上报时间、即每个基站的上报时间点必须在上报粒度的前2/3时间内，保留一定的时间用以上报失败的性能文件的重传、即重新上报。当然，本发明并不限定于上报粒度的前2/3时间为上报时间，可以根据实际需要进行定制、如上报粒度的前4/5时间为上报时间等。

本发明采用均匀法计算上报时间点，具体为：

通过函数PMP_CalculateReportTimer来实现，该函数如下：

其中，函数中各变量的定义如下：

srand()：为种子函数；

gp_Var->t_SelfLogicalAddr.wModule：为基站配置的group号（种子）；

Now().dwSecond：函数调用时，基站当时时间、即上报粒度开始的时间（种子）；

gp_Var->t_SelfLogicalAddr.wSystem：为基站配置的system号（种子）；

rand()：随机函数，种子不同，一般产生的随机数是不同的；

RAND_MAX：是一个宏值，表示基站所在的系统产生的最大值；

((float)rand()/(RAND_MAX))：获取一个0到1之间的随机数；

dwCurrentReportDur*2/3：三分之二的上报时间窗口；

将当前基站的group号、system号和上报粒度开始的时间作为种子，通过该函数得出的为上报定时器时长，则从上报粒度开始时启动上报定时器，该上报定时器到时时，即为当前基站的上报时间点。

从该函数可以看出：

1、在函数中，做了两次随机处理，一次是以group号和上报粒度开始的时间作为种子，一次是以system号作为种子，这样取得的随机效果会更好些；

2、因为system号可以为0，则gp_Var->t_SelfLogicalAddr.wSystem*rand()等于0导致随机无效，所以为了防止随机，使gp_Var->t_SelfLogicalAddr.wSystem+1。

3、通过dwCurrentReportDur*2/3，使通过该函数计算出的所有基站的上报时间点都在上报粒度的前2/3时间内。

自适应机制：在上述均匀上报机制讨论中，提到的上报时间点的随机处理是针对一个基站首次进行性能文件上传的，即基站在首传上报性能文件时，采用均匀法来计算上报时间点。由于各个基站对于上报时间点的计算是独立的，则从整个网关系统的角度看，这些上报时间点的分布无法保证其规律性和均匀性；因此在具体实现时，本发明采用自动调节的方式、即自适应机制来达到上报时间点分布尽可能的均匀，做法为：基站上传成功时，会记录下该次成功的上报时间点，用于下次性能文件的上报；而三次重传仍然失败的基站则会进行上报时间点的重新计算（依据均匀法），以寻找其他空隙。这样，一个网络系统的配置基本稳定后，经过基站一段时间的自动调节，可以最终达到上报时间点均匀分布的目的。

二、重传机制：在当前上报粒度之内，基站可以对上报失败的性能文件进行三次重传。

性能文件的FTP上报经过：FTP建立链路、传输数据和拆除FTP链路三个阶段。通过测试，上报一个性能文件用时在100ms到4s之间不等；由于本发明的方案实现的是上报时间点在统计意义上的均匀，所以必然会出现部分基站申请不到FTP资源导致的性能文件上报失败情况；另外，其他FTP链路异常的情况同样会导致性能文件上报失败，所以重传可以有效地增加上报成功率。

另外，每个基站维护一个文件上传列表，用于对即将上报的和前期上报失败的性能文件的维护。该文件列表遵循以旧换新循环使用的原则、即用最新的性能文件替换最旧的性能文件，最旧的性能文件即为在文件上传列表中存储时间最长的性能文件；在性能文件被删除前的所有上报粒度内，均有重传的机会，很大程度上解决了由于链路短时间不稳定造成的性能文件丢失问题。

下面通过具体的实施例来说明本发明的方案，如图2所示，基站完整上报性能数据的流程如下：

步骤201，基站在采集粒度内采集性能数据，将采集到的性能数据记录到性能文件。

步骤202，采集粒度结束后，基站将性能文件添加到文件上传列表，若列表未满，直接将性能文件添加到最新位置；若列表已满，则将最新的性能文件替换最旧的性能文件。

步骤203，采集粒度结束后，基站判断是否进入上报粒度，若是，则执行步骤204，若否，则返回步骤201，直到进入上报粒度时，执行步骤204。

需要说明的是，组成上报粒度和采集粒度的单位时间是一致的，且上报粒度为采集粒度的整数倍，因此，当前采集粒度结束时间可能是上报粒度的开始时间，否则要等到下一个或多个采集粒度结束时，进入上报粒度。

步骤204，基站计算自身的上报时间点。

上报粒度开始时，基站计算自身的上报时间点。

若此次为基站首次上报性能文件，则采用均匀法计算上报时间点；若非首次，则采用保存的上次上报性能文件时的上报时间点。

步骤205，上报时间点到来时，基站上报性能文件，具体的：采用FTP方式将性能文件上报到网管系统，其中，上报的性能文件为：基站将文件上传列表中的所有性能文件进行压缩，形成最终上报的性能文件压缩包。

步骤206，基站判断上报性能文件压缩包是否成功，如果是，执行步骤207，基站保存本次上报时间点供下次上报性能文件时使用，同时将文件上传列表清空，并删除性能文件压缩包，结束本次上报流程；若性能文件压缩包上报失败，则执行步骤208。

步骤208，基站对上报失败的性能文件压缩包进行重传，判断重传次数是否超过三次；如果否，则返回步骤205，再次上报性能文件、即重传（此时与上报时间点无关，而是直接重传，直到超过三次）；如果是，则认为本次上报失败，执行步骤209。

步骤209，三次重传均失败时，基站采用均匀法重新计算上报时间点，保存供下次上报使用，并结束本次上报流程。

需要指出的是，在上述流程中，如果当前上报粒度结束，则立即结束本次上报流程。

为了实现上述方法，本发明还提供了一种性能数据上报的系统，如图3所示包括：上报时间点确定模块和上报模块，其中：

上报时间点确定模块，用于在上报粒度到来时，采用均匀法计算上报时间点、或者采用保存的上次上报性能文件的上报时间点；

上报模块，用于在上报时间点到来时，向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报。

上报时间点确定模块，还用于根据基站的组（group）号、系统（system）号和所述上报粒度开始的时间，通过函数PMP_CalculateReportTimer计算出上报定时器时长；并从上报粒度开始时启动上报定时器，上报定时器到时时，即为上报时间点。

该系统进一步包括：存储模块，用于将性能文件保存在文件上传列表中，并将文件上传列表中的所有性能文件进行压缩，形成性能文件压缩包，提供给上报模块；还用于保存上报时间点。

存储模块，还用于当文件上传列表满时，将性能文件替换文件上传列表中存储时间最久的性能文件。

存储模块，还用于在上报模块向网管系统上报性能文件成功时，保存上报时间点，将文件上传列表清空，并删除性能文件压缩包。

上报模块，还用于在对上报失败的性能文件进行重新上报时，判断重新上报的次数是否超过三次，如果是，则结束上报，并通知上报时间点确定模块重新采用均匀法计算上报时间点，保存在存储模块中；如果否，则直接重新上报所述性能文件。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (11)

1.一种性能数据上报的方法，其特征在于，该方法包括：

上报粒度到来时，若此次为基站首次上报性能文件，则基站采用均匀法计算上报时间点；若此次为基站非首次上报性能文件，则基站采用保存的上次上报性能文件的上报时间点；

所述上报时间点到来时，基站向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报；

其中，所述均匀法通过计算上报定时器时长的函数PMP_CalculateReportTimer来实现，在所述函数PMP_CalculateReportTimer中，做了两次随机处理，一次是以基站的组group号和上报粒度开始的时间作为种子，一次是以系统system号作为种子；

从所述上报粒度开始时启动上报定时器，所述上报定时器到时时，即为上报时间点。

2.根据权利要求1所述性能数据上报的方法，其特征在于，所述上报的性能文件为：基站将文件上传列表中的所有性能文件进行压缩，形成的性能文件压缩包。

3.根据权利要求2所述性能数据上报的方法，其特征在于，所述基站向网管系统上报性能文件成功时，该方法进一步包括：所述基站保存所述上报时间点，将所述文件上传列表清空，并删除所述性能文件压缩包。

4.根据权利要求3所述性能数据上报的方法，其特征在于，所述对上报失败的性能文件进行重新上报时，该方法还包括：所述基站判断重新上报的次数是否超过三次，如果是，则结束上报，并重新采用所述均匀法计算上报时间点，并保存；如果否，则直接重新上报所述性能文件。

5.根据权利要求4所述性能数据上报的方法，其特征在于，上报粒度到来之前该方法还包括：所述基站在采集粒度内采集性能数据；在所述采集粒度结束时，将所述性能数据写入性能文件，并将所述性能文件添加到所述文件上传列表。

6.根据权利要求5所述性能数据上报的方法，其特征在于，所述文件上传列表满时，该方法还包括：将所述性能文件替换所述文件上传列表中存储时间最久的性能文件。

7.一种性能数据上报的系统，其特征在于，该系统包括：上报时间点确定模块和上报模块，其中：

所述上报时间点确定模块，用于在上报粒度到来时，此次为基站首次上报性能文件的情况，采用均匀法计算上报时间点；此次为非首次上报性能文件的情况，采用保存的上次上报性能文件的上报时间点；

上报模块，用于在所述上报时间点到来时，向网管系统上报性能文件，并在上报失败时，对上报失败的性能文件进行重新上报；

其中，所述均匀法通过计算上报定时器时长的函数PMP_CalculateReportTimer来实现，在所述函数PMP_CalculateReportTimer中，做了两次随机处理，一次是以基站的组group号和上报粒度开始的时间作为种子，一次是以系统system号作为种子；

从所述上报粒度开始时启动上报定时器，所述上报定时器到时时，即为上报时间点。

8.根据权利要求7所述性能数据上报的系统，其特征在于，该系统进一步包括：存储模块，用于将所述性能文件保存在文件上传列表中，并将所述文件上传列表中的所有性能文件进行压缩，形成性能文件压缩包，提供给所述上报模块。

9.根据权利要求8所述性能数据上报的系统，其特征在于，所述存储模块，还用于当所述文件上传列表满时，将所述性能文件替换所述文件上传列表中存储时间最久的性能文件。

10.根据权利要求8所述性能数据上报的系统，其特征在于，所述存储模块，还用于在所述上报模块向网管系统上报性能文件成功时，保存所述上报时间点，将所述文件上传列表清空，并删除所述性能文件压缩包。

11.根据权利要求10所述性能数据上报的系统，其特征在于，所述上报模块，还用于在对上报失败的性能文件进行重新上报时，判断重新上报的次数是否超过三次，如果是，则结束上报，并通知所述上报时间点确定模块重新采用所述均匀法计算上报时间点，保存在所述存储模块中；如果否，则直接重新上报所述性能文件。