CN1453956B

CN1453956B - 电信网络的方法和结构

Info

Publication number: CN1453956B
Application number: CN031225934A
Authority: CN
Inventors: A·波维达德米格尔; M·罗伦佐赫尔南德斯; J·荣松; A·艾利松; I·贝里; L·延森
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-04-25
Filing date: 2003-03-13
Publication date: 2010-05-12
Anticipated expiration: 2023-03-13
Also published as: GB2387990B; JP2003333182A; CN1453956A; US20040039807A1; SE0201287D0; KR20030084582A; KR100989479B1; GB0305838D0; ITMI20030818A1; ITMI20030653A1; GB2387990A; JP4088549B2; DE10311074A1

Abstract

本发明涉及一种在具有多个服务供应商和服务发起商的通信网中用于提供与不同服务相关的不同数据整合的装置和方法。根据本发明的该系统具有包含用户和订户信息的公共订户/用户数据库(300)和订户/用户数据记录(803)。订户/用户数据记录包括：至少一个标识订户和用户的标识域(805，810)，以及至少一个指定至少一个从服务网(200)提供的多种服务中选择服务的服务域(635，640)，其中通过用户或订户选择至少一个选择服务。至少在所述至少一个服务域上提供与订户/用户相关分支数据的链接以及该分支数据存储在公共订户/用户数据库以外。

Description

电信网络的方法和结构

技术领域

本发明一般涉及通信网络中的数据分布领域，尤其涉及与具有多个服务供应商以及服务发起商的通信网络中不同服务有关的不同数据的整合。

背景技术

诸如移动电话网络(PLMN)，固定电路交换网络(PSTN)以及数据通信网络的传统通信网络已经成为独立的系统。电信网路已经具有垂直整合的特征，即意味着应用和服务也与传输技术的限制密切相关。例如移动系统GSM，提供了一套服务和应用，他们的表现，好处以及限制，至少在很大程度上，受制于通信技术。固定电话网路(PSTN)已经提供了一套不同的服务和应用，密切链接于系统中所使用的通信技术，以及服务的使用和表现常常不同于PLMN中的类似服务。与终端用户看似类似的服务，由于同样与技术限制密切相关，可能在不同网络中被相当不同地实施。

服务和通信技术之间的紧密链接关系已经另外成为以下事实的一个重要原因，即网络运营商也已经成为终端用户服务的主要供应商。为了提供服务，完整的网络知识和访问已经是至关重要了。图1描述了一种垂直整合的网络。

对更多不同种类的服务，综合服务以及允许服务供应商之间竞争的需求正在增长。与此同时，电信和数据通信网络已经发展。新一代通信系统整合了诸如蜂窝电话和基于IP数据通信的不同通信技术。新的系统经常被描绘为水平分层的结构，例如，接入层，核心层以及服务层。在图2中描述了一种分层的通信系统。在这种情形下，已有的以及新的竞争者，例如，运营商，服务供应商，服务发起商，内容供应商以及应用(互联网)服务供应商，相互协作以为终端用户提供大量的不同服务。在服务层中提供和管理服务，该层形成了网络，即服务网200。服务网200与核心网210互联，其典型地具有IP结构并提供传输和交换功能。从核心网它可能与多个接入网进行通信。接入网可能具有不同种类，包括具有诸如GSM或UMTS的不同容量和特性的蜂窝系统220，固定电话(PSTN)230，基于IP的数据通信240，以及有线电视250。为了使得竞争者相互协作来为终端用户提供服务，服务网200优选地具有开放式结构，例如开放服务结构，OSA和开放接口，例如OSA应用程序接口，API。可以从爱立信评论，No.2，2001中找到垂直整合网络和分层网络之间的比较。

提供的服务优选地根据终端用户的个人选项，接入方法(移动系统，固定系统，等等)，接入终端特性(例如，移动终端的容量)，预约类型等等来定制。尽管例如，接入方法将影响服务网中服务的执行，但是服务执行的许多部分将类似或一样，而不考虑例如接入方法。因此，服务供应商可能使用相同“建筑块”来构建适合于不同终端用户的不同服务。建筑块可能例如是目录服务，消息服务或定位工具。服务网络的开放性以及使用用于不止一项特定服务的建筑块的可能性，在吸引象运营商，服务供应商以及服务发起商的竞争者以及终端用户分别开发和使用新的服务方面被认为是关键因数。

提供服务的范围从诸如在两个移动用户之间发起呼叫的基本电话服务到包括不同接入网，一个或多个互联网应用以及安全服务的综合服务.综合服务可能包括使用定位，消息以及电子商务的服务.基于定位的服务可能例如在靠近终端用户附件查找旅馆位置.这样的一种服务可能包括通过移动定位中心使用移动系统的定位工具，在一特定区域内找到旅馆并将其分类的一个或多个互联网应用，将信息转换为适合于在终端用户终端上显示格式的应用，例如，WAP，以及便于对房间进行安全预订和付费的电子商务应用.另一个综合服务的实例与称为的车队管理服务有关.在用户选择组中的每个单独用户的定位信息呈现给该组的一个或全部用户.通过定位系统来提供每个用户的位置.一个用户可能以这种方式得到该组中所有其他用户位置的升级信息.这种类型服务可能有利用于例如管理运输车辆的车队.为了提供和执行这样一种服务，在不同服务系统之间需要提供大量的接口，以及因为不同服务发起商可能提供不同的服务系统，服务网的需要以及具有开放结构和标准化接口的服务网应该是明显的.

