CN1633795A

CN1633795A - 用户的服务实体之间的灵活用户分布

Info

Publication number: CN1633795A
Application number: CN02806042.3A
Authority: CN
Inventors: J·A·桑切斯埃雷罗; I·P·安德烈斯
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2001-03-06
Filing date: 2002-03-06
Publication date: 2005-06-29
Anticipated expiration: 2022-03-06
Also published as: DE60204289D1; US20020147845A1; CA2440121A1; CA2440121C; CN100566328C; WO2002071674A3; EP1366590A2; AU2002242719A1; DE60204289T2; ATE296509T1; WO2002071674A2; EP1366590B1

Abstract

在一个网络内提供一个用户分布服务器(UDS)，所述网络具有均利用多个不同的使用标识符识别的多个服务器和用户。该UDS位于可以访问一个被配置用于请求用户信息的实体的位置上，该UDS通过将查询改发到合适的服务器或服务实体来响应一个与特定用户有关的查询。UDS使用从与服务器有关或者从这些服务器中推导出的主用户数据库获得的用户与服务器标识符来实现一个辅助数据库。因为可以在主数据库内很容易地管理数据变化和更新，并且然后将这些数据变化和更新传送给辅助数据库或者在辅助数据库中实现，所以不同的主数据库和辅助数据库的使用简化了数据处理。

Description

用户的服务实体之间的灵活用户分布

技术领域

在此所公开和要求保护的发明一般地涉及使用多个服务器向它们的用户或订户提供业务的大型通信网络，通过多个不同的用户标识符来识别或接入所述用户或订户。更具体地说，本发明涉及用于上述类型的网络的装置、系统和方法，所述网络在不限制用户和提供业务的服务器所使用的标识符类型的情况下，能够找到合适的服务器为一个特定用户提供一个特定的服务器。

现在，大型电信系统趋向于扩展并跨越多个运营商网络，其中各个网络都提供许多种不同的业务，并且通常以不同和独立的技术为基础。这种发展的一个重要的例子是在一个固定或者移动环境中新出现的基于互联网的网络与传统的有线和无线电话系统的互连。具有不同特性并且向网络用户提供不同种类业务的不同运营商网络的合并通常需要在一个电信网络内有多个不同的服务器，以便保存预约和向它们的用户提供业务。

另一方面，使用现有的网络资源经过适当的修改之后实现和支持新兴业务可能成为以及时的方式和在不丢失现有网络资源中的性能或其它特征的情况下有效地将这些新业务推向市场的主要障碍。曾经普遍使用的一种方法是引入新的专用服务器，用于引入仅在某种技术条件下可用或打算使用的业务。因此，引入多个业务专用服务器以及多个预约专用服务器所面对的一个基本的问题是在不对用户和提供业务的服务器的标识进行任何限制的情况下如何找到合适的服务特定用户的服务器。这个问题的解决方法必须能够适应当前不可用或者不知道的用户和服务器标识符。

一般而言，现在在一个大型通信网络中一般使用特定的用户标识符来识别一个用户或订户，所述特定用户标识符通常根据具体的系统技术是不同的。在一些情况下，由于不同的原因，一个具体的网络为同一个用户支持或者使用多个标识符。有许多网络使用不同的用户标识符，例如在许多方面在概念上类似的GSM和ANSI-41。

例如，为了内部识别的目的，GSM网络具有特定的用户标识符，例如IMSI，而为了外部识别的目的，GSM和PSTN网络都具有E.164标识符。而且，E.164标识符可以与用户或者网络节点相关，并可以用于寻址目的。在UMTS网络内，以与GSM网络类似的方式，数字方案与非数字方案并存。举另外一个例子，网际协议(IP)多媒体系统使用通常基于非数字方案的不同标识符，例如SIP url、电子邮件名称或者其它别名。这些标识符用于在一个具体的业务环境下识别用户，即，配置用户接收一个具体的业务或者一组业务。这些标识符还用于识别一个具体业务的服务器。另一方面，这些IP多媒体系统还使用E.164标识符与PSTN网络互连，而将典型的IP机制用于寻址目的。

在一个大型电信网络内不断地为每个用户使用不同的标识符以及与不同业务或者业务环境相关的多个服务器的出现需要一种改进的机制，用于找到为特定用户提供服务的适当的服务器。这种改进的机制必须非常灵活，也就是说，它必须如上所述不能限制为用户或者提供业务的服务器使用多个标识符。这种机制还必须考虑在确定哪一个服务器是为一个终端用户提供服务的实际或正确的服务器的处理中严格的实时限制。而且，所提供的解决方法必须最小化实施和配置的复杂性，并限制运营成本，尽管存在大量用户，每个用户都具有多个用户标识符，每个标识符可以与一个通信网络相关。

在标准化论坛“第三代合作项目”(在下文中称作3GPP)中在IP多媒体子系统的开发过程中将着重研究上述更有效地分布用户标识符的需要。具体而言，如在附件F(信息资料)：技术规范(TS)23.228中“到HSS解析的用户标识(User Identity to HSS resolution)”所描述的，一个感兴趣的用户被编址成预约位置功能的输出。在此，认识到在登记和会话建立过程中，因为在具体运营商的网络通常存在多个HSS，所以需要确定当前保存用户特定数据的实际原籍用户服务器(HSS)的位置，所述用户具体数据例如是位置或鉴权参数。

因而，本发明的第一个目的是提供允许在多个不同和专用的预约和业务服务器之间灵活地分布用户的装置和方法。所述灵活地分布是希望独立于用户标识符的方案、结构和可用的业务。

本发明的另一个目的是提供一种解决方案，它在尽可能地与现有的传统电信系统兼容的情况下，使对第三代电信系统当前推荐的结构影响最小。

本发明的又一个目的是提供在不明显增加所需要的操作和维护(O&M)工作和相关成本的情况下允许上述用户的灵活分布的方法和装置。在这一方面，在数据库之间交换所需要数据的自动程序是本发明所寻求的一个重要特征。

