CN117793759A - 基于tr069协议的基站性能文件处理系统及方法 - Google Patents

Abstract

本发明实施例公开了一种基于TR069协议的基站性能文件处理系统及方法，所述系统包括基站、网管、服务器，网管接收基站上传的性能文件；并查询是否存在该性能文件，如果存在，则不接收；如果不存在，则查询服务器中是否存在，如果存在，则不接收该性能文件，如果不存在，则判断性能文件临时区是否存储满，如果是，由服务器处理性能文件，并将性能文件的性能指标存储到数据库；如果否，则存储到性能文件临时区，并保存基站上传此次性能文件的记录。本发明的网管只进行文件校验与临时存储，不处理文件的详细解析，加快了文件的接收能力，降低了网管集中并发处理的压力。本发明使用服务器统一处理性能文件，减轻了网管存储与解析压力。

Description

基于TR069协议的基站性能文件处理系统及方法

技术领域

本发明涉及网管领域，尤其涉及一种基于TR069协议的基站性能文件处理系统及方法。

背景技术

小基站网管系统（一种ACS系统，简称：网管系统、网管或ACS），是一种为监控各类运营商小基站设备工作状态，进行日常操作维护而开发的管理系统。TR069是CPE（CustomerPremises Equipment，客户端设备）和ACS（Auto Configuration Server，自动配置服务器）之间沟通的通讯协议。目前小基站网管系统普遍采用TR069协议进行小基站（CPE的一种）的管理，在基站运维的过程中，网管会对基站上报的性能文件进行存储与解析，生成基站对应的报表，便于运维人员对基站的信号指标进行了解。

目前，基站一般按照配置的定时器时间周期性上传性能文件，例如：15分钟上传一次性能文件。当基站上传性能文件时间点比较集中，将会对网管处理性能文件产生较大压力，导致网管与基站之间的通信管道堵塞，无法及时处理其它交互指令。另外，性能文件上传有时延要求，若网管吞吐量不足会造成基站侧文件上传超时。当性能文件上传失败会在基站侧积压，基站会反复尝试上传性能文件给网管，导致更严重的消息堵塞。

发明内容

本发明实施例所要解决的技术问题在于，提供一种基于TR069协议的基站性能文件处理系统及方法，以解决在网管的性能文件集中处理时，基站与网管之间通信消息积压，文件重传等问题。

为了解决上述技术问题，本发明实施例提出了一种基于TR069协议的基站性能文件处理系统，包括基站、网管、服务器，网管包含用于缓存性能文件的性能文件临时区，服务器包括存储性能文件的性能指标的数据库，

基站按照预设的周期上传性能文件；

网管接收基站上传的性能文件，校验文件名称与文件格式；并查询性能文件临时区是否存在该性能文件，如果存在，则不接收基站上传的该性能文件；如果不存在，则进一步查询服务器中是否存在该性能文件，如果服务器中存在，则不接收该性能文件，如果服务器中不存在，则判断性能文件临时区是否存储满，

如果是，网管将性能文件临时区的所有性能文件传递到服务器，然后由服务器处理性能文件，并将性能文件的性能指标存储到数据库，网管再删除掉性能文件临时区的所有性能文件；

如果否，网管则将基站上传的该性能文件存储到性能文件临时区，并保存基站上传此次性能文件的记录。

进一步地，网管定时将性能文件临时区的性能文件传递到服务器中，网管根据用户设置的性能文件任务，定时触发服务器处理性能文件；在服务器处理完性能文件后，网管删除性能文件临时区已经处理过的性能文件。

进一步地，服务器处理性能文件具体为：解析原始性能文件，并存储到数据库中，以及生成对应的便于用户查看与导出的性能文件报表。

进一步地，当服务器处理性能文件时发现性能文件异常，则向网管发送性能文件补采消息，补采消息包括基站SN、性能补采开始时间与性能补采结束时间；

基站接收到服务器的性能文补采消息，向基站发送SetParameterValues消息来设置参数，设置基站性能补采开启，性能补采开始时间与性能补采结束时间；

