CN100438497C - 移动通信网络中处理应用功能实体信息的方法 - Google Patents

Abstract

本发明提出了移动通信网络中处理应用功能实体信息的方法，包括以下步骤：a、当应用功能实体向控制节点发送信息时，控制节点根据签约信息判断所述应用功能实体的签约信息是否在签约信息列表中存在，如果是，则转至步骤b，否则转至步骤c；b、控制节点接收所述信息，并进行处理，过程结束；c、控制节点放弃所述信息。本发明确保控制节点处理的来自应用层的相关信息都是合法有效的信息，从而避免了无效信息占用控制节点的处理能力，避免出现业务较大的时延或者因超时而导致的业务中断，提高用户对业务的满意程度。

Description

移动通信网络中处理应用功能实体信息的方法

技术领域

本发明涉及移动通信技术领域，尤其涉及一种对应用功能实体发来的信息进行处理的方法。

背景技术

随着移动分组数据业务应用的逐渐广泛，如何对移动分组数据业务进行准确合理地进行计费，已成为移动运营商普遍关注的课题。当前通用分组无线业务(General Packet Radio Service，GPRS)网络结构，针对用户数据流只能识别到接入点名称(Access Point Name，APN)和分组数据协议内容(Packet DataProtocol context，PDP Context)这一级别。而现实中并行的多个业务数据流很可能使用同一个PDP Context承载，而不同业务则可能采用不同的计费方式，而当前GPRS网络无法满足这一需求。例如，用户可能同时进行流媒体业务和多媒体消息业务，两个业务同时承载在同一个APN和PDP Context中，但计费规则不同，如流媒体业务根据用户数据流量或时间计费，多媒体消息业务则根据事件计费，如发送或接收一条消息。

为了对不同类型的IP连接网络能使用相同的计费解决方案，需要对当前GPRS提出一种新的承载计费结构，采用一种通用的基于流的计费机制。

针对这种情况，目前第三代移动通信标准化的伙伴项目(3rd GenerationPartnership Project，3GPP)正在讨论如何实现基于IP流的计费(Flow BasedCharging，FBC)，对于一个分组数据业务来说，用户在使用该项业务所消耗的数据量称为业务数据流(Service Data Flow，SDF)，业务数据流是多个IP流组成的集合。而在一个PDP context中可以承载多个不同的业务，因此基于IP流的计费粒度可以小于基于PDP context的计费粒度，从而能够为运营商以及业务提供商提供更为丰富的计费手段。

在3GPP的TS 23.125中对FBC的系统结构、功能要求以及消息流程等方面进行了描述。

其中支持在线计费的FBC系统结构如图1所示，支持离线计费的FBC系统结构如图2所示。

FBC系统的各个功能模块的作用分别为：

传输面功能模块(Traffic Plane Function，TPF)是承载分组业务数据流的功能模块，可以区分属于不同业务数据流的分组数据包，用于离线计费信息收集和执行在线信用控制，当承载发生变化的时候，比如承载的建立，修改和删除过程中，TPF通过Gx接口向基于业务流计费的计费规则功能模块(service dataflow based Charging Rule Function，CRF)请求计费规则，消息中可以携带：用户和终端相关的信息，如移动台国际ISDN号码MSISDN、国际移动用户标识IMSI，承载特性，如Qos信息以及网络相关的信息，如移动网编码MNC，移动国家码MCC。根据CRF返回的计费规则，TPF在对应的业务数据流上执行分组过滤和计费数据收集。

一个TPF可以由一个或者多个CRF服务，根据UE的标识信息来选择，可以支持预定义的计费规则以及预定义的过滤器。

CRF是保存计费规则的功能模块，支持动态(根据业务准则实时生成一些计费规则数据)和静态(在用户使用数据业务过程中计费规则是一成不变的，静态计费规则可以被动态的激活)的计费规则。CRF通过接收到的TPF信息、应用功能模块(Application Function，AF)信息以及在线计费系统(OnlineCharging System，OCS)信息作为输入，用于选取适当的计费规则，在TPF请求或者有特定事件触发的时候将选取的计费规则发送给TPF

一个CRF可以对应多个TPF。