背景技术

在诸如GSM和ANSI-41网络等典型的第二代无线系统中找到了感兴趣的起始点。随着所述无线系统拥有越来越多的用户，运营商需要诸如原籍位置寄存器(HLR)等大型用户数据库以保存大量的预约信息，所述预约信息最小化操作和维护工作，并优化七号信令系统(SS7)网络内的路由表。随后，运营商开始通过拆分现有的HLR来引入冗余HLR，以使每个HLR包括自己的用户组和冗余HLR拥有的用户组。伴随着这种支持冗余的用户初始化分布的是在SS7网络内引入越来越复杂的路由表。因为将整个用户组从一个HLR移动到另一个HLR，所以并不一定需要一个数据库分布器为某个用户找到保存其预约的正确的HLR，这种分布可以通过在SS7网络内添加更多的路由表来解决。最近出现的号码可移植性的要求使对数据库分布器的需要成为必然，所述号码可移植性的要求在一些情况下是通过法律规定的，其中各个用户从属于一个运营商的HLR移动到属于另一个运营商的另一个HLR。

这样一个数据库分布器的示例性描述可以在国际申请WO 99/23838中找到，其中所述的在某个网络内的数据库分布器被称作灵活号码寄存器(FNR)。这个FNR是在第二代无线网络内与其用户号码组属于所述网络的那些用户有关的查询的自然入口，而与当前哪个网络保存有用户预约无关。也就是说，所述FNR包括寻址这一网络的所有用户号码组以及用于用户从另一个网络进入该网络的个人用户号码。另外，已经进入另一个网络的原籍用户的个人用户号码被特别地标记，并且具有一个特定网络标识符以抵达网络内用户当前保存他或她的预约的一个入口节点。

以诸如IMSI或E.164格式等用户号码为基础的与用户有关的查询被发送给由所述IMSI或E.164格式寻址的一个网络内的FNR。然后，FNR决定是否应因为用户从未进入其它网络或者从其它网络进入而将该查询简单地转发给其自己网络内的适当的HLR，或者应当将该查询改发到正确的用户已经进入的网络。在较低的信令层上执行所有的所需要的路由选择和寻址过程，例如在SS7中在信令连接控制部分(SCCP)上。

尽管将这种方案视为最接近的现有技术，但是对于直接应用于在大型电信网络内互连传统的固定和无线电话网络与互联网和多媒体业务网络的最新情况来说，它依然存在严重的局限性。例如，这种FNR的现有技术根据用户或订户的标识符仅仅基于结构化编码的SS7的原理而仅仅考虑信令、路由选择和寻址。而且，必须以这种方式来结构化编码与一个用户有关的至少一个标识符以通过分析这个号码就能够明确地识别出正确的HLR。这种现有方案的另一个局限性在于在这些第二代无线网络的发展过程中并未考虑其它最新的标识符方法，也未考虑除了SS7相关较高层之外的协议支持。这种方案所隐含的另一个缺点也是本发明所要解决的问题是这些数据库结构的高成本的操作和维护，其中运营商必须人工地介入所有这些数据库以确保一致的数据相互关系。另外，在这种现有技术中也没有预见到业务专用服务器，例如支持多媒体相关业务的业务专用服务器，这些业务是可以通过响应以相应用户标识符为基础的查询来实现的。

美国专利申请公开文献2001/0049676(Kepler等人)描述了使用由主数据库和辅助数据库构成的数据库体系来搜索内容的方法和系统，所述主数据库包含具体数据，所述辅助数据库包含这些数据的子集以及一个表示包含这些数据的主数据库的字段。该申请需要一个前端路由数据库，它包含分布在若干后端数据库之中的大量数据，不便于顺序地查询，更不可能得知所有这些后端数据库或者其中包含的数据类型。除此之外，如本领域的任意一位技术人员可以理解的，在前端数据库中接收查询方面可能存在一些其它优点，所述查询例如查询搜索排除字段的验证，并在将所述查询转发给有关后端数据库时进一步检验。当在前端数据库上接收到一个数据库搜索时，根据该搜索请求中所包含信息的类型和在前端数据库的数据字段内所包含信息的类型之间的重叠生成一个修改后的搜索。这个修改后的搜索请求用于提取一个可能生成原搜索请求结果的候选数据库的列表。然后将原搜索请求提交给这些候选数据库，并将结果返送给用户。

如本领域的任意一位技术人员可以理解的，上述申请中的教导具体针对执行特殊内容的搜索，其中将一个候选结果列表提供给用户，以便根据原始搜索的目标来选择一个最有吸引力的结果。具体而言，该申请看起来在描述由搜索装置执行的工作任务的种类。然而，在3G无线网络的用户试图调用一个具体业务的情况下应用这种方法是不方便的，所述具体业务例如是启动一个视频会议。主叫用户执行一个呼叫或者调用一个业务，并且希望网络透明地工作，以便用户不必采取与选择最合适的服务器有关的任何动作，另一方面，在一般情况下用户绝对不知道最合适的服务器。从这一方面来说，该申请中的搜索或者路由选择方法都不能用于在电信系统内的多个不同服务器中实现用户的灵活分布。

因此，看起来通过上述申请的教导不能实现或者预测到本发明的上述目的。从这一方面来说，本发明的目的是提供在与用户标识符方案、结构和可应用的业务无关的情况下允许在多个服务器之间用户的灵活分布的装置和方法。本发明的目的还在于最小化对最新的和传统的电信系统互连的影响以及最小化操作与维护O&M工作任务及成本的所述装置和方法。

发明内容

为了实现这些目的，本发明将一个用户标识符分布器放置在一个网络的解析域(resolution domain)内，并且可以访问一个设置用于请求用户信息的实体。该分布器或者用户分布服务器(UDS)包括用于在不同业务环境下识别一个用户的每个用户的多个用户标识符。