大量服务供应商，发起者等等在服务网中提供大量的服务，终端用户在不同接入网中分布，随着对个性化服务和不同形式付费的需求，正确的终端用户数据和迅速访问至关重要数据的需求也将增长。在当今网络中，终端用户有关的数据在整个网络中分散开来，在许多情况下，大量终端用户数据被存储和使用。分散存储数据和大量的数据使得搜索和升级终端用户信息变得困难。在现有的具有分散终端用户数据的网络中，这将非常难以实现并确保综合服务稳定的功能。分散终端用户数据的一个缺陷可能通过终端用户结束对一个综合服务预订的实例来例举，其中例如依靠一个定位服务。所有与用户有关的数据然后从提供定位服务的服务系统中删除。该终端用户可能仍旧想使用其他使用定位的综合服务，但是终端用户的有关数据已经从提供定位服务的服务系统中删除，这些其他的综合服务将缺少至关重要的有关终端用户数据。该综合服务可能在某些情况下不可能执行，以及在其他情况下，如果终端用户数据仍旧可能从网络的某些地方重新获取，综合服务的执行也将被延迟和/或导致业务负荷增加。

而且，用户可能被通过依赖于服务的不同ID，名字或别名来标识。例如，用户电话号码可能被传统电话服务所使用，电子邮件地址被基于电子邮件通信服务所使用以及用户别名被基于日历的服务使用。综合服务可能需要通过不同标识方式来访问用户数据，如果用户数据被分散，那么所有综合服务不得不存储和升级所有用户标识。

与现有处理终端用户数据有关的问题可能总结如下：

a)与服务有关的终端用户数据不能立即被访问，以及访问全部终端用户数据可能非常困难和消耗时间，

b)获得一种服务系统如何与另一种服务系统相关的信息并不容易，因此如果例如，终端用户数据被改变，将不知道其他服务系统是如何受到影响的。

c)终端用户数据的分布以及缺少不同服务系统之间关系的知识相当地消弱了数据一致性并增加了系统的业务负荷。

发明内容

针对问题是，在提供综合服务和/或多种服务的服务网中，提供一种适用于存储和访问终端用户和订户数据的方法，系统以及存储实体，以便确保立即访问数据并保持数据的一致性。

该问题通过权利要求1所定义的系统，根据权利要求15的数据记录，权利要求35中所定义的方法，以及权利要求40和41中所定义的REF和计算机程序产品来解决.

根据本发明的一个实施方案的系统提供了公共订户/用户数据库，和具有用户和订户信息的订户/用户数据记录。该订户/用户数据记录包括：至少一个标识一个订户和用户的标识域；至少一个指定从服务网中提供的多项服务中选择至少一项服务的服务域，其中至少一个选择服务通过用户或订户选择。至少在所述至少一个服务域上适合用于提供与订户/用户有关分支数据的链接，其中的分支数据存储在公共订户/用户数据库以外。因此，公共订户/用户数据库以及订户/用户记录在服务网中提供了方便用于访问用户和/或订户数据的单一访问节点。

根据本发明进一步的实施方案，订户/用户数据记录包括至少两个服务域：一个服务预订域，用于指定订户可能获得的第一组服务，其中第一组服务中的服务从服务网提供的所述多个服务中选择；以及至少一个服务激活域，每个服务激活域指定通过用户激活从第一组服务中选择的服务。服务预订域和/或服务激活域适合于提供与订户/用户有关分支数据的链接，其中分支数据存储在所述公共订户/用户数据库以外。

根据本发明，适合用于在服务网中存储和保持用户和订户数据的数据记录包括：至少一个标识一个订户和用户的标识域；以及至少一个服务域，指定至少一个从服务网提供的多个服务中选择的服务，其中至少一个选择服务通过用户或订户来选择。至少在所述至少一个服务域上适合用于提供到订户/用户有关的分支数据的链接，以及该分支数据存储在公共订户/用户数据库以外。

由于本发明，公共订户/用户数据库以及用户数据记录，籍此提供一种用于在服务网中访问用户和订户数据的单一访问节点。因此，确保了快速访问用户数据，由于仅仅通过该单一访问节点来访问，以及可能增加，升级或删除用户数据，可能实现数据一致性。

根据本发明一个实施方案的方法包括步骤：

-访问服务网中上述系统和数据记录所提供的单一访问节点；

-从该单一访问节点请求读和/或写数据，

-通过单一访问节点搜索用户数据记录或变换为用户数据记录。

根据本发明的方法提供的一个优点，即优选地所有用户/订户数据的请求在服务网中指向一个位置，即单一访问节点。

本发明提供的另一个优点，即与分支数据的链接和请求访问分支数据的信息由根据本发明的系统提供，根据本发明使用的方法用于搜索所述数据。

定义

服务网(SN)-对应于通信系统中水平分层视图的服务层。节点，以及多个服务系统，考虑将提供终端用户服务的必要作为服务网的部分。确切地，考虑哪一个节点属于该服务网将依赖于实施。一定节点可能也属于不止一个层/网。

服务系统-提供服务或部分服务的系统。该服务系统典型属于服务网。服务系统可以使用(与通信)其他服务系统为终端用户提供特定的服务。服务系统可能提供一种或多种不同的服务，或一组服务。