AF代表所有和应用相关的功能模块，可以是运营商自己的，也可以是第三方业务提供商的，AF向CRF提供相应的信息使得CRF可以选择或配置相应的计费规则，AF提供的信息包括：业务数据流的标识信息(可以通配)；计费规则选择的信息；应用/业务标识，应用/业务计费规则触发事件，用户信息(比如用户标识等)，流类型(视频，音频)(可选)，流速率(可选)。

一个AF可以对应于多个CRF，AF可以根据UE的标识信息选择CRF进行交互。

信用控制模块(Credit Control，CC)是执行信用控制的功能模块，只用于在线计费系统，是通过在现有的OCS中增加新的功能来实现的，通过Ry接口，OCS可以向CRF提供计费规则选择的输入信息。

计费网关功能模块(Charging Gateway Function，CCF)和计费信息收集功能模块(Charging Collection Function，CGF)这两个功能模块是用于离线计费系统的，可以沿用现有的GPRS网络计费中的实现。

如果承载网络是GPRS网络的话，则TPF位于GGSN处，AF为PDN中的一个业务网关，或是业务服务器，当IMS承载在GPRS网络之上的时候AF就是P-CSCF，CRF为新增的逻辑模块。

同样，这种计费机制也可以应用于3GPP2和WLAN的网络结构中。

同时，3GPP提出了基于业务的本地策略控制，并定义了UE本地承载业务、GPRS承载业务和外部承载业务之间的交互，以及这些组合在一起为分组域端到端业务提供QoS。IP承载管理功能(IP BS Manager)在UE和GGSN中都可能存在，一般使用差分服务(DiffServ)或综合服务/资源预留(IntServ/RSVP)与外部IP网络进行互通。

3GPP描述了为分组域提供端到端QoS的IP层必需机制，通过基于业务的本地策略控制机制实现。如图3所示：代理呼叫状态控制功能(P-CSCF)作为应用功能的一种，和UE通过SIP协议交互，PDF从应用功能实体处得到应用层协议如会话描述协议(Session Description Protocol，SDP)中的参数，将该应用层参数信息映射到IP QoS参数，如RSVP，该映射遵守特定的策略规则。策略决策功能实体(Policy Decision Function，PDF)的决策将传送到GGSN中的IP承载管理功能，进一步通过翻译/映射功能映射到UMTS承载管理功能上，GGSN完成相应的IP策略执行点(IP Policy Enforcement Point，PEP)功能。PDF和GGSN之间的Go接口采用COPS协议，传送QoS相关信息和策略。

R5中只为IMS业务提供基于业务的QoS控制，所以PDF是IMS实体P-CSCF中的逻辑实体。R6阶段PDF是一个单独的功能实体，可以为所有分组域业务提供基于业务的QoS策略控制。当其他类型的承载网络要实现基于业务的策略控制的时候，PEP就在对应的网关设备上实现。当使用IMS的时候，AF就是P-CSCF。

当UE请求建立传送业务数据的承载连接时，PEP向PDF发送请求(Request，REQ)消息，其中携带客户端的对话信息，用于标识对应PDF的授权令牌以及该会话中一个或者多个流的标识；如果通过了授权，则PDF返回决定(Decision，DEC)消息给PEP，其中携带客户端的对话信息，控制层面计费标识，上下行指示，授权的QOS信息，过滤器信息以及对应的通道是否打开的状态信息；然后GGSN会根据DEC的执行情况，返回报告(Report，RPT)消息给PDF，报告执行的结果等。

策略和计费控制架构则同时提供基于业务的本地策略控制功能和基于流的计费功能，统一和合并了策略控制和流计费的结构和实现过程，同时考虑了终端用户签约时候的差异性以及在策略控制和计费控制方面的通用性，处理的时候将业务和承载结合起来考虑。

目前策略和计费控制框架和基于业务数据流计费的框架类似，如图4所示：

其中很多功能实体和基于业务数据流的计费是一样的，在此不再赘述，新增的实体的功能为：

策略和计费控制节点(Policy and Charging Control Node，PCCN)同时包含PDF和CRF的功能，向GW提供有关QOS策略和计费的控制。

网关(GateWay，GW)同时包括PEP和TPF的功能，提供对业务的QOS控制，基于流的分组计数功能，在线和离线计费交互功能。

这种框架也可以应用于3GPP2和WLAN的网络结构中。