基站收到SetParameterValues消息后，回复SetParameterValuesResponse消息给网管，并按照消息中的性能补采开始时间与性能补采结束时间进行基站性能文件收集，将其进行打包压缩，并根据预设的命名规则对压缩后的性能文件进行命名；基站使用HttpPut/Post消息将压缩后的性能文件上传给网管；基站发送完性能文件后，发送Inform消息给网管；

网管回应InformResponse消息给基站，并对接收到的性能文件进行文件名称与文件格式检验，检验通过后保存基站此次上传的性能文件以及上传记录。

进一步地，所述预设的命名规则为：

<RAT><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_UniqueId ；

其中，<RAT>表示为NR或LTE制式的性能文件，5G取值为NR，4G取值为LTE；<Startdate>为性能补采的开始日期；<Enddate>为性能补采的结束日期；<Starttime>为性能补采的开始时间；<Endtime>为性能补采的结束时间；所述UniqueId以OUI和SN表示，中间以.分割；

当<Enddate>和<Starttime>相同时，<Enddate>为可选字段；当<Enddate>和<Starttime>不同时，<Enddate>为必选字段；所述OUI为24bit的十六进制数。

相应地，本发明实施例还提供了一种基于TR069协议的基站性能文件处理方法，包括：

步骤1：基站按照预设的周期上传性能文件；

步骤2：网管接收基站上传的性能文件，校验文件名称与文件格式；

步骤3：网管查询性能文件临时区是否存在该性能文件，如果存在，则不接收基站上传的该性能文件；如果不存在，则进一步查询服务器中是否存在该性能文件，如果服务器中存在，则不接收该性能文件，如果服务器中不存在，则判断性能文件临时区是否存储满，

如果是，网管将性能文件临时区的所有性能文件传递到服务器，然后由服务器处理性能文件，并将性能文件的性能指标存储到数据库，网管再删除掉性能文件临时区的所有性能文件；

如果否，网管则将基站上传的该性能文件存储到性能文件临时区，并保存基站上传此次性能文件的记录。

进一步地，步骤3之后还包括：

步骤4：网管定时将性能文件临时区的性能文件传递到服务器中；

步骤5：网管根据用户设置的性能文件任务，定时触发服务器处理性能文件；在服务器处理完性能文件后，网管删除性能文件临时区已经处理过的性能文件。

进一步地，步骤3中，服务器处理性能文件具体为：解析原始性能文件，并存储到数据库中，以及生成对应的便于用户查看与导出的性能文件报表。

进一步地，步骤3包括：

子步骤1：当服务器处理性能文件时发现性能文件异常，则向网管发送性能文件补采消息，补采消息包括基站SN、性能补采开始时间与性能补采结束时间；

子步骤2：基站接收到服务器的性能文补采消息，向基站发送SetParameterValues消息来设置参数，设置基站性能补采开启，性能补采开始时间与性能补采结束时间；

子步骤3：基站收到SetParameterValues消息后，回复SetParameterValuesResponse消息给网管，并按照消息中的性能补采开始时间与性能补采结束时间进行基站性能文件收集，将其进行打包压缩；

子步骤4：基站根据预设的命名规则对压缩后的性能文件进行命名；

子步骤5：基站使用Http Put/Post消息将压缩后的性能文件上传给网管；

子步骤6：基站发送完性能文件后，发送Inform消息给网管；

子步骤7：网管回应InformResponse消息给基站，并对接收到的性能文件进行文件名称与文件格式检验，检验通过后保存基站此次上传的性能文件以及上传记录。

进一步地，所述预设的命名规则为：

<RAT><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_UniqueId ；

其中，<RAT>表示为NR或LTE制式的性能文件，5G取值为NR，4G取值为LTE；<Startdate>为性能补采的开始日期；<Enddate>为性能补采的结束日期；<Starttime>为性能补采的开始时间；<Endtime>为性能补采的结束时间；所述UniqueId以OUI和SN表示，中间以.分割；

当<Enddate>和<Starttime>相同时，<Enddate>为可选字段；当<Enddate>和<Starttime>不同时，<Enddate>为必选字段；所述OUI为24bit的十六进制数。

