CN104380670A - Diameter路由代理规则组的组织 - Google Patents

Abstract

多种示例性实施例涉及一种方法和相关的网络节点，包括一个或多个以下操作：在DRA从第一源设备接收第一Diameter消息；确定与所述第一Diameter消息相关联的第一消息类型；识别多个规则组中与第一消息类型相关联的第一规则组；评估第一规则组中的第一规则；以及基于所述第一规则的评估发送消息。

Description

Diameter路由代理规则组的组织

相关申请的交叉参考

本申请涉及以下共同未决的申请，该申请在此引入作为参考：申请号为13/482690，代理人案卷号为ALC3810，“ROUTING DECISIONCONTEXT OBJECTS”。

技术领域

本文所公开的各种典型实施例一般地涉及计算机网络。

背景技术

从互联网工程任务组(IETF)征求意见文档(RFC)3588的建议开始起，Diameter协议已经越来越多地被大量网络应用采用。例如，第三代合作伙伴项目(3GPP)已经为多种策略和计费控制(PCC)、移动性管理、以及IP多媒体子系统(IMS)应用采用了Diameter。由于基于IP的网络对电路交换网络的替代，Diameter甚至要取代SS7作为密钥通信信令协议。随着网络的发展，Diameter将成为无线和有线通信网络中广泛使用的协议。

Diameter协议的一个显著方面是Diameter分组路由。被称为Diameter路由代理(DRA)的实体帮助网络中的数据分组的移动。在多种部署中，DRA可执行如简单的路由、代理和重定向的基本功能。

发明内容

多种示例性实施例的简要总结如下。在下面的发明内容中可做一些简化和省略，其意在突出和介绍各种示例性实施方式的一些方面，而不是限制本发明的范围。足以使本领域普通技术人员能够制造和使用本发明概念的优选的示例性实施例的详细说明将在后面的章节中呈现。

多种示例性实施例涉及由Diameter路由代理(DRA)执行的，用于处理Diameter消息的方法，该方法包括一个或多个以下操作：在DRA接收来自第一源设备的第一Diameter消息；确定与所述第一Diameter消息相关联的第一消息类型；识别多个规则组中与所述第一消息类型相关联的第一规则组；评估第一规则组中的第一规则；以及基于所述第一规则的评估发送消息。

多种示例性实施例涉及一种用于处理Diameter消息的Diameter路由代理(DRA)，所述DRA包括以下一个或多个：规则存储器，被配置为存储多个规则组；Diameter堆栈，被配置为接收来自第一源设备的第一Diameter消息；消息处理器，被配置为：确定与所述第一Diameter消息相关联的第一消息类型，并识别多个规则组中与所述第一消息类型相关联的第一规则组；以及规则引擎，被配置为评估所述第一规则组中的第一规则，其中，所述消息处理器被进一步配置为基于所述第一规则的评估发送消息。

多种示例性实施例涉及一种永久的机器可读存储介质，其被由Diameter路由代理(DRA)执行的用于处理Diameter消息的指令所编码，所述指令包括下述的一个或多个：用于在DRA接收来自第一源设备的第一Diameter消息的指令；确定与所述第一Diameter消息相关联的第一消息类型的指令；识别多个规则组中与所述第一消息类型相关联的第一规则组的指令；评估第一规则组中的第一规则的指令；以及基于所述第一规则的评估发送消息的指令。

描述了多种实施例，其中所述消息类型是基于所述第一Diameter消息的命令类型和应用类型。

多种实施例还包括多个规则组中适用于至少两个不同的消息类型的第二规则组；以及评估第二规则组的第二规则，其中，基于所述第一规则的评估对第一消息的发送包括：基于所述第一规则的评估和所述第二规则的评估发送第一消息。

描述了多种实施例，其中在评估所述第一规则之前执行所述第二规则的评估。

多种实施例还包括在DRA从第二源设备接收第二Diameter消息，其中所述第二Diameter消息为Diameter请求；评估第二规则组的第三规则，其中所述第三规则的评估生成Diameter应答的至少一部分；以及发送所述Diameter应答到第二源设备，其中仅在所述第二规则组已被评估之后执行所述发送。

描述了多种实施例，其中对所述第一规则的评估包括修改所述第一Diameter消息，以及基于所述第一规则的评估对消息的发送包括发送第一Diameter消息到另一设备。

描述了多种实施例，其中所述第一Diameter消息为Diameter请求，对所述第一规则的评估包括修改Diameter应答，并且基于所述第一规则的评估对该消息的发送包括发送所述Diameter应答到第一源设备。

附图说明

参考下面的附图进行说明，以便更好地理解多种示例性实施例，其中：

图1示出了Diameter路由代理的示例性网络环境；

图2示出了示例性的Diameter路由代理；

图3示出了用于处理Diameter消息的示例性方法；

图4示出了用于评估多个规则组的示例性方法；

图5示出了一个示例性的通用规则组；

图6示出了示例性的消息类型特定的规则组；以及

图7示出了示例性的消息交换。

为了便于理解，相同的附图标记被用于指代具有实质上相同或类似的结构或实质上相同或类似的功能的单元。

具体实施方式

本说明书和附图仅示出本发明的原理。因此，应指出尽管这里没有明确地描述或示出，本领域的技术人员能够设计体现本发明的原理并包括在其范围之内的多种布局。此外，本文描述的所有示例原则上仅用于示范的目的，以帮助读者理解发明人提供的概念以及本发明的原理来促进本领域，并且应当被解释为不限于这些具体引用的示例和条件。另外，除非另有说明(例如，“否则”或“或在替代方案中”)，本文中所使用的术语“或”是指非排他性的或(即，和/或)。另外，本文所描述的多种实施例并不一定是相互排斥的，因为一些实施例可以与一个或多个其它实施例结合以形成新的实施例。本文所用的，术语“上下文”和“上下文对象”将被理解为是同义的，除非另有说明。

现在可用的Diameter路由代理(DRA)只提供典型地在硬编码或脚本中定义的基本功能。因此，用户可能典型地不能被授权来轻松并且灵活地为DRA定义更复杂的行为模式。鉴于上述情况，希望提供一种便于用户定义和扩展DRA消息处理行为的方法和系统。