这个UDS使用从主数据库获得的用户和服务器标识符实现一个辅助数据库，安排用于在一个具体业务环境下确定负责一个给定用户的一个特定网络服务器。这些特定网络服务器是指其中分布有在具体业务环境下的用户或者更具体地说用户数据的主数据库。

因此，该UDS用作一个辅助数据库，包括用于从所述用作主数据库的特定网络服务器以及从网络解析域内的其它UDS重新获得用户标识符和必要的业务数据的装置。这个UDS还包括存储器，用于每个特定网络服务器的用户标识符和必要的业务数据，如果有的话。

能够在具体业务环境下确定负责通过某个用户标识符标识的给定用户的特定网络服务器的所述UDS还包括用于从业务请求器节点或者从解析域内的另一个UDS接收和处理业务请求的装置。而且，所述UDS还包括用于向所述业务请求器节点或者另一个UDS应答先前请求的装置。具体而言，该应答可以包括在具体业务环境下负责所述用户的特定网络服务器，或者如果存在冗余配置的话一个可能的网络服务器的列表，或者一个新的用户标识符和需要在另一个服务器内再次查询给定新标识符和可选地说明原因的指示。

该UDS适合于与使用相同或者不同协议的主数据库、其它外部数据库和业务请求器节点进行通信。因此，UDS还包括多个协议处理器模块中的至少一个和在某些情况下的一个协议鉴别器模块。

因此，本发明提供一个包括至少一个上述UDS的系统，尽管也可以包括多个。例如，如果考虑与现有业务请求器节点的位置有关的近似标准，不同的UDS可以负责不同的网络域段。在这个系统中，多个主服务器可以使用不同内容或者为了冗余目的使用相同的内容更新不同的UDS。

在一个实施例中，UDS可以用作一个预约定位器功能。在这个实施例中的UDS能够确定负责给定用户的原籍预约服务器(HSS)。这些HSS用作UDS的主数据库。在这个系统内的业务请求器节点例如用作一个查询或者一个服务呼叫状态控制功能。

本发明的另一个实施例涉及电信系统，其中为了更新可以将多个主数据库中的至少一个主数据库内的相关用户标识符提交给在至少一个主数据库上所知的一个特定UDS、一组UDS或者所有UDS。而且，多个主数据库中的至少一个主数据库被安排用于从在至少一个主数据库上所知的一个特定UDS，一组UDS或者所有的UDS接收UDS恢复优选选择。该系统还安排用于根据每个恢复优先选择来更新每个UDS。

本发明还提供一种在每个用户使用多个用户标识符的一个网络解析域内在不同的业务环境下识别一个用户的方法。该方法包括在用户分布服务器(UDS)内在一个具体业务环境下确定负责每个用户的特定网络服务器的步骤。该方法还包括：在UDS上从用作主数据库的特定网络服务器以及从该网络解析域内的其它UDS恢复用户标识符和必要的业务数据的步骤；和在UDS上存储每个特定网络服务器的每个用户所述用户标识符和必要的业务数据(如果有的话)的步骤。该方法还包括：接收并处理来自业务请求器节点或者来自解析域内另一个UDS的业务请求的步骤；和向业务请求器节点或者向另一个UDS应答一个预期响应的步骤。所述预期响应可以是在一个具体业务环境下负责所述用户的特定网络服务器，或者在存在冗余配置时一个可能的网络服务器的列表，或者一个新的用户标识符，具有在另一个服务器内再次查询所述新标识符是必需的的指示和可选地说明背后原因。

由于根据本发明由UDS提供的特殊灵活性，业务请求器节点可以是一个移动交换中心、一个信令网关、一个GPRS支持节点或者一个用于多媒体用途的应用服务器。该列表是以非限制性的方式示范性地列举的，决不打算限制本发明的范围。

附图说明

通过结合附图阅读说明书，本发明的特征、目的和优点将变得显而易见，在附图中：

图1图示一个普通的网络结构，说明用于本发明一个实施例的主和辅助数据库的结构。

图2基本地图示用于本发明至少一个实施例的在辅助数据库内每个用户的个人记录的内容。

图3a示意性地描述根据本发明的用户分布服务器内部结构的一个实施例。

图3b示意性地描述一个用户分布服务器内部结构的另一个实施例，其中在一个外部协议适应实体内处理多种协议。

图4基本地图示为了使用在图1的实施例中来自主数据库的内容更新辅助数据库而执行的一个示范性流程。

具体实施方式

下面描述在与用户标识符方案、结构和可应用业务无关的情况下允许在多个服务器之间灵活分布用户的装置、方法和系统的当前优选

实施例。

根据本发明的一个方面，在一个网路解析域内提供一个用户分布服务器(在下文中称作UDS)，用于在具体业务环境下接收对特定用户的业务请求有关的查询。该UDS被安排用作一个辅助数据库，它包括以每个用户为基础的多个用户标识符，每个用户标识符可以应用于一个具体的业务环境，并与寻址当前负责相应用户数据的特定服务器的一个服务器标识符相关。这些特定服务器被安排用作主服务器，从其将用户标识符和必要的业务数据下载到用作辅助数据库的UDS中。该UDS通过提供服务器标识符以进一步访问当前在可应用的业务环境下服务该用户的特定服务器，向任意一个业务请求器节点应答与查询一个特定用户有关的业务请求。

在图1中允许用户灵活分布的示范性结构图示了专用用户分布服务器可以如何负责某个网络域内的特定地理位置。例如，UDS-1和UDS-2可以分别负责网络域-2内的地理区域1和地理区域2。用户标识符可以根据不同的标准分布在这个网络域-2内的多个服务器中，其中为了清楚仅图示了服务器-1、服务器-2、服务器-3和服务器-n。这些服务器分别标注为14-20。所述服务器-1、服务器-2、服务器-3和服务器-n用作主数据库，从此主数据库中通过所述服务器-1的相应接口(P-11，P-12)、所述服务器-2的相应接口(P-21，P22)、所述服务器-3的相应接口(P-31，P-32)和所述服务器-n的相应接口(P-n1，P-n2)将用户数据下载到UDS-1和有可能下载到UDS-2。