本发明的有益效果为：

1、本发明在基站上传性能文件时，只进行文件校验与临时存储，不处理文件的详细解析，加快了文件的接收能力，降低了网管集中并发处理的压力。

2、本发明针对基站设备上传性能文件时间点集中的特点，使用性能文件临时区+服务器双存储，降低了平台出现内存不足、带宽不足、系统资源不足等严重问题。

3、本发明使用服务器统一处理性能文件，减轻了网管存储与解析压力。

4、本发明使用性能补采方法将性能文件异常时的文件重新进行采集，解决了性能文件处理出错的问题。

附图说明

图1是本发明实施例的基于TR069协议的基站性能文件处理系统的组网结构图。

图2是本发明实施例的基于TR069协议的基站性能文件处理方法的流程图。

图3是本发明实施例的性能文件定时处理流程图。

图4是本发明实施例的性能文件补采处理流程图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互结合，下面结合附图和具体实施例对本发明作进一步详细说明。

本发明实施例中若有方向性指示（诸如上、下、左、右、前、后……）仅用于解释在某一特定姿态（如附图所示）下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。

另外，在本发明中若涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。

实施例1，本发明实施例的基于TR069协议的基站性能文件处理系统的组网图请参照图1，本发明实施例的基于TR069协议的基站性能文件处理系统包括网管、服务器以及若干基站。

基站1至基站n通过网络连接网管，网管设置有性能文件临时区，用来临时存放基站上报的性能文件。性能文件临时区是网管缓存性能文件的区域。

网管与服务器通过网络相连。所述服务器采用部署文件系统的文件系统服务器。服务器包括存储性能文件的性能指标的数据库。文件系统为一种专业处理各种文件的系统。

基站按照预设的周期（该周期一般由网管配置）上传性能文件。

网管接收基站上传的性能文件，校验文件名称与文件格式。并查询性能文件临时区是否存在该性能文件，如果存在，则不接收基站上传的该性能文件；如果不存在，则进一步查询服务器中是否存在该性能文件，如果服务器中存在，则不接收该性能文件，如果服务器中不存在，则判断性能文件临时区是否存储满。

如果是，网管将性能文件临时区的所有性能文件传递到服务器，然后由服务器处理性能文件，并将性能文件的性能指标存储到数据库，网管再删除掉性能文件临时区的所有性能文件；

如果否，则继续后续处理，网管将基站上传的该性能文件存储到性能文件临时区，并保存基站上传此次性能文件的记录。

作为一种实施方式，网管定时将性能文件临时区的性能文件传递到服务器中，网管根据用户设置的性能文件任务，定时触发服务器处理性能文件；在服务器处理完性能文件后，网管删除性能文件临时区已经处理过的性能文件。

作为一种实施方式，服务器处理性能文件具体为：解析原始性能文件，并存储到数据库中，以及生成对应的便于用户查看与导出的性能文件报表。

作为一种实施方式，当服务器处理性能文件时发现性能文件异常，则向网管发送性能文件补采消息，补采消息包括基站SN（SerialNumber，序列号）、性能补采开始时间与性能补采结束时间。所述性能补采开始时间与性能补采结束时间格式为：日期+时间:yyyy/mm/dd hh:mm。

基站接收到服务器的性能文补采消息，向基站发送SetParameterValues消息来设置参数，设置基站性能补采开启，性能补采开始时间与性能补采结束时间；

基站收到SetParameterValues消息后，回复SetParameterValuesResponse消息给网管，并按照消息中的性能补采开始时间与性能补采结束时间进行基站性能文件收集，将其进行打包压缩，并根据预设的命名规则对压缩后的性能文件进行命名；基站使用HttpPut/Post消息将压缩后的性能文件上传给网管；基站发送完性能文件后，发送Inform消息（EventCode 为10 AUTONOMOUS TRANSFER COMPLETE）给网管；

网管回应InformResponse消息给基站，并对接收到的性能文件进行文件名称与文件格式检验，检验通过后保存基站此次上传的性能文件以及上传记录。