图1示出了用于Diameter路由代理(DRA)142的示例性网络环境100。示例性网络环境100可以是用于提供多种服务的订户网络。在多种实施例中，订户网络100可以是公共陆地移动网(PLMN)。示例性的订户网络100可以是用于提供对多种服务的访问的电信网络或其他网络。示例性订户网络100可以包括用户设备110、基站120、演进的分组核心(EPC)130、分组数据网络150和应用功能(AF)160。

用户设备110可以是与分组数据网络150进行通信的，用于向终端用户提供数据服务的设备。这样的数据服务可包括例如语音通信、文本消息传送、多媒体流、以及互联网接入。更具体地，在多种示例性实施例中，用户设备110为个人计算机或膝上型计算机、无线电子邮件设备、蜂窝电话、平板电脑、电视机顶盒、或能够经由EPC130与其他设备进行通信的任何其他设备。

基站120可以是能够使用户设备110与EPC130之间进行通信的设备。例如，基站120可为诸如由相关的3GPP标准所定义的演进的节点B(e节点B)的基站收发信台。因此，基站120可以与用户设备110经由第一介质通信，所述第一介质例如为无线电波，并经由第二介质与EPC130进行通信，所述第二介质例如为以太网电缆。基站120可以与EPC130直接通信或经由多个中间节点进行通信(未示出)。在多种实施例中，可以存在多个基站(未示出)来向用户设备110提供移动性。注意，在多种备选实施例中，用户设备110可直接与EPC130进行通信。在这样的实施例中，可不存在基站120。

演进的分组核心(EPC)130可以为向用户设备110提供到分组数据网络140的网关接入的一个设备或多个设备的网络。EPC 130还可向订户收取使用提供的数据服务的费用，并确保满足特定的质量体验(QoE)标准。因此，EPC130可以至少部分地根据相关3GPP标准来实现。EPC130可以包括服务网关(SGW)132、分组数据网络网关(PGW)134、以及会话控制设备140。

服务网关(SGW)132可以是提供至EPC130网关接入的设备。SGW132可以是接收由用户设备110发送的数据包的EPC 130内的第一设备之一。多种实施例还可包括在SGW132之前接收分组的移动性管理实体(MME)(未示出)。SGW132可以向PGW134转发这些分组。SGW 132可以执行多种功能，例如管理多个基站(未示出)之间的用户设备110的移动性以及为每个被服务的流执行特定服务质量(QoS)特性。在多种实现中，例如那些实施代理移动IP标准的实现，SGW132可以包括承载绑定(Bearer Binding)和事件报告功能(BBERF)。在多种示例性实施例中，EPC130可以包括多个SGW(未示出)，并且每个SGW可以与多个基站通信(未示出)。

分组数据网络网关(PGW)134可以是向分组数据网络140提供网关接入的设备。PGW134可以是接收分组的EPC130的最后设备，所述分组由用户设备110经SGW132向分组数据网络140发送。PGW 134可以包括对每个服务数据流(SDF)执行策略和计费控制(PCC)规则的策略和计费执行功能(PCEF)。因此，PGW 134可以是策略和计费执行节点(PCEN)。PGW134可以包括许多附加的功能，例如分组过滤、深度分组检测以及订户计费支持。PGW134还可为未知应用服务负责请求资源分配。

会话控制设备140可为在EPC130内提供多种管理或其他功能的设备。例如，会话控制设备140可提供策略和计费规则功能(PCRF)。在多种实施例中，会议控制设备140可包括阿尔卡特朗讯5780动态服务控制器(DSC)。会议控制设备140可包括DRA142、多个策略和计费规则刀片(PCRB)144、146，以及订户概要文件存储库(subscriber profilerepository)。

如将在下文中更详细描述的，DRA142可为智能的Diameter路由代理。由此，DRA 142可以接收、处理和发送多种Diameter消息。DRA 142可以包括若干用户定义的规则，所述规则就DRA142可能会遇到的多种Diameter消息来管理DRA 142的行为。基于这样的规则，DRA142可以操作为中继代理、委托代理、或重定向代理。例如，DRA 142可中继接收到的消息至适当的接收设备。这样的路由可以相对于输入和输出消息以及对会话控制设备来说的内部消息来执行。

策略和计费规则刀片(PCRB)144、146的每一个可以是设备或设备组，其接收对应用服务的请求，生成PCC规则，并向PGW134或其他PCEN(未示出)提供PCC规则。PCRB144、146可以经由Rx接口与AF160通信。如下面进一步关于AF160要详细描述的，PCRB144、146可以从AF 160接收认证和授权请求(AAR)形式的应用请求。在接收到AAR时，PCRB144、146可以生成至少一个新的PCC规则用于履行应用请求。

PCRB 144、146也可分别经由Gxx和Gx接口与SGW 132和PGW 134通信。PCRB 144、146可以从SGW132或PGW134接收信用控制请求(CCR)形式的应用请求。与收到AAR一样，在接收到CCR时，PCRB 144、146可生成至少一个新的PCC规则用于履行应用请求。在多种实施例中，AAR和CCR可以代表将被单独处理的两个独立的应用请求，而在其它实施例中，AAR和CCR可以携带关于单个应用请求的信息，并且PCRB 144、146可以基于AAR和CCR的结合创建至少一个PCC规则。在多种实施例中，PCRB 144、146可具有处理单个消息和配对消息的应用请求的能力。

当创建新PCC规则时或者当PGW134请求时，PCRB 144、146可通过Gx接口向PGW134提供PCC规则。在多种实施例中，例如在那些实施代理移动IP(PMIP)标准的实施例中，PCRB 144、146还可生成QoS规则。当创建新的QoS规则时或者当SGW132请求时，PCRB 144、146可以经由Gxx接口向SGW132提供QoS规则。

订户概要文件存储库(SPR)148可以是存储与订户网络100的订户相关的信息的设备。这样，SPR 148可包括机器可读存储介质，如只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪存设备、和/或类似的存储介质。SPR 148可以是PCRB144、146之一的组成部分，或者可以构成EPC130或者会话控制设备140内的独立节点。SPR 138存储的数据可以包括订户信息140，例如每个订户的标识符、带宽限制、计费参数、以及订户的优先级。