综合服务-需要包括两个或更多服务系统的服务为终端用户提供特定的服务。

附图说明

上述列举的本发明的特征和优点将参考附图在下面更加完整地详细描述，这里全文中相似的参考数字参照相似的单元，其中：

图1是传统的，垂直整合网络的示意图；

图2是包括服务网的水平分层网络的示意图；

图3是本发明使用的公共用户/订户数据库的示意图；

图4是本发明单一访问节点的示意图；

图5示例了本发明基本实体之间的关系；

图6根据本发明的用户数据模型的示意图；

图7根据本发明使用用户数据模型的一个实例；

图8是根据本发明的用户数据记录的示意图；以及

图9是示例根据本发明的方法的示意图。

具体实施方式

现在将参考附图来描述本发明的实施方案。

本发明通过在服务网中为终端用户相关数据提供单一访问节点(SAP)来解决由于终端用户相关数据在整个互联网中分布引起的问题。在最高等级SAP上包括公共订户-用户数据库(CSD)以及数据记录存储在CSD内。数据记录存储用户相关数据并提供与存储用户相关数据的其他记录的链接。相互作用形成综合服务的不同服务系统之间的相关性优选地也存储在CSD中。CSD从服务网200接入并典型地保留在服务网200中。

在图3中，例举了CSD的作用。多个服务系统典型访问的用户或订户相关数据存储在CSD300中。而且，链接也存储在CSD300中，该链接将存储在CSD300中的终端用户数据与没有存储在CSD300中的终端用户相关数据链接，称为分支数据的数据，典型地，对于一项服务，或一组服务是特定的，并且仅仅对于特定服务系统来说是相关的。服务系统A310，服务系统B320以及服务系统C330是提供一项或一组服务的服务网200中系统的实例。链接A340，链接B350以及链接C360示例了CSD300中的数据记录，并提供与分支数据的链接或参照。公共用户和订户数据不在服务系统A310，B320或C330中复制，但是存储在CSD300中。因此，确保了数据一致性。

在综合服务的情况下，需要使用不止一个的服务系统，例如，服务系统B320以及C330，两个系统B和C之间的相关性存储在CSD300中，这通过链接B+C370来示例。在一种实现中，服务系统A能够例如提供目录服务，服务系统B定位移动终端以及服务系统C可以是用于查找城市中的旅馆，出租车以及饭店的互联网应用。服务系统B和服务系统C将然后必须相互作用为终端用户提供基于位置的服务。

在一种实现的服务网中，典型地，服务系统的数量将相当的大于这里所示例的，以及系统之间的相关性和相互作用可能包括多于两个的系统。因此，上述的实例应该认为是非限制性的。不管提供服务的系统数量如何以及这些系统之间的综合相关性，公共用户相关数据并不复制。因此，确保了数据的一致性。下面将详细描述存储在CSD中的数据记录结构以及使能数据一致性。

最现实地，CSD将是非常巨大的数据库，由于它将必须包含用于使用服务网提供多项服务的终端用户的用户相关数据.这可能通过使用图4中所示例的分布式数据库来处理.CSD300的数据被分割为几个包括在不同单元中的数据库400.CSD索引表410在数据库400中隐藏数据的内部分布.CSD索引表410可能存储在包括一个数据库的一个单元中或分离单元中.数据库400和CSD索引表410连接到CSD前端420，该前端与存储在数据库400中的数据记录相合并，是SAP430的一种实现.CSD前端420接收所有的数据请求，在图中用箭头示例，并通过使用CSD索引表410来搜索数据库400的数据.从外部CSD300将被认为是具有访问节点的数据库，但是在内部，可能使用大量的分离数据库400.分布式数据库的详细结构在本领域中是已知的，所以从本发明描述中省略.应该理解这里描述的实体被认为是逻辑实体.正如所描述的，数据库可能是分布式的并在物理上不同的单元中被提供，而且其他诸如CDS前端420和CSD索引410表的实体可能以许多不同方式实现，包括分布于物理上分离的单元中.术语单一访问节点SAP应该以一种总体方式理解，在服务网中这意味着是用于终端用户相关数据的逻辑访问节点.在CDS前端420一种实现中，需要能够处理大量同时的访问，以及不同方式的访问，以及包括例如通过使用IP-地址，HTML-地址，以及E.136-地址或通过URL来访问的方法.

存储在CSD300中的用户相关数据构建于三个基本实体周围。这三个实体，订户，用户以及服务，他们的关系在图5中所示例。实体订户510预订一组或更多组或一包或更多包服务网所提供的服务525。订户510拥有一个或更多用户505。用户505积极地利用服务520。用户可能仅仅使用属于订户510预订的该组服务525中的服务。用户505将总是必须属于一个订户510。订户510将总是拥有一个或更多用户505。在许多情况下，订户510和用户505将是相同的人，但是对于例如商业订户来说，订户可能是公司以及用户将是该公司的雇员。