作为一种实施方式，所述预设的命名规则为：

<RAT><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_UniqueId ；

其中，<RAT>表示为“NR”或“LTE”制式的性能数据文件，5G取值为“NR”，4G取值为“LTE”。<Startdate>为性能补采的开始日期；<Enddate>为性能补采的结束日期；<Starttime>为性能补采的开始时间；<Endtime>为性能补采的结束时间；所述UniqueId以OUI和SN表示，中间以符号“.”分割，即OUI.SN。

当<Enddate>和<Starttime>相同时，<Enddate>为可选字段；当<Enddate>和<Starttime>不同时，<Enddate>为必选字段；OUI（Organizationally-Unique Identifier）为一种24bit的十六进制数。

网管对基站性能文件的格式校验，按照上述命名规则进行处理，对不符合上述命名规则的性能文件进行丢弃。

实施例2，本发明实施例的基于TR069协议的基站性能文件处理方法的流程如图2所示。基于TR069协议的基站性能文件处理方法包括步骤1~步骤3。

步骤1：基站按照预设的周期上传性能文件。预设的周期由网管配置，例如：基站配置为每15分钟上传一次性能文件。

步骤2：网管接收基站上传的性能文件，校验文件名称与文件格式，将校验不通过的性能文件丢弃。

步骤3：网管查询性能文件临时区是否存在该性能文件。

如果存在，则不接收基站上传的该性能文件，结束整个流程。

如果不存在，则继续后续流程。网管进一步查询服务器中是否存在该性能文件。

如果服务器中存在，则不接收该性能文件，结束整个流程。

如果服务器中不存在，则继续后续流程，判断网管的性能文件临时区是否存储满。

如果是，网管将性能文件临时区的所有性能文件传递到服务器，然后由服务器处理性能文件，并将性能文件的性能指标存储到数据库，网管再删除掉性能文件临时区的所有性能文件；

如果否，网管则将基站上传的该性能文件存储到性能文件临时区，并保存基站上传此次性能文件的记录，然后结束整个流程。

为了更完善的处理性能文件，网管定时将性能文件临时区的性能文件，传递到服务器中。并且，网管根据用户设置的性能文件任务，定时触发服务器处理性能文件。服务器处理完性能文件，通知网管删除性能文件临时区已经处理过的性能文件。

实施例3，本发明的网管性能任务触发的性能文件定时处理流程如图3所示。

1、网管设置的性能文件任务超时，触发网管向服务器发送消息，要求服务器处理基站性能文件。

2、服务器收到消息后，处理该网管下所有基站的性能文件。

3、服务器处理的性能文件的性能指标存储到数据库中。

4、网管删除掉性能文件临时区的性能文件。

实施例4，本发明的性能文件补采处理流程如图4所示。

1、服务器向网管发送性能文件补采消息。消息中携带基站SN信息，性能补采开始时间，性能补采结束时间。网管再向基站发送SetParameterValues 消息来设置参数。其发送的消息中参数定义如表1：

表1

备注：上述参数为符合TR-098协议定义的数据模型，是一种适配TR069协议的4G基站的参数。其参数值根据用户设置，此处不再详述。

2、基站设置性能补采参数（性能补采开启，性能补采开始时间，性能补采结束时间）。

3、基站设置完补采参数后，发送SetParameterValuesResponse消息通知网管参数设置完毕。

4、基站根据性能补采开始时间和性能补采结束时间收集性能文件，并压缩打包。

5、基站使用Http Put/Post消息将压缩后的性能文件上传给网管的性能文件临时区。

6、基站发送完性能文件后，发送Inform消息（EventCode 为10 AUTONOMOUSTRANSFER COMPLETE）给网管。消息中SOAP结构举例如下：

<Event soap_enc:arrayType=\"cwmp:EventStruct[1]\">

<EventStruct>

<EventCode xsi:type=\"xsd:string\">10 AUTONOMOUS TRANSFERCOMPLETE</EventCode>

<CommandKey xsi:type=\"xsd:string\"/>