分组数据网络150可以是用于提供用户设备110与诸如AF 160的连接到分组数据网络150的其他设备之间的数据通信的任何网络。分组数据网络150还可以向与分组数据网络150进行通信的多种用户设备提供例如电话或互联网服务。

应用功能(AF)160可以是向用户设备110提供已知应用服务的设备。因此，AF 160可以是服务器或例如向用户设备110提供视频流或语音通信服务的其他设备。AF160还可以经由Rx接口与EPC130的PCRB144、146通信。当AF160开始向用户设备110提供已知应用服务时，AF160可以生成应用请求消息——例如依照Diameter协议的验证和授权请求(AAR)——以通知PCRB144、146应分配资源给该应用服务。该应用请求消息可以包括这样的信息，例如使用应用服务的订户的标识、订户的IP地址、相关联的IP-CAN会话的APN，或者必须被建立以提供所请求的服务的特定服务数据流的标识。

应理解，多种Diameter的应用可在订户网络100内建立并被DRA 142所支持。例如，可以在AF 160和每一个PCRB 144、146之间建立Rx应用。作为另一个例子，可以在SPR 148和每一个PCRB 144、146之间建立Sp应用。作为又一个例子，可以在一个或多个PCRB 144、146与实施另一个PCRF(未示出)的远程设备之间建立S9应用。可以理解的是，可以在订户网络100内建立许多其它Diameter应用。

在支持多种可能的Diameter应用中，DRA 142可接收Diameter消息、处理该消息，并基于所述处理执行操作。例如，DRA 142可以从PGW 134接收Gx CCR、识别适当的PCRB144、146来处理所述Gx CCR、并转发所述Gx CCR至识别出的PCRB 144、146。DRA 142还可以用作代理，其可通过修改由PCRB 144、146发送的后续Gx CCA来携带指向DRA 142而不是PCRB144、146的源主机标识。附加地或者可选地，DRA 142可作为重定向代理或者通过形成适当应答消息并发送该应答消息到适当的请求设备的方式来直接响应请求消息。

图2示出示例性的Diameter路由代理(DRA)200。DRA 200可以是独立的设备或另一系统的组成部分。例如，DRA 200可以对应于示例性环境100的DRA142。在这样的实施例中，DRA 142可以支持由3GPP所定义的多种Diameter的应用，如Gx、Gxx、Rx、或Sp。应当理解的是，DRA 200可被部署在多种支持附加或备选的应用的备选实施例中。因此，显而易见的是，本文所描述的方法和系统可以一般性地适于支持任何Diameter应用。

DRA 200可包括若干组件，如Diameter堆栈205、消息处理器210、规则引擎215、规则存储器220、用户接口225、上下文创建器230、上下文工件存储器(context artifact storage)240、消息词典245、路由决策数据库250、清理模块255、或订户记录检索器260。

Diameter堆栈205可包括硬件或机器可读存储介质上被配置为根据Diameter协议与其它设备交换信息的可执行指令。Diameter堆栈205可以包括接口，所述接口包括硬件或编码在机器可读存储介质上被配置为与其他设备进行通信的可执行指令。例如，Diameter堆栈205可包括以太网或TCP/IP接口。在多种实施例中，Diameter堆栈205可包括多个物理端口。