根据现有的基于业务数据流计费的实现机制，在承载建立、修改和删除的时候，TPF都需要向CRF上报一些承载相关信息用于选择计费规则，CRF根据来自TPF、AF和OCS的信息进行选择，决定计费规则的实施。

和TPF向CRF请求计费规则的过程相独立的，AF和OCS也可以向CRF提供选择计费规则的输入信息，其中AF提供的信息和应用层业务相关，OCS提供的信息则和在线计费中业务的信用相关，CRF根据可用的信息综合选择某个业务数据流承载计费应该实施的计费规则。简单的，可以用图5说明：

AF向CRF提供输入供选择计费规则使用

1、AF发送应用/业务数据流计费信息给CRF；

2、CRF确认收到该输入信息。

通过Rx接口，AF向CRF提供应用/业务数据流计费信息，CRF根据该信息，选择和构造适当的计费规则发送给TPF。AF决定什么时候发送该信息给CRF，CRF从收到该信息的那一刻开始在计费规则的选择和决定上将应用/业务信息考虑在内。

在现有的FBC计费方案中，AF和CRF之间存在接口，提供一些和应用相关的信息，用于CRF选择适当的计费规则，或者配置计费规则中的一些参数，运营商在配置CRF中的计费规则时，可以决定来自AF的哪些数据可用于计费规则的选择。目前，AF提供给CRF的信息包括：

标识业务数据流的信息：

基于IP五元组(源IP地址，目的IP地址，源端口号，目的端口号，IP层以上的协议号)的过滤器，端口号和协议号可以通配，IP地址也可以通配或者带掩码前缀，来表示很多IP流的聚合；

特殊的过滤器，需要深入到分组包的更深层次，或者需要复杂的操作来支持，比如维持状态等，这些过滤器可以预先配置在TPF中，由CRF调用。这种过滤器可以用来支持那些基于IP层以上的传输层和应用层协议的业务数据流，比如HTTP和WAP；

可选的应用层记录信息，该信息包含在AF和TPF产生的计费信息中，用于后付费处理的时候关联计费记录；

支持计费规则选择的信息：应用/业务标识，应用/业务相关事件标识，媒体流类型(视频，音频)(可选)，媒体流速率(可选)，用户信息(比如用户标识等)。

在现有的策略控制实现中，AF通过Gq接口和PDF交换基于业务的策略建立信息，以及从PDF中请求授权令牌。目前，AF提供给PDF的信息和FBC中AF提供给CRF的信息类似，包括，IP五元组信息(源IP地址，目的IP地址，源端口号，目的端口号，IP层以上的协议号)，用于关联计费记录的IMS计费标识(ICID：IMS Charging IDentifier)，应用标识，各类媒体成分的描述信息(比如媒体流类型，速率等)等等。策略和计费控制框架中，因为PCCN是融合了PDF和CRF两个功能实体，因此AF提供给PCCN的信息可以认为至少是AF提供给CRF和AF提供给PDF信息的集合，此外，考虑到结合策略实施的计费控制以及集合计费实施的策略控制，今后还可能增加一些新的输入信息。

在策略和计费控制框架中，为了能够根据用户签约的不同在QOS控制和计费实施上体现出差异，增加了一个签约文件数据库，用于为策略和计费控制提供和签约相关的输入信息。如图6所示：

目前CRF的输入信息主要来自OCS，AF和TPF，PDF的输入信息主要来自AF和PEP，PCCN的输入信息主要来自OCS，AF，TPF，PEP和签约文件数据库(Subscription Profile Repository，SPR)。其中OCS、TPF、PEP以及SPR都是位于和CRF、PDF或PCCN同一个运营商的网络中，因此，来自这些功能实体的输入信息是可以保证其安全性和有效性的，即这些信息对于CRF来说，不会造成不良影响，而且都是有用的信息。

