CN105472594B - 一种用于处理数据的方法与设备 - Google Patents

Abstract

本发明的目的是提供一种在UDC架构下处理数据的方法和设备。UDR中存储的数据分为共享数据和用户数据。当UDR中的共享数据发生变化时，UDR向FE发送通知消息。FE再向UDR发送检索请求消息，其中包含了待检索的用户数据的信息，用于指示UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。然后，UDR搜索待检索的用户数据，判断其中哪些用户数据引用了所述共享数据，对于每个引用了该共享数据的用户数据，向FE发送通知消息。通过采用本发明，可以实现对共享数据的改变的自动控制，并实现过程的标准化。

Description

一种用于处理数据的方法与设备

技术领域

本发明涉及通信技术领域，尤其涉及一种UDC架构下数据管理的技术。

背景技术

3GPP定义的UDC(User Data Convergence)架构如图1所示。UDC架构提出了一种分层的结构，将用户数据处理和数据存储分离。UDC架构包括两部分：

UDR(User Data Repository，用户数据存储)：仅用于存储用户数据，其对于用户数据之间的逻辑关系并不知晓。UDR也被称为后端。

FE(Front End，前端)：负责业务处理。

FE和UDR之间通过Ud接口通信，Ud接口主要包括LDAP(Lightweight DirectoryAccess Protocol，轻量目录访问协议)和SOAP(Simple Object Access Protocol，简单对象访问协议)。LDAP主要用于对于数据的操作，比如增加、删除、修改、查询操作等。SOAP主要用于数据的订阅和通知。

UDC的前端(即FE)主要面向核心网络，处理来自核心网络的信令消息和业务请求，通过Ud接口向后端数据库(即UDR)访问，更新用户数据。FE不永久存储用户数据，在业务处理完成后将删除临时获得的用户数据。

UDC架构可以简化网络的拓扑结构和接口，避免数据重复和不一致性，UDC提供了标准的数据访问接口使得新业务的创建变得更加容易。

但是，3GPP定义的UDC架构也存在一些不足。

实际中很多用户的用户数据具有一些相同的内容，比如，几百万个LTE用户可能具有相同的EPS(Evolved Packet System，演进的分组系统)业务数据，这些EPS业务数据包括AMBR数据(Aggregated Maximum Bit Rate，聚合最大比特速率)、APN数据(Access PointName，接入点名称)、QoS(Quality of Service，服务质量)数据等。而一个LTE用户可能具有几十个甚至上百个EPS业务数据。对于每个用户数据，UDR都要存储这些EPS业务数据，而对于需要存储大量用户数据的UDR来说，这无疑要浪费很多的存储空间。而且，当FE从UDR下载用户数据时，对于每个用户数据，这些业务数据均会被下载。FE和UDR之间的通信通常是通过WAN(Wide Area Network，广域网)，而WAN的带宽是非常宝贵的。每次都下载相同的EPS业务数据占用了大量的带宽，这无疑也是很大的浪费，而且降低了系统的性能。

为了解决这些问题，共享数据的概念被提出并在UDR中实现了。把大量用户数据中相同的数据抽出来作为单独的对象来存储，而在用户数据部分定义对这些抽出来的数据的引用。这些被抽出来的单独存储的数据被称之为共享数据。因为共享数据可能被很多用户引用，所以共享数据的改动会影响到很多用户，所以在各种引入了共享数据的概念的方案中，都需要解决如果管理共享数据问题。但是，现有的解决方案大多数是私有的，不是通用的。特别是对于共享数据的管理，很多是采用人工管理的方式，当UDR中的共享数据发生改变时，在FE侧手动地进行相应的操作。而手动操作难免会带来一些错误和失误，而且由于这些操作不是标准的，也无法和其他厂商的设备很好的兼容。

因此，如何在3GPP的UDC架构中有效地管理共享数据是一个急需解决的问题。

发明内容

本发明的目的是提供一种在UDC架构下有效管理数据的方法与设备。