在总体水平上，根据称为用户数据模型的数据模型构造标识用户，订户以及服务的数据和这些实体之间关系的定义。用户数据模型UDM，包括实际用户相关数据和服务相关数据以及终端用户预订服务。在服务网中模型也作为关键单元，负责通过保持与分支数据库的参照可搜索服务中的用户前后关系并来管理用户。在本发明中，存储在CSD300中的终端用户相关数据根据用户数据模型的原理来构造。产生的数据记录称为用户数据记录UDR，其存储在CSD300中。分支数据库的参照对应于从CSD300的记录到存储在系统A，B和C的用户相关数据部分的链接340，350，360，该系统用于提供服务310，320，330。UDR也可能包括与其他类型数据的链接，例如，可获取服务和他们的特性的信息。

用户数据模型原理将参考图6描述。用户数据记录，UDR将根据UDM的原理构造。存储在CSD300中的数据结构必须仔细设计，以避免数据的内部复制，以最逻辑的方式提供与提供服务和保持必须数据的系统的正确链接。数据在逻辑上分组成对象，该对象具有订户，用户和服务的关键对象，对应于上述的主实体。图中箭头表示不同对象之间的链接。依赖于用于构造CSD的技术，实现可能不同，但是逻辑分组应该是相同的。

下面对象应该优选地包含在UDM中：

-用户605：包含基本用户信息(例如，用户标识)。用户605总是属于一个订户610；

-订户610：包含基本预订信息(例如，订户标识)；

-客户段615：用于分类订户610，包含客户段描述和基本数据；

-提供服务620：包含服务基本信息；

-服务包625：用于打包提供服务620；

-服务包预订630：用于反映订户610对服务包625的有效预订；

-服务预订635：用于反映订户在服务包中对每一个服务620的有效预订；并通过服务包预订630指定。

-服务激活640：用于反映用户605服务预订635的每一个服务的有效激活；

-订户共享资源645：包含在订户610预订的特定服务中所使用的共享资源的基本数据，并通过服务预订635来指定。共享资源是提供需要支持其他服务系统所执行的服务的任何系统；

-用户共享资源650：包含用户605激活特定服务640中所使用的共享资源的基本数据。该共享资源是需要支持其他服务系统执行的服务的任何系统。

用户对象605和订户对象610是标识对象的实例。服务预订对象635和服务激活对象640是服务对象的实例。服务网200中提供的所有服务通过UDM来已知。订户610可能接着预订一个服务。对象提供服务620包含有关所有提供服务的信息以及可能保持与存储在其他系统中的服务相关数据的参照。优选地，多项服务的详细信息存储在公共服务数据库中。公共服务数据库有关服务的更加详细信息和提供服务对象620的内容展示了适合于用户服务信息的一个特例。提供服务620因此可以被视为CSD300和公共服务数据库之间的联接点。订户610可能一个一个地预订服务，但是这将使得服务提供变得麻烦。优选地，相似服务，或可能吸引相同订户的服务被分组在一起，这反映在对象服务包625中。特定服务可能以多个服务包被提供。另外，服务包可能提供给具有相同特性和期望需要的一组订户。因此，订户610可能被分组为客户段615，订户610可能预订提供给该订户所属客户段的所有服务。通过在一个或更多服务包625中包括一个客户段将该服务填加到该客户段中。简而言之，服务包625分组提供服务620以及客户段615分组订户610。

订户610以服务包625的形式而不是以单独的服务形式预订提供给客户段的服务。如果需要分别地提供服务，服务必须包括在服务包625中。对象服务包预订630保持订户预订服务包信息，以及对象服务预订635保持包括单独提供服务620的信息。这些是提供给单独的用户605的服务。用户可能选择使用所有订户预订的服务，但是最有可能的是，用户将选择服务。用户服务选择包含在对象服务激活640中。对象服务激活640包含与分支数据的参照。

综合服务经常需要包含两个或更多提供服务的系统，例如在先前描述的预订房间的实例。基于定位的服务将典型地包含系统移动定位中心，MPC，和家庭预订服务器，HSS，这里用于移动网(接入网)的用户简况被存储。类似MPC和HSS的系统是共享资源或服务发起商的实例。对象订户共享资源645和用户共享资源650包含不同系统之间的相关性以提供综合服务和与这些系统分支数据的参照。特定的相关性防止了用于服务系统的必要数据被另外一个例如使用MPC的服务系统中断MPC预订/激活的系统改变或删除，如果另一个服务系统需要预订/激活来执行综合服务。

另一个被多个综合服务使用的共享资源的实例是日历.用户典型地仅仅想要一个示出所有条目的日历，而不管怎样产生这些不同的条目.在上述预订旅馆的实例中，预订旅馆的服务优选地也访问日历以便自动进入预订.用户使用相同日历来预订会议，记住生日等等.在商业情况中，订户可能想要所有的用户访问一个公共日历，或每一个其他的日历，以便能够使用例如自动检测什么时候一组用户有空开会的功能.因此，服务“日历”能够依赖于使用，被认为是用于综合服务的独立服务，或一个“建筑块”，或服务发起商.

在本发明可替换的实施方案中，形成综合服务的服务之间的相关性或共享资源使用并不存储在CSD中，而是存储在公共服务数据库中。在本实施方案中，服务之间的相关性存储在公共服务数据库的每个服务等级中，而不是存储在CSD的用户/订户等级中。通过该替换的安排，几乎较少的相关性必须存储在服务系统中，这是由于相关性对于大量用户是公共的，以及用户数量典型地大大超出服务的数量。另一方面，公共服务数据库必须致力于获得服务之间相关性的有关知识，例如，如果用户解除激活综合服务。为了对所有用户/订户相关数据保持具有仅仅一个访问节点的观点，为了升级用户/订户数据，在检测服务之间相关性的情形中，访问公共服务数据库被优选地安排通过SAP。[正确？]