</EventStruct>

</Event>

7、网管发送InformResponse消息回复基站。

8、网管对性能文件进行校验，校验通过后保存此次性能文件，并记录此次性能文件上传记录。

9、网管发送性能文件给服务器进行处理。

实施例5，本发明的打包压缩的性能文件，其命名方法如下：

<RAT><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_UniqueId

<RAT>指示是“NR”或“LTE”制式的性能数据文件，5G取值为“NR”，4G取值为“LTE”。

<Startdate>为性能补采的开始日期。

<Enddate>为性能补采的结束日期。

<Starttime>为性能补采的开始时间。

<Endtime>为性能补采的结束时间。

UniqueId以OUI和SN表示，中间以“.”分割，即OUI.SN。

当<Enddate>和<Starttime>相同时，<Enddate>为可选字段；当<Enddate>和<Starttime>不同时，<Enddate>为必选字段。

例如：一种4G的性能文件，其OUI为20AC9C，SN为882304261CE265-LTE，<Startdate>为2023年1月1日，<Enddate>为2023年1月2日，<Starttime>为10:00，<Endtime>为20:00，则其压缩文件名为：LTE20230101.1000-20230102.2000_20AC9C.882304261CE265-LTE。其文件属性为rar的压缩包。压缩文件名中通过命名中携带的LTE或NR，能够直观看出是4G或5G基站的压缩文件，通过携带开始与结束时间，可以清晰看出性能补采的时间段，最后UniqueId将OUI与SN结合，标识了厂家和设备信息。此种命名规则不仅可以严格校验基站性能文件，更便于用户识别基站厂商的性能文件的基站类型与补采时间。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同范围限定。

Claims (10)

1.一种基于TR069协议的基站性能文件处理系统，其特征在于，包括基站、网管、服务器，网管包含用于缓存性能文件的性能文件临时区，服务器包括存储性能文件的性能指标的数据库，

基站按照预设的周期上传性能文件；

网管接收基站上传的性能文件，校验文件名称与文件格式；并查询性能文件临时区是否存在该性能文件，如果存在，则不接收基站上传的该性能文件；如果不存在，则进一步查询服务器中是否存在该性能文件，如果服务器中存在，则不接收该性能文件，如果服务器中不存在，则判断性能文件临时区是否存储满，

如果是，网管将性能文件临时区的所有性能文件传递到服务器，然后由服务器处理性能文件，并将性能文件的性能指标存储到数据库，网管再删除掉性能文件临时区的所有性能文件；

如果否，网管则将基站上传的该性能文件存储到性能文件临时区，并保存基站上传此次性能文件的记录。

2.如权利要求1所述的基于TR069协议的基站性能文件处理系统，其特征在于，网管定时将性能文件临时区的性能文件传递到服务器中，网管根据用户设置的性能文件任务，定时触发服务器处理性能文件；在服务器处理完性能文件后，网管删除性能文件临时区已经处理过的性能文件。

3.如权利要求1所述的基于TR069协议的基站性能文件处理系统，其特征在于，服务器处理性能文件具体为：解析原始性能文件，并存储到数据库中，以及生成对应的便于用户查看与导出的性能文件报表。

4.如权利要求3所述的基于TR069协议的基站性能文件处理系统，其特征在于，当服务器处理性能文件时发现性能文件异常，则向网管发送性能文件补采消息，补采消息包括基站SN、性能补采开始时间与性能补采结束时间；

基站接收到服务器的性能文补采消息，向基站发送SetParameterValues消息来设置参数，设置基站性能补采开启，性能补采开始时间与性能补采结束时间；

基站收到SetParameterValues消息后，回复SetParameterValuesResponse消息给网管，并按照消息中的性能补采开始时间与性能补采结束时间进行基站性能文件收集，将其进行打包压缩，并根据预设的命名规则对压缩后的性能文件进行命名；基站使用Http Put/Post消息将压缩后的性能文件上传给网管；基站发送完性能文件后，发送Inform消息给网管；