Diameter堆栈205也可以被配置为读取并根据Diameter协议构造消息。例如，Diameter堆栈可以被配置为读取和构造CCR、CCA、AAR、AAA、RAR和RAA消息。Diameter堆栈205可提供的应用编程接口(application programmer's interface)(API)，使得DRA 200的其它组件可以调用Diameter堆栈的功能。例如，规则引擎215可能够利用API从接收到的CCR读取属性值对(AVP)或者修改新CCA的AVP。从下列描述中多种附加的功能将变得显而易见。

消息处理器210可以包括硬件或机器可读存储介质上的可执行指令，所述可执行指令被配置为解释接收的消息，并适当地调用规则引擎215。在多种实施例中，消息处理器210可以从Diameter堆栈205接收的消息中提取消息类型并使用适于所提取的消息类型的规则组调用规则引擎。例如，消息类型可以通过接收的消息的应用和指令来定义。在规则引擎215评估完一个或多个规则后，消息处理器210可以基于由规则引擎215调用一个或多个上下文对象动作经由Diameter堆栈发送一个或多个消息。

规则引擎215可以包括硬件或机器可读存储介质上的可执行指令，所述可执行指令被配置为通过评估一个或多个存储在规则存储器220的规则来处理接收到的消息。因此，规则引擎215可以是一种类型的处理引擎。规则引擎215可以检索一个或多个规则、评估规则的准则(criteria)来确定该规则是否适用、以及指定任何适用规则的一个或多个结果。例如，规则引擎215可以确定当收到的Gx CCR包括标识DRA 200的目的主机AVP时，规则适用。所述规则可指定在转发消息之前，目标主机AVP应被更改以标识PCRB。

规则存储器220可以是能够存储供规则引擎215评估的一个或多个规则的任何计算机可读介质。因此，规则存储器220可包括机器可读存储介质，如只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪存设备、和/或类似的存储介质。在多种实施例中，规则存储器220可以将一个或多个规则组存储为二元判定树数据结构。多种用于存储规则组的其它数据结构是显而易见的。

应当理解的是，尽管多种组件被描述为被配置为执行诸如评估规则或基于规则访问上下文对象的功能，这样的配置可以不要求规则存储器中存在任何的规则。例如，规则引擎215可被配置为评估包括上下文对象引用的规则，即使没有这样的规则存储在规则存储器220中。此后，如果用户向规则存储器添加了这样的规则，规则引擎215可以如本文所述地处理该规则。换言之，如本文所使用的，当用于与规则有关的功能时，短语“被配置为”将被理解为是指该组件能够执行的适当功能，而不管请求这样功能的规则是否实际存在。

用户接口225可包括硬件或计算机可读存储介质上的可执行指令，所述可执行指令被配置以使与用户通信成为可能。这样，用户接口225可以包括网络接口(如包括在Diameter堆栈205中的网络接口)、显示器、键盘、鼠标、或触敏显示器。用户接口225还可以提供用于促进用户交互的图形用户接口(GUI)。用户接口225可以使用户能够定制的DRA 200的行为。例如，用户接口225可使得用户能够定义规则，所述规则用于存储在规则存储器220中并由规则引擎215进行评估。对于本领域技术人员来说，让用户通过用户接口225定制DRA200的行为的多种其他方法将是显而易见的。

根据多种实施例，规则存储器220可以包括引用一个或多个“上下文”或“上下文对象”的规则。在这样的实施例中，上下文创建器230可以包括硬件或机器可读存储介质上的可执行指令，所述可执行指令被配置为实例化上下文中的对象并向发出请求的组件提供上下文对象的元数据。上下文对象可以在运行时被上下文创建器230实例化，并且可以包括用于支持规则引擎215和使用户能够通过用户接口225定义复杂规则的属性或动作。例如，上下文创建器230可以提供表示多种Diameter消息、先前的路由决策、或订户概要文件的上下文对象。

当DRA 200接收Diameter消息进行处理时，消息处理器210可以向上下文创建器230发送指示，以表明适当的上下文对象要被实例化。上下文创建器230随后可以实例化这样的上下文对象。在一些实施例中，上下文创建器230可以实例化所有已知的上下文对象或者可以只实例化那些要由规则存储器220应用的规则组实际使用的上下文对象。在其它实施例中，上下文创建器230可以不实例化上下文对象，直到它被规则引擎215实际的请求。

上下文创建器230可通过向用户接口225提供上下文元数据额外地促进规则创建。在多种实施例中，上下文创建器230可向用户接口225指示哪些上下文对象对于被修改的规则组可用以及每个上下文对象可能拥有什么属性或动作。利用这些信息，用户接口225可以呈现指向和点击接口(point-and-click interface)，用于创建复杂规则。例如，用户接口225可以使用户能够从列表选择上下文对象的期望的属性或者动作来包含在正在构建或修改的规则之中。

上下文创建器230在建立上下文中的对象时可依赖在上下文工件存储器240中存储的一个或多个上下文工件。因此，上下文工件存储器240可以是能够存储一个或多个上下文工件的任何计算机可读介质。因此，上下文工件存储240可包括机器可读存储介质，如只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪存设备、和/或类似存储介质。上下文工件存储器240可以用多种形式存储工件，例如，运行库(run-time libraries)。在多种实施例中，这样的运行库可以被存储为Java归档(.jar)文件。

每个上下文工件可以定义可用于上下文对象的属性或动作。在多种实施例中，上下文工件可定义当属性或动作被访问时要执行的一个或多个功能。这样的功能可以利用DRA 200的其它功能，例如访问Diameter堆栈的API，或可以将值返回调用该属性或动作的部件。上下文工件还可以包括标签或其他用于上下文创建器230的元数据，以提供给用户接口225用于对上下文对象的行为和属性进行描述。在示例性DRA 200中，上下文工件存储器240可以存储定义消息上下文、路由决策上下文、或订户记录上下文的上下文工件。这些上下文工件可以在运行时由上下文创建器230使用来实例化不同类型的上下文对象。因此，上下文创建器230可以被视为包括消息上下文模块232、路由决策上下文模块236、和订户纪录上下文模块238。在多种实施例中，用户能够经由用户接口225来定义新的上下文工件以存储在上下文工件存储器中，例如通过指定现有文件(如.jar文件)或通过使用用户接口225的文本编辑器定义新的上下文工件。

消息上下文模块232可以代表上下文创建器230的生成上下文对象的能力，所述上下文对象代表并提供对Diameter消息的访问。例如，消息上下文模块232可生成表示接收到的消息的上下文对象。在多种实施例中，适当地，消息上下文模块232还可以被配置为生成表示与接收到的Diameter消息相关的应答消息或请求消息的上下文对象。这样，消息上下文模块232可以被视为包括接收的消息子模块233、相关的请求子模块234、和相关的应答子模块235。

Diameter消息的内容可以根据应用和命令的类型而有所不同。例如，RX RAA消息可以包括与GX CCR消息的不同数据。这种差异可以通过管理相关Diameter应用的多种标准来定义。此外，一些供应商可包括多种消息的专有权或其他非标准定义。消息上下文模块232可依赖于存储在消息词典245中的消息定义为不同类型Diameter消息生成消息上下文。例如，当接收Diameter消息时，消息处理器210可以递送应用程序和指令类型至上下文创建器230。消息上下文模块232随后可在消息词典245中定位(locate)匹配的定义。该定义可指示可能存在于指定类型的消息中的AVP。消息上下文模块232随后可实例化具有与信息定义中识别的AVP匹配的属性和行为的消息上下文对象。

消息词典245可以是能够存储一个或多个上下文工件的任何计算机可读介质。因此，消息词典245可以包括机器可读存储介质，例如只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪存设备、和/或类似的存储媒体。消息词典245可以包括以适当形式——例如XML文件——的多种消息定义。消息词典245可包括多个由供应商提供的包含在DRA 200中的预先确定的定义。在多种实施例中，用户能够经由用户接口225提供新的、用户定义的消息定义。例如，如果用户希望支持还未由预先确定的定义所定义的应用，用户可以生成或者获得定义文件以存储在消息词典245中。在多种实施例中，用户定义的定义可以与预先确定的定义存储在消息词典245的不同部分，例如不同的目录中。

在多种实施例中，用户还可以能够经由用户接口225扩展预先确定的定义。用户可以能够提供扩展的定义，所述扩展的定义定义了新的AVP或指定在特定消息类型中存在的附加AVP。例如，用户可能希望在Rx AAR内支持专有的AVP。为了提供这样的支持，用户可以提供定义专有AVP并指示该专有AVP可以存在于Rx AAR中的定义文件，如XML文件。这样的扩展定义也可以存储在消息词典245中与预先确定的定义不同的区域中。消息上下文模块232可以被配置为在实例化新的消息上下文对象或向用户接口225提供上下文元数据时，应用任何适用的扩展定义。

如上所述，在接收Diameter消息时，消息处理器210可提取应用和指令类型并将此信息传递到上下文创建器230，上下文创建器230随后可以定位任何适用的定义，以实例化新接收的消息上下文对象。接收的消息子模块233还可以被配置为将新的上下文对象与接收的Diameter消息本身相关联。例如，接收的消息子模块233可以从Diameter堆栈205将接收到的Diameter消息复制至私有或受保护的变量。备选地，接收的消息子模块233可存储对实现经由Diameter消息堆栈205的API访问Diameter消息时有用的Diameter消息的标识。

在多种实施例中，DRA 200可以支持逆消息上下文(inverse messagecontexts)的使用。在这样的实施例中，在从接收的Diameter消息提取命令类型时，消息处理器210也可识别逆指令类型(inverse command type)。在一些这样的实施例中，消息处理器210可实现识别每个消息命令的逆(inverse for each message command)的查找表。例如，在确定接收的Diameter消息是Gx CCR时，消息处理器可确定逆消息会是Gx CCA。消息处理器210也可以将此信息传递到上下文创建器230。

在接收到逆消息类型(inverse message type)时，消息上下文模块232可以以类似于上面描述的方式就接收到的消息上下文对象实例化逆消息上下文对象。相关的请求子模块234或相关的应答子模块235，适当时，也可以将新的上下文对象与消息数据相关联。如果逆消息是请求消息，相关的请求模块234可识别存储在Diameter堆栈205中的以前处理过的请求并且将该消息以类似于上面描述的方式与新的上下文对象相关联。在多种实施例中，当接收应答消息时，Diameter堆栈205可定位与应答消息对应的以前处理和转发过的的请求消息。Diameter堆栈205可通过上下文创建器230或DRA 200的其他组件使用的API来呈现这个相关的请求消息。通过将先前的请求消息与相关请求上下文对象相关联，可提供具有访问由请求消息携带的AVP能力的属性的规则引擎215，这促进了正被处理的应答消息的发送。

另一方面，当所述逆消息是应答消息时，相关的应答模块235可以通过例如经由API请求Diameter堆栈205构造应答消息的来构造新的应答消息。新应答消息可以是完全空白的，或者可以包括从接收的Diameter请求消息复制过来的至少一些值。相关的应答模块235可以以类似于上面描述的接收的消息的模块233的方式将新的上下文对象中与新的应答消息相关联。然后，相关的应答上下文对象可以向规则引擎215提供到能够修改新的应答消息的多种动作的访问。例如，规则引擎可以利用相关应答上下文对象的动作来设定应答消息的结果码AVP，由此向消息处理器210表明应答应发送回发送所述接收到的请求的装置。然后，消息处理器210还可以避免转发所述接收的请求消息到任何其他装置。

如上文所述，上下文创建器230可具有定义不表示Diameter消息的其他上下文对象的能力。这样的上下文对象可以被称为“计算上下文”(computational context)，并且也可以通过上下文工件存储240中的上下文工件来定义。例如，路由决策上下文模块236可以被配置为实例化路由决策上下文对象。这样的路由决策上下文可为每个接收到的Diameter消息识别可能适用于所述接收到的消息的先前作出的路由决策。这样的先前作出的路由决策可以与会话标识符一起存储至路由决策数据库250，以便将接收到的消息与先前处理的消息相互关联。路由决策数据库250可以是能够存储这样的路由决策的任何计算机可读介质。因此，路由决策数据库250可以包括机器可读存储介质，例如只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪存设备、和/或类似存储介质。

计算上下文可通过其它DPA 200功能支持。例如，DPA200可以包括周期性地从路由决策数据库250移除陈旧条目的清理模块255。在一些实施方案中，所述路由决策的上下文对象可以不直接与清理模块255交互。相反，清理模块255可以独立地操作，通过修改路由决策数据库250中的内容间接地影响路由判决上下文对象的行为。

作为计算上下文的另一示例，订户记录上下文模块238可生成订户记录上下文对象。订户记录上下文对象可以利用其它的DRA 200功能，例如订户记录检索器260，来为接收的Diameter消息检索订户记录。订户记录检索器260可以包括硬件或者机器可读存储介质上的可执行指令，所述可执行指令被配置为经由Diameter堆栈205与订户概要文件存储库(SPR)进行通信来为Diameter消息检索订户记录。这样的通信可以例如根据Sp应用来执行。实现订户记录检索器260的多种方法是显而易见的。通过该订户记录的检索，订户记录上下文对象可以向规则引擎215提供对订户记录的访问。

应当指出的是，虽然规则存储器220、上下文工件存储器240、消息词典245、和路由决策数据库250被示为单独设备，其中的一个或多个组件可以驻留在多个存储设备上。此外，这些组件中的一个或多个可以共享存储装置。例如，规则存储器、上下文工件存储器240、消息词典245和路由决策数据库250可均指同一硬盘或闪存设备的一部分。

图3示出了用于处理Diameter消息的示例性方法300。方法300可通过DRA 200的组件来执行，例如Diameter堆栈205、消息处理器210、规则引擎215、或上下文创建器230。

方法300可开始于步骤305并继续进行到步骤310，在步骤310中，DRA200可以接收要被处理的Diameter消息。接着，在步骤315中，DRA200可以从接收到的Diameter消息提取消息类型。在多种实施例中，可以通过所述消息的应用和指令的类型来定义消息类型。然后，在步骤320中，DRA可使用提取出的消息类型建立消息上下文对象以包裹(wrap)接收的Diameter消息。以类似的方式，DRA200可以在步骤325中为与所述Diameter消息的逆建立消息上下文对象。例如，DRA 200可以使用查找表来识别所提取的消息类型的逆消息类型以及基于所述逆消息类型请求新的消息上下文。

然后，DRA200可在步骤330中继续建立其他任何计算上下文对象，DRA 200为该计算上下文对象存储上下文工件或者规则引擎可以请求该计算上下文对象。例如，DRA 200可以建立路由决策上下文对象以及订户记录上下文对象。在适当的上下文对象至少已被实例化之后，方法300可以进行到步骤335，在步骤335，DRA 200可以选择一个或多个适当的规则组以在处理中评估接收到的Diameter消息。在多种实施例中，DRA 200可为每个消息类型存储一个规则组。在一些实施例中，DRA 200可附加地或备选地存储普遍适用于所有Diameter消息、特定应用的所有Diameter消息、或者Diameter消息的另一个子组的规则组。

识别适当的规则组后，DRA 200可以针对在步骤340中实例化的上下文评估已选出的规则组或表。单个的规则可包括对上下文对象的多种组分的引用，在本文中称之为“上下文对象引用”。这样的组分可以构成上下文对象的属性或动作。为了评估包括这类引用的规则，DRA可以访问被引用的组分。例如，可以在比较中使用上下文对象的属性，以确定规则是否适用，或者上下文对象的动作是否可以在应用规则的结果时使用。对上下文对象的引用的多种附加用途是显而易见的。在应用适当的规则组后，DRA 200可以在步骤345中发送一个或多个消息至其它设备。例如，DRA可转发Diameter消息到另一个设备，所述Diameter消息可被修改，或者可以向发送已接收消息的设备回送应答。方法300可以进行到步骤350结束。

如上面所提到的，步骤335和340可包括不同类型的规则组的评估。例如，在一些实施例中，每个消息类型可与适用于该类型消息的规则组相关联。因此，可将一个规则组应用于Gx CCR消息而可将不同的规则组应用于Rx AAR消息。一些实施例还可包括普遍适用于全部Diameter消息、全部Diameter请求、或全部Diameter应答的规则组。在这样的实施例中，DRA200可以顺序的评估多个规则组。图4示出用于评估多个规则组的示例性方法400。方法400可以通过DSC 200的部件执行，代替方法300的步骤335、340。

方法400可开始于步骤405并继续进行到步骤410，在步骤410中，DRA200可识别适用于在步骤310中接收到的消息的通用规则组。例如，DRA200可以包括普遍适用于所有消息、所有Diameter消息、所有Diameter请求、或所有Diameter应答的规则组。例如，如果接收到的消息是GX CCR，DRA200可以识别对所有Diameter请求的通用规则组。然后，在步骤415中，DRA 200可评估识别出的规则组。在这样做时，DRA200可修改接收到的消息或生成将被发送回源设备的不同的Diameter消息。

评估通用规则组之后，方法400可前进至步骤420，在步骤420中DRA200可确定接收到的消息是否是请求消息。如果该消息是请求消息，方法400可以前进到步骤425，在步骤425中DRA 200可确定该请求是否已被应答。例如，在步骤415中，DRA 200可生成或修改Diameter应答消息。在步骤425中，DRA 200可确定Diameter应答的结果码AVP或实验结果AVP是否已被设置，以确定应答消息是否已被构建以便传输到源设备。如果是这样，方法400可前进至步骤440以结束而不评估任何附加的规则。DRA 200可以继续进行至将应答消息发送回源设备，例如在步骤300的步骤345中。

如果，在另一方面，接收到的消息不是请求消息，或者未在步骤415得到应答，方法400可以前进到步骤430。在步骤430中，DRA 200可以选择适用于接收到的消息的第二规则组。例如，DRA 200可定位与接收到的消息的应用和指令类型相关联的规则组。例如，如果接收的Diameter消息是Gx CCR，DRA 200可以识别与Gx CCR消息相关联的规则组。然后，在步骤435，DRA200可以再次调用规则引擎。该调用可涉及将在步骤430中识别的规则组而非在步骤410中识别的规则组递送给规则引擎。这样，DRA200可以在步骤435中评估所述特别地与接收到的Diameter消息的相关的规则组。方法400可以前进到步骤440结束。在多种实施例中，在完成方法400之后，DRA200可以继续前进至方法300的步骤345。

对于方法400来说，多种修改将是显而易见。例如，在一些实施例中，两个以上的规则组可适用于接收到的Diameter消息。在这样的实施例中，方法400可以调用规则引擎多于两次。再如另外一个例子，多个实施例可在确定请求是否已被应答之前评估所有的适用规则组，或者可以根本无需确定请求是否已被应答。

图5示出示例性的通用规则组500。通用规则组500可被存储在规则存储器中，例如DRA 200的规则存储器。在多种实施例中，通用规则组500可被存储为二元决策树，如图所示。显而易见的是，可以使用多种备选的安排来存储规则组。例如，规则组500可以被存储为多个记录，每个记录均包括用于评估以确定规则是否适用的准则字段(criteria field)以及存储当规则适用时要采取的动作或动作组的结果字段(result field)。另外，通用规则组500可被存储为例如规则存储器220的数据库中的表。备选地，规则组500可以是一系列链接的列表、阵列或类似的数据结构。因此，应当清楚，规则组500可以是基础数据的抽象；可以使用适于存储该数据的任何数据结构。

通用规则组500可普遍适用于所有的Diameter请求。DRA可存储适用于所有Diameter应答的单独的通用规则组(未示出)。规则组500可以包括诸如准则节点(criteria node)510的准则节点，以及诸如结果节点520、530的结果节点。显而易见的是，规则组500是示例性的，多种实施例可包括比示出的规则组500更复杂的规则组(未示出)。

准则节点可能会呈现由规则引擎评估的条件。基于所述评估，规则引擎可以选择另一准则节点或结果节点来评估。作为示例，准则节点510可在存储条件“Request.Peer-Origin–Host in FilterList”。在准则节点510的评估时，规则引擎可以确定所述条件是真还是假。例如，规则引擎可从表示接收到的消息或一些其它请求消息的“Request”上下文对象读取“Peer-Origin-Host(对端-源-主机)”属性，并确定该值是否被列在单独定义的FilterList中，所述FilterList可列出应对其阻塞消息的Peer-Origin–Hosts。如果是，规则引擎可选择结果节点520作为下一个节点来评估。如果该值未在FilterList中列出，规则引擎可以选择结果节点530作为下一个被评估的节点。

结果节点可表示将由规则引擎执行的一个或多个动作。这样的动作可包括，例如，修改Diameter消息或将Diameter消息发送到特定设备。作为一个例子，结果节点520可表明规则引擎应该向“answer(应答)”上下文对象添加具有值“0x12”的“result-code(结果-码)”AVP。该“answer”上下文对象可表示在Diameter堆栈中创建的相关应答消息，如上面关于DRA 200的相关应答模块235所讨论的那样。作为另一个例子，结果节点530可指示规则引擎应访问“Request”上下文对象的“remove”动作以从Diameter消息移除Route-Record(路由-记录)AVP，从而向接收Diameter消息的后续设备隐藏路由记录。规则引擎可以在遇见结果节点520或结果节点530之后完成对规则500的评估，因为这些节点也可是不具有其他子节点的叶节点。

明显的是，规则组500可以采取多种备选的结构。例如，规则组500可包括更少或额外的准则节点或结果节点。另外，准则节点可包括另一个作为孩子(child)的准则节点或者结果节点可以包括另一个作为孩子的结果节点。

图6示出了示例性消息的类型特定(type-specific)的规则组600。规则组600可被存储在规则存储器中，例如DRA 200的规则存储器220。在多种实施例中，规则组600可被存储为二元决策树，如图所示。显而易见的是，可使用多种备选的安排存储规则组。例如，规则组600可以被存储为多个记录，每个包括用于评估以确定规则是否适用的准则字段以及存储当规则适用时采取的动作的结果字段。此外，规则组600可被存储为，例如存储在规则存储器220的数据库中的表。备选地，规则组600可以是一系列链接的列表、阵列或类似的数据结构。因此，应当清楚，规则组600可以是基础数据的抽象；可以使用适合于存储该数据的任何数据结构。

消息类型特定的规则组600可以适用于特定消息类型的Diameter消息，例如，Rx AAR消息。DRA可为多个不同的消息类型存储单独的消息类型特定的规则组(未示出)。与规则组500类似，规则组600可以包括准则节点，例如准则节点610、640，以及结果节点，例如结果节点620、630、650、660。

作为示例，准则节点610可以存储条件“(Rx AAR.Session-ID<0x0A||Rx AAR.Session-ID>0x2A)”，当“Rx AAR”上下文对象的Session-ID(会话-ID)小于0x0A或大于0x2A时，所述条件被评估为“真”。当准则节点610评估为“真”时，规则引擎可以评估结果节点620。这样的评估可以包括向Session-ID AVP的当前值添加0x10值。

如果准则节点610评估为假，规则引擎可评估结果节点630。这样的评估可包括访问用于Rx AAR上下文对象的Flow-Description(流-描述)AVP的“remove(移除)”动作。然后，规则引擎可前进到准则节点640。准则节点640可包括条件“Present(RxAAR.Media-Component-Description”，当Rx AAR对象包括Media-Component-Description AVP时，所述条件可评估为真。当准则节点640评估为真时，规则引擎可以前进到结果节点650，在结果节点650中规则引擎可以将Flow-Description AVP设置为值“floober”。如果准则节点640评估为假，则规则引擎可继续前进到结果节点660。结果节点660可指定在评估中可采取的多个动作。例如，结果节点660可指示应该添加新的Media-Component-Description至Rx AAR上下文对象，并且应该添加“floober”的Flow-Description到Media-Sub-Component AVP。

很明显，规则组500、600可基于用户输入来生成。在多种实施例中，用户接口可使用户能够建立如图所示的树。在其它实施例中，用户接口可生成二元决策树或基于用户提供的不同规则定义的其他规则表示。例如，规则组500、600可以基于由用户提供的下述伪码规则定义来生成：

在接收上述伪代码时，DRA可以以在运行时更加迅速或高效地被评估的形式生成规则组。显而易见的是多种备选的方法能够使用户定义规则或规则组。

已经描述了示例性的组件和用于操作示例性网络100和DRA200的方法，现在将参考图1-7提供DRA的操作的示例。图7示出了示例性的消息交换700。消息交换700可出现在应用功能710、DRA720和PCRB730之间。出于示例的目的，应用功能710可对应于应用功能160；DRA720可对应于DRA 142和DRA 200；PCRB可以对应于PCRB144；方法300、400可描述DRA720的动作，并且规则组500、600可以描述规则存储器220的内容。

该过程可开始于步骤310，在步骤310中DRA720可从AF710接收Diameter消息740。消息处理器210可在步骤315从消息740提取应用程序和指令“Rx AAR”，并继续在步骤320-330中建立任意上下文对象。例如，上下文创建器230可实例化Rx AAR上下文对象和RX AAA上下文对象。

在步骤410中，因为消息740为Diameter请求，消息处理器可确定通用规则组500可以适用于消息740。消息处理器210随后在步骤415用规则组500调用规则引擎215。作为步骤415的一部分，规则引擎215可评估准则节点510，并确定与Rx AAR 740相关的Peer-Origin–Hosts，“0X2”可属于FilterList。因此，规则引擎215可评估结果节点520并添加具有值“0x12”的结果码AVP至Rx AAA上下文对象。由于已经在AAA中设置了结果码AVP，DRA720随后可确定步骤420、425为接收到的消息是请求消息并且该请求已在步骤415被应答。DRA720可仅基于规则组500的评估来继续向AF710回发消息750。

随后，AF 710可发送另一Rx AAR消息760至DRA720。在执行步骤310-330以及410之后，如上文所述。然而，在相对于消息760评估规则组500时，规则引擎215可确定Peer-Origin–Hosts“0x5”不在FilterList上。因此，规则引擎215可通过访问用于请求上下文对象的Route-Record(路由-记录)的移除动作来评估结果节点530。

接着，由于所述请求可能在步骤415没有被应答，方法400可从步骤425前进到步骤430，其中消息处理器210可识别适用于如消息760的RxAAR消息的规则组600。消息处理器210随后可在步骤435中第二次调用规则引擎，这一次采用规则组600。规则引擎可首先确定准则节点610的评估结果为“假”，因为会话ID 0x1A大于0x0A但小于0x2A。因此，规则引擎215可通过从消息760移除Flow-Description(流-描述)AVP来评估结果节点630。接下来，在确定Media-Component-Description(媒体-成分-描述)出现在消息760中之后，规则引擎215可以通过向Media-Sub-Component(媒体-子-成分)添加具有值“floober”的Flow-Description AVP来评估结果节点650。最后，在步骤345中，DRA可发送修改的消息770至PCRB 730。所图所示，所述消息770已经基于规则组500、600被修改为包括Flow-Description“floober”，并且不再包括Route-Record AVP。

根据上述内容，多种实施例在Diameter路由代理上实现了多种Diameter消息的鲁棒(robust)和动态处理。特别是，通过包括普遍适用于广泛类别的Diameter消息的规则以及与特定Diameter消息类型相关的规则组，DRA可帮助用户指定在处理各种Diameter消息时应遵循的复杂行为。例如，用户可指定为不同的Diameter应用所应用的不同行为，但仍以有效的方式执行其他系统范围的策略。从前面的公开来看，多种额外的好处将是显而易见的。

从上面的描述可以清楚地看出，本发明的多种示例性实施例可以以硬件或固件来实现。此外，多种示例性实施例可被实现为存储在机器可读存储介质上的指令，这些指令可以被读取并由至少一个处理器执行以实施在本文中详细描述的操作。机器可读存储介质可包括任何用于存储机器可读形式的信息的机制，所述机器例如个人计算机或膝上型计算机、服务器、或其他计算设备。因此，有形的和非临时性计算机可读存储介质可包括只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质，光存储介质、闪存设备、和类似的存储介质。

本领域技术人员应当理解，这里的任何方框图代表实施本发明的原理的说明性电路的概念性视图。类似地，可以理解，任何流程表、流程图、状态转移图、伪码及类似物代表实质上在计算机可读介质中表示并因此由计算机或处理器执行的各种处理，无论这样的计算机或处理器是否被明确示出。

虽然特别参考了特定示例性的例子详细地说明了多种示例性实施例，但是应当理解的是，本发明能够具有其它实施例，并且其细节能够在多种明显的方面进行修改。对于本领域技术人员来说，显而易见的，可以在本发明的精神和范围之内进行各种变化和修改。因此，前面的公开、说明和附图仅为说明性的目的，并不以任何方式限制本发明，本发明的范围仅由权利要求限定。

Claims (14)

1.一种由Diameter路由代理(DRA)执行的用于处理Diameter消息的方法，所述方法包括：

在DRA从第一源设备接收(310)第一Diameter消息；

确定(315)与所述第一Diameter消息相关联的第一消息类型；

识别(335)多个规则组中与所述第一消息类型相关联的第一规则组；

评估(340)所述第一规则组的第一规则；和

基于所述第一规则的评估发送(345)消息。

2.如权利要求1所述的方法，其中所述消息类型基于所述第一Diameter消息的命令类型和应用类型。

3.如权利要求1-2中任一项所述的方法，进一步包括：

识别(410)多个规则组中适用于至少两个不同的消息类型的第二规则组；和

评估(415)所述第二规则组的第二规则，

其中，基于所述第一规则的评估对第一消息的发送(345)包括：基于第一规则的评估和第二规则的评估发送第一消息。

4.如权利要求3所述的方法，其中在评估第一规则之前执行对第二规则的评估。

5.如权利要求4所述的方法，进一步包括：

在DRA从第二源设备接收(310)第二Diameter消息，其中所述第二Diameter消息为Diameter请求；

评估(415)所述第二规则组的第三规则，其中，对所述第三规则的评估生成Diameter应答的至少一部分；和

发送(345)所述Diameter应答至第二源设备，其中仅在所述第二规则组已被评估之后才执行所述发送。

6.如权利要求1-5中任一项的方法，其中：

评估(340)所述第一规则包括修改所述第一Diameter消息，并且，

基于所述第一规则的评估对所述消息的发送(345)包括发送第一Diameter消息至另一个设备。

7.如权利要求1-6中任一项所述的方法，其中：

所述第一Diameter消息为Diameter请求，

对所述第一规则的评估(340)包括修改Diameter应答，以及

基于所述第一规则的评估对所述消息的发送(345)包括：发送所述Diameter应答至第一源设备。

8.一种用于处理Diameter消息的Diameter路由代理(DRA)，所述DRA包括：

规则存储器(220)，被配置为存储多个规则组；

Diameter堆栈(205)，被配置为从第一源设备接收第一Diameter消息；

消息处理器(210)，被配置为：

确定与所述第一Diameter消息相关联的第一消息类型，以及

识别多个规则组中与所述第一消息类型相关联的第一规则组；和规则引擎，被配置为评估所述第一规则组中的第一规则，

其中，所述消息处理器(210)进一步被配置为：基于第一规则的评估发送消息。

9.如权利要求8所述的DRA，其中所述消息类型基于所述第一Diameter消息的命令类型和应用类型。

10.如权利要求8-9中任一项所述的方法，其中：

消息处理器(210)进一步被配置为识别多个规则组中适用于至少两个不同的消息类型的第二规则组，

规则引擎(215)进一步被配置为评估所述第二规则组的第二规则，并且

在基于所述第一规则的评估对第一消息的发送中，所述消息处理器(210)被配置为基于第一规则的评估和第二规则的评估发送第一消息。

11.如权利要求10所述的DRA，其中，所述规则引擎(215)在评估第一规则之前评估第二规则。

12.如权利要求11所述的DRA，其中：

Diameter堆栈(205)进一步被配置为从第二源设备接收第二Diameter消息，其中所述第二Diameter消息为Diameter请求；

规则引擎(215)被进一步配置为评估所述第二规则组的第三规则，其中对所述第三规则的评估生成Diameter应答的至少一部分；并且

消息处理器(210)进一步被配置为发送所述Diameter应答至所述第二源设备，其中仅在所述第二规则组已被评估之后才执行发送。

13.如权利要求8-12中任一项所述的DRA，其中：

规则引擎(215)被配置为在对第一规则的评估中修改所述第一Diameter消息，并且

消息处理器(210)被配置为在基于所述第一规则的评估对消息进行的发送中，将所述第一Diameter消息发送至另一设备。

14.如权利要求8-13中任一项所述的DRA，其中：

所述第一Diameter消息为Diameter请求,

所述规则引擎(215)被配置为在对第一规则的评估中修改Diameter应答，并且

消息处理器(210)被配置为在基于所述第一规则的评估对消息进行

的发送中，将所述Diameter应答发送至第一源设备。