根据本发明的第一个方面，提供了一种在UDR中处理数据的方法，所述UDR中存储的数据分为用户数据和共享数据，其中，所述用户数据和每个用户一一对应，每个共享数据被至少一个用户数据引用，该方法包括以下步骤：当一个共享数据发生改变时，向订阅该共享数据的改变的FE发送第一通知消息，其中包含了所述共享数据的标识；接收来自所述FE的检索请求消息，其中包含了所述共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；根据所述待检索的用户数据的信息判断其中哪些用户数据引用了所述共享数据；对于每个引用了所述共享数据的用户数据，向所述FE发送第二通知消息，其中包含了所述用户数据的标识。

优选地，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

优选地，所述检索请求消息还包含发送通知的间隔时间，所述向所述FE发送第二通知消息的步骤进一步包括当发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

根据本发明的第二个方面，提供了一种在FE中处理数据的方法，该方法包括以下步骤：接收来自一个UDR的第一通知消息，其中包含了发生改变的数据的标识；判断所述发生改变的数据是否是一个共享数据；如果是，向所述UDR发送检索请求消息，其中包含了所述发生改变的共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；接收来自所述UDR的第二通知消息，其中包含了一个用户数据的标识，所述用户数据被包含在所述待检索的用户数据之中且引用了所述共享数据。

优选地，在所述向所述UDR发送检索请求消息步骤之前，该方法还包括：根据预定规则确定所述待检索的用户数据。

优选地，该方法还包括：根据发生改变的数据的内容，向相关网元发送通知消息。

优选地，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

优选地，所述检索请求消息还包含发送通知的间隔时间，当所述UDR发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

优选地，其中相关网元为以下网元之一：S-CSCF，MME，AAA服务器，AS，所述通知消息为Diameter消息。

根据本发明的第三个方面，提供了一种在UDR中处理数据的装置，所述UDR中存储的数据分为用户数据和共享数据，其中，所述用户数据和每个用户一一对应，每个共享数据被至少一个用户数据引用，该装置包括：第一发送装置，用于当一个共享数据发生改变时，向订阅该共享数据的改变的FE发送第一通知消息，其中包含了所述共享数据的标识；第一接收装置，用于接收来自所述FE的检索请求消息，其中包含了所述共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；第一判断装置，用于根据所述待检索的用户数据的信息判断其中哪些用户数据引用了所述共享数据；第二发送装置，用于对于每个引用了所述共享数据的用户数据，向所述FE发送第二通知消息，其中包含了所述用户数据的标识。

优选地，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

优选地，所述检索请求消息还包含发送通知的间隔时间，所述向所述FE发送第二通知消息的步骤进一步包括当发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

根据本发明的第四个方面，提供了一种在FE中处理数据的装置，该装置包括：第二接收装置，用于接收来自一个UDR的第一通知消息，其中包含了发生改变的数据的标识；第二判断装置，用于判断所述发生改变的数据是否是一个共享数据；第三发送装置，用于当第二判断装置的判断结果为是时，向所述UDR发送检索请求消息，其中包含了所述发生改变的共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；第三接收装置，用于接收来自所述UDR的第二通知消息，其中包含了一个用户数据的标识，所述用户数据被包含在所述待检索的用户数据之中且引用了所述共享数据。

优选地，该装置还包括：确定装置，用于根据预定规则确定所述待检索的用户数据。

优选地，该装置还包括：第四发送装置，用于根据发生改变的数据的内容向相关网元发送通知消息。

优选地，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

优选地，所述检索请求消息还包含发送通知的间隔时间，当所述UDR发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

优选地，其中相关网元为以下网元之一：S-CSCF，MME，AAA服务器，AS，所述通知消息为Diameter消息。

与现有的在UDC架构下管理共享数据的技术相比，本发明提出了一种自动管理的方法，无需人工操作，节省了人工成本，保证了数据的准确性。同时，本发明的方法也是一种标准的、通用的方法，利用标准中现有的通知机制，只需要对现行的标准做少量改动，实现起来简单，而且克服了现有技术存在的不兼容的问题。由于FE可以根据预定规则确定待检索的数据，缩小检索范围，所以本发明的方法可以避免对UDR中所有的数据进行检索，从而提高了效率，同时减轻了网元的负担。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1示出3GPP标准定义的UDC架构图；