而AF这个功能实体，具体可以看作是多个应用服务器，它们既可能是运营商网络中的实体，也可能是第三方网络中的实体，对于运营商网络中的实体来说，其安全性是可以保证的，有效性一般来说也是可以保证的，但是对于第三方网络中的实体，则可能存在不安全的隐患，比如AF输入一些和当前策略控制或者计费控制无关的信息，CRF、PDF或者PCCN就不得不浪费一部分处理能力来对这些输入信息进行检查，判断其无用之后，做相应的处理，比如丢弃，如果一个AF怀有恶意，可能连续不断的输入应用层相关的信息，而这些信息在CRF、PDF或者PCCN检查之后可能都是没有用处的，但是在防火墙是无法检查出的，因此这种输入信息会造成其他有效的输入信息得不到处理能力，从而造成业务产生较大时延甚至导致超时中断。这是运营商以及用户都无法接受的。而且，还可能CRF、PDF或者PCCN收到的来自应用层相关信息完全是正确的和可用的，但是这些信息却是一个非法的应用功能实体发送的，这种情况下，如果不对应用层相关信息的来源进行检查，就可能使用这些看似正确其实是非法的信息选择计费规则，造成计费的错误或者策略控制的错误。

在策略和计费控制结构中，虽然增加了一个和签约信息相关的数据库SPR，但是这个数据库定位是只提供和签约信息相关的输入，供PCCN进行QOS策略控制和计费控制使用，也没有用来对提供应用层输入信息的AF进行签约检查。

发明内容

本发明的目的是提出移动通信网络中处理应用功能实体信息的方法，确保控制节点处理的来自应用层的相关信息都是合法有效的信息，从而避免了无效信息占用控制节点的处理能力。

为此，本发明采用如下方案：

一种移动通信网络中处理应用功能实体信息的方法，其特征在于包括以下步骤：

a、当应用功能实体向控制节点发送信息时，控制节点根据签约信息判断所述应用功能实体的签约信息是否在签约信息列表中存在，如果是，则转至步骤b，否则转至步骤c；

b、控制节点接收所述信息，并进行处理，过程结束；

c、控制节点放弃所述信息。

所述控制节点可以是计费规则功能实体，也可以是策略决策功能实体，还可以是策略和计费控制节点。

所述步骤a进一步包括以下步骤：

a11、控制节点设置签约信息列表，所述签约信息列表包含有所有向所述控制节点提供应用层输入信息的应用功能实体的签约信息；

a12、当应用功能实体向控制节点发送信息时，控制节点在所述签约信息列表中查找所述应用功能实体发送的信息中包含的应用/业务标识，如果在所述签约信息列表中查找到了所述的应用/业务标识，则判断所述应用功能实体的签约信息在签约信息列表中存在，否则所述应用功能实体的签约信息不在签约信息列表中存在。

所述步骤a12还包括以下步骤：

a121、控制节点结合用户信息中的用户标识，在所述签约信息列表中查找和所述用户相关的服务器中是否包含了所述应用功能实体的签约信息。

所述步骤a12还包括以下步骤：

a122、控制节点结合应用/业务相关事件标识，在所述签约信息列表中查找和所述事件相关的服务器中是否包含了所述应用功能实体的签约信息。

所述步骤a进一步包括以下步骤：

a21、在一个数据库中设置签约信息列表，所述签约信息列表包含有所有向所述控制节点提供应用层输入信息的应用功能实体的签约信息；

a22、当应用功能实体向控制节点发送信息时，控制节点向所述数据库发送查询请求消息，所述数据库收到查询请求消息后，在所述签约信息列表中查找所述应用功能实体发送的信息中包含的应用/业务标识，如果在所述签约信息列表中查找到了所述的应用/业务标识，则转至步骤a23，否则转至步骤a24；

a23、所述数据库向控制节点返回成功应答消息，控制节点判断所述应用功能实体的签约信息在签约信息列表中存在；

a24、所述数据库向控制节点返回失败应答消息，控制节点判断所述应用功能实体的签约信息不在签约信息列表中存在。

所述数据库可以是签约文件数据库，也可以是归属签约用户服务器，还可以是经过安全认证的数据库。

所述的方法，如果所述数据库是签约文件数据库，策略和计费控制节点在向所述数据库发送查询请求消息中可以请求用户终端的签约信息，则所述成功应答消息还可以包括所述签约文件数据库提供给策略和计费控制节点的用户终端的签约信息。

所述步骤a22还包括以下步骤：

a221、控制节点结合用户信息中的用户标识，请求所述数据库在所述签约信息列表中查找和所述用户相关的服务器中是否包含了所述应用功能实体的签约信息。

所述步骤a22还包括以下步骤：