服务网可能为多个使用不同通信技术的不同接入网提供服务，例如类似GSM的电路交换移动系统，类似GPRS的分组交换系统或类似UMTS的混合系统。UDM提供用于存储终端用户可以使用哪一个接入网以及用于接入网的用户ID和属性的信息。

示例UDM原理的实例将参考图7来描述。示意图示例了订户和两个用户利用一些服务网所提供的服务。这是为了保持实例清楚并且对本发明不加任何限制。在现实中，订户/用户典型地使用大量的服务。

Richman家是注册到客户段615：家庭VIPS的服务网客户。Richman家由Richman先生，Richman女士以及Junior组成，实际上只有一个有权预订服务的是父亲，订户615：Richman先生。他们的客户段提供给他们服务包625：团体包裹和服务包：金融。

“盒”分支数据660表示所有的加入到服务中的分支数据。在这种情形下，用于提供预订豪华轿车和预订喷气机服务的分支数据660以及用于共享资源650MPC的分支数据。应该注意到，在本例中，提供服务620：预订豪华轿车是基于位置的服务，因此依赖于用户共享资源650MPC。

服务包625：团体包裹是他们真正需要的。当反映出与订户610：Richman先生和服务包625：团体包裹相关的服务包对象存在时，因此他们已经购买包裹。购买该服务包导致了三种服务预订635产生，每个提供服务620的服务包含在服务包625中：团体包裹。

另一方面服务包625：金融对于这个家庭来说并不那么有吸引力，正如可以从以下事实中得出的，即图中不能看到为此目的的任何服务包预订630。

一个用户605：Richman女士有权使用提供服务620：“预订豪华轿车。这是通过与服务预订635相关的服务激活对象640的存在来表示的，依次，与提供服务620：预订豪华轿车相关的服务激活对象的存在来表示。这里也存在用于用户：Richman女士的预订豪华轿车分支的对应用户数据对象。注意到，这是目前为止她能够使用的唯一提供的服务，因此当她对使用其他服务变得感兴趣时，那么新的服务激活对象640必须相应地产生。由于他付了帐单，因此订户610：Richman先生必须对此作出同意。

其他用户605-Junior-喜欢飞行，有权使用提供的服务620：预订喷气机，也包含在预订服务包625中：团体包裹.对于用户：Junior，在预订喷气机分支中存在对应的用户数据对象.请注意，这是他目前为止能够使用的唯一提供的服务，因此当他对使用其他服务变得感兴趣时，那么新的服务激活对象640必须相应地产生.再次，订户：Richman先生，由于他毕竟付了帐单，必须对此作出同意.

第三提供服务620：在服务包625中建立团体：团体包裹还没有被任何用户预订，因此预订激活对象或者用户数据都不存在于用于该服务和这些用户的分支数据中。

由于提供服务620：预订豪华轿车是基于位置的服务，当反映出对应用户共享资源650和MPC分支数据中的用户数据对象存在时，用户：Richman女士也已经被提供MPC。

相反，提供预订喷气机服务不需要任何共享资源中所提供的用户数据。因此对于与该服务相关的用户：Junior不产生任何用户共享资源对象。

在本例中，不仅没有位于分支数据中的订户数据对象也没有订户共享资源对象，由于在本例中没有一个订户服务需要用于不同用户的公共环境(所以，在本例中，不需要为任何分支数据提供订户数据，尽管本发明允许这种类型的提供)。在本例中，服务预订对象作用是简单地将该预订链接到他们相关的提供服务。

存储在CSD300中的用户，订户和服务数据根据上述的UDM构造。产生的数据记录将参考图8来描述。在该图中，箭头表示域之间的相关性，较细箭头表示一对一相关性和较粗箭头表示多个域之间的相关性。用户数据记录，UDR803，将包括包含基本订户信息例如，订户标识的订户域810。一个或更多用户域805指定订户所拥有的用户。用户域805和订户域810是标识域的实例。客户段域815描述订户特征并定义订户将被提供哪一个服务包。服务包域825，用于每一个包的服务包域，定义可得到的服务包以及与每个服务包域825链接的是提供服务域820，该域包含用于每个独立服务的基本服务信息。服务包预订域830定义订户预订了哪一个服务包以及服务预订域835，用于每个服务的一个，定义所有的分别可得到的服务。正如前面所述，每一个用户选择激活哪个服务(从服务激活域835的服务中选择)，以及在服务激活域840中指定每一个用户服务选择。因此，每个用户域805链接到服务激活域840。服务激活域840包含与分支数据的链接，即，存储在服务系统340，350，360中的终端用户数据部分。链接可能优选地为分支数据库的地址，例如IP地址。服务预订域835和服务激活域840是服务域的实例。如果用户选择的任何服务需要使用共享资源，即不止一个综合服务使用相同的服务系统，系统之间的相关性以及与这些系统中存储的分支数据链接，将包含在用户共享资源域850中。以相同的方式，订户共享资源域845包含订户等级上系统之间的相关性。