图2示出根据本发明一个实施例的用于处理数据的方法流程图；

图3示出根据本发明一个实施例的在UDR中存储的数据的示意图；

图4示出根据本发明一个实施例的在UDR中用于处理数据的装置示意图；

图5示出根据本发明一个实施例的在FE中用于处理数据的装置示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本发明作进一步详细描述。

图2示出了根据本发明一个实施例的方法流程图。在该实施例中，UDR2A中存储的数据分为用户数据和共享数据。共享数据指被至少一个用户引用的数据，这种数据是独立于用户数据存储的。用户数据指用户特有的数据，比如：用户标识、鉴权信息、业务信息等，用户数据中的某些数据属性可以引用上述共享数据。一个用户数据和一个用户一一对应。而共享数据则被至少一个用户数据所引用。FE2B中仅暂存共享数据，并不暂存用户数据。

图3示出根据本发明一个实施例的在UDR2A中存储的数据的示意图。在UDR2A中采用的是DIT(Directory Information Tree)的数据结构，可以看出，其采用的数据结构是树型的。树中的每一个节点称为一个条目(Entry)，每个条目由DN(Distinguished Name，识别名)来标识。DN是由当前节点和当前节点的所有上级节点的RDN(Relative DN)从左到右串联起来的。RDN指的是当前节点相对于它的直接上级的相对识别名。对于同一个条目，DN取不同的值则对应于该条目的不同实例(instance)。

在该实施例中，根节点对应的DN为RootEntryID。根节点下有两个子节点，其对应的DN分别为：

左子节点的DN：SubscriberID，RootEntryID，

右子节点的DN：GlbBranchID，RootEntryID。

左子节点有3个不同的实例，分别如图中所示的实例301、实例302和实例303。他们对应的DN的值分别如下：

实例301的DN：SubscriberID＝13800138001，RootEntryID＝1；

实例302的DN：SubscriberID＝13800138002，RootEntryID＝1；

实例303的DN：SubscriberID＝13800138003，RootEntryID＝1。

可以看出，实例301、实例302和实例303分别对应于一个用户，我们称其为用户数据。因此，下文称其为用户数据301、用户数据302和用户数据303。

DN为(GlbBranchID，RootEntryID)的节点为共享数据所在子树的根节点，下有两个子节点，其对应的DN分别为：

左子节点的DN：ChargingInfoID，GlbBranchID，RootEntryID，

右子节点的DN：GlbIFCID，GlbBranchID，RootEntryID。

左子节点有3个不同的实例，分别如图中所示的实例304、实例305和实例306。他们对应的DN的值分别如下：

实例304的DN：ChargingInfoID＝1，GlbBranchID＝1，RootEntryID＝1；

实例305的DN：ChargingInfoID＝2，GlbBranchID＝1，RootEntryID＝1；

实例306的DN：ChargingInfoID＝3，GlbBranchID＝1，RootEntryID＝1。

下文中，实例304、实例305和实例306也被称为共享数据304、共享数据305和共享数据306。

每个用户数据都包括一些属性(Attribute)或者子节点用于说明其对应的用户的信息，其中一个属性为ChargingInfoID。用户数据301的ChargingInfoID＝1，其引用共享数据304。用户数据302的ChargingInfoID＝1，其也引用共享数据304。用户数据303的ChargingInfoID＝2，其引用共享数据305。

可以看出，引入共享数据的概念后，用户数据只需要存储其引用的共享数据的标识，而不需要存储共享数据本身的信息，这样UDR可以大大节省存储空间，而且，可以节省FE和UDR之间的带宽。

下面结合图3详细描述图2所示的方法。该方法开始于步骤S201。

如前所述，由于数据存储在UDR2A中，FE2B对于数据的改变并不知晓，因此，FE2B需要向UDR2A订阅数据的改变并指明其对哪些数据的改变感兴趣。在3GPP的标准TS29.335中对这种订阅进行了描述。这种订阅通常是通过SOAP的Subscribe消息。

在步骤S201之前，FE2B向UDR2A发送SOAP的Subscribe请求，具体如下：