a222、控制节点结合应用/业务相关事件标识，请求所述数据库在所述签约信息列表中查找和所述事件相关的服务器中是否包含了所述应用功能实体的签约信息。

所述步骤a进一步包括以下步骤：

a31、在一个通过安全性和信息有效性认证的应用功能实体上设置签约信息列表，所述签约信息列表包含有所有向所述控制节点提供应用层输入信息的应用功能实体的签约信息；

a32、其他应用功能实体首先向设置有签约信息列表的应用功能实体发送信息，设置有签约信息列表的应用功能实体在所述签约信息列表中查找其他应用功能实体发送的信息中包含的应用/业务标识，如果在所述签约信息列表中查找到了所述的应用/业务标识，则转至步骤a33，否则，设置有签约信息列表的应用功能实体判断发送信息的应用功能实体的签约信息不在签约信息列表中存在；

a33、设置有签约信息列表的应用功能实体判断发送信息的应用功能实体的签约信息在签约信息列表中存在，并将来自发送信息的应用功能实体的信息转发给控制节点。

采用了本发明，通过增加对输入应用层相关信息的功能实体的合法性检查，确保控制节点处理的来自应用层的相关信息都是合法有效的信息，从而避免了无效信息占用控制节点的处理能力，避免出现业务较大的时延或者因超时而导致的业务中断，提高用户对业务的满意程度。

附图说明

图1是支持在线计费的FBC系统结构图；

图2是支持离线计费的FBC系统结构图；

图3是基于业务的本地策略控制系统结构图；

图4是策略和计费控制框架示意图；

图5是现有技术中处理应用功能实体信息的流程图；

图6是包含有签约文件数据库的策略和计费控制框架示意图；

图7是本发明中第一种具体实施方式的流程图；

图8是本发明中第二种具体实施方式的流程图。

具体实施方式

下面结合说明书附图来说明本发明的具体实施方式。

本发明的技术方案中应用到签约信息列表，该表就是和运营商进行了签约的一些信息的一个集合，用于在应用过程中通过检查区分合法有效的签约信息和未签约的其他信息。在本发明中，如果只是针对应用/业务标识进行检查，实现的时候签约信息列表可以就是所有签约的应用功能/业务服务器的标识信息的集合，检查的时候，用收到的应用/业务标识在该签约信息列表中进行查找，找到的话，说明这个应用功能/业务服务器是合法有效的应用功能/业务服务器，否则，说明没有签约。如果是同时结合应用/业务标识和用户标识进行检查，则签约信息列表可以是所有签约的应用功能/业务服务器以及对应用户的标识信息的集合。

第一种具体实施方式是控制节点处保存和应用相关的服务器签约信息列表。CRF、PDF或PCCN处维持一个和所有可能提供应用层相关输入信息给自己处理的服务器的签约信息列表，当某个AF第一次提供输入信息给CRF、PDF或PCCN的时候，CRF、PDF或PCCN根据输入信息中的应用/业务标识，如果发现该服务器属于签约信息列表，则CRF、PDF或PCCN才进一步处理收到的来自该AF的其他信息，进行计费规则和/或策略决策的配置或者选择；进一步的，可以结合用户标识，检查签约信息列表中和该用户相关的服务器中是否包含了该服务器，包含的话才进行处理；进一步的，还可以结合应用/业务相关事件标识，检查签约信息列表中和对应事件相关的服务器中是否包含了该服务器，包含的话才进行处理；此外，还可以同时结合应用/业务标识，用户标识和应用/业务相关事件标识执行上述检查。

如果签约检查没有通过，则CRF、PDF或PCCN执行相应的处理，如丢弃这些输入信息，返回失败应答，其中可能带错误原因指示。

考虑到CRF、PDF或PCCN处对AF的检查主要是确定来自AF的输入信息是否是有效的，避免无效信息的处理占用大量设备处理能力，因此，一般对应用/业务标识进行检查就足够了，结合用户标识以及其他信息的检查可以在应用/业务标识检查通过之后的业务处理过程中同时进行。

如图7所示，AF发送应用/业务相关的做计费和/或策略控制所需的信息给CRF、PDF或PCCN；CRF、PDF或PCCN对于收到的输入信息，首先根据其中的应用/业务标识在签约服务器列表中进行检查，如果通过，则进行后续处理，否则，直接丢弃；然后返回确认消息，确认该AF的输入，对于无效的输入，可能会指示AF检查没有通过。