主数据库和辅助数据库之间的分类简化了数据处理，允许在主数据库内容易地管理变化，并将在辅助数据库内进一步更新这些变化。在图4中图示了一个如何执行此更新的示范性实施例，其中初始假定为UDS-1已经存在网络内，操作和维护系统(22)已经启动一个新服务器(服务器-1)。在此假定下，服务器-1通过一个包括其自己的服务器-1标识符的诸如REGISTER(登记)的可应用协议操作将它的出现指示给UDS-1。UDS-1使用该服务器指示在一个诸如UPDATE_Req(更新请求)的可应用协议操作中请求更新所有的相关用户。一旦在服务器-1上接收到该请求，使用图4所示的可应用协议方法通过一个操作UPDATE_Ind(更新指示)提交合适的用户数据。此操作实际上可以代表某个信令流以提交服务器-1内的所有用户的用户数据。在更新UDS-1之后，在诸如服务器-1、新用户的主数据库内由操作和维护Q&M系统(22)执行的任意一个新的更新产生一个从服务器-1到UDS-1的自动更新。都包括新用户的标识符的用于a--用户的类似协议方法等更具体地可以使用例如所述操作UPDATE-Ind。

图4还图示了在假定上述情况已经出现的情况下如何在网络内引入另一个UDS(UDS-2)。UDS-2开始于操作和维护系统(24)，或者是其它的典型装置，并且已经或者最近被配置以获知它应当处理的目前存在的服务器。在上述假定的情况下，所述UDS-2请求使用上述在图4中用操作UPDATE_Req表示的类似指示和协议操作请求来更新所有相关用户。一旦在服务器-1上接收到请求，就使用必要的更新指示(UPDATE_Ind)执行一个类似于更新UDS-1的处理，直到下载了所有用户的标识符。假设通过服务器-1内的操作和维护系统(22)执行任意一个新的更新，例如一个新用户，启动一个从所述服务器-1到UDS-1和UDS-2的自动更新。

在图4中的另一个示范性的步骤考虑在上述情况下引入另一个服务器(服务器-2)。服务器-2开始于操作和维护系统(24)，或者通过其它的典型装置，并且已经或者最近被配置以获得必须更新的当前存在的UDS。然后，服务器-2通过广播可应用的协议操作，例如上述REGISTER操作，其中包括它自己的服务器-2标识符，将它的存在指示给UDS-1和UDS-2。然后，一旦从每个UDS接收到更新所有用户相关信息的相应请求，服务器-2启动相应的请求UDS的指示(UPDATE_Ind)。

作为上述更新程序的结果，一个UDS包括与在网络内或者在其控制下的网络区域内提供特定业务的所有服务器有关的信息，包括以每个用户为基础的相关被服务用户的标识符。因此，主数据库更新相关用户数据变化的UDS。而且，在存在多个UDS的解析域内，每个UDS可以维护根据某个标准直接从主数据库或者从另一个UDS或者从两者更新的冗余信息。例如，如图1所示，服务不同地理区域的用户分布服务器可以通过链路(P-00)相互提供所请求的信息。优选地，UDS可以自己联系一些特定服务器以在需要时提供与服务实体有关的更动态的信息。

为此，网络域内的服务器(服务器-1、服务器-2、服务器-3、服务器-n)从其自身预约(P-11、P-21、P-31、P-n1)网络域-2内的多个UDS中的至少之一(UDS-1)。此外，在存在另一个UDS(UDS-2)的情况下，两个UDS可以相互通信(P-00)以相互检验数据，或者为了可靠性的原因，或者仅仅因为它们负责不同的地理区域。

如图1所示，出现一个典型的流程，其中网络解析域例如网络域-1内的一个外部客户(26)向通常在另一个网络解析域例如网络域-2内的一个业务请求器节点发送一个消息(S-10)。所述消息例如可以是一个呼叫的一部分或者一个登记流程的一部分，一旦接收到，该业务请求器节点向一个特定UDS(UDS-1)发起一个查询(S-20)。可以通过诸如在发现阶段、在启动阶段或者通过配置执行的给定方法在业务请求器节点上指定所述UDS，用于处理与业务请求有关的查询。

接收到查询的UDS(UDS-1)通过检查其数据库记录来检查接收到的参数，即，用户和/或业务相关数据，UDS-1与在可应用的业务环境下负责特定用户的正确服务器交互。在这一方面上，图2图示根据本发明的一个方面一个UDS中内部数据库内容的一个解释性和非限制性的例子。图2图示一个特定用户可以具有不同的标识符。

一个UDS由请求与一个特定服务器的连接的实体来查询，所述特定服务器向特定用户提供业务。因此，该请求实体指示用户标识符和可选的其它数据，例如所请求业务的指示。一般来说，UDS数据库的行为可以通过定制行为来优化，例如，接受查询而不明确指示所涉及业务的事实，在这种情况下返回所有被存储的用户数据以便另一个节点解释这个结果。假设这个用户和业务相关信息可能非常快地改变，指示表示其有效性的参数，例如使用期限值(在下文中称作TTL)。而且，在多个服务器可以向一个特定用户提供业务的情况下，例如在冗余配置的情况下，可以指示可能的服务器列表。另外，在构建用户标识符以便在某个结构层次中包括的所有用户由一个特定服务器服务的情况下，查询的应答可以指示所述结构的层次。