UDR可能不仅包括与分支数据的链接，而且包括访问分支数据或使用共享资源的必要信息，例如，这样信息的一个实例是在不同服务中所使用的用于标识用户的不同方式。传统电话服务典型地使用电话号码作为标识符，电子邮件服务使用电子邮件地址作为标识符以及日历功能使用别名作为标识符。那么，综合系统使用不同的服务系统，可能需要一个或更多不同的标识用户的方式。不同标识用户的方式需要链接到一起，即所谓的标识映射。这是通过根据本发明的数据模型和数据记录提供的，在UDR中，包括不同的标识方式以及服务所属的标识，优选地，在该域中也保持与服务系统的链接，即订户共享资源域845，用户共享资源域850和服务激活域840。

所述的数据记录和包含域可以以许多方式实现，主要依赖于数据库所使用的技术。这样实现的细节对于本领域普通技术人员是显而易见的。除了上述实例的域以外，也可能提供与分支数据的链接。但是，为了保持实现的简单化和增强数据的一致性，优选地提供这些链接的不同域的数量应该被限制，并注意不要提供非必要和/或重复链接。

包含在服务激活域840，订户共享资源域845和用户共享资源域850中的链接是存储在CSD300中的主用户数据和服务系统340，350，360的分支数据之间的唯一连接点。这对于保持用户数据的一致性是重要的。分支数据应该仅仅用于服务范围内。应该向单一访问节点请求用户和订户数据，优选地通过CSD前端420和CSD前端420从中搜索订户和用户数据的UDR803来实现。

根据先前描述的本发明的可替换实施方案，如果服务之间的相关性存储在公共服务数据库中，那么不需要用户共享资源域850和订户共享资源域845。代之以，在公共服务数据库的数据记录范围内提供对应的域。

可能访问SAP用于进行数据管理，诸如升级终端用户数据，以及用于实时使用，诸如搜索执行服务的必要数据。数据管理包括用户管理，订户管理，服务管理，客户段管理，服务预订和激活以及服务包管理。实时使用在执行服务系统的一个应用中发生。例如，该应用提供基于位置的服务。该应用需要为基于位置的服务提供特定用户数据，该数据从SAP搜索得到。接着，另一个实例是应用需要分支数据参照和一些不同用户ID，以及与用户相关的名字和别名的知识。

根据本发明的访问用户和订户数据的方法即使用本发明的SAP，将参考图9的示意性例举来描述。这里访问功能由客户端900来表示，他可能执行上述的数据管理功能或实时使用。详细的实例在以下的子部分“用户案例”中体现。客户端使用典型地由执行服务的服务系统中的一个应用发起，或由服务供应商或服务网的其他竞争者发起的数据管理应用而发起。因此，特定的客户端经常地，但不是必要地，链接到特定的服务系统。该方法包括步骤：

910：客户端通过CSD前端420访问SAP。访问可能优选地包括建立访问数据管理功能权利的请求/确认程序，例如读和/或写允许。

920：客户端典型地通过参照用户或订户ID向CSD前端420请求读和/或写数据。

930：通过使用CSD索引表410，CSD前端420访问分布式数据库中的正确数据库：和

940：CSD前端420从UDR803搜索数据或将数据转换到UDR803。

950：CSD前端420返回到客户端请求的数据。

方法可能可选地包括步骤：

955：如果客户端需要访问未存储在SAP内的用户数据，即分支数据，SAP根据上述的步骤被首先访问。从例如，服务激活域840，为客户端提供到分支数据，以及诸如用户ID或需要访问分支数据的用户名字信息的链接。

960：客户端使用SAP信息来访问分支数据库和请求用户相关数据。

965：分支数据库将用户相关数据返回到客户端。

该方法可能进一步可选地包括步骤：

970：如果客户端意图改变，删除或填加用户数据，为不同服务系统之间的相关性应该检测UDR803即在上述的示例性实现中，为了不同服务系统之间的相关性，检测用户共享资源域850和订户共享资源域845。如果这些相关性存在那么客户端将被通知，其他服务系统可能使用用户数据以及正常情况下不应该改变或删除用户数据。

依赖于管理行为的类型，每一个步骤的细节将会不同.改变用户和订户数据的关键特征指向SAP.为了改变典型地存储在服务系统中的分支数据，访问SAP以得到有关哪里可以找到适当的分支数据库的信息，即服务激活域840，用户共享资源域850以及订户共享资源域845中所给出的信息.然后，分支数据在它的数据库中被直接访问.可替换地，如果这些功能提供给SAP，可能通过SAP来访问分支数据.

访问的步骤910可能以大量不同方式执行，其中包括使用IP地址或一个ULR，以及SAP通过CSD前端420能够处理多种不同的访问方法和不同的访问方式，以及许多同时访问。不同访问方法在本领域中是已知的。

根据本发明的上述方法可能作为一个计算机程序产品或部分计算机程序产品来实现。程序产品例如在属于服务网200中服务系统的计算机上执行。

这里，根据本发明的SAP和方法已经被描述为在服务网中扩展了所有服务。这是优选的实现。但是，SAP可能在服务网中与不使用本发明的服务系统共存，但是只有使用SAP的服务系统将利用本发明提供的优点。

尽管已经结合被认为是最实际和优选的实施方案对本发明进行了描述，但是应该理解，本发明并不局限于公开的实施方案，相反，本发明旨在覆盖包括在附属权利要求精神和范围之内的不同修改和等同安排。

使用案例的实例

在本例中，术语管理员涉及服务网管理功能，典型地涉及在客户端-服务器情景中通过软件客户端来工作。