第二种具体实施方式是CRF、PDF或PCCN和保存应用相关服务器签约信息的数据库之间存在接口。在这种实现方案中，CRF、PDF或PCCN处和保存应用服务器签约信息的数据库之间存在接口，这个数据库可以是策略和计费控制结构中的SPR或者HSS或者其它一个属于运营商网络的数据库，其关键点在于这个数据库中保存了应用服务器的签约信息。当某个AF第一次提供输入信息给CRF、PDF或PCCN的时候，CRF、PDF或PCCN根据输入信息中的应用/业务标识，有时候还可以结合用户信息中的用户标识，以后也可能根据需求扩展到结合其他信息，构造消息，其中包括应用/业务标识信息，有时候也可以包括用户标识等信息，进一步的，还可以结合应用/业务相关事件标识，通过这个接口向该数据库发送查询请求消息，该数据库收到该请求之后，在本地的签约信息中进行查找，检查签约信息列表中是否包含了该服务器，包含的话才进行处理；此外，还可以同时结合应用/业务标识，用户标识和应用/业务相关事件标识执行上述检查。如果通过了签约检查，则返回成功应答，在策略和计费控制结构中，如果这个数据库是SPR，则在成功应答消息中还可以包括SPR提供给PCCN的签约相关的信息，如果没有通过签约检查，则返回失败应答，指示检查没有通过，而且应答消息中不携带提供给PCCN的签约相关信息。

CRF、PDF或PCCN只有在收到成功应答的时候才进一步处理收到的来自该AF的其他信息，进行计费规则和/或策略决策的配置或者选择，收到失败应答的时候则执行相应的处理，如丢弃这些输入信息，直接返回确认消息，其中可能带错误原因指示。

考虑到CRF、PDF或PCCN处对AF的检查主要是确定来自AF的输入信息是否是有效的，避免无效信息的处理占用大量设备处理能力，因此，一般数据库中对应用/业务标识进行检查就足够了，结合用户标识以及其他信息的检查可以在应用/业务标识检查通过之后的业务处理过程中同时进行。

如图8所示，AF发送应用/业务相关的和计费和/或策略控制所需的信息给CRF、PDF或PCCN；CRF、PDF或PCCN构造消息向保存应用服务器签约信息的数据库请求检查来自该AF的信息是否是有效的，其中包括应用/业务标识，如果该数据库中同时保存用户相关的签约信息，也可以在这个消息中同时请求；该数据库根据收到的应用/业务标识对该AF的有效性进行检查，如果通过了返回成功应答，其中可以同时包括请求的用户签约信息，如果没有通过，则返回带错误原因的应答消息；CRF、PDF或PCCN根据收到的应答消息中的结果，决定对收到的来自AF的输入信息的处理，如果通过，则进行后续处理，否则，直接丢弃；然后返回确认消息，确认该AF的输入，对于无效的输入，可能会指示AF检查没有通过。

第三种具体实施方式是AF处统一对提供输入信息给CRF、PDF或PCCN的应用服务器的身份进行检查。为了减轻CRF、PDF或PCCN的负担，在这种实现方案中，将检查应用服务器身份的功能放在了AF来实现，但是要求这个AF是一个特定的代理应用服务器，该AF和CRF、PDF或PCCN之间的连接是完全可以信任的，不但包括安全性还包括信息的有效性，凡是这个AF向CRF、PDF或PCCN提供的应用/业务相关信息一定是有效的信息，可以用于本地策略的制定和/或计费规则的选择。在这种实现中，这个AF上设置签约信息列表，签约信息列表包含有所有向CRF、PDF或PCCN提供应用层输入信息的应用功能实体的签约信息，其他的应用服务器都向这个AF发送信息而不是直接和CRF、PDF或PCCN交互，该AF收到来自其他应用服务器的应用/业务相关信息之后，在所述签约信息列表中查找其他AF发送的信息中包含的应用/业务标识，如果有，这个AF判断这些应用功能实体在签约信息列表存在，并将来自应用功能实体的信息转发给CRF、PDF或PCCN。否则不将所述来自应用功能实体的信息转发给CRF、PDF或PCCN。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉该技术的人在本发明所揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (11)