然而，如果所指示的用户或者业务在该网络解析域内不存在，则UDS发送适当的错误。在此一个非常重要的方面是UDS查询如图1所示的外部数据库(S-25)以请求与诸如号码可移植性解析的某些入口有关的进一步信息的能力。这个外部数据库(在下文中简称为Ex-Db)可以具有与根据本发明一个方面的UDS类似的结构和类似的内容，或者可以具有其它的结构或内容。查询这个外部数据库的接口可以是在主数据库和辅助数据库之间使用的接口之一，也可以是一个与之不同的接口。

一旦该查询已经被内部或者外部地解决，UDS-1向业务请求器节点返回(S-30)一个相应的响应，其中包括合适的服务器标识符以进一步访问该合适的服务器。假设这些应答由业务请求器节点缓存，在应答内提供一个有效时间(即，上述TTL值)以优化该缓存。

而且，以不同的呼叫为基础，业务请求器节点可以访问(S-40)该合适的服务器，或者相应地发送(S-45)期望的响应给外部客户机以便该客户访问(S-50)该合适的服务器。

图1还图示安装有分别用于接收一个查询(S-20)和提供一个响应或应答(S-30)的第一装置(40)和第二装置(42)的UDS-1。UDS-1还安装有第三装置(44)，用于从服务器主数据库传送或恢复用户标识符和业务数据。

如上所述，UDS安排用于处理不同的协议，这些协议用于与用作主数据库的不同的特定服务器通信，用于与最终的外部数据库通信，和用于与多个业务请求器节点中的至少之一通信。因此，UDS安装有至少一个协议处理器模块(在下文中称作PHM)，这些模块能够处理这些不同通信协议中的至少一个协议。假设存在多个PHM，则需要一种协议鉴别功能以根据特定的协议基础来确定哪一特定PHM应当处理一个接收到的查询、应答或者其它消息。所述协议鉴别功能由如图3a和图3b所示的一个附加协议鉴别器模块(在下文中称作PDM)来执行，仅在存在多个PHM的情况下需要所述附加协议鉴别器模块。例如，在支持最好根据“域名服务器(DNS)”协议、“轻量级目录访问协议”(LDAP)、半径协议或者直径协议中的至少之一操作的电信协议的情况下，UDS(例如UDS-1或UDS-2)能够解释查询和提交响应。以非限制性的方式提及这些协议，仅仅是为了阐述包含一个用于支持若干协议的UDS的明显优点，这可以通过替换或者添加专用协议处理器模块并仅在协议鉴别器模块内进行修改来改变。

图3a图示包括几个PHM(29)(也称作1-3，m)和唯一一个PDM(30)的UDS(10)的优选实施例。本领域的技术人员将理解通过划分在一个所谓的协议自适应实体(32)(在下文中称作PAE)中集成的多个PHM(29)和PDM(30)可以实现类似的实施例。如图3b所示，可以在PAE上保存一个专用PHM，用于与UDS(10)的内部通信，其中还存在唯一一个专用PHM(34)。图3b还图示包含一个内部数据库(36)的UDS。

如果辅助数据库(即，UDS)在地理上更靠近信息的请求器(即，所谓的业务请求器节点(28))以加速解析处理，则可以获得其它的优点，尽管所述优点不是一个基本的特征。

不考虑地理位置，从诸如UDS的辅助数据库请求第一查询，而主服务器仅在成功应答第一查询的情况下进行进一步的查询。这一程序可以有效地避免由于查询不存在的用户通常称作“业务拒绝”(DOS)攻击所导致的主数据库过载。具有在网络运营商内部的部署或者在一个信任环境下，例如在不同国家运营共用某个基础设备的合作伙伴，这种解决方案不需要与运营商网络内任何其它标准节点不同的特殊安全保护。

图1所示的结构以及UDS的上述基本特征和优点适合于在根据第三代合作项目(3GPP)操作的电信系统内使用。更具体地说，该UDS可以如在附录F的所述3GPP的技术规范(TS)23.228中所述操作为业务定位器功能(SLF)。

如在所述TS中描述的，因为在运营商的网络内通常存在多个HSS，所以在登记和会话或呼叫建立过程中必须识别出原籍用户服务器(HSS)，所述原籍用户服务器当前保存有用户特定数据，例如用户位置或鉴权参数。一个查询呼叫状态控制功能(I-CSCF)节点和服务呼叫状态控制功能(S-CSCF)节点需要识别一个特定的HSS，从而获得负责一个给定用户的HSS的实际名称和/或地址。更具体地说，I-CSCF节点在登记和会话或呼叫建立过程中需要HSS识别，而S-CSCF节点仅在登记过程中需要这样的HSS识别。为了简化，本说明书仅涉及一个呼叫状态控制功能(CSCF)节点，所述解释同样可以应用于查询或者服务CSCF。

在这种情况下，分布有用户的不同HSS被安排用作主数据库，与先前在图1中所示的主数据库相同，在本说明书中称作服务器-i(i从1到n)，而CSCF节点被安排用作上述服务请求器节点(28)。根据本发明，上述UDS(10)然后可操作为用作一个辅助数据库的所述业务定位器功能(SLF)，用于从CSCF接收查询，与负责一个给定用户的HSS交互，并将结果应答给所述CSCF。

因此，安排用作SLF的UDS包括至少一个协议处理器模块，用于处理从CSCF节点接收到的查询，并向该CSCF节点应答该查询。而且，假设适合于SLF和HSS之间通信的协议不同于SLF和CSCF之间的通信协议，则安排用作SLF的UDS包括另一个协议处理器模块(PHM)，用于处理更新或者与HSS的下载。如已经描述的，在使用多个PHM的UDS中包括一个协议鉴别器模块(PHM)。