其中的参数SubscribedDNList中列出了其感兴趣的节点的列表，其中包括DN为(ChargingInfoID，GlbBranchID，RootEntryID)的条目。

由于某些原因，运营商将共享数据304中的PrimaryChargSvr从“chargingserver101.ims.company.com”修改为“chargingserver301.ims.company.com”时，UDR2A检测到了共享数据304发生了改变，其会执行步骤S201。

在步骤S201中，当UDR2A中的一个共享数据发生改变时，UDR2A向订阅该共享数据的改变的FE发送第一通知消息，其中包含了所述共享数据的标识。比如，UDR2A检测到了共享数据304发生了改变，并且FE2B订阅了DN为(ChargingInfoID，GlbBranchID，RootEntryID)的条目的改变，而共享数据304正是这一条目的一个实例，因此，UDR2A必需向FE2B通知共享数据304的改变，即向FE2B发送第一通知消息，这里所述的第一通知消息可以是如下的SOAP的Notify消息：

在该Notify消息中指明了发生改变的数据的标识，即DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据304，并且也标明了发生改变的数据属性即PrimaryChargSvr，以及发生改变前后该数据属性的值即OldValue和NewValue对应的值。

当FE2B接收到上述第一通知消息后，会执行步骤S202。在步骤S202中，FE2B判断所述发生改变的数据是否是一个共享数据。

如前所述，UDR2A对存储的数据之间的逻辑关系并不知晓，因此，UDR2A并不知道发生改变的数据是用户数据还是共享数据，在UDR2A发送给FE2B的第一通知消息中也不会指明该发生改变的数据是用户数据还是共享数据。因此，FE2B收到第一通知消息后，首先会判断其中指明的数据是否是一个共享数据。FE2B知道数据之间的逻辑关系，知道哪些DN是标识用户数据的，哪些DN是标识共享数据的，FE2B主要是根据该数据的DN来判断其是否是一个共享数据，具体的，根据DN的语法(Syntax)来判断。比如，DN为(ChargingInfoID，GlbBranchID，RootEntryID)的数据为共享数据，而DN为(SubscriberID，RootEntryID)的数据为用户数据。

在本实施例中，FE2B判断出第一通知消息中指明的发生改变的数据为共享数据，其会保存该共享数据的新的值。

接着，在步骤S203中，FE2B向UDR2A发送检索请求消息，其中包含了所述发生改变的共享数据的标识和待检索的用户数据的信息，该检索请求消息用于指示UDR2A从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。

当FE2B判断出发生改变的数据为共享数据时，会进一步想知道哪些用户数据引用了该共享数据，从而根据发生变化的内容做后续处理。而FE2B中并没有用户数据的信息，因此，FE2B会指示UDR2A做检索，其会生成检索请求消息，其中包含了发生改变的共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。这里，检索请求消息可以是LDAP消息，而现有的LDAP消息并不能满足上述的需要，因此，本发明需要对LDAP消息作扩展，在消息中指明发生改变的共享数据的标识和待检索的用户数据的信息，并指示UDR2A从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。扩展的LDAP消息的语法定义如下所示：

其中，requestName的值是一个不同于已有LDAP消息的requestName的新的OID(Object Identification，对象标识)，用于指示UDR2A从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。其中，sharedData域指明这是一个共享数据并指明了共享数据的标识，这里的DN指的是一个具体的值，即特定的共享数据发生改变需要做用户数据检索。searchDn域指的是待检索的用户数据的DN，这里的DN指的是语法，而不是具体的值，即待检索的用户数据的条目，即从树的哪个节点进行检索。Attributelist域指的是待检索的数据属性，即检索用户数据的哪个数据属性引用了sharedData域指明的共享数据。

下面示例性给出一个该扩展的LDAP消息的实例。

在上述的扩展的LDAP消息中，FE2B指示UDR2A在DN为(SubscriberID，RootEntryID)的条目处进行检索，检索这些用户数据的ChargingInfoID属性并判断哪些用户数据的ChargingInfoID属性引用了DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据即共享数据304。