1.一种移动通信网络中处理应用功能实体信息的方法，其特征在于包括以下步骤：

a、当应用功能实体向控制节点发送信息时，控制节点根据签约信息判断所述应用功能实体的签约信息是否在签约信息列表中存在，如果是，则转至步骤b，否则转至步骤c；

b、控制节点接收所述信息，并进行处理，过程结束；

c、控制节点放弃所述信息。

2.如权利要求1所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述控制节点可以是计费规则功能实体，也可以是策略决策功能实体，还可以是策略和计费控制节点。

3.如权利要求1或2所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a进一步包括以下步骤：

a11、控制节点设置签约信息列表，所述签约信息列表包含有所有向所述控制节点提供应用层输入信息的应用功能实体的签约信息；

a12、当应用功能实体向控制节点发送信息时，控制节点在所述签约信息列表中查找所述应用功能实体发送的信息中包含的应用/业务标识，如果在所述签约信息列表中查找到了所述的应用/业务标识，则判断所述应用功能实体的签约信息在签约信息列表中存在，否则所述应用功能实体的签约信息不在签约信息列表中存在。

4.如权利要求3所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a12还包括以下步骤：

a121、控制节点结合用户信息中的用户标识，在所述签约信息列表中查找和所述用户相关的服务器中是否包含了所述应用功能实体的签约信息。

5.如权利要求3所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a12还包括以下步骤：

a122、控制节点结合应用/业务相关事件标识，在所述签约信息列表中查找和所述事件相关的服务器中是否包含了所述应用功能实体的签约信息。

6.如权利要求1或2所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a进一步包括以下步骤：

a21、在一个数据库中设置签约信息列表，所述签约信息列表包含有所有向所述控制节点提供应用层输入信息的应用功能实体的签约信息；

a22、当应用功能实体向控制节点发送信息时，控制节点向所述数据库发送查询请求消息，所述数据库收到查询请求消息后，在所述签约信息列表中查找所述应用功能实体发送的信息中包含的应用/业务标识，如果在所述签约信息列表中查找到了所述的应用/业务标识，则转至步骤a23，否则转至步骤a24；

a23、所述数据库向控制节点返回成功应答消息，控制节点判断所述应用功能实体的签约信息在签约信息列表中存在；

a24、所述数据库向控制节点返回失败应答消息，控制节点判断所述应用功能实体的签约信息不在签约信息列表中存在。

7.如权利要求6所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述数据库可以是签约文件数据库，也可以是归属签约用户服务器，还可以是经过安全认证的数据库。

8.如权利要求7所述的移动通信网络中处理应用功能实体信息的方法，其特征在于：如果所述数据库是签约文件数据库，策略和计费控制节点在向所述数据库发送查询请求消息中可以请求用户终端的签约信息，则所述成功应答消息还可以包括所述签约文件数据库提供给策略和计费控制节点的用户终端的签约信息。

9.如权利要求6所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a22还包括以下步骤：

a221、控制节点结合用户信息中的用户标识，请求所述数据库在所述签约信息列表中查找和所述用户相关的服务器中是否包含了所述应用功能实体的签约信息。

10.如权利要求6所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a22还包括以下步骤：

a222、控制节点结合应用/业务相关事件标识，请求所述数据库在所述签约信息列表中查找和所述事件相关的服务器中是否包含了所述应用功能实体的签约信息。

11.如权利要求1或2所述的移动通信网络中处理应用功能实体信息的方法，其特征在于所述步骤a进一步包括以下步骤：

a31、在一个通过安全性和信息有效性认证的应用功能实体上设置签约信息列表，所述签约信息列表包含有所有向所述控制节点提供应用层输入信息的应用功能实体的签约信息；

a32、其他应用功能实体首先向设置有签约信息列表的应用功能实体发送信息，设置有签约信息列表的应用功能实体在所述签约信息列表中查找其他应用功能实体发送的信息中包含的应用/业务标识，如果在所述签约信息列表中查找到了所述的应用/业务标识，则转至步骤a33，否则，设置有签约信息列表的应用功能实体判断发送信息的应用功能实体的签约信息不在签约信息列表中存在；

a33、设置有签约信息列表的应用功能实体判断发送信息的应用功能实体的签约信息在签约信息列表中存在，并将来自发送信息的应用功能实体的信息转发给控制节点。

Images