例如，CSCF和UDS之间的接口包括一个用于从CSCF查询预约定位器的操作和一个用于将HSS地址提供给CSCF的响应，所述UDS安排用作一个SLF。具体地说，通过发送一个诸如SLF_QUERY的操作，CSCF指示HSS寻找的用户标识(在登记或者会话或呼叫建立过程中接收到的)。然后，通过返回操作SLF_RESP，用作SLF的UDS用HSS名称和/或地址进行响应以便CSCF继续查询给定的HSS。可选择地，操作SLF_RESP可以指示一个新的用户标识符和必须进行另一次查询的指示。这个指示可以包括新查询的地址和原因的说明，或者可以仅是新查询的原因。前面的指示类型例如用于号码可移植性，而后者暗示必须通过查询实体来发现新服务器的地址。假设CSCF和SLF之间的上述示范性DNS协议也使用在SLF和HSS之间，则操作SLF_UPDATE_REQUEST可以用于从每个特定HSS请求用户数据。然后，操作SLF_UPDATE用于在这个HSS中出现变化时随时从该HSS更新用作SLF的UDS。

在登记流程期间，可选择地，查询CSCF(I-CSCF)可以将HSS地址转发给一个服务CSCF(S-CSCF)以简化S-CSCF寻找HSS的行为。在所接收的用户标识符并不对应于任意一个已知用户时，返回对应的错误。

在示范性地使用DNS协议的情况下，尽管也可以使用其它的协议，例如直径或者半径协议，诸如用作SLF的UDS的辅助数据库从诸如HSS的主数据库的更新包括图4所示的专用方法。

图4中的SLF_UPDATE_REQUEST操作(即，UPDATE_Req)提供为查询实体指示在所有或者一组标识符空间上请求特定操作的方法。所述操作包括用于为一个或一组用户请求“所有用户数据”或“特定用户数据”的方法。例如，仅电路交换(在下文中称作CS)接入相关数据，或者仅分组交换(在下文中称作PS)接入相关数据，或者仅互联网协议多媒体(在下文中称作IM)相关数据。所述操作还包括用于为一个或一组用户请求与业务网络相关的“一组特定数据”的方法，所述业务网络实际上可能包括一组业务。而且，所述操作还包括用于请求一种特定类型的标识符的方法，例如和以非限制性的方式，E.164号码或SIP_url。另外，所述操作还包括用于仅请求属于一个特定标识空间的标识符的方法，例如仅仅到acme.land.land域的标识符。

相应地，SLF_UPDATE响应操作(即，图4中的UPDATE_Ind)提供用于向查询实体指示为一个特定用户或者为一组用户更新“所有用户数据”或者仅“特定用户数据”的方法。

另一方面，如上面参考图4所描述的，就用于一个、一组或者所有用户的唯一业务、一组业务或者所有业务来说，将要请求更新的实体范围以及被有效更新的实体范围在这种情况下也具有可应用性。

总的来说，SLF_UPDATE_REQUEST操作(即，图4中的UPDATE_Req)提供方法以指示：

-用户范围，可以是一个用户、在某种分组条件下的一组用户或者所有用户。

-业务范围，可以是一个特定业务、一组业务或者所有业务。

-将要查询的实体范围，可以是一个实体，在某种条件下的一组实体，即组播，或者所有实体，即广播。

相应地，SLF_UPDATE响应操作(即，图4中的UPDATE_Ind)提供方法以指示：

-业务范围，可以是一个特定业务、一组业务或者所有业务。

-将要更新的实体范围，可以是一个实体，在某种条件下的一组实体，即组播，或者所有实体，即广播。

如上面参考图4所预期的，当在网络内引入一个用作SLF的新UDS时，向提供业务的所有节点，也就是说向所有的主数据库发起一个查询，即，向诸如HSS的主数据库广播。另一方面，从网络中移除一个诸如UDS的查询实体可以继之以一个向所有协同操作的主数据库的告警消息OUT_OF_SERVICE_like，或者，可选择地，在主数据库上提供附加的与存在有关的机制ACTIVITY_TEST_like以被定期地调用。根据本发明在从网络中移除诸如HSS的任意一个主数据库的情况下使用一个与上述机制OUT_OF_SERVICE_like或者相应的ACTIVITY_TEST_like的相关机制类似的方法。与用户数据的引入、移除或者修改有关，上述UPDATE_Ind包括与明确地注释更新类型有关的合适的指示符数值。

即使在主数据库和辅助数据库上有意地和优选地执行更新请求以及更新本身，也可能出现辅助数据库UDS并不知道最新请求的某些特定用户数据的情况。在这种情况下，由于UDS知道保存该数据的另一个主数据库或辅助数据库，从接收机UDS向另一个UDS或者向另一个外部数据库发出一个新的查询。这对于号码可移植性的支持特别有用，将在本说明书中进一步为此提供一个附加的说明性的使用情况。

一个特别感兴趣的方面是根据本发明用作一个SLF和因而在登记阶段与CSCF交互工作的UDS的最佳行为。参考图1中的接口和实体进行下述解释。首先，CSCF(业务请求器节点)接收一个登记请求(S-10)，并必须启动一个用户数据位置的查询。然后，CSCF向SLF(UDS-1)发送一个操作SLF_QUERY_like(S-20)，并包括在登记请求中所述的用户标识。此时所使用的协议并不重要，因为根据本发明的UDS可以以如图3a所示的方式安装有多个协议处理器模块(PHM)，例如适合于与DNS、半径、直径或者任何其它适当的协议通信。而且，为此可以将图3b中的上述协议适配实体(32)插入在CSCF和UDS之间。第三，依然参考图1，SLF(UDS-1)查看如图2所示的它自己的数据库内容，例如所查询的用户标识。第四，再次参考图1，SLF(UDS-1)用可以发现用户数据的HSS名称应答(S-30)。第五，CSCF优选地直接向HSS(服务器-3)发起一个查询(S-40)。作为上述第五步骤的替代步骤和以某种呼叫为基础，CSCF(业务请求器节点)(28)可以继之以将查询结果(S-45)返送给发出登记请求的外部客户(26)，用于所述外部客户查询(S-50)合适的HSS(服务器-3)。