网管回应InformResponse消息给基站，并对接收到的性能文件进行文件名称与文件格式检验，检验通过后保存基站此次上传的性能文件以及上传记录。

5.如权利要求4所述的基于TR069协议的基站性能文件处理系统，其特征在于，所述预设的命名规则为：

<RAT><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_UniqueId ；

其中，<RAT>表示为NR或LTE制式的性能文件，5G取值为NR，4G取值为LTE；<Startdate>为性能补采的开始日期；<Enddate>为性能补采的结束日期； <Starttime>为性能补采的开始时间；<Endtime>为性能补采的结束时间；所述UniqueId以OUI和SN表示，中间以.分割；

当<Enddate>和<Starttime>相同时，<Enddate>为可选字段；当<Enddate>和<Starttime>不同时，<Enddate>为必选字段；所述OUI为24bit的十六进制数。

6.一种基于TR069协议的基站性能文件处理方法，其特征在于，包括：

步骤1：基站按照预设的周期上传性能文件；

步骤2：网管接收基站上传的性能文件，校验文件名称与文件格式；

步骤3：网管查询性能文件临时区是否存在该性能文件，如果存在，则不接收基站上传的该性能文件；如果不存在，则进一步查询服务器中是否存在该性能文件，如果服务器中存在，则不接收该性能文件，如果服务器中不存在，则判断性能文件临时区是否存储满，

如果是，网管将性能文件临时区的所有性能文件传递到服务器，然后由服务器处理性能文件，并将性能文件的性能指标存储到数据库，网管再删除掉性能文件临时区的所有性能文件；

如果否，网管则将基站上传的该性能文件存储到性能文件临时区，并保存基站上传此次性能文件的记录。

7.如权利要求6所述的基于TR069协议的基站性能文件处理方法，其特征在于，步骤3之后还包括：

步骤4：网管定时将性能文件临时区的性能文件传递到服务器中；

步骤5：网管根据用户设置的性能文件任务，定时触发服务器处理性能文件；在服务器处理完性能文件后，网管删除性能文件临时区已经处理过的性能文件。

8.如权利要求6所述的基于TR069协议的基站性能文件处理方法，其特征在于，步骤3中，服务器处理性能文件具体为：解析原始性能文件，并存储到数据库中，以及生成对应的便于用户查看与导出的性能文件报表。

9.如权利要求8所述的基于TR069协议的基站性能文件处理方法，其特征在于，步骤3包括：

子步骤1：当服务器处理性能文件时发现性能文件异常，则向网管发送性能文件补采消息，补采消息包括基站SN、性能补采开始时间与性能补采结束时间；

子步骤2：基站接收到服务器的性能文补采消息，向基站发送SetParameterValues消息来设置参数，设置基站性能补采开启，性能补采开始时间与性能补采结束时间；

子步骤3：基站收到SetParameterValues消息后，回复SetParameterValuesResponse消息给网管，并按照消息中的性能补采开始时间与性能补采结束时间进行基站性能文件收集，将其进行打包压缩；

子步骤4：基站根据预设的命名规则对压缩后的性能文件进行命名；

子步骤5：基站使用Http Put/Post消息将压缩后的性能文件上传给网管；

子步骤6：基站发送完性能文件后，发送Inform消息给网管；

子步骤7：网管回应InformResponse消息给基站，并对接收到的性能文件进行文件名称与文件格式检验，检验通过后保存基站此次上传的性能文件以及上传记录。

10.如权利要求9所述的基于TR069协议的基站性能文件处理方法，其特征在于，所述预设的命名规则为：

<RAT><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_UniqueId ；

其中，<RAT>表示为NR或LTE制式的性能文件，5G取值为NR，4G取值为LTE；<Startdate>为性能补采的开始日期；<Enddate>为性能补采的结束日期； <Starttime>为性能补采的开始时间；<Endtime>为性能补采的结束时间；所述UniqueId以OUI和SN表示，中间以.分割；

当<Enddate>和<Starttime>相同时，<Enddate>为可选字段；当<Enddate>和<Starttime>不同时，<Enddate>为必选字段；所述OUI为24bit的十六进制数。