数据管理

用户管理

得到用户

期望结果：

在SN用户数据模型中搜索用户相关信息。

前提：

必须至少存在一个用户。

案例描述：

管理员需要搜索用户信息并向SAP发出请求。就管理员有适当权限阅读该请求信息而言，请求的信息(用户信息和/或预订数据和/或网络访问数据和/或用户共享资源)是可搜索的。

由于SN用户数据模型提供的该信息，管理员使用的系统(例如一个规定工具)可能需要搜索SN用户数据模型以外的用户信息，即，到达一些分支数据库，这里保留了实际预订数据和/或用户共享资源数据。为此目的，SN SAP保持搜索的参照(提供用户id和服务地址)朝向这些分支数据将被跟随以及将使用分支公布的合适的数据访问协议。

产生用户

期望结果：

定义一个新用户。

前提：

必须至少存在一个订户。在专用用户的情况中，以与用户相同程序产生订户。

案例描述：

管理员想产生一个新用户。为此目的，管理员进入用户的基本数据并选择一个与用户相关的订户。然后在SAP中产生新用户记录，并与订户相关。由于用户不能单独存在，该相关对于处理是固有的，因为它必须使用订户刚刚产生的预订。

删除用户

期望结果：

从SAP删除一个特定用户，以及所有他的相关信息。

前提：

必须至少存在一个用户。

案例描述：

管理员想从SAP删除一个用户。为了到达每个库以及删除存储在每个库中的用户服务数据，管理员使用的系统(典型地一个指定系统)将首先得到保留服务数据的分支数据库的服务参照和用户共享资源参照。那么，将删除用户对象，加上预订对象和/或网络访问对象和/或用户共享资源对象。

升级用户

期望结果：

管理员修改用户数据。

前提：

必须至少存在一个用户。

案例描述：

管理员(可能是用户本身)想改变用户基本数据(唯一影响的对象是用户对象)。在SAP中升级用户对象信息。

订户管理

得到订户

期望结果：

搜索位于SN用户数据模型中的订户相关信息。

前提：

至少已经定义一个订户。

案例描述：

管理员向SAP请求一个订户相关信息。该信息可能包括以下任何一种：订户基本数据，服务包预订，服务预订数据，客户段数据，订户共享资源数据，以及用户列表。

由于SN用户数据模型提供的该信息，管理员所用的系统(例如规定工具)可能需要搜索SAP以外的订户信息，即到达一些分支数据库，这里保留了实际服务预订数据和/或订户共享资源数据。为此目的，SAP保持搜索参照(提供用户id和服务地址)朝向这些分支数据将被跟随以及将使用分支所公布的合适数据访问协议。

服务管理

得到服务

期望结果：

从SAP得到提供服务。

前提：

至少已经定义一种服务。

案例描述：

管理员向SN SAP请求提供的服务信息。搜索服务对象中所包含的数据。

增加服务

期望结果：

新提供服务将被打包。

前提：

已经开发，开展以及构造一种服务，即存在一种提供的服务，该服务的信息从SN的其他部分可以得到。

案例描述：

为了获得提供的预订服务，第一步是通过产生一个提供的服务对象使SAP意识到该服务。提供服务产生的提供服务模板必须由管理员提供。

客户段

得到客户段

期望结果：

从SAP搜索客户段和相关信息。

前提：

至少必须存在一个客户段。

案例描述：

管理员，典型通过指定系统，可能需要知道客户段相关信息。这些信息是从SNSAP请求的，并发送客户段信息加上相关的服务包信息(它包括包含在每个服务包中的服务)。

变化：

另外，可以搜索属于客户段的订户列表。

产生客户段

期望结果：

定义一个新客户段，以及订户可以与其相关。

前提：

至少必须存在一个服务包。

案例描述：

客户段允许订户分类和服务分组。每个订户必须属于一个客户段，所以在定义订户之前必须产生这些客户段。

为此目的，管理员产生一个与一些可得到服务包相关的客户段。包含在这些服务包中的服务组成了提供给每个与该新客户段相关的订户服务。将新的客户段对象填加到SAP，并链接到选择服务。

服务预订和激活

产生一个预订

期望结果：

激活用于特定用户的特定提供服务变为可能。参见下一个0。

前提：

参与者(订户)已经预订服务包。

案例描述：

订户想要使得通过用户激活和使用服务变为可能。预订对象必须通过预存在的用户独立服务预订产生并与提供服务相关。

必须根据分支规定协议和规定如提供服务模板中设置的分支相关固定预订信息来执行用户规定。这导致了分支数据中新用户数据对象的产生。

预订对象将指向分支中的用户前后关系以便进一步支持激活，和其他的规定相关活动。这种参照将包括应用分配的用户id和分支地址。

激活服务

期望结果：

准备被第一次使用一种服务。

前提：

与该用户和提供服务相关的预订已经根据上述产生。

案例描述：

最后一步具有准备用于激活使用的特定提供服务。管理员(有些情况下也许就是用户)根据规定模板提供需要用于服务激活的个人信息。根据他们的分支规定协议将激活设置转发到分支数据库。

升级SAP(预订对象)中的对应对象以反映该服务已经被激活。

参照(服务用户id加上分支地址)朝向保留服务的分支数据库，也必须建立服务和它所需的共享资源之间的关系。