优选地，FE2B可以根据预定规则确定所述待检索的用户数据。比如，可以将FE2B上所有注册的用户或者所有在其管辖范围内的用户作为待检索的用户，从而避免了UDR2B对其保存的所有用户数据进行检索，缩小了检索范围。

UDR2A接收到上述检索请求消息。然后，在步骤S204中，根据所述待检索的用户数据的信息判断其中哪些用户数据引用了所述共享数据。UDR2A会搜索待检索的用户数据的信息所包含的所有的用户数据，判断其中哪些用户数据引用了所述共享数据。比如，UDR2A在收到来自FE2B的上述扩展的LDAP消息后，会搜索(SubscriberID，RootEntryID)的条目处所有的用户数据，即用户数据301、用户数据302和用户数据303，判断其中哪些用户数据的ChargingInfoID属性引用了DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据即共享数据304。经过判断，UDR2A判断出用户数据301和用户数据302引用了共享数据304。

接着，在步骤S205中，UDR2A对于每个引用了所述共享数据的用户数据，向所述FE发送第二通知消息，其中包含了所述用户数据的标识。所述第二通知消息可以是SOAP的Notify消息。在步骤S204中，UDR2A判断出用户数据301和用户数据302引用了共享数据304。对于用户数据301，UDR2A向FE2B发送的Notify消息如下：

对于用户数据302，UDR2A向FE2B发送的Notify消息如下：

对于每个引用了所述共享数据的用户数据，UDR2A均会向FE2B发送一条第二通知消息，当检索出的用户数据的数量很大时，FE2B会在短时间内收到大量的第二通知消息。为了减轻FE2B的负担，优选地，在步骤S203中，FE2B向UDR2A发送的检索请求消息还包含发送通知的间隔时间，当UDR2A发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

FE2B接收到上述第二通知消息后，得知哪些用户数据的哪些数据属性发生了改变。然后，根据现有的标准的规定，FE2B会采取相应的后续动作。在步骤S206中，FE2B根据发生改变的数据的内容向相应的网元2C发送通知消息。这里，相应的网元2C可以是S-CSCF(Serving-Call Session Control Function,呼叫会话控制功能)、MME(MobilityManagement Entity，移动性管理实体)、AAA(Authentication-Authorization-Accounting，验证-授权-记账)服务器、AS(Application Server，应用服务器)等，所述的通知消息可以是Diameter消息。需要指出的是，并不是所有的数据改变都会触发FE2B向网元2C发送通知消息，因此，步骤S206不是必需的。

在本实施例中，FE2B接收到的第二通知消息表明用户数据301引用了共享数据304且用户数据301的ChargingInfoID数据属性发生了改变，而ChargingInfoID＝1对应的信息可以在本地的共享数据304获得，这是一个和计费相关的信息。根据3GPP标准的规定，用户的与计费相关的属性发生改变时，必需向S-CSCF发送通知消息。因此，FE2B会向其对应的S-CSCF发送PPR(Push Profile Request)消息，告诉其用户数据301对应的用户的计费信息发生改变和更新后的值。

图4示出根据本发明一个实施例的在UDR2A中用于处理数据的装置示意图。该装置400包括：第一发送装置401、第一接收装置402、第一判断装置403和第二发送装置404。

下面结合图2和图3详细描述该装置的工作过程。

由于某些原因，运营商将UDR2A中的共享数据304中的PrimaryChargSvr从“chargingserver101.ims.company.com”修改为“chargingserver301.ims.company.com”时，UDR2A检测到了共享数据304发生了改变。

当UDR2A中的一个共享数据发生改变时，第一发送装置401向订阅该共享数据的改变的FE发送第一通知消息，其中包含了所述共享数据的标识。比如，UDR2A检测到了共享数据304发生了改变，并且FE2B订阅了DN为(ChargingInfoID，GlbBranchID，RootEntryID)的条目的改变，而共享数据304正是这一条目的一个实例，因此，UDR2A必需向FE2B通知共享数据304的改变，即第一发送装置401向FE2B发送第一通知消息，这里所述的第一通知消息可以是如下的SOAP的Notify消息：