除了针对在一个CSCF实体上接收一个登记请求的情况已经描述的之外，从根据本发明的一个UDS预见到一个类似的方法和行为，用于一个参与会话或呼叫建立的I-CSCF节点的情况。

根据本发明将一个UDS用作一个SLF的另一个优点是如何轻易地执行向外部数据库(38)的特定查询，并因而在下述两种情况下支持号码可移植性查询：在一个供方(donor)网络上，和在一个始发网络上。

在一个供方网络上，UDS概念可以用于在一些情况下处理号码和名称可移植性。如当前在一些情况下规定的，可能会发生一些流程进入当前并未保存用户预约的网络的I-CSCF。当这样一个I-CSCF查询SLF时，必须在这个步骤中应用一个鉴别以避免这些来自一个进入用户的查询可以进入这个网络的HSS。参见图1，I-CSCF(业务请求器节点)接收一个INVITE请求(S-10)，并必须查询用户数据的位置。I-CSCF向SLF(UDS-1)发送一个SLF_QUERY(S-20)，作为参数包括先前在INVITE请求中接收到的用户标识。SLF(UDS-1)在它自己的本地数据库内查找所查询的用户标识。一个图2中的标识符“2.2.3.4.9.e164.arpa”的示范性入口说明这个用户使用一个作为服务器标识符的“Forward_query_to_Ex_Db”型的指示进入。然后，SLF(UDS_1)通过接口S-25查询如图1所示的可移植性数据库(外部数据库)(38)，并从所述可移植性数据库获得将用于联系该用户的标识符。随后，SLF(UDS_1)使用一个地址或者一个用于抵达所述用户的URL应答(S-30)I-CSCF(业务请求器节点)。I-CSCF现在可以命令将该INVITE消息改发到用户已经进入的网络。

另一方面，UDS还可以有利地用于解决在始发网络内的号码可移植性，其中实际上从一个服务呼叫状态控制功能(S-CSCF)实体执行查询。在这一方面上，相同的原理应用于从一个S-CSCF到一个用作SLF的UDS的查询以及从上面指出的I-CSCF的查询。

许多其它情况可以有利地使用根据本发明的UDS。例如，所述UDS可以为一个包含其自己的HSS的虚拟网络运营商提供实质支持，在作为一个相应的网络解析域寻址的一个非虚拟网络内通过用作SLF的UDS来识别所述自己的HSS。

根据本发明，一个UDS可应用性的另一个例子是在外部互联网协议多媒体业务提供器(在下文中称作IMSP)内用户的登记。可以遵循与上述相同的原理使用UDS概念，但是在这种情况下，用户指示的联系名称可以用于识别IMSP提供业务的领域。换句话说，原籍运营商用作一种代理，即，根据这个用户的任意优先选择提供用户的联系地址，或者在号码或者名称可移植性的情况下提供改发业务的业务提供器。

当考虑在一个IP移动性管理(IPMM)结构中通过HSS和应用服务器(在下文中称作AS)之间的所谓Sh接口的查询和响应时，发现另一种有利的使用情况。所述应用服务器必须访问在HSS内存储的用户数据，但是如同I-CSCF或者S-CSCF的情况，让它们知道所有用户的所有HSS的地址是不现实的。因此，根据本发明的相同UDS看起来也可以应用于这种情况，其中为了根据每个用户和/或业务的请求将查询从AS改发到正确HSS的目的，可以将一个诸如所述UDS的实体放置在HSS和AS之间。

上面已经确定了使用的优点和不同的情况，它们中的大多数涉及最新一代的无线系统，尤其考虑它们与最新的多媒体和互联网相关业务的连通性。然而，还存在另一种UDS在典型的GSM或UMTS标识符上的有利应用。可以利用相同的原理使用该UDS的概念，但是在这种情况下，用户指示的联系名称根据特定的消息流可以是IMSI或者MSISDN。这可以以将这些号码映射成可路由的名称为基础来进行，如已经在ENUM协议中推荐的，它将E.164号码映射到可路由的名称。在这种特定情况下，参考图1，业务请求器节点所表示的查询实体是移动交换中心服务器(MSC)、网关MSC服务器(GMSC)、服务GSM服务器节点(SGSN)、或者网关GSM服务器节点(GGSN)。以举例而非限制性的方式列举这些实体。而且，在这种典型的GSM或UMTS环境下，HLR和HSS是用服务器-1至服务器-n表示的主数据库。这些业务请求器节点也可以是一个信令网关、一个GPRS支持节点、一个开放业务结构业务性能服务器、一个多媒体消息服务器或者一个CAMEL网关服务器。

尽管已经在附图中图示和在上述优选实施例的详细描述中描述了本发明的优选实施例，将理解本发明并不限制于所公开的实施例，在不脱离由权利要求书阐述和定义的本发明范围的情况下，能够进行多种重新配置、修改和置换。

Claims

1.一种在一个网络解析域内的用户分布服务器(UDS)，包括用于在不同业务环境下识别用户的以每个用户为基础的多个用户标识符，所述UDS被安排用于确定在一个具体业务环境下负责所述用户的一个特定网络服务器，其特征在于，所述UDS用作一个辅助数据库，包括：

(a)装置，用于从用作主数据库的特定网络服务器中以及从网络解析域内的其它UDS中恢复用户标识符和必要的业务数据；

(b)存储器，用于每个特定网络服务器的用户标识符和必要的业务数据，如果有的话；

(c)装置，用于接收和处理来自一个业务请求器节点或者来自该解析域内另一个UDS的业务请求；和

(d)装置，用于应答所述业务请求器节点或者另一个UDS：

(d1)在一个具体业务环境下负责所述用户的特定网络服务器；或

(d2)如果存在冗余配置，一个可能的网络服务器的列表；或

(d3)一个新的用户标识符，具有在另一个服务器内对所述新标识符的另一次查询是必需的指示和可选地指示背后原因。