实时使用情形

得到共享资源

期望结果：

应用得到用户或订户所使用的共享资源。为了执行服务该应用可能使用该信息以访问资源。

前提：

必须至少准备使用一种用于用户的服务。

案例描述：

应用提供的服务可能需要在执行时间访问支持服务执行处理的共享资源。例如，提供基于位置服务的应用将需要访问从接入网中获得位置信息的发起者并使其对应用是明显的。

为此目的，愿意获得属于一个用户/订户的共享资源信息的应用，将使用用户标识请求该信息。由于所有可能标识都被保存在SN用户数据模型中，也存在具有共享资源的每个服务的相关性，将请求信息传送到该应用。

得到用户Id

期望结果：

应用获得用户Id中的任何一个。为了执行服务，应用可能使用该信息。

前提：

至少必须存在一个用户。

案例描述：

应用提供的服务可以使用用户的任何标识，但是，由于服务的特性，它可能需要知道用户的其他标识(例如，具有电子邮件地址，可能有兴趣知道MSISDN以SMS格式来发送电子邮件)。SN SAP知道全部用户的标识，因此发送请求的信息。

得到服务列表

期望结果：

将预订服务列表发送到一个访问SN SAP的实体。

前提：

至少存在一个用户。

案例描述：

为了授权目的，存在一些可能对获取用户预订服务列表感兴趣的实体，因此当试图使用该服务时，检测该用户是否有权使用该服务。为此目的，SAP能够构造并当被请求时发送该列表。

Claims

1.一种在服务网(200)中存储和保持用户和订户数据的方法，该服务网具有多个提供多种服务的服务系统(310，320，330)，该服务网(200)包括包含公共订户/用户数据库的单一访问节点，该公共订户/用户数据库包括具有与多种服务有关的用户/订户信息的订户/用户数据记录，所述方法的特征在于：

-在所述公共订户/用户数据库(300)中以订户/用户数据记录的形式存储用户和订户数据；

-在所述订户/用户数据记录中存储至少一个标识用户和订户的标识对象(605，610)；

-在所述订户/用户数据记录中存储至少一个指定从服务网(200)提供的所述多种服务中选择的至少一种服务的服务对象(635，640)，其中选择的所述至少一种服务是用户选择的，以及其中所述至少一个服务对象中的至少一个服务对象提供与订户或用户相关的分支数据(660)的链接，所述分支数据存储在所述公共订户/用户数据库以外；

-客户端访问(910)公共订户/用户数据库(300)以存取有关订户或用户的信息；

-通过单一访问节点从订户/用户数据记录检索数据或向该数据记录传递数据(930-950)；以及

检测(970)订户/用户数据记录的服务对象(635，640)是否包括到分支数据(660)的链接，如果包括，则访问分支数据库以检索用户数据。

2.根据权利要求1的方法，所述方法还包括在订户/用户数据记录中存储：

-一个指定订户可得到的第一组服务的服务预订对象(635)，其中第一组服务中的服务是从服务网(200)提供的所述多种服务中选择的；和

-至少一个服务激活对象(640)，每个服务激活对象通过用户指定从第一组服务中选择的激活服务，

其中所述服务预订对象和/或服务激活对象适合于提供与订户或用户相关分支数据的链接，该分支数据存储在所述公共订户/用户数据库以外。

3.根据权利要求2的方法，其中方法还包括在订户/用户数据记录中存储：

-多个用户对象(605)，每个作为标识对象的用户对象(605)标识一个用户；和

-至少一个用于每个用户的服务激活对象(640)，所述服务激活对象(640)链接到各自的用户对象(605)，每个服务激活对象(640)指定各个用户可得到的每个用户服务组，每个用户服务组是从第一组服务中选择的服务，其中所述服务激活对象(640)提供与存储在所述公共订户/用户数据库(300)以外的分支数据(860)的链接。

4.根据权利要求3的方法，其中，在订户/用户数据记录中存储定义了执行综合服务的不同服务系统之间相关性的信息。

5.根据权利要求4的方法，还包括：对于每个用户，在订户/用户数据记录中存储一个用户共享资源对象(650)，该用户共享资源对象链接到用户对象(605)和服务激活对象(640)，以及所述用户共享资源对象定义了服务系统之间的相关性，该相关性位于一个用户水平上。

6.根据权利要求4的方法，还包括在订户/用户数据记录中存储链接到作为标识对象的订户对象的订户共享资源对象(645)以及服务预订对象，所述订户共享资源对象(645)定义服务系统之间的相关性，该相关性位于订户水平上。

7.根据权利要求4的方法，还包括：对于每个用户，在订户/用户数据记录中存储识别各个用户的多种方式。

8.根据权利要求7的方法，其中所述识别方式是下列中的一种或更多种：电话号码、个人标识代码、电子邮件地址、名字或别名。

9.根据权利要求3的方法，其中所述方法进一步包括在订户/用户数据记录中存储指定用户可获得服务的多个对象，所述多个对象包括：

-至少一个服务包对象(625)，每个服务包对象指定一组由作为所述标识对象的订户对象(610)指定的订户可得到的服务；

-客户段对象(615)，其适合于描述订户对象(610)的订户的特性和指定服务包；和

-至少一个包括用于每种独立服务的服务信息的提供服务对象(620)，该每种独立服务包括在服务包对象(625)指定的服务包中。