在该Notify消息中指明了发生改变的数据的标识，即DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据304，并且也标明了发生改变的数据属性即PrimaryChargSvr，以及发生改变前后该数据属性的值即OldValue和NewValue对应的值。

然后，第一接收装置402接收到来自FE2B的检索请求消息，其中包含了上述发生变化的共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。这里，检索请求消息可以是LDAP消息，而现有的LDAP消息并不能满足上述的需要，因此，本发明需要对LDAP消息作扩展，在消息中指明发生改变的共享数据的标识和待检索的用户数据的信息，并指示UDR2A从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。关于扩展的LDAP消息的语法定义请参见上文。一个扩展的LDAP消息的实施如下所示：

在上述的扩展的LDAP消息中，FE2B指示UDR2A在DN为(SubscriberID，RootEntryID)的条目处进行检索，检索这些用户数据的ChargingInfoID属性并判断哪些用户数据的ChargingInfoID属性引用了DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据即共享数据304。

然后，第一判断装置403根据所述待检索的用户数据的信息判断其中哪些用户数据引用了所述共享数据。第一判断装置403会搜索待检索的用户数据的信息所包含的所有的用户数据，判断其中哪些用户数据引用了所述共享数据。比如，第一接收装置402在收到来自FE2B的上述扩展的LDAP消息后，第一判断装置403会搜索(SubscriberID，RootEntryID)的条目处所有的用户数据，即用户数据301、用户数据302和用户数据303，判断其中哪些用户数据的ChargingInfoID属性引用了DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据即共享数据304。经过判断，第一判断装置403判断出用户数据301和用户数据302引用了共享数据304。

接着，第二发送装置404对于每个引用了所述共享数据的用户数据，向所述FE发送第二通知消息，其中包含了所述用户数据的标识。所述第二通知消息可以是SOAP的Notify消息。第一判断装置403判断出用户数据301和用户数据302引用了共享数据304。对于用户数据301，第二发送装置404向FE2B发送的Notify消息如下：

对于用户数据302，第二发送装置404向FE2B发送的Notify消息如下：

对于每个引用了所述共享数据的用户数据，第二发送装置404均会向FE2B发送一条第二通知消息，当检索出的用户数据的数量很大时，FE2B会在短时间内收到大量的第二通知消息。为了减轻FE2B的负担，FE2B向UDR2A发送的检索请求消息还包含发送通知的间隔时间，当第二发送装置404发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

图5示出根据本发明一个实施例的在FE2B中用于处理数据的装置示意图。该装置500包括：第二接收装置501、第二判断装置502、第三发送装置503和第三接收装置504。

下面结合图2和图3详细描述该装置的工作过程。

首先，第二接收装置501接收到来自UDR2A的第一通知消息，其中包含了发生改变的数据的标识。这里所述的第一通知消息可以是如下的SOAP的Notify消息：

在该Notify消息中指明了发生改变的数据的标识，即DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据304，并且也标明了发生改变的数据属性即PrimaryChargSvr，以及发生改变前后该数据属性的值即beforeValue和currentValue对应的值。

当第二接收装置501接收到上述第一通知消息后，会执行步骤S202。第二判断装置502会判断所述发生改变的数据是否是一个共享数据。

如前所述，UDR2A对存储的数据之间的逻辑关系并不知晓，因此，UDR2A并不知道发生改变的数据是用户数据还是共享数据，在UDR2A发送给FE2B的第一通知消息中也不会指明该发生改变的数据是用户数据还是共享数据。因此，FE2B收到第一通知消息后，首先会判断其中指明的数据是否是一个共享数据。FE2B知道数据之间的逻辑关系，知道哪些DN是标识用户数据的，哪些DN是标识共享数据的，第二判断装置502主要是根据该数据的DN来判断其是否是一个共享数据，具体的，根据DN的语法(Syntax)来判断。比如，DN为(ChargingInfoID，GlbBranchID，RootEntryID)的数据为共享数据，而DN为(SubscriberID，RootEntryID)的数据为用户数据。

在本实施例中，第二判断装置502判断出第一通知消息中指明的发生改变的数据为共享数据，其会保存该共享数据的新的值。