2.权利要求1的用户分布服务器(UDS)，其中装置a)包括：装置，用于在指示上和从主数据库或另一个UDS中将有关更新用户标识符和/或必要的业务数据的需要通知所述UDS。

3.权利要求2的用户分布服务器(UDS)，其中装置a)包括：装置，用于在打算用作主数据库的所有网络服务器中登记所述UDS和从这些所有网络服务器中撤销登记。

4.权利要求3的用户分布服务器(UDS)，其中装置a)包括：装置，用于指示为所有被服务的用户、为一个特定组的用户或者仅为一个特定用户恢复用户标识符和/或必要的业务数据所用的恢复优先选择。

5.权利要求4的用户分布服务器(UDS)，其中装置a)还包括：装置，用于为下列组之中的至少一个组恢复用户标识符和/或必要的业务数据：

(a)多个有效标识符类型之中的一种特定类型的标识符；

(b)在特定域内使用的标识符；和

(c)属于一个域内特定标识空间的标识符。

6.权利要求5的用户分布服务器(UDS)，其中每个特定网络业务的对临时有效性敏感的数据包括一个“使用期限”(TTL)参数，用于确定从主数据库恢复数据的需要。

7.权利要求5的用户分布服务器(UDS)，还包括至少一个协议处理器模块，并且在存在一个以上的协议处理器模块的情况下还包括一个协议鉴别器模块，每个协议处理器模块负责一个特定的电信协议。

8.权利要求7的用户分布服务器(UDS)，其中包括至少一个“域名服务器(DNS)”相关的协议处理器模块。

9.权利要求7的用户分布服务器(UDS)，其中包括至少一个“直径”相关的协议处理器模块。

10.权利要求7的用户分布服务器(UDS)，其中包括至少一个“轻量级目录访问协议(LDAP)”相关的协议处理器模块。

11.权利要求7的用户分布服务器(UDS)，其中包括至少一个“半径”相关的协议处理器模块。

12.权利要求7的用户分布服务器(UDS)，还包括协议和处理装置，用于使用不打算用作主数据库或者用作另一个UDS的一个外部数据库来解决业务请求。

13.权利要求12的用户分布服务器(UDS)，其中所述外部数据库是一个号码可移植性数据库。

14.一种电信系统，包括权利要求1的用户分布服务器(UDS)，其特征在于，可以为了更新将多个主数据库之中的至少一个主数据库内的相关用户标识符提交给在所述至少一个主数据库上所知道的一个特定UDS、一组UDS或者所有的UDS。

15.权利要求14的电信系统，其中多个主数据库之中的至少一个主数据库被安排用于从在所述至少一个主数据库上所知道的一个特定UDS、一组UDS或者所有的UDS中接收UDS恢复优先选择，并且被安排用于根据每个恢复优先选择来相应地更新每个UDS。

16.权利要求15的电信系统，其中UDS起着预约定位器功能(SLF)。

17.权利要求15的电信系统，其中用作主数据库的多个特定服务器之中的至少一个特定服务器是一个原籍预约服务器(HSS)。

18.权利要求15的电信系统，其中用作主数据库的多个特定服务器之中的至少一个特定服务器是一个存在服务器。

19.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个询问呼叫状态控制功能(I-CSCF)。

20.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个服务呼叫状态控制功能(S-CSCF)。

21.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个移动交换中心(MSC)。

22.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个信令网关。

23.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个GPRS支持节点。

24.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个打算用于多媒体相关用途的应用服务器(AS)。

25.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个开放业务结构业务性能服务器。

26.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个多媒体通信服务器。

27.权利要求15的电信系统，其中多个业务请求器节点之中的至少一个业务请求器节点是一个CAMEL网关服务器。

28.权利要求15的电信系统，其中多个用于解析的外部数据库之中的至少一个外部数据库是一个域名服务器。

29.权利要求15的电信系统，其中多个用于解析的外部数据库之中的至少一个外部数据库是一个以轻量级目录访问协议(LDAP)为基础的数据库系统。

30.权利要求15的电信系统，其中多个用于解析的外部数据库之中的至少一个外部数据库是一个号码可移植性数据库。

31.一种网络解析域内的方法，其中使用以每个用户为基础的多个用户标识符来在不同业务环境下识别用户，并且其中权利要求1中的用户分布服务器(UDS)被配置用于确定在一个具体业务环境下负责每个用户的一个特定网络服务器，该方法的特征在于，所述方法包括步骤：

(a)在UDS上从用作主数据库的特定网络服务器和从网络解析域内的其它UDS中恢复用户标识符和必要的业务数据；

(b)在UDS上存储每个特定网络服务器的以每个用户为基础的用户标识符和必要的业务数据，如果有的话；

(c)接收和处理来自业务请求器节点或者来自该解析域内另一个UDS的业务请求；和

(d)应答业务请求器节点或者应答另一个UDS：

(d1)在具体业务环境下负责所述用户的特定网络服务器；

(d2)如果存在冗余配置，一个可能的网络服务器的列表；

或

(d3)一个新的用户标识符，具有在另一个服务器内对所述

新标识符进行另一次查询是必需的指示和可选地指示背后原因。

32.权利要求31的方法，还包括步骤：在指示上和从主数据库或另一个UDS中将有关更新用户标识符和/或必要的业务数据的需要通知至少一个UDS。

33.权利要求32的方法，还包括步骤：在打算用作主数据库的所有网络服务器中登记一个UDS和从这些所有网络服务器中撤销一个UDS的登记。

34.权利要求33的方法，还包括步骤：向至少一个主数据库指示为所有被服务的用户、为一组特定用户或者仅为一个特定用户恢复用户标识符和/或必要的业务数据所用的UDS恢复优先选择。

35.权利要求34的方法，还包括步骤：从在至少一个主数据库上所知道的一个特定UDS、一组UDS或者所有的UDS中接收UDS恢复优先选择，并根据每个恢复优先选择从所述至少一个主数据库中相应地更新每个UDS。