[发明专利]目录数据库处的数据管理

说明书

技术领域

本发明涉及电信，具体地涉及用于在目录数据库处的数据管理的方法，且更具体地涉及在目录服务器侧强制执行的LDAP互斥机制。本发明还涉及目录数据库、计算机程序、计算机程序产品、客户端和通信系统。

背景技术

当前，针对将要到来的3GPP版本9，正在对第3代合作伙伴项目(3GPP)用户数据汇聚(UDC，3GPP术语)进行标准化。提出了核心网(CN)100中的图1所示的新的架构，其中，将不同网络单元的订户服务相关数据和商务逻辑加以分离。这样，将用户数据仓库102(UDR，3GPP术语)用作集中式数据库，使得不同的应用前端106至110可以访问用户数据(通过新的“Ud”参考点112)。需要最小化由于引入UDC而产生的对现有网络的影响。

当应用UDC架构时，诸如归属位置寄存器(HLR)/归属订户服务器(HSS)、认证中心(AuC)、应用服务器、供应(provisioning)系统等等之类的功能实体保持应用逻辑，但是他们不持久地本地存储用户数据。在UDC架构中，将这些无数据功能实体统称为应用前端(FE)106至110。

现在已同意(阶段3活动正在进行中)轻量级目录访问协议(LDAP，互联网工程任务组(IETF)标准)作为要在针对CRUD(创建、读取、更新、删除)操作的Ud接口中使用的数据访问协议。

根据UDC架构原则，每个应用-FE可以在任何时间管理任何订户相关的请求。且对于很多应用，可以并发地(即并行地)针对相同订户管理多于一个应用相关的过程(即，操作)。因此，可以存在以下情况：两个(或更多)不同的应用-FE实例正在管理针对严格相同的数据(即，在UDR中管理的严格相同的订户目录条目/属性)的两个(或更多)不同的应用相关请求。

例如，一个3G移动订户正在归属网络上移动(因此，在核心网内部发出“位置更新”过程，以更新订户位置)，且同时相同的订户正在调用“订户过程”以改变针对(之前激活的)“无应答时的呼叫转移”补充服务的重定向号码。

在前述示例中，两个不同的HLR-FE实例(管理发出的“移动应用部分(MAP，SS7栈)位置更新”过程的实例和管理调用的订户过程的实例)正在同时/接近同时尝试访问并修改在UDR中的严格相同的数据。

存在很多其他的可以发生这种类型情况的网络使用情况。根据第一示例，供应-FE实体可以尝试更新订户简档(作为从客户管理系统(CAS)接收到供应命令的结果)，且同时应用-FE正在尝试更新严格相同的数据(或某些共同的部分)。根据第二示例，来自两个不同应用的两个不同的FE实例可以尝试修改相同订户简档的某些共同(对于两个应用而言)的数据。

注意到：在前述示例列表中的第一使用情况(UC)(调用供应-FE实例)可能是发生的最一般的UC(因为其与以下过程无关：应用允许或不允许从两个或更多不同FE实例并行处理两个或更多与严格相同的订户相关的过程)。

在所有这些类型的情况下，如果在UDR中不能保障某种互斥机制，则“数据一致性”问题可能发生，如图2的序列图更好地示出(将其作为图形化示例)：

具体地，这种有问题的情况可能源于两个客户端(如HLR-FE 206和供应-FE 208)都请求修改目录数据库(如UDR 202)处的数据条目。图2的示例序列图的步骤如下所述：

在第一步骤216中，HLR-FE 206从订户具体接收MAP位置更新。在另一步骤218中，HLR-FE 206请求读取与该订户相关联的订户简档，且HLR-FE 206向UDR 202发送相应的LDAP搜索请求。因此，UDR 202向进行请求的HLR-FE 206发送相应的简档数据。于是，在另一步骤220中，HLR-FE 206执行应用相关逻辑，并可以具体地处理接收到的该订户的简档数据。

在下一步骤222中，供应-FE 208从CAS具体接收供应命令。在下一步骤224中，供应-FE 208请求读取与订户相关联的订户简档，并向UDR 202发送相应的LDAP搜索请求。因此，UDR 202向进行请求的供应-FE 206发送相应的简档数据。于是，在另一步骤226中，供应-FE 206执行应用相关逻辑，并可以具体地处理接收到的该订户的简档数据。

在步骤228中，供应-FE 208通过发送相应的LDAP修改请求，请求更新在UDR 202处存储的订户简档。因此，UDR 202更新该订户简档，并向供应-FE 208发送与更新过程相关的信息，具体地，已更新的订户简档。