接着，第三发送装置503向UDR2A发送检索请求消息，其中包含了所述发生改变的共享数据的标识和待检索的用户数据的信息，该检索请求消息用于指示UDR2A从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。

当第二判断装置502判断出发生改变的数据为共享数据时，FE2B会进一步想知道哪些用户数据引用了该共享数据，从而根据发生变化的内容做后续处理。而FE2B中并没有用户数据的信息，因此，FE2B会指示UDR2A做检索，其会生成检索请求消息，其中包含了发生改变的共享数据的标识和待检索的用户数据的信息。这里，检索请求消息可以是LDAP消息，而现有的LDAP消息并不能满足上述的需要，因此，本发明需要对LDAP消息作扩展，在消息中指明发生改变的共享数据的标识和待检索的用户数据的信息，并指示UDR2A从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据。关于扩展的LDAP消息的语法定义请参见上文。

下面示例性给出一个该扩展的LDAP消息的实例。

在上述的扩展的LDAP消息中，FE2B指示UDR2A在DN为(SubscriberID，RootEntryID)的条目处进行检索，检索这些用户数据的ChargingInfoID属性并判断哪些用户数据的ChargingInfoID属性引用了DN为(ChargingInfoID＝1,GlbBranchID＝1,RootEntryID＝1)的共享数据即共享数据304。

优选地，装置500包括确定装置(图中未示出)。所述确定装置根据预定规则确定所述待检索的用户数据。比如，可以将FE2B上所有注册的用户或者所有在其管辖范围内的用户作为待检索的用户，从而避免了UDR2B对其保存的所有用户数据进行检索，缩小了检索范围。

接着，第三接收装置504接收到来自UDR2A的第二通知消息，其中包含了一个用户数据的标识，该用户数据被包含在上述待检索的用户数据之中且引用了上述共享数据。所述第二通知消息可以是如下所示的SOAP的Notify消息：

收到上述第二通知消息后，FE2B便知道DN为(SubscriberID＝13800138001,RootEntryID＝1)的用户数据包含在待检索的用户数据(SubscriberID，RootEntryID)之中且引用了共享数据304。

对于每个引用了所述共享数据的用户数据，UDR2A均会向FE2B发送一条第二通知消息，当检索出的用户数据的数量很大时，FE2B会在短时间内收到大量的第二通知消息。为了减轻FE2B的负担，优选地，第三发送装置503向UDR2A发送的检索请求消息还包含发送通知的间隔时间，当UDR2A发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

FE2B接收到上述第二通知消息后，得知哪些用户数据的哪些数据属性发生了改变。然后，根据现有的标准的规定，FE2B会采取相应的后续动作。优选地，FE2B还包括第四发送装置(图中未示出)。第四发送装置根据发生改变的数据的内容向相应的网元2C发送通知消息。这里，相应的网元2C可以是S-CSCF、MME、AAA服务器、AS等，所述的通知消息可以是Diameter消息。需要指出的是，并不是所有的数据改变都会触发FE2B向网元2C发送通知消息。

在本实施例中，FE2B接收到的第二通知消息表明用户数据301引用了共享数据304且用户数据301的ChargingInfoID数据属性发生了改变，而ChargingInfoID＝1对应的信息可以在本地的共享数据304获得，这是一个和计费相关的信息。根据3GPP标准的规定，用户的与计费相关的属性发生改变时，必需向S-CSCF发送通知消息。因此，第四发送装置会向其对应的S-CSCF发送PPR消息，告诉其用户数据301对应的用户的计费信息发生改变和更新后的值。

需要注意的是，本发明可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本发明的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本发明的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本发明的方法和/或技术方案。而调用本发明的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本发明的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本发明的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (18)

1.一种在UDR中处理数据的方法，所述UDR中存储的数据分为用户数据和共享数据，其中，所述用户数据和每个用户一一对应，每个共享数据被至少一个用户数据引用，该方法包括以下步骤：

当一个共享数据发生改变时，向订阅该共享数据的改变的FE发送第一通知消息，其中包含了所述共享数据的标识；

接收来自所述FE的检索请求消息，其中包含了所述共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；

