本发明涉及网络
技术领域：
：，尤其涉及一种策略相关信息处理方法及装置。
背景技术：
：：为了向用户提供差异化的服务，在网络中引入了策略控制及计费(policycontrolcharging，pcc)框架进行策略控制、执行和计费。图1所示为一种pcc架构示意图。所述pcc架构主要包括策略和计费规则功能(policyandchargingrulefunction，pcrf)实体及策略和计费执行功能(policyandchargingenforcementfunction，pcef)实体。所述pcrf实体，主要用于策略控制决策和基于流计费控制的功能，向pcef实体提供关于业务数据流检测、门控、基于服务质量和基于流计费的网络控制功能，能够以业务、用户、位置、累计使用量、接入类型、时间等多个维度为触发条件，生成管控规则下发给pcef实体进行执行。所述pcef实体，主要用于业务数据流的检测、策略执行和基于流的计费等功能，功能实体通常部署于网关设备中。通常，所述pcef实体设置在系统架构演进网关(systemarchitectureevolutiongateway，sae-gw)上，一端与移动管理实体(mobilitymanagemententity，mme)连接。而mme将连接到基站，例如，演进型基站enodeb，再由enodeb为用户设备(userequipment，ue)提供无线接入。所述pcef实体的另一端与业务侧连接，这里的业务侧可为各种提供业务服务的网络设备或网络网元。所述用户属性存储器(subscriptionprofilerepository，spr)通常设在pcrf实体上，其与业务运营支撑系统(businessandoperationsupportsystem，boss)直接或间接连接，获取用户的策略签约信息。当spr与pcrf实体独立部署时，pcrf将与spr进行直接连接。总之，在整个pcc框架中仅有pcrf实体能够感知或记录少量pcc架构中各个策略的运行状态。然而随着pcc架构的功能的日益丰富，需要完整监控pcc架构中的各个策略的运行状态的需求越来越强烈，只有通过这些信息的监控，才可能知道策略的运行结果，以便后续的策略分析和策略执行异常的分析。技术实现要素：有鉴于此，本发明实施例期望提供一种策略相关信息处理方法及装置，以从多维度获取pcc架构中策略相关信息的获取。为达到上述目的，本发明的技术方案是这样实现的：本发明实施例第一方面提供一种策略相关信息的处理方法，包括：策略和计费规则功能pcrf实体对策略状况进行统计生成统计信息，并将所述统计信息上报给管理平台；所述管理平台接收策略和计费规则功能pcrf实体上报的统计信息；所述管理平台向所述pcfr实体发送查询请求；所述pcrf实体接收所述管理平台查询请求，并基于所述查询请求向所述管理平台返回与策略执行相关的查询结果；所述管理平台接收所述查询结果；所述pcrf实体根据策略运行状态，生成执行日志，并将所述执行日志上报给所述管理平台；所述管理平台接收所述pcrf实体上报的执行日志；所述管理平台对所述统计信息，查询结果及所述执行日志的至少之一，按照预设维度进行数据汇总，并集中存储汇总后的数据；对所述统计信息、查询结果及所述执行日志的至少之一，按照预设分析策略进行数据分析，形成并呈现分析结果。基于上述方案，所述统计信息包括：策略和规则映射表、策略统计信息表及规则统计信息表；所述策略和规则映射表包括：策略和策略中规则的对应关系；所述策略统计信息表包括：策略的执行统计信息；所述规则统计信息表包括：规则的执行统计信息。基于上述方案，所述pcrf实体将所述统计信息上报给管理平台，包括：所述pcrf实体按照第一周期向所述管理平台上报所述统计信息；所述pcrf实体将所述执行日志上报给所述管理平台，包括：所述pcrf实体按照第二周期向所述管理平台上报所述执行日志。基于上述方案，所述pcrf实体按照第一周期向所述管理平台上报所述统计信息，包括：所述pcrf实体采用第一链路向所述管理平台上报所述统计信息；当连续n个周期所述统计信息上报失败时，所述pcrf实体以第二链路向所述管理平台发送预定消息，其中，所述预定消息用于所述管理平台主动向所述pcrf实体拉取所述统计信息，所述n为正整数；所述管理平台接收所述pcrf实体在连续n个周期以第一链路所述统计信息上报失败时，以第二链路发送的预定消息；所述管理平台根据所述预定消息，向所述pcrf实体拉取所述统计信息；或，当连续n个周期所述统计信息上报失败时，所述pcrf实体以所述第二链路向所述管理平台发送告警信息，其中，所述告警信息用于指示所述第一链路异常；当所述第一链路恢复正常之后，所述pcrf实体将上报失败的所述统计信息通过所述第一链路重新上报给所述管理平台；所述管理平台接收所述pcrf实体在连续n个周期以第一链路所述统计信息上报失败时，以第二链路发送的告警信息；输出所述告警信息。基于上述方案，所述策略和规则映射表、所述策略统计信息表及所述规则统计信息表均存储为数据库文件，且以预定格式命名所述数据库文件的文件名；其中，所述文件名包括：表名、地理位置标识、实体标识和时间标识；所述表名用于指示所述数据库文件存储的信息为所述策略和规则映射表、所述策略统计信息表或所述规则统计信息表；所述地理位置标识为所述pcrf实体服务的地理位置的标识信息；所述实体标识为所述pcrf实体的逻辑标识；所述时间标识为所述数据库文件对应的第一周期的时间标记。基于上述方案，所述pcrf实体接收所述查询请求，并基于所述查询请求向所述管理平台返回与策略执行相关的查询结果管理平台，包括以下至少之一：接收策略下发通知的查询请求，基于所述策略下发通知的查询请求，将第一预定时间内策略的通知下发状况信息反馈给所述管理平台；接收策略生效的查询请求，基于所述策略生效的查询请求，将第二预定时间内策略的生效状况信息反馈给所述管理平台；接收业务变更的查询请求，基于所述业务变更的查询请求，将第三预定时间内的业务变更状况信息反馈给所述管理平台；接收业务签约趋势的查询请求，基于所述业务签约的查询请求，将第四预定时间内的业务签约趋势信息反馈给所述管理平台。本发明实施例第二方面提供种策略相关信息的处理装置，应用于策略和计费规则功能pcrf实体中，包括：统计上报模块，用于对策略状况进行统计生成统计信息，并将所述统计信息上报给管理平台；第一查询模块，用于接收所述管理平台的查询请求，基于所述查询请求向所述管理平台返回与策略执行相关的查询结果；日志上报模块，用于根据策略运行状态，生成执行日志，并将所述执行日志上报给所述管理平台。基于上述方案，所述统计信息包括：策略和规则映射表、策略统计信息表及规则统计信息表；所述策略和规则映射表包括：策略和策略中规则的对应关系；所述策略统计信息表包括：策略的执行统计信息；所述规则统计信息表包括：规则的执行统计信息。基于上述方案，所述统计上报模块，具体用于按照第一周期向所述管理平台上报所述统计信息；所述日志上报模块，具体用于按照第二周期向所述管理平台上报所述执行日志。基于上述方案，所述统计上报模块，还用于采用第一链路向所述管理平台上报所述统计信息；当连续n个周期所述统计信息上报失败时，以第二链路向所述管理平台发送预定消息，其中，所述预定消息用于所述管理平台主动向所述pcrf实体拉取所述统计信息，所述n为正整数；或，当连续n个周期所述统计信息上报失败时，以所述第二链路向所述管理平台发送告警信息，其中，所述告警信息用于指示所述第一链路异常；当所述第一链路恢复正常之后，将上报失败的所述统计信息通过所述第一链路重新上报给所述管理平台。基于上述方案，所述策略和规则映射表、所述策略统计信息表及所述规则统计信息表均存储为数据库文件，且以预定格式命名所述数据库文件的文件名；其中，所述文件名包括：表名、地理位置标识、实体标识和时间标识；所述表名用于指示所述数据库文件存储的信息为所述策略和规则映射表、所述策略统计信息表或所述规则统计信息表；所述地理位置标识为所述pcrf实体服务的地理位置的标识信息；所述实体标识为所述pcrf实体的逻辑标识；所述时间标识为所述数据库文件对应的第一周期的时间标记。基于上述方案，所述第一查询模块，具体用于接收策略下发通知的查询请求，基于所述策略下发通知的查询请求，将第一预定时间内策略的通知下发状况信息反馈给所述管理平台；和/或，接收策略生效的查询请求，基于所述策略生效的查询请求，将第二预定时间内策略的生效状况信息反馈给所述管理平台；和/或，接收业务变更的查询请求，基于所述业务变更的查询请求，将第三预定时间内的业务变更状况信息反馈给所述管理平台；和/或，接收业务签约趋势的查询请求，基于所述业务签约的查询请求，将第四预定时间内的业务签约趋势信息反馈给所述管理平台。本发明实施例第三方面提供一种策略相关信息的处理装置，应用于管理平台中，包括：统计信息接收模块，用于接收策略和计费规则功能pcrf实体上报的统计信息；第二查询模块，用于向所述pcfr实体发送查询请求，接收所述pcrf实体基于所述查询请求返回的查询结果；日志接收模块，用于日志接收所述pcrf实体上报的执行日志；数据汇总模块，用于对所述统计信息，查询结果及所述执行日志的至少之一，按照预设维度进行数据汇总，并集中存储汇总后的数据；分析呈现模块，用于对所述统计信息、查询结果及所述执行日志的至少之一，按照预设分析策略进行数据分析，形成并呈现分析结果。基于上述方案，所述统计信息接收模块，还具体用于接收所述pcrf实体在连续n个周期以第一链路所述统计信息上报失败时，以第二链路发送的预定消息；根据所述预定消息，向所述pcrf实体拉取所述统计信息；或，接收所述pcrf实体在连续n个周期以第一链路所述统计信息上报失败时，以第二链路发送的告警信息；并输出所述告警信息。本发明实施例提供的策略相关信息处理方法及装置，会根据策略的运行状态生成执行日志，并会根据策略状况，生成统计信息；并可以根据管理平台的查询请求，形成查询结果；显然pcrf实体可以从多维度获取策略的各种相关信息，策略的相关信息的维度多且全面，这些信息上报给管理平台，管理平台可以根据这些信息进行策略的调整、网络参数的调整和/或故障分析、定位和故障去除等操作，从而更好的监控pcc框架内的策略状况。附图说明图1为一种pcc框架的结构示意图；图2a为本发明实施例提供第一种策略相关信息的处理方法的流程示意图图2b为本发明实施例提供的第二种策略相关信息的处理方法的流程示意图；图3为本发明实施例提供的第三种策略相关信息的处理方法的流程示意图；图4为本发明实施例提供一种策略相关信息的处理装置的结构示意图；图5为本发明实施例提供另一种策略相关信息的处理装置的结构示意图；图6为本发明实施例提供的一种pcc框架的结构示意图；图7为本发明实施例提供的统计信息的上报流程示意图；图8为本发明实施例提供的数据查询的流程示意图。具体实施方式以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。如图2a所示，本实施例提供策略相关信息的处理方法，应用于包括管理平台和策略和计费规则功能pcrf实体的系统中，所述方法具体包括：步骤s101：策略和计费规则功能pcrf实体对策略状况进行统计生成统计信息，并将所述统计信息上报给管理平台；步骤s102：所述管理平台接收策略和计费规则功能pcrf实体上报的统计信息；步骤s103：所述管理平台向所述pcfr实体发送查询请求；步骤s104：所述pcrf实体接收所述管理平台查询请求，并基于所述查询请求向所述管理平台返回与策略执行相关的查询结果；步骤s105：所述管理平台接收所述查询结果；步骤s106：所述pcrf实体根据策略运行状态，生成执行日志，并将所述执行日志上报给所述管理平台；步骤s107：所述管理平台接收所述pcrf实体上报的执行日志；步骤s108：所述管理平台对所述统计信息，查询结果及所述执行日志的至少之一，按照预设维度进行数据汇总，并集中存储汇总后的数据；对所述统计信息、查询结果及所述执行日志的至少之一，按照预设分析策略进行数据分析，形成并呈现分析结果。本实施例中的pcrf实体，所述pcrf实体为策略的生成、下发及执行的控制设备，故可以获取到策略生成、下发及执行的各种状况信息。通常pcrf实体生成策略，会将策略下发到pcef实体进行执行。这里的管理平台与所述pcrf实体连接，能够与pcrf实体之间进行信息交互。值得注意的是图2a所示为pcrf实体与管理平台之间的一种交互流程；在具体实现时，pcrf实体与管理平台之间的信息交互顺序并不严格按照图2a所示的顺序执行。所述步骤s101与步骤s103及步骤s106中的任意两个，可以相互颠倒顺序。总之通过上述方法提出，pcrf实体从多维度获取策略的各种相关信息，策略的相关信息的维度多且全面，这些信息上报给管理平台，管理平台获得这些信息之后，可以执行各种数据分析操作，从而更好的监控pcc框架内的策略生成、下发以及执行等状况。以下分别从pcrf实体和管理平台的不同侧来介绍pcrf实体和管理平台执行的策略相关信息的管理方法。如图2b所示，本实施例提供一种策略相关信息的处理方法，应用于策略和计费规则功能pcrf实体中，包括：步骤s110：对策略状况进行统计生成统计信息，并将所述统计信息上报给管理平台；步骤s120：接收管理平台的查询请求，基于所述查询请求向所述管理平台返回与策略执行相关的查询结果；步骤s130：根据策略运行状态，生成执行日志，并将所述执行日志上报给所述管理平台。本实施例可为应用于pcrf实体中的信息处理方法。在本实施例中所述步骤s110中会对策略状况进行统计，生成统计信息。这里的策略状况可包括策略的生成状况、下发状况、命中状况及执行状况进行统计。例如，一个策略可包括多条规则，一个策略生成之后下发给了哪些用户设备、哪些用户设备命中了该策略，这些策略是否被执行了和/或执行了之后产生的效果数据等。在本实施例中pcrf实体会策略状况进行统计，生成统计数据。这里的统计数据可包括策略的在指定时间范围内的下发次数、命中次数、执行次数等统计得到的数值。在步骤s120中会接收查询客户端发送的查询请求。在本实施例中所述pcrf实体可以提供实时查询接口，这里的实时查询接口可以供查询客户端实时接入向所述pcrf实体发送所述查询请求，所述pcrf实体可基于所述查询请求在当前采集、监控或统计得到的数据中进行查询，并实时返回查询结果。这里的查询客户端可为任意客户端，例如，所述管理平台将作为查询客户端发送查询请求。所述查询客户端可为简单对象访问协议(simpleobjectaccessprotocol，soap)客户端，基于soap向所述pcrf实体发送查询请求，接收pcrf实体基于soap协议返回的查询请求。在步骤s130中，所述pcrf实体还会根据策略运行状况，生成详细的执行日志。在执行日志中详细记录了策略及策略中每一个规则的详细执行状况。所述执行状况可包括：执行时间、执行用户标识、用户类别、终端类型、终端所在地理位置等各种信息。所述策略及规则的每一个执行都做都可以生成条执行日志，形成所述执行日志。总之，在本实施例中还会生成所述执行日志，将执行日志上报给管理平台。这样的话，一方面管理平台获得了统计信息，知道了策略状况的统计状况，另一方通过执行日志的接收，知道了策略的详细执行状况，若有需要详细执行数据时，可以通过查询所述执行日志获取。此外，所述pcrf实体还提供基于查询请求的查询结果的返回，在本实施例中所述pcrf实体提供的查询接口可为实时查询接口，可供管理平台有需要时，随时查询所需要的信息，从而可以及时的获知策略的生成、下发、命中以及执行等各种信息。这里的管理平台在接收到所述统计信息、查询结果和/或执行日志之后，可以按照预设的分析方式进行数据分析，然后得到从各个维度所需的策略状况信息，并通过显示或发送给显示设备等方式呈现出来，方便管理人员的查看，或将上述信息进行汇总和整合，然后集中存储，方便后续数据的查询，实现数据的集中式管理和备份。总之，本实施例中所述pcrf实体会从多个维度获取策略的相关信息，并上报给管理平台或供管理平台查询，这样的话，就提供了pcc框架内策略的详细和多维度的监控，方便根据获取的统计信息、执行日志和查询结果中的一个或多个，进行策略调整或网络拓、带宽等各种网络参数的调整，实现pcc框架的资源优化和通信服务的优化。值得注意的上，上述步骤s110至步骤s130的执行顺序，可以如图1所示，而实质上，所述步骤s110和步骤s130的执行顺序不限于图1所示，步骤s110至步骤s130之间可以随意排序，在此就不做限定。当然，在一些实施例中所述统计信息中策略执行状况和策略中的规则执行状况，可以是根据执行日志生成的，则所述步骤s110可位于所述步骤s130中执行日志生成之后执行。但是所述统计信息的生成，例如，策略的下发，在执行日志生成的同时，策略的下发次数随着下发动作的执行，被实时统计了，显然所述步骤s110也可以与所述步骤s130同步执行或限于步骤s130执行。总之，本实施例中步骤s110至步骤s130的执行不局限于上述操作。在一些实施例中。所述统计信息包括：策略和规则映射表、策略统计信息表及规则统计信息表；所述策略和规则映射表包括：策略和策略中规则的对应关系；所述策略统计信息表包括：策略的执行统计信息；所述规则统计信息表包括：规则的执行统计信息。这样的话，管理平台根据所述策略和规则映射表，就知道当前生成了哪些策略，每一个策略中包括哪些规则。根据所述策略的执行统计信息就，可以知道每一个策略整体执行状况，而根据所述规则的执行统计信息就可以知道每一条规则的整体执行状况。显然，统计信息按照策略和规则的对应维度、策略整体执行维度和规则的统计执行维度，生成不同的信息表，一方面实现了数据的条理清晰的统计，且方便后续管理平外的查询客户端或管理平台的信息简便查询。在所述步骤s110可包括：按照第一周期向所述管理平台上报所述统计信息；所述步骤s130可包括：按照第二周期向所述管理平台上报所述执行日志。在本实施例中，所述统计信息和所述执行日志都是按照周期由所述pcrf实体自行上报的，通常一个管理平台可能连接有多个pcrf实体，pcrf实体自行按照周期上报所述统计信息和执行日志，可以减少管理平台通过出发消息的形式，自动查询导致的负荷重的现象。在本实施例中所述第一周期和所述第二周期分别对应的时长可相等，也可以不等。在本实施例中所述第一周期对应的时长短于所述第二周期。详细的执行日志，比统计信息的数据量较大，若pcrf实体频繁上报可能会占据带宽。通过统计信息的上报，管理平台可以根据统计信息确定出是否出现异常，若出现异常可以通过查询请求的方式获取执行日志，来进行查看。为了减少带宽的占用，在上报所述执行日志之前，将所述执行日志进行压缩，上传所述执行日志的压缩包，以减少上传的数据量，减少占用的带宽及带宽占用过多导致的拥堵等现象。在一些实施例中，所述按照第一周期向所述管理平台上报所述统计信息，包括：采用第一链路向所述管理平台上报所述统计信息；当连续n个周期所述统计信息上报失败时，以第二链路向所述管理平台发送预定消息；其中，所述预定消息用于所述管理平台主动向所述pcrf实体拉取所述统计信息。例如，所述pcrf实体与管理平台之间可以基于文件传输协议(filetransferprotocol，ftp)建立第一链路，采用ftp协议利用所述第一链路周期性向所述管理平台发送所述统计信息。当第n周期上报失败时，在第n+1个周期将第n个周期和第n+1个周期所需上报的统计信息一同上报给管理平台。但是连续n个周期都上报失败，此时可能是第一链路出现故障，同时为了确保管理平台及时获得所述统计信息，做出基于所述统计信息的相关操作，所述pcrf平台会基于第二链路向管理平台发送预定消息。所述第二链路为不同于第一链路的传输链路，例如，所述第二链路为基于soap协议建立的传输链路，所述预定消息可为soap消息。通过预定消息的发送，则管理平台就会接收到所述预定消息，来自动拉取所述统计信息。这里的拉取的统计信息，为这n个周期的统计信息。pcrf实体和管理平台是双向连接的，当pcrf实体向管理平台发送数据的第一链路故障时，管理平台与pcrf实体通信的第三链路未必故障，此时，若管理平台自动来拉取是可以获取到数据的。当然，在具体实现时，所述第三链路可为不同于所述第一链路的另一个传输链路。在另外一些实施例中，所述方法还包括：当连续n个周期所述统计信息上报失败时，以第二链路向所述管理平台发送告警信息。管理平台接收到所述告警信息之后会输出所述告警信息，触发第一链路的修复处理。所述方法还包括：当所述第一链路修复正常之后，会利用所述第一链路将上传失败的所述统计信息重新上传给所述管理平台。采用这种方式，所述管理平台也会获得pcrf实体形成的所有统计信息。在一些实施例中，所述策略和规则映射表、所述策略统计信息表及所述规则统计信息表均存储为数据库文件，且以预定格式命名所述数据库文件的文件名；其中，所述文件名包括：表名、地理位置标识、实体标识和时间标识；所述表名用于指示所述数据库文件存储的信息为所述策略和规则映射表、所述策略统计信息表或所述规则统计信息表；所述地理位置标识为所述pcrf实体服务的地理位置的标识信息；所述实体标识为所述pcrf实体的逻辑标识；所述时间标识为所述数据库文件对应的第一周期的时间标记。在本实施例中所述统计信息都有统一的命名规则，通过该统一的命名规则，方便后续管理平台通过文件名就知道当前文件的主要内容，是来自哪一个地理位置的pcrf实体，采集的哪一个时间段的数据。且在本实施例中统一采用数据库文件，而并非文本文件等其他文件格式，方便后续数据存储过程中，直接添加到管理平台的集中管理的数据库中，减少数据文件格式的转换，实现数据的简单存储。所述数据库文件可为文件后缀为.csv的文件。在一些实施例中，所述查询请求根据查询内容可以分为多种，以下提供可选的几种：第一种：pcrf实体接收策略下发通知的查询请求，基于所述策略下发通知的查询请求，将第一预定时间内策略的通知下发状况信息反馈给所述查询客户端。策略生成了，可能需要通知到对应的用户，在本实施例中查询的策略生成之后，向用户设备的通知的下发状况。第二种：pcrf实体接收策略生效的查询请求，基于所述策略生效的查询请求，将第二预定时间内策略的生效状况信息反馈给所述查询客户端。一个策略生成之后，需要满足一些特定条件才能生效，在本实施例中查询的一条或多条策略的生效状况，例如，当前生效用户数等信息。第三种：pcrf实体接收业务变更的查询请求，基于所述业务变更的查询请求，将第三预定时间内的业务变更状况信息反馈给所述查询客户端。通信业务或网络业务在使用过程中，用户签约的或订购的业务可能会发生变化，这些变化可能导致对用户执行的策略的变化，故在本实施例中还引入业务变更的查询请求。这的业务变更状况信息，可包括退订某一个业务的用户数，某一个业务的新增用户数，退订用户的用户标识或新增用户的用户标识等信息。这里的用户标识可为用户的通信标识，所述通信标识可为手机号或社交账号等各种能够标识用户的信息。第四种：pcrf实体接收业务签约趋势的查询请求，基于所述业务签约的查询请求，将第四预定时间内的业务签约趋势信息反馈给所述查询客户端。所述业务签约趋势信息，可用于指示当前业务的签约变化趋势，例如，签约用户整体是增加了，还是减少，趋势变化幅度以及同比变化幅度等各种指示变化趋势的信息，通过业务签约趋势信息的反馈，可方便管理平台整体上对业务签约趋势进行获取。在一些实施例中，所述查询请求可为所述管理平台发送的任意请求，在所述查询请求中携带有查询参数；所述查询参数有可包括检索参数和限定参数；所述pcrf实体将根据查询请求中的检索参数，为查询数据的查询依据，检索存储在所述pcrf实体中的信息，形成所述查询结果。所述限定参数可用于限定执行日志或统计信息的生成时间等时间参数，用于限制信息检索的检索范围，利用依据参数在所述检索范围内检索得到所述查询结果。如图3所示，本实施例提供一种策略相关信息的处理方法，应用于管理平台中，包括：步骤s210：接收策略和计费规则功能pcrf实体上报的统计信息；步骤s220：向所述pcfr实体发送查询请求，接收所述pcrf实体基于所述查询请求返回的查询结果；步骤s230：接收所述pcrf实体上报的执行日志；步骤s240：对所述统计信息，查询结果及所述执行日志的至少之一，按照预设维度进行数据汇总，并集中存储汇总后的数据；步骤s250：对所述统计信息、查询结果及所述执行日志的至少之一，按照预设分析策略进行数据分析，形成并呈现分析结果。本实施例为实现于管理平台中的信息处理方法。。管理平台与pcrf实体连接，可以接收执行日志、统计信息和查询结果，并会基于从pcrf实体接收的信息，可按照策略、业务、时间、用户类型等各种维度进行数据汇总，并将汇总后的数据进行集中管理和存储。例如，按照策略维度进行数据汇总，可以将每一个策略的执行日志、统计信息和查询结果进行汇总，集中到预定区域进行存储。当然，也可以按照时间顺序进行汇总。在具体实现可以结合多个预设维度进行数据汇总。此外，所述pop等管理平台还会按照预设分析策略进行数据分析，得到分析结果，并呈现出所述分析结果，这里的呈现包括显示输出所述分析结果，或者，将所述分析结果发送给各种输出设备，输出所述分析结果。所述分析结果可以是各种图表。所述输出设备可为各种显示输出设备。当然，所述输出设备还可以音频输出设备等。所述显示输出设备可包括投影输出设备，液晶显示输出设备或电子墨水显示输出设备。在本实施例中所述步骤s210至步骤s230之间的执行顺序可以如图2所示，但是也不限于如图3所示。所述步骤s210至步骤s230的执行顺序的可以任意随后调换。所述步骤s240和步骤s250之间的顺序也可以随意调换，仅需要保证步骤s240和步骤s250位于所述步骤s210至步骤s230之后。当然，在步骤s240至步骤s250都可以是周期性执行的。在本实施例中管理平台，可以从pcrf实体接收统计信息、执行日志，还可以是满足特定需求的查询结果，从而满足了对pcc框架各种策略监控和执行的各种信息。在本实施例中，所述方法还包括：接收所述pcrf实体在n个周期以第一链路所述统计信息上报失败时，以第二链路发送的预定消息；根据所述预定消息，向所述pcrf实体拉取所述统计信息。在本实施例中管理平台和pcrf实体之间可以建立第一链路和第二链路。大多数情况下，所述pcrf实体都是通过第一链路上传所述统计信息，当连续n个周期统计信息都上传失败时，则会接收到管理平台以第二链路发送的预定消息。这里的第一链路可为基于ftp建立的传输链路，所述第二链路可为基于soap建立的传输链路。当管理平台接收到预定消息之后，会自动到发送所述预定消息的pcrf实体拉取所述统计信息。这里的预定消息可为soap消息。在还有些实施例中，所述方法还包括：接收所述pcrf实体在n个周期以第一链路所述统计信息上报失败时，以第二链路发送的告警信息；输出所述告警信息。这里的告警信息的输出可包括显示输出、音频输出等各种输出方式，这样管理人员看到所述告警信息之后，就知道对应的第一链路故障，将即时启动修复。在本实施例中所述方法还可包括：在所述第一链路修复正常之后，接收所述pcrf实体重新上报的之前上报失败的统计信息。在本实施例中所述统计信息及查询结果的相关描述，可以参见前述实施例对应部分，在此就不再详细介绍。如图4所示，本实施例提供一种策略相关信息的处理装置，应用于策略和计费规则功能pcrf实体中，包括：统计上报模块110，用于对策略状况进行统计生成统计信息，并将所述统计信息上报给管理平台；第一查询模块120，用于接收管理平台的查询请求，基于所述查询请求向所述管理平台返回与策略执行相关的查询结果；日志上报模块130，用于根据策略运行状态，生成执行日志，并将所述执行日志上报给所述管理平台。本实施例提供的所述装置，为所述pcrf实体内的信息处理结果。所述统计上报模块110、第一查询模块120及日志上报模块130，可对应于所述pcrf实体中的处理器或处理电路，所述处理器或处理电路与通信接口连接，该通信接口可用于与管理平台或管理平台进行数据交互。所述处理器可包括中央处理器、微处理器、数字信号处理器、应用处理器或可编程阵列等。所述处理电路可包括专用集成电路。所述处理器或处理电路，可用于执行指定代码或程序，从而完成上述统计信息的生成、执行日志的采集及查询结果的反馈等操作。所述通信接口可为各种类型的通信接口，例如，电路接口或光缆接口等有线接口，还可以是各种形式的收发天线等无线接口。本实施例中所述pcrf实体不是简单进行少量监控处理，而是会从统计层面形成统计信息，并会采集形成详细的执行日志，并可以提供实时的查询接口，以响应随时产生的查询请求，反馈查询结果；从而实现了对pcc框架各个层面的策略的生成、下发、命中以及执行等各个层面的状况信息和相关信息的监控和采集。在一些实施例中，所述统计信息包括：策略和规则映射表、策略统计信息表及规则统计信息表；所述策略和规则映射表包括：策略和策略中规则的对应关系；所述策略统计信息表包括：策略的执行统计信息；所述规则统计信息表包括：规则的执行统计信息。以上是统计信息的一种举例，但是不限于上述举例。在有些实施例中，所述统计上报模块110，具体用于按照第一周期向所述管理平台上报所述统计信息；所述日志上报模块130，具体用于按照第二周期向所述管理平台上报所述执行日志。在本实施例中所述统计上报模块110和日志上报模块130，都是自动周期性上报统计信息和执行日志，能够减少管理平台的拉取信息所造成的负荷。在还有一些实施例中，所述统计上报模块110，还用于采用第一链路向所述管理平台上报所述统计信息；当连续n个周期所述统计信息上报失败时，以第二链路向所述管理平台发送预定消息，其中，所述预定消息用于所述管理平台主动向所述pcrf实体拉取所述统计信息，所述n为正整数；或，当连续n个周期所述统计信息上报失败时，以所述第二链路向所述管理平台发送告警信息，其中，所述告警信息用于指示所述第一链路异常；当所述第一链路恢复正常之后，将上报失败的所述统计信息通过所述第一链路重新上报给所述管理平台。当统计信息连续上报失败，会以第二链路向管理平台发送预定消息，能够触发管理平台主动向pcrf实体拉取所述统计信息。当然，统计信息连续上报失败时，还可以以第二链路上报告警信息，能够触发第一链路的修复。在第一链路修复之后，再上报未上报成功的告警信息。所述策略和规则映射表、所述策略统计信息表及所述规则统计信息表均存储为数据库文件，且以预定格式命名所述数据库文件的文件名；其中，所述文件名包括：表名、地理位置标识、实体标识和时间标识；所述表名用于指示所述数据库文件存储的信息为所述策略和规则映射表、所述策略统计信息表或所述规则统计信息表；所述地理位置标识为所述pcrf实体服务的地理位置的标识信息；所述实体标识为所述pcrf实体的逻辑标识；所述时间标识为所述数据库文件对应的第一周期的时间标记。在本实施例中所述统计信息以预定格式命名，采用这种命名方式，一方面可以准确的概括出所述统计信息的内容，另一方面方便通过数据库文件的文件名快速定位所需查询的信息，实现了信息的简便管理。在有些实施例中，所述第一查询模块120，具体用于接收策略下发通知的查询请求，基于所述策略下发通知的查询请求，将第一预定时间内策略的通知下发状况信息反馈给所述查询客户端；和/或，接收策略生效的查询请求，基于所述策略生效的查询请求，将第二预定时间内策略的生效状况信息反馈给所述查询客户端；和/或，接收业务变更的查询请求，基于所述业务变更的查询请求，将第三预定时间内的业务变更状况信息反馈给所述查询客户端；和/或，接收业务签约趋势的查询请求，基于所述业务签约的查询请求，将第四预定时间内的业务签约趋势信息反馈给所述查询客户端。值得注意的是这里的查询客户端可为位于所述管理平台中的查询客户端。所述查询请求可为所述管理平台发送的任意请求，在所述查询请求中携带有查询参数；所述pcrf实体将根据查询请求中的查询参数，为查询数据的查询依据，检索存储在所述pcrf实体中的信息，形成所述查询结果。当然，这里仅是所述第一查询模块120，形成所述查询结果的一种形式，但是不局限于该形式。如图5所示，本实施例还提供另一种策略相关信息的处理装置，应用于管理平台中，所述管理平台可为前述的pop。所述处理装置可包括：统计信息接收模块210，用于接收策略和计费规则功能pcrf实体上报的统计信息；第二查询模块220，用于向所述pcfr实体发送查询请求，接收所述pcrf实体基于所述查询请求返回的查询结果；日志接收模块230，用于日志接收所述pcrf实体上报的执行日志；数据汇总模块240，用于对所述统计信息，查询结果及所述执行日志的至少之一，按照预设维度进行数据汇总，并集中存储汇总后的数据；分析呈现模块250，用于对所述统计信息、查询结果及所述执行日志的至少之一，按照预设分析策略进行数据分析，形成并呈现分析结果。本实施例提供的管理平台可为一台或多台服务器构成。例如，所述管理平台可为由多个相互连接的服务器机群构成。所述统计信息接收模块210、第二查询模块220、日志接收模块230、数据汇总模块240及分析呈现模块250等，同样可对应于管理平台中的处理器或处理电路。所述处理器或处理电路可与管理平台中的通信接口连接。这里的处理器或处理电路或通信接口的详细结构可以参见前述对处理器、处理电路及通信接口的描述。在一些实施例中，所述统计信息接收模块210，还具体用于接收所述pcrf实体在连续n个周期以第一链路所述统计信息上报失败时，以第二链路发送的预定消息；根据所述预定消息，向所述pcrf实体拉取所述统计信息。在本实施例中所述统计信息接收模块210，不仅会接收pcrf实体发送的信息，还可以主动基于预定信息拉取所述pcrf实体内形成并存储的统计信息。在还有一些实施例中，所述统计信息接收模块210，还具体接收所述pcrf实体在连续n个周期以第一链路所述统计信息上报失败时，以第二链路发送的告警信息；并输出所述告警信息。在本实施例中所述统计信息接收模块210还会被复用接收告警信息，通过告警信息的输出，以促使第一链路的尽快修复。以下结合上述任意实施例提供一个具体示例：如图6所示，本示例提供一种pcc框架，包括：pcc运营管理平台pop及pcrf实体。所述pop与pcrf实体之间分别给予soap和ftp建立两种传输链路。运营管理平台(pop)，用于负责pcc框架内各种策略的日志采集和分析呈现的功能，具体包括了策略效果呈现模块、策略数据汇总合并模块、策略统计数据采集模块、日志分析数据查询模块及策略执行日志采集。策略效果呈现模块，为前述分析呈现模块250的组成结构之一，用于将采集到的执行日志，按照用户、业务、时间、地点等维度的组合要求筛选历史信息，并以图表的形式进行呈现。策略数据汇总合并模块，为前述数据汇总模块240的组成结构之一，主要是将pcc框架内运营管理平台下辖的多个pcrf实体上报的执行日志，以策略和业务为维度进行合并，并按照时间先后顺序进行排序，实现对于区域内策略数据的集中式管理。策略统计数据采集模块，为前述的统计信息接收模块210的组成结构之一，主要是向pcrf实体采集各策略的统一或共性的统计数据。统计数据采取周期性的方式进行采集。日志分析数据查询模块，为前述第二查询模块220的组成结构之一，主要是利用实时接口(可以利用soap或rest等协议实现)向pcrf实体查询单用户的策略执行情况以及业务签约、业务使用情况的记录信息。策略执行日志采集模块，为前述日志接收模块230的组成结构之一，主要是通过ftp的方式收集各pcrf实体上产生的详细的执行日志。为支撑pcc运营分析工作的需求，pcrf实体将在已有的pcc策略逻辑处理能力之上还需具备：策略统计信息及上报模块、策略日志分析查询模块以及策略详细日志上报模块。策略统计信息及上报模块，为前述统计上报模块110的组成结构之一，用于周期性的统计并生成策略统计信息记录表，统计周期可以根据运营商的需求进行灵活设定。pcrf实体以在网运行策略为维度，统计包含策略签约用户数、业务运营支撑系统(boss)用户配额耗尽用户数、boss用户配额充值用户数、boss业务配额耗尽用户数、boss业务配额充值用户数\规则下发次数、策略生效次数、策略通知消息下发次数、策略通知消息下发用户数、规则命中用户数以及策略命中用户数等信息。所述策略签约用户数为统计信息生成时间节点的各策略的签约用户总数。所述boss用户配额耗尽用户数为在一个统计周期内，boss侧因配额耗尽而触发用户(usrstatus)状态形成的套外用户数量。boss用户配额充值用户数：在一个统计周期内，boss侧因用户充值或升舱套餐而出发用户状态为套内的用户数量(跨起帐日的状态变更不统计为配额充值)。boss业务配额耗尽用户数：在一个统计周期内，boss侧因业务配额耗尽而触发serviceusagestate状态形成的业务流量包外的用户数量。boss业务配额充值用户数：在一个统计周期内，boss侧因业务配额充值而触发serviceusagestate状态变更形成的业务流量包内的用户数量(跨起帐日的状态变更不统计为配额充值)。规则下发次数为：在一个统计周期内，因各种触发条件满足而导致各规则下发的次数统计。策略生效次数为：在一个统计周期内，各策略被命中并触发执行的次数统计。策略通知消息下发次数为：在一个统计周期内，各策略触发的通知消息的次数统计。策略通知消息下发用户数为：一个统计周期内，各策略所通知的用户数量统计(一个用户被多次下发消息，按一个用户统计)。规则命中用户数为：在一个统计周期内，各规则因各种触发条件满足而命中(包含命中后生效以及命中但未生效)的用户数量统计。策略命中用户数为：在一个统计周期内，各策略因各种触发条件满足而命中(包含命中后生效以及命中但未生效)的用户数量统计。策略统计信息需按照策略/规则映射表、策略统计信息表以及规则统计信息表三种表的形式进行统计和上报。上述三种表需按照csv的格式进行存储；策略/规则映射表用于记录策略名及策略内诸规则名的对应关系，其中每一行为一条策略与下辖规则的对应记录，分别记录策略编号(policyid)以及该策略所对应的一条规则名(rulename)，所述策略编号为32位十进制数，规则名为统一码unicode型的字符。具体格式如下：policyid1，rulename1，policyid1，rulename2，…policyidn，rulenamem，策略统计信息表用于记录以策略为维度的执行记录信息，其中每一行为一个策略的执行信息，包括策略编码(policyid)、策略签约用户数(nsubscriber)、boss用户配额耗尽用户数(nusrexausted)、boss用户配额充值用户数(nusrrecharge)、boss业务配额耗尽用户数(nserviceexausted)、boss业务配额充值用户数(nservicerecharge)、策略生效次数(tpolicy)、策略通知消息下发次数(tmessage)、策略通知下发用户数(nmessage)以及策略命中用户数(npolicy)等。策略编号为32位十进制数，其余各字段均为16位十进制数，具体格式如下：policyid1，nsubscriber1，nusrexausted1，nusrrecharge1，nserviceexausted1，nservicerecharge1，tpolicy1，tmessage1，nmessage1，npolicy1，policyid2，nsubscriber2，nusrexausted1，nusrrecharge1，nserviceexausted1，nservicerecharge1，tpolicy2，tmessage2，nmessage2，npolicy2，…policyidn，nsubscribern，nusrexausted1，nusrrecharge1，nserviceexausted1，nservicerecharge1，tpolicyn，tmessagen，nmessagen，npolicyn，规则统计信息表用于记录各个规则的执行记录信息，其中每一行为一个规则的执行信息，包括规则名(rulename)，规则下发次数(trule)，规则命中用户数(nrule)。其中规则名为unicode型的字符。其余各字段均为16位十进制数，具体格式如下：rulename1，trule1，nrule1，rulename2，trule2，nrule2，…rulenamen，trulen，nrulen，pcc策略统计信息文件按照统一格式进行命名，以便pcc运营管理平台便于进行策略数据汇总合并。“策略/规则映射表”统一命名为：“policy&rule_mapingtable_ss_pcrfid_yyyymmddhhmmss.csv”；“策略统计信息表”统一命名为：“policystatisticstable_ss_pcrfid_yyyymmddhhmmss.csv”；“规则统计信息表”统一命名为：“rulestatisticstable_ss_pcrfid_yyyymmddhhmmss.csv”。上述ss可为省份缩写等地理标识信息，所述pcrfid为pcrf实体的实体标识，yyyymmddhhmmss为信息记录表生成时间。策略统计信息上报流程如下：pcrf实体作为ftp/sftp的客户端，策略运营平台作为ftp/sftp的客户端。pcrf采用push的方式根据运营商所指定的周期进行ftp文件的上传。当因链路故障等原因导致pcc策略统计信息无法完成ftp上传时，需采取重传机制。在10次重传后仍无法成功时，触发soap消息，进行ftp日志上传失败报告。此处，所述n＝10，所述n的取值可能是5，3，8或12等具体取值，取值根据实际需要而定。如果是由于链路故障导致ftp上传失败，在链路恢复后，pcrf应立即将未成功上传的文件重新上传给运营管理平台。如图7所示，本示例提供一种统计信息上报方法，包括：步骤s1：基于ftp周期性上传各种统计信息表；这里的统计信息表为前述统计信息的一种；步骤s2：统计信息表上传失败；步骤s3：发送上传失败报告；步骤s4：上传失败报告响应；步骤s5：拉取未成功上报的统计信息；步骤s6：ftp周期上传统计信息表。策略日志分析查询模块，为前述第一查询模块120的组成结构之一，用于对外提供实时的查询接口，以便查询单用户的策略历史执行情况以及业务签约、业务使用情况的记录，并能够对外提供实时查询功能。在本示例中，所述pop和pcrf实体之间时报告和报告响应的传输，可以为基于soap进行的，所述pop相当于soap服务端，所述pcrf相当于soap客户端。查询流程可如下：日志分析查询消息接口基于soap协议进行实时的操作指令以及执行结果的消息传递，其中pcrf作为soap服务端，策略运营平台作为soap客户端进行信息交互。单用户历史查询：用以查询单用户的通知历史信息、策略生效统计、业务变更历史信息等。单用户的通知历史信息：用于查询某段时间内pcrf给单个用户或一批用户发送通知的形式(例如：短信(sms)、电子邮件(email))和结果(仅需要记录cmpp接口成功失败)。查询请求可包含查询的用户的号码以及查询记录的开始时间和截止时间。若一次性查询一批用户数，需携带该批次多个用户的号码信息。查询结果反馈该用户在查询时间窗口内的发送通知的时间、形式和结果。用户策略生效统计：用于查询某段时间内单个用户或一批用户策略配置信息，策略生效时间，策略生效原因等策略相关历史记录。查询请求可包含：查询的用户的号码以及查询记录的开始时间和截止时间。若一次性查询一批用户数，需携带该批次多个用户的号码信息。查询结果反馈该用户在查询时间窗口内的生效策略的标识id、策略生效时间以及策略生效原因(用户等级、当前时间、当前位置、访问业务、boss用户配额状态、boss业务配额状态、pcrf套餐配额、终端类型等信息)。业务变更历史信息：用于查询某段时间内单个用户或一批用户的业务变更详情。业务变更类型包括：复位boss用户配额(resetbossusrquota)、复位boss业务配额(resetbossservicequota)、复位pcrf配额(resetpcrfquota)、耗尽boss用户配额(exhaustbossusrquota)、耗尽boss业务配额(exhaustbossservicequota)、耗尽pcrf配额(exhaustpcrfquota)、充值boss用户配额(rechargebossusrquota)、充值boss业务配额(rechargebossservicequota)、更新用户信息(updateuserinfor)、删除用户(deletesubscriber)、签约业务(subscribeservice)、退订业务(unsubscribeservice)、更新已签约业务(updatesubscribeservice)。boss配额是指boss侧的流量累计额度，pcrf配额是指pcrf本地的流量累计额度。boss配额的复位和充值是基于boss与pcrf接口传递的usrstatus字段进行判定。用户信息是指boss侧传递给pcrf的用户级签约信息；业务信息是指boss侧传递给pcrf的的业务订购信息。查询请求可包含：查询的用户的号码以及查询记录的开始时间和截止时间。若一次性查询一批用户数，需携带该批次多个用户的号码信息。查询结果反馈该用户在查询时间窗口内的业务变更时间以及业务变更类型。这的查询时间窗口即为前述的限制参数的一种。所述用户的号码信息可为用户的手机号等通信标识，可为前述的限制参数。业务签约趋势：用于查询某段时间内每个业务的签约用户数的变化情况。查询请求：包含待查业务的业务标识以及查询记录的开始时间和截止时间。查询结果反馈该业务在查询时间窗口内的签约用户变化情况：查询记录以天为单位形成一条记录。策略详细日志上报模块，可为前述日志上报模块130的组成结构之一。pcrf实体对于策略及规则每一次执行，进行详细的信息记录。每一次的执行动作为一条记录，记录包含时间、用户标识、用户类别、终端类型、用户所在位置等此次pcc会话中的字段详细信息。该模块将详细执行日志存储，并按照运营商设定的上报周期，将执行日志进行打包压缩，并利用ftp协议进行执行日志上传。图8所示，为pop到pcrf实体中查询数据的一种示例，应用于soap系统中，所述soap系统包括soap客户端和soap服务端。所述soap客户端可位于pop；所述soap服务端可对应于pcrf实体。具体的查询步骤包括：步骤s11：soap客户端发送查询操作指令；步骤s12：soap服务端反馈查询结果。在本示例中前述的boss业务配额或fcrf套餐配额中的配额，均指的是订购流量数。在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本
技术领域：
：的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。当前第1页12当前第1页12