根据所述待检索的用户数据的信息判断其中哪些用户数据引用了所述共享数据；

对于每个引用了所述共享数据的用户数据，向所述FE发送第二通知消息，其中包含了所述用户数据的标识。

2.根据权利要求1所述的方法，其中，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

3.根据权利要求1或2所述的方法，其中，所述检索请求消息还包含发送通知的间隔时间，所述向所述FE发送第二通知消息的步骤进一步包括当发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

4.一种在FE中处理数据的方法，该方法包括以下步骤：

接收来自一个UDR的第一通知消息，其中包含了发生改变的数据的标识；

判断所述发生改变的数据是否是一个共享数据；

如果是，向所述UDR发送检索请求消息，其中包含了所述发生改变的共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；

接收来自所述UDR的第二通知消息，其中包含了一个用户数据的标识，所述用户数据被包含在所述待检索的用户数据之中且引用了所述共享数据。

5.根据权利要求4所述的方法，其中，在所述向所述UDR发送检索请求消息步骤之前，该方法还包括：

根据预定规则确定所述待检索的用户数据。

6.根据权利要求4或5所述的方法，该方法还包括：

根据发生改变的数据的内容，向相关网元发送通知消息。

7.根据权利要求4或5所述的方法，其中，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

8.根据权利要求4或5所述的方法，其中，所述检索请求消息还包含发送通知的间隔时间，当所述UDR发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

9.根据权利要求6所述的方法，其中相关网元为以下网元之一：S-CSCF、MME、AAA服务器、AS，所述通知消息为Diameter消息。

10.一种在UDR中处理数据的装置，所述UDR中存储的数据分为用户数据和共享数据，其中，所述用户数据和每个用户一一对应，每个共享数据被至少一个用户数据引用，该装置包括：

第一发送装置，用于当一个共享数据发生改变时，向订阅该共享数据的改变的FE发送第一通知消息，其中包含了所述共享数据的标识；

第一接收装置，用于接收来自所述FE的检索请求消息，其中包含了所述共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；

第一判断装置，用于根据所述待检索的用户数据的信息判断其中哪些用户数据引用了所述共享数据；

第二发送装置，用于对于每个引用了所述共享数据的用户数据，向所述FE发送第二通知消息，其中包含了所述用户数据的标识。

11.根据权利要求10所述的装置，其中，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

12.根据权利要求10或11所述的装置，其中，所述检索请求消息还包含发送通知的间隔时间，所述向所述FE发送第二通知消息的步骤进一步包括当发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

13.一种在FE中处理数据的装置，该装置包括：

第二接收装置，用于接收来自一个UDR的第一通知消息，其中包含了发生改变的数据的标识；

第二判断装置，用于判断所述发生改变的数据是否是一个共享数据；

第三发送装置，用于当第二判断装置的判断结果为是时，向所述UDR发送检索请求消息，其中包含了所述发生改变的共享数据的标识和待检索的用户数据的信息，所述检索请求消息用于指示所述UDR从所述待检索的用户数据中检索出哪些用户数据引用了所述共享数据；

第三接收装置，用于接收来自所述UDR的第二通知消息，其中包含了一个用户数据的标识，所述用户数据被包含在所述待检索的用户数据之中且引用了所述共享数据。

14.根据权利要求13所述的装置，该装置还包括：

确定装置，用于根据预定规则确定所述待检索的用户数据。

15.根据权利要求13所述的装置，该装置还包括：

第四发送装置，用于根据发生改变的数据的内容向相关网元发送通知消息。

16.根据权利要求13或14所述的装置，其中，检索请求消息为LDAP消息，待检索的用户数据的信息进一步包括待检索的用户数据的DN和待检索的数据属性。

17.根据权利要求13或14所述的装置，其中，所述检索请求消息还包含发送通知的间隔时间，当所述UDR发送的第二通知消息为多条时，相邻两条第二通知消息的发送时间之间的间隔为所述间隔时间。

18.根据权利要求15所述的装置，其中相关网元为以下网元之一：S-CSCF，MME，AAA服务器，AS，所述通知消息为Diameter消息。