CN100367212C

CN100367212C - 不同网络中远端业务调用

Info

Publication number: CN100367212C
Application number: CNB038249537A
Authority: CN
Inventors: A·J·默尔迪克; J·范埃伯; P·卡若曼斯; E·博尔斯马
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-11-05
Filing date: 2003-04-01
Publication date: 2008-02-06
Anticipated expiration: 2023-04-01
Also published as: AU2003217128A1; WO2004042573A1; CN1695119A; CA2500435A1; US20060248206A1; EP1559002A1; BR0315765A; JP2006506696A; JP4335812B2; SE0203297D0

Abstract

本发明提供一种系统和方法，通过诸如在OSA/PARLAY标准主体中规定的标准化接口，用来向那些具有到第一域业务的接入的客户应用提供到另一个域业务的接入。因此，根据本发明，提供一种框架到框架接口，由此许多域能够提供业务到其他许多域，并且由此第一域的特定第一框架通过其他域的相应第二框架，能够发现在所述其他域中可用的业务引擎。因此，根据本发明，除了那些已经被所述第一域自己提供的业务，第一域能够从第二域提供业务到它的客户应用。另外，本发明通过指定、交换和执行所涉及域之间的协定的方法，扩充了该系统和方法。

Description

不同网络中远端业务调用

发明领域

[0001]本发明一般涉及由核心网提供的业务和驻留在业务网中的应用之间的交互工作和兼容性。具体而言，本发明涉及核心网和业务网之间、以及许多核心网之间的开放式标准接口的开发。

背景技术

[0002]如今，电信市场上的大玩家们拥有着分布在各个国家的几种类型的接入和核心网技术，他们运营这些技术为用户提供到电信网和互联网的接入。上述各种类型的示例性技术，如GPRS，EDGE，CDMA，TDMA，D-AMPS，PDC，CDMA-2000，WCDMA等等及其组合源于其中出现各种不同环境不同情况。因此，除了这种不同环境带来的复杂性，在这些网络之间行政划分成几个局部公司更为环境增加了多样性，并且使得为在不同核心网或不同网域漫游的用户提供统一业务和业务应用接入变得更加复杂。

[0003]现在出现了新的竞争者来运营传统电信前提之外的网络。当允许漫游、比传统PLMN网络更宽的宽带接入、以及为用户加入其他增值业务时，这些新的竞争者如今是电信市场尤其是所有涉及数据传输方面的一部分。这些公司还可以运营几种类型的网络，诸如小的WLAN本地运营商、卫星运营商、电缆运营商等等。

[0004]在这种电信网络市场的情况下，旧的和新的网络运营商们有他们自己的用户基础，由于技术和管理环境非常大的多样性，因此开发应用和业务的努力比以前更加复杂。在面临该复杂性时，电信网络目前被理解为包括业务层、控制层和连接层。该业务层通常理解为一种网络环境，用来开发和操作高级应用，更具体而言即是终端用户的业务应用。连接层提供建立端到端连接所需的基础结构，或网络资源。当为业务层提供所需网络支持从而运行终端用户业务应用时，控制层提供所需的基础结构，网络控制实体，用来控制连接层中的那些网络资源。为了快速又容易地开发个性化业务，下一步就是建议一种网络结构：业务应用层被实现为独立的网络，即业务网，而控制和连接层保留在与接入网交互工作的核心网中。

[0005]必须解决不同环境下的业务层和控制层之间的交互作用和兼容性以便为用户提供真实的虚拟归属环境(Virtual HomeEnvironment-VHE)，从而允许跨越网络边界和不同终端之间的个性化业务可移植性(portability)。VHE的概念就是始终向用户提供同样的个性化特征、用户接口定制和业务，无论用户处于何种网络、使用何种终端、也不论身处何地、即，独立于用户目前预定和目前漫游的接入和核心网。在这一方面，远端业务调用和业务网漫游表现为允许用户拥有真实的虚拟归属环境的关键因素。

[0006]最近对业务网层和核心网层之间的开放式业务接入(OpenService Access-OSA)接口进行标准化所作努力的一个示例性例子就是Parlay/OSA规范，该规范基于许多应用编程接口(API)。这些API允许开发者以简单的方式接入由核心网提供的业务。

[0007]在所谓的Parlay组织中定义了一组初始应用编程接口(API)，它们的标准化在第三代合作伙伴计划(3GPP)和欧洲电信标准协会(ETSI)的标准化组织下进行。在本文中，业务网概念连同上述的API一起在Parlay组织中被传统地称为“Parlay”，而3GPP和ETSI通常将它们称为“开放业务接入”(OSA)。为了清楚起见，在整个说明书中使用术语OSA/PARLAY，用来代表图1所示的核心网和业务网之间的接口层。如今，Parlay，3GPP和ETSI之间存在着关于OSA/PARLAY API规范化和标准化的紧密合作，并且许多工作是共同完成的。

[0008]因此，OSA/PARLAY允许用户和开发者接入，并提供使用由运营商的核心归属网络提供的业务的应用。目标就是上述的API独立于网络，这样能够发展核心网技术，而不影响应用，还允许应用与各种类型的核心网合作。

[0009]因此如图2A所示，基于OSA/PARLAY的传统结构包括从前包含在业务网中并在应用服务器(AS)之上配置的客户应用、代表OSA/PARLAY接口的接口类别并在又被称为业务引擎(ServiceEnabler)的业务能力服务器(SCS)中实现的业务能力特征(SCF)、为诸如到业务能力特征的受控接入(S-30)这样的应用提供(S-10)框架能力的OSA/PARLAY框架(FW)、和核心网单元(CN)。具体而言，在应用服务器(AS)上运行的应用使用(S-20)由业务能力服务器(SCS)提供的业务能力特征，因此SCS实现API的服务器侧而AS实现客户端侧。SCS可以与诸如归属位置寄存器(HLR)、移动交互中心(MSC)、呼叫状态控制功能(CSCF)等等的核心网单元相互作用(S-40)。

[0010]客户应用通过标准应用接口根据业务能力特征接入OSA/PARLAY功能。这意味着，通过在OSA/PARLAY API接口上的调用操作，业务能力特征对于客户应用来说是可接入而且是可见的。

[0011]上述的OSA/PARLAY功能大体上分为3种不同的类型：

-框架功能：提供OSA/PARLAY功能的接入控制、安全、复原和管理所需的公用功能；

-网络功能：使应用能够使用基础网络能力的功能；和

-与用户数据相关的功能：使应用能够接入特殊用户的数据，诸如用户状态、位置、或相应用户简档中的数据。

[0012]特别地，框架提供了允许OSA/PARLAY应用使用归属网络中的业务能力的必要能力，更具体地，提供了包括验证和授权的安全管理、业务注册和发现功能、和完整性管理。

[0013]关于上述的OSA/PARLAY API接口中的操作，划分了3种接口类型：

-接口类型(S-10)，在业务网中的应用和框架之间，用来向应用提供诸如验证的基础机制，从而使所述应用能够使用归属网络中的业务能力；

-接口类型(S-20)，在应用和业务能力特征(SCF)之间，一旦从框架中获得(S-10)该接口类型(S-20)，那么它们就是应用可用的单独业务；和

-接口类型(S-30)，在框架和业务能力特征之间，提供用于支持多厂商环境的机制。

[0014]然而如图3A所示，没有办法在用户的归属网络中运行应用(AS-1，SCS-1)的执行过程(S-45)，该用户归属网络包括若干客户应用(AS-1)、框架(FW-1)、若干业务能力(SCS-1)和第一核心网(CN-1)，其中所述应用(AS-1，SCS-1)通过OSA/PARLAY接口使用被访问网络的业务能力(SCS-2)，该被访问网络包括若干客户应用(AS-2)、框架(FW-2)、业务能力(SCS-2)和第二核心网(CN-2)，其中所述归属网络和所述被访问网络属于不同的域运营商，并且其中所述被访问网络的业务能力(SCS-2)没有在归属网络中注册。

[0015]上述讨论的OSA/PARLAY模型能够以这样的方式可变地分布在各种玩家中，从而出现了不同的管理和商业区域。一些示例性的模型显示在图2B和2C中，其中，具体而言，企业运营商将自己表示为另一个域，代表面向网域运营商的应用而运行。

[0016]某些运营商以这样的方式构成：一个组织负责核心网以及内部开发的终端用户业务和应用，而另一个独立的组织负责通过合作者(partner)提供终端用户业务并负责为所述的合作者提供业务能力，如图2B所示。上述这种不同的组织在某种程度上意味着不同的电信域(核心网域，终端用户业务域，合作者)，需要独立地执行他们自己的政策并搜集他们自己的业务信息。这样，这些不同的电信域将获得相应的优势，即提供除了那些由每个域自己提供的业务能力之外的来自其他域的业务能力，这在最近的某个论坛中被称为“联合(Federation)”。换句话说，不同的组织，甚至是不同的公司，可以从灵活的解决方案中获得附加的优势，其中第二个域，即施主(donor)域，能够向第一个域，即接收者域，提供业务能力，第一个域进而又能够提供这些所述的能力到它自己的合作者，即它自己的业务提供商。另外，在一些面向商业的情况下，存在着管理零售网络业务的公司运营商角色。如图2C所示，这种公司运营商的角色允许在所述公司运营商(EO)和应用提供商(AP)之间的业务域内建立(A-11)业务协定。业务协定(A-10)即业务合同将公司运营商与提供其特定业务引擎(SCS)的网域运营商(NDO)绑定。

[0017]然而，现在没有方法让网域运营商提供另一个域的业务引擎到那些应用供应商，所述网域运营商和这些应用供应商具有业务协定。如图3B所示，OSA/PARLAY所关注的结构和接口模型不提供(S-25)将自己的业务能力(SCS-2)提供给第一域(NDO-1)和反之亦然的第二域(NDO-2)；并且这些域(NDO-1；NDO-2)的任何一个没有自己的合作者(AP-1，EO-1；AP-2，EO-2)来提供相应的应用业务级别协定(A-10，A-11)，即政策，这些协定在运行业务执行时被执行。

[0018]在这个方面，本发明的目的是提供装置和方法，通过OSA/PARLAY接口，使得能够在使用来自另一个域的网络诸如被访问网络的网络业务的用户归属网络中执行应用，其中所述用户归属网络和所述被访问网络属于不同的域运营商，并且所述网络业务没有在用户归属网络中注册。

[0019]本发明的另一个目的就是除了那些由每个域自己提供的业务能力，让域还能够提供来自另一个域的业务能力。

发明概述

[0020]除此之外，根据本发明提供的电信系统和方法来实现上述目的，该电信系统和方法通过标准接口向客户业务应用提供到业务能力特征的接入。特别地，该电信系统和方法适用于这种情况：标准接口，如OSA/PARLAY API提供的标准接口，存在于许多不同网域下的业务网和核心网之间。

[0021]因此，该电信系统包括若干运行客户业务应用的应用服务器；若干第一业务引擎，即第一业务能力服务器，其中第一业务能力特征被指定在第一(接收者)网域；第一框架，用来提供到所述第一业务能力特征的受控接入；和若干与业务网实体交互工作的核心网元。

[0022]一般来讲，框架可以被看作功能型的框架实体，用来执行如上所述的关于OSA/PARLAY标准的框架功能，也可以被看作根据本发明以及进一步描述所提供的新框架功能。另一方面，为了达到本发明的目的，业务引擎可以被看作是业务能力服务器(SCS)，其中业务能力特征(SCF)被指定在某个网域中。为了简明起见，贯穿整个文档根据特定的上下文来引用业务能力特征、业务引擎、或业务能力服务器，它们并不总是相互关联的。

[0023]因此，根据本发明，在这个电信系统的所述第一框架用来与至少一个第二框架通信，后者预定用来接入被指定在第二网域的若干第二(施主)业务引擎中的第二业务能力特征。

[0024]为了清楚起见，本发明经常将施主域称为提供自己的业务引擎到另一个域的网域，或更确切的说是在所述业务引擎中指定的业务能力特征。在这个方面，本发明经常将接收者域称为能够使用由施主域提供的业务引擎的网域。

[0025]该电信系统中的框架是允许框架到框架通信的给定协议装置。这种协议装置包括将第二网域的第二框架的存在通告给第一网域的第一框架的装置，业务能力特征可以与之共享。该协议装置还包括用来从第二网域的第二框架向第一网域的第一框架通告业务能力特征能够从所述第二网域的业务引擎提供给所述第一网域的客户应用的装置。

[0026]另外，通告其他域的其他框架存在的装置包括将每个框架自动地注册到其他框架的装置。除了该自我注册，或可替换地，用来向第一域的第一框架通告第二域的第二框架的存在的装置包括：为所述第一域的运营商将第二框架注册到第一框架的装置，和为所述第二域的运营商将第一框架注册到第二框架的装置。

[0027]另外，通告能够从第二网域的业务引擎提供的业务能力特征的装置包括：将来从所述第二网域的第二框架向第一网域的第一框架通知关于元素集合中选出的至少一个业务信息元素的业务信息的装置，该元素集合包括：业务标识符、业务类型、业务可用性、业务属性和业务接口。此外，通告第二网域的可用业务能力特征存在的装置包括：从第一网域的第一框架向第二网域的第二框架建立这种业务信息元素通知的标准的装置。

[0028]该电信系统还包括：执行所述第一网域的第一框架和所述第二网域的第二框架之间的安全管理机制的装置。所述执行安全管理机制的装置包括：用来捕获第一和第二域之间的业务协定的装置。这些业务协定指定了其中第一域能够让它的接收者客户应用使用第二域的业务能力的条件；并指定了其中第二域能够将业务能力供应到第一域的义务。这些业务协定从而可以被认为是应用在所述第一和第二域之间的政策。除了上述用来捕获业务协定的装置，或可替换地，用来转交业务声明和签名的装置也可以包括在执行第一框架和第二框架之间的安全管理机制的装置内。

[0029]更具体而言，该电信系统还包括：用来发现在第一网域的第一框架和第二网域的第二框架之间的所述第二网域的业务引擎处可用的业务能力特征的装置。该装置包括：当被所述第一域的客户应用所需时，用来协商特定能力的装置。一旦这些特定能力已经被成功地协商，该电信系统包括装置，用来把到在第二网域的业务引擎处建立的业务实例的引用从第二框架返回给第一框架，从而允许第一网域的客户应用使用第二网域的相应业务。

[0030]另外，该电信系统还包括：放在第一(接收者)域和第二(施主)域之间的业务引擎代理，所述业务引擎代理预定将为从第一域的那些应用到第二域的业务引擎的业务请求以及相反方向的通信起到代理的作用。该业务引擎代理优选地被提供在第一(接收者)域并且可以包括所述第一域的若干专用的业务能力特征，用来存储第二(施主)域的相应业务能力特征的引用。因此，该电信系统可以进一步包括：基于从第二(施主)域的框架(施主框架)接收的信息在第一(接收者)域自动建立业务引擎代理的装置，所述信息包括从元素集合中选择的至少一个业务信息元素，该元素集合包括：业务标识符、业务类型、业务可用性、业务属性和业务接口。可替换地，该电信系统可以进一步包括：通过从第二(施主)域下载诸如源代码或运行时间代码的代码来建立业务引擎代理的装置。该电信系统可以包括：通过在第一(接收者)域的第一框架注册第二(施主)域的特殊业务引擎而建立业务引擎代理的替换装置，所述特殊业务引擎起到面向第二(施主)域的业务引擎代理的作用。

[0031]这里所呈现的电信系统实现了上述本发明的目的，特别地，第一(接收者)网域可以包括用户的归属核心网，而第二(施主)网域可以包括用户正在其中漫游的被访问核心网。

[0032]本发明还提供了一种方法，用于通过标准化接口(OSA/PARLAY API)向客户业务应用提供到业务能力特征的接入，该方法包括以下步骤：

-向第一框架注册第一(接收者)网域中的第一业务能力特征，向第二框架注册第二(施主)网域中的第二业务能力特征；

-在每个网域中，通过各自的框架，执行用于从包含用户、网络、请求者应用及其组合的一组中选出的若干玩家的验证和授权的安全管理机制；和

-发现可以在所述第一(接收者)网域中被请求者应用使用的第一业务能力特征。

[0033]根据本发明的方法还包括以下步骤：

-在第一(接收者)网域确定在第二(施主)网域的第二业务能力特征对于请求者应用来说是可用的；

-通过所述第二(施主)网域的第二框架，执行用于从所述第一(接收者)网域的第一框架进行验证和授权的安全管理机制；和

-发现能够被所述第二(施主)网域的请求者应用使用的第二业务能力特征(SCF-2)。

[0034]为了确定第二业务能力特征在第二网域中是可用的，该方法还包括向第一(接收者)网域的第一框架请求接入到第二(施主)网域中可用的第二业务能力特征的步骤。该确定可以包括从第一(接收者)网域选出的第一业务能力特征接收这种信息的附加步骤。

[0035]另外，该方法中发现在第二(施主)网域中可用的第二业务能力特征的步骤还可以包括：与第二(施主)网域的第二框架协商来自第一(接收者)网域的第一框架的能力的步骤。更具体而言，协商能力的步骤包括：在第二(施主)域的业务引擎处建立所选第二业务能力特征实例的步骤，和从第二框架到第一框架返回这种实例的引用的步骤。

[0036]当该方法还包括向第一(接收者)网域的第一框架注册第二(施主)网域的第二框架的步骤时可获得有利的性能。该注册包括：在第一框架中注册第二框架本身的第一步骤；在第二框架中注册第一框架本身的第二步骤。除了该自身注册，或可替换地，本方法还可以包括：第一步骤，其中第二(施主)网域的运营商在第二框架中注册第一(接收者)网域的第一框架；第二步骤，其中第一(接收者)网域的运营商在第一框架中注册第二(施主)网域的第二框架。独立于使用自身注册或者运营商发动的注册，该方法还包括：公布允许所述第一和所述第二框架接入分别由对方控制的业务能力特征的至少一个接口的步骤。

[0037]有时，在任何特殊域的业务引擎可以使用新的或修正的业务能力特征来升级。确实需要在所述业务能力特征注册的所有域中更新相应业务信息。因此，该方法进一步包括：在第一和第二框架之间交换关于分别在第一和第二网域中可用业务能力特征的信息的步骤，使用或不使用接入这样的业务能力特征所需的接口的明确显示。特别地，当在第一网域中的专用业务能力特征负责确定第二业务能力特征在第二网域中可用时，该方法包括：向第一网域的至少一个第一业务能力特征指示在第二网域中可用的至少一个第二业务能力特征的步骤，很可能还有：在第一网域的这种专用业务能力特征中存储相应信息的步骤。

[0038]通过在本方法中包括如下步骤可以获得另外的优点：捕获网域的网络运营商和请求者应用的业务提供商之间的业务级别协定。与此相一致，该方法还包括：通过相应的第一和第二框架捕获第一和第二网域之间的业务级别协定的步骤。

[0039]因此，所述业务级别协定在第二(施主)域和第一(接收者)域之间以这样的方式扩展，该方法可以还包括以下步骤：

-在施主框架上建立和分配联合业务简档(Federation ServiceProfile)；

-在施主框架上签署(sign)联合业务协定；

-为了让客户应用能够发现施主业务而在接收者框架中安装(注册)必需的关于施主业务的信息；

-从施主框架请求在联合业务协定的范围内的接收者应用业务协定。

[0040]通过包括以下步骤可以获得一个更加有利的安全管理机制：分发和转交赋予专业人员在联合框架建立中使用业务的权利的声明。因此，该方法进一步包括以下步骤：

-由接收者框架转交声明到任何其他实体；

-签署关于分发和/或转交声明的协定；

-请求声明；和

-施主业务引擎使用施主框架检查接收的声明的有效性。

[0041]当本方法还包括以下步骤时可以获得另一个优点：在第一(接收者)域中建立业务引擎代理用来起到与在第二(施主)域的业务引擎中所选的第二业务能力特征实例进行通信的代理的作用的步骤。这种业务引擎代理的另一个优点在于在第一(接收者)域的这种情况下，实施局部政策。

[0042]在该方法中，在第一(接收者)网域中的第一框架中自动地建立业务引擎代理的步骤可以包括步骤：为从元素集合中选择的至少一个业务信息元素，在第一(接收者)网域中获得来自第二(施主)网域的业务信息，该元素集合包括：业务类型、业务属性和业务接口。

[0043]可替换地，在该方法中，在第一(接收者)网域建立业务引擎代理的步骤可以包括步骤：从第二(施主)域下载源代码或运行时间代码。该下载的代码可以包括局部政策执行规则，例如通过允许第一(接收者)域加上包含局部政策的源代码，或者通过在从第二(施主)域下载的运行时间代码中具有到存储在局部政策服务器的政策的引用。在后一情况下，第一(接收者)域仅需要确信下载的代码被配置成能够查阅该局部政策服务器。

[0044]另外，也可以将第二(施主)域的业务引擎注册到第一(接收者)域的框架中，并且允许两个域建立政策并拥有这些由业务引擎执行的政策。该方法允许第一(接收者)框架为每个客户应用建立业务引擎代理，或者允许主业务引擎代理存在于第一(接收者)域，当第一(接收者)框架请求时为每个客户应用产生实例。

附图说明

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

[0046]图1显示了本发明适用的技术领域的基本概略图，业务网和核心网之间的标准接口。

[0047]图2A显示了与归属公共陆地移动网络交互作用的简化的OSA/PARLAY结构。

[0048]图2B显示了另一幅OSA/PARLAY结构图，其中一个组织负责核心网域，而另一个组织负责通过合作者提供终端用户业务。

[0049]图2C显示了公司运营商的角色，它表示预定用来代表应用提供商在网络运营商域中建立业务协定的域本身。

[0050]图3A显示了现有技术的情况，其中在域之间的业务协定的情况下，第一域不能将第二域的业务能力提供给它的客户应用。

[0051]图3B显示了现有技术的情况，其中在两个域之间的业务协定的情况下，第一域不能将第二域的业务引擎提供给它的客户应用。

[0052]图4显示了紧凑的结构，其中在多个网域的环境下，通过为业务和核心网之间的交互作用加上一个新的框架到框架接口，从而建立虚拟全局框架。

[0053]图5A显示了分布式结构，在多个网域的环境下通过为业务和核心网之间的交互作用加上一个新的框架到框架接口，许多网域通常支持远端业务执行和尤其支持业务漫游。

[0054]图5B显示了具有若干网域的分布式的结构，其中由于所述新的框架到框架接口，第一网域运营商能够在另一个网域运营商的业务引擎中提供给第一应用运营商业务能力特征。

[0055]图6引入了注册框架，即施主和接收者框架，以及从施主域向接收者域通告可用业务的基本和简化的步骤。

[0056]图7A到7F显示了基于业务协定划分的详细实施例之下所遵循的多个时序。具体来讲，图7A显示了业务级别协定如何被通告给接收者框架。图7B显示了如何建立联合业务简档。图7C显示了如何在接收者框架中安装联合SCF。图7D显示了如何签署联合业务级别协定。图7E显示了如何签署应用业务级别协定。图7E显示了如何终止联合业务级别协定。

[0057]图8A到8D显示了接下来在基于代理引擎模型的详细实施例下提供业务接入的时序。具体来讲，图8A显示了如何安装代理。图8B显示了当执行接收者域的局部政策时，如何签署应用业务级别协定，以及代理SCS如何将请求中继到实际的SCS。图8C显示了如何终止业务级别协定。图8D显示了SCS如何被注册为替换的代理。

[0058]图9A到9E显示了在基于业务声明交换的详细实施例之下所遵循的时序。具体来讲，图9A显示了业务类型如何被通告给接收者框架。图9B显示了如何建立声明简档和声明。图9C显示了施主框架如何分发声明到接收者框架。图9D显示了接收者框架如何将声明转交给应用。图9E显示了接收者应用如何实行声明。

[0059]图10显示了在漫游环境下的定位(localization)业务相关使用情况，包括一些根据本发明的优选实施例。

优选实施例描述

[0060]根据本发明的第一方面，提供了系统和方法的许多当前优选的实施例，通过用扩展的和改进的OSA/PARLAY接口来使用来自各种被访问网络的网络业务，用来支持执行用户归属网络的业务应用，其中所述用户归属网络和所述各种被访问网络属于不同域运营商，因此所述网络业务没有明确地在用户归属网络注册。

[0061]一般来讲，根据本发明的第二方面，还提供了所述系统和方法的许多当前优选的实施例，允许第二网域，即施主域，提供自己的业务能力到第一域，即接收者域，接收者域进而又能够提供这些业务能力到它自己的合作者或者业务提供商。

[0062]还提供了根据本发明的被上述两个方面共享的特别实施例，允许协定的捕获和安全声明在不同网络和域之间的交换；以及在运行时间执行它们。

[0063]根据本发明的另一个方面，一个特殊结构的概略图如图4所示，显示了为在多个网域环境中业务和核心网之间的交互工作，通过加上一个新的框架到框架接口如何建立虚拟全局框架(在下文中称之为VGF)。这种新的框架到框架接口(S-60)允许客户应用(Appl.1；Appl.2；Appl.3；Appl.M)在一致的业务能力服务器(SCS-1；SCS-2；SCS-3；SCS-N)中具有到特殊业务能力特征(S CF)的接入以便和各自的核心网(CN-1；CN-2；CN-3；CN-N)交互工作。

[0064]这样，通过包括若干局部框架(FW-1；FW-2；FW-3；FW-N)和框架到框架接口(S-60)，并且每个局部框架局部地服务于特殊的网域用来控制接入该网域的业务能力服务器(SCS-1；SCS-2；SCS-3；SCS-N)中的业务能力特征(SCF)，虚拟全局框架(VGF)被建立。

[0065]该VGF，或者更确切的说是根据本发明所提供的新的框架到框架接口(S-60)，通常允许远端业务调用，更具体而言，允许共享不同网域的业务并提供在OSA/PARLAY覆盖范围内的业务网漫游。例如，图5A显示了支持所述远端业务调用的一般结构，尤其应用于当用户漫游到被访问的公共陆地移动网络(PLMN)时提供核心网业务。又例如，图5B显示了网域运营商(E0-1)如何借助于所述新的框架到框架接口(S-60)向已经签署了业务协定(A-11)的应用提供商(AP-1)提供另一个网域运营商的业务引擎即业务能力服务器(SCS-2)中的业务能力特征(SCF)。

[0066]根据本发明的另一个方面，框架到框架接口(S-60)呈现了2个主要的操作模式，在线和离线的模式。在线模式优选地被执行用于其中服务于客户应用的第一域第一框架准备接入并有效地接入到业务被调用的第二域的第二框架的那些过程。优选地执行于在线模式的示例性实施例如图7E和7F，图9D和9E，和图10所示。另一方面，离线模式优选地被使用于框架交换和刷新信息，该信息是关于某个通信所需的、在特别业务协定下它们各自的业务，和各自的接口协议。优选地执行在离线模式的示例性实施例如图6，图7A到图7C，和图9A到图9B所示。

[0067]为了简明起见，在线模式操作的优选的和非常简单化的示例性实施例通过参考图5A能够更好地被描述。这样，第一客户应用(Appl-1)向它的局部框架(FW-1)请求(S-10)一个特别的业务。该局部框架(FW-1)检查(S-30)仅仅在它自己域的业务引擎即自己域的业务能力特征(SCS-1)的参与下，该业务是否能被完全地和有效地执行，以及该客户应用是否被适当地通知(S-10；S-20)。如果调用这种请求的业务(SCS-2)必须涉及另一个网域，那么客户应用(Appl-1)请求(S-10)局部框架(FW-1)来接入相应远端域的这种业务。然后，局部框架(FW-1)使用远端框架(FW-2)发起(S-60)安全管理机制从而进一步允许由局部请求者客户应用(Appl-1)使用远端业务(SCS-2)。局部框架(FW-1)和远端框架(FW-2)协商(S-60)所需的业务能力并选择(S-60)远端业务能力特征(SCF)最适当的参与。一旦特殊业务已经在业务引擎(SCS-2)被实例化，远端框架(FW-2)通知局部框架(FW-1)业务的实例标识，这然后由它的局部框架(FW-1)被提供到请求者客户应用(Appl-1)。该请求者客户应用因此能够最终关于该业务连接到远端SCF。

[0068]另一方面，另一个离线模式操作的简化示例性实施例参考图6被更好地描述，图6显示了在框架之间交换和刷新有关各自业务包括各自注册的信息。

[0069]首先，如图6所示，不同框架之间的注册阶段能够被总结为两个基本的和简化的步骤。第一步骤注册就是通告新框架即远端或施主框架的存在，该新框架能被拥有该应用的运营商的框架即局部的或者接收者框架接入。第二步骤业务宣告在图7A和9A所示的替换优选实施例中进一步详细描述，公布可使用的将允许局部或接收者框架来接入远端或者施主框架内所述业务的业务和接口。

[0070]该新的远端或者施主框架引用，以及基于每个远端框架的可用业务，优选地被存储在替换实施例的图7A和7C所示的局部或接收者框架，其中框架的注册实际上从各自的域运营商触发。

[0071]然而，当为此使用专用或非专用特殊业务能力特征(SCF)时，可以获得其他额外的优点。根据图10所示示例性使用情况进一步解释的本发明另一个实施例，基于每个远端框架的可用业务，或它的引用，在局部或者接收者框架接入控制下被优选地存储在驻留在业务引擎(SCS)中的特别业务能力特征(SCF-1)中。

[0072]更具体来讲，图8A到8D显示了进一步详细描述的替换实施例，其中该SCS实际上起代理业务引擎(代理SCS)的作用，该代理业务引擎(代理SCS)被放置在接收者域和施主域之间，并预定用于为从接收者域的应用(Appl-1；Application)到施主域的业务引擎(SCS-2)的业务请求以及相反方向的通信担当起代理的作用。该另一个实施例使得框架以更标准的方式工作，如图10所示，经常在接收者域的特别业务引擎(SCS)，可能是SCS代理，联系(S-30)业务能力特征(SCF-1)，用来选择施主域的适当的业务能力特征(SCF-2)以便为特殊的业务处理客户应用。

[0073]独立于该基于每个远端框架的可用业务或其引用是否被存储在局部框架中，还是存储在所述局部框架的控制下的特别业务能力特征(SCF)中，还是存储在放置在施主和接收者域之间的代理业务引擎中，当框架(局部；远端；施主)增加或者改变业务时，所述框架发送该业务的更新到相关的框架(远端；局部；接收者)，如图6，7A和9A所示。

[0074]对于上述实施例可以描述各种使用情况。然而，特别相关的使用情况是定位业务，这根据本发明的一些实施例适合于解决上述的示例性问题。因此，图10，显示了在漫游环境下定位业务使用情况，其中客户应用(Appl-1)使用其中存在适当业务协定的引用的第一域局部框架(FW-1)执行所需的安全管理机制来验证。然后，客户应用(Appl-1)向本地框架(FW-1)请求发现到可用的业务能力特征的接口的过程。局部框架(FW-1)发起与该第一域业务能力服务器(SCS)的一组业务能力特征(SCF-1)的协商，选择一个适当的SCF_ID以便处理所请求的业务，并且返回这样的SCF_ID引用作为最后的发现接口，应用使用该发现接口其来请求特定的业务，即定位SCF，以及应用(Appl-1)所需的特殊能力。

[0075]在上述安全管理机制期间，局部框架(FW-1)检查应用(Appl-1)是否被允许使用该SCF以及在什么政策标准之下使用。这可以在域网络运营商和业务提供商之间的所谓的业务级别协定(SLA)中捕获。在允许应用使用SCF的情况下，局部框架(FW-1)返回所有业务能力特征的标识，即所有的SCF_ID，这可能实现客户应用(Appl-1)的需求。接着，应用选择这些SCF_ID中的一个，然后SCS建立应用所使用并且也能够检查条件的SCF实例。该SCF实例的引用被返回到框架(FW-1)，框架返回这样的引用到应用(Appl-1)。从此时起，该应用就能够使用该SCF(SCF-1)。

[0076]该应用(Appl-1)请该S CF实例产生发现接口(SCF-1)用来定位移动终端“Z”(MTZ)。所述SCF实例(SCF-1)探测MT Z被定位在网络R。换句话说，第一域确定第二网域即网络R的业务能力特征对于请求者应用来说是可用的。这个响应被发送回应用(Appl-1)。该应用请求局部框架(FW-1)关于在所述的远端网域的远端业务能力特征的可能接入。特别地，通过使用上述期望和详细描述的SCS代理的替换实施例，在接收者域的业务能力特征(SCF-1)可以被联系用来选择施主域的适当的业务能力特征(SCF-2)来为特别业务处理客户应用。

[0077]目前，局部框架(FW-1)使用存在适当业务协定的引用的第二域的远端框架(FW-2)发起相应的安全管理机制。在业务协定前提之下的适用安全管理机制的成功结果之上，远端处理过程能够从局部框架(FW-1)向远端框架(FW-2)发起，为后者(FW-2)发现能被所述第二网域的请求者应用(Appl-1)使用的业务能力特征(SCF-2)。这样的安全管理机制能够在业务级别协定划分方面被执行，如图7D和7E所示，或者在声明有效性标准方面执行，如图9C所示。

[0078]因此，局部框架(FW-1)为定位业务向远端框架(FW-2)请求也许位于第二域业务能力服务器或业务引擎(SCS-2)中的业务能力特征(SCF-2)。当被应用(Appl-1)请求时，局部框架(FW-1)选择一个可用的被访问业务能力特征(SCF-2)，并且通过远端框架(FW-2)协商特定能力，因为局部框架知道应用的需求，并且远端框架让这样的能力注册。然后该被访问业务能力服务器(SCS-2)建立将被第一域中的客户应用(Appl-1)使用的被访问业务的实例。到该实例的引用从远端框架(FW-2)被返回到局部框架(FW-1)，局部框架将它返还到应用(Appl-1)。从此时开始，客户应用(Appl-1)能够使用被访问业务能力特征(SCF-2)，并且该过程已经在局部和远端框架之间被管理。

[0079]根据本发明这个方面的主要优点是：每一次客户应用希望接入业务时，它仅仅与它的局部框架联系，同时该框架管理接下来的处理过程，以及与其他联合的OSA/PARALAY环境的关系。该客户应用因此仅仅在一个框架中注册，不需要在所有联合的域中注册。

[0080]补充地，根据本发明的上述第二方面提供许多实施例，并还实现了本发明的其他目的。在这个方面，3个详细实施例预定用来允许第二网域，即施主域，将它自己的业务能力提供给第一网域，即接收者域，第一网域进而能够提供这些业务能力到它自己的合作者或业务提供商，同时允许每个域来安装和执行它自己的政策。这3个详细实施例的每一个根据寻求的特定优点，为其他特定方面提供特定的实施例。

[0081]第一详细实施例如图7A到7F所示，提供扩展现有的业务协定模型，从而允许接收者域来“划分”施主和所述接收者域之间的业务协定。该划分构成了接收者域和其业务提供商之间的业务协定。对于该第一详细实施例，下文中被称为业务协定划分实施例，提供进一步的描述。第二详细实施例如图8A到8D所示，提供一种模型，其中接收者域优选地对于施主域的每个业务引擎具有所谓的代理引擎(代理SCS)。对于该第二个详细实施例也提供了进一步的描述，在下文中被称为代理实施例。第三个详细实施例如图9A到9E所示，提供附加的优点，通过将当前业务协定模型替换成基于声明的模型。为该第三个详细实施例也提供了进一步解释，下文中被称为业务声明实施例。

[0082]在业务协定划分实施例下，在施主域的OSA/PARLAY框架(下文称之为施主框架)能够将业务引擎(SCS-2)通告给已经在所述施主域预定其通知的应用，例如使用如图2A和2C所述的现有机制。根据图6已经提及的本发明的详细实施例，现在根据图7A详细说明，不仅仅接收者域中这样的应用还有OSA/PARLAY框架(下文称为接收者框架)能够被通知施主域中的所述业务引擎(SCS-2)。因此，当接收者域将来自施主域的业务引擎(SCS-2)提供给接收者域合作者(应用)时，这两个域被称之为形成联合。以相似的方法，当接收者框架提供由施主框架通告的业务引擎(SCS-2)时，该两个框架被称之为工作在联合建立中。

[0083]在该业务协定划分实施例下联合建立中的施主框架负责：

-在使用根据图6的上述离线运行模式或者使用如图7B所示的操作相关的过程注册接收者框架之后，通告新注册的业务引擎到那些在所述施主框架中注册的接收者框架，如图7A所示；

-提供机制，由此接收者框架能够签署联合业务协定，这能够被看作是在施主和接收者框架之间关于如下条款的合同，在该条款下，接收者框架和它的合作者能够使用特定的业务引擎，如图7D所示；以及

-提供机制，由此，在由联合业务协定设置的限制下，接收者框架能够为一个接收者框架合作者的应用向施主框架请求接收者应用业务协定，如图7E所总结的。

[0084]接收者应用业务协定的条款由接收者框架建立，但是施主框架确保请求的接收者应用业务协定是在由联合业务协定条款设置的限制之下。接收者应用业务协定能被看成是用在特定应用的联合业务协定的一部分。当接收者应用业务协定被分发给接收者框架时，一个新的业务实例被建立，并且一个引用被赋予接收者框架，如图7E所示，这已经参考图10的使用情况讨论过。

[0085]另一方面，在这个业务协定划分实施例中在联合建立中的接收者框架负责注册施主域的业务引擎，该业务引擎由施主框架通告并且也能够称为施主业务，并且使得对于它们自己的应用可用，如图7C所示。因此，对于通告的业务引擎的属性列表从施主框架获得。

[0086]除了该详细的业务协定划分实施例中的这几个实施例，专用的业务简档能够，像如图7B所示的为接收者域中的其它任一业务一样为施主业务建立。在这一方面，如上面考虑如图10所示使用情况来阐述的，这样的业务简档可以采用接收者域中的专用业务能力特征的形式，或者可以被存储在接收者域的专用业务能力特征中。

[0087]另外，在接收者域的适用安全管理机制中，在当接收者应用选择这样的施主业务并且与接收者框架签署该业务协定时，所述接收者框架向施主框架请求接收者应用业务协定，作为施主和接收者域之间的相应安全管理机制的一部分。该接收者框架在该请求中提供在分配给所述接收者应用的业务简档中定义的条款和/或约束。然后，施主框架使用这些条款和/或约束来建立接收者应用业务协定，如图7E的时序图所示，在图10所示的使用情况中也考虑过了。

[0088]而且，图7F显示了目前优选的实施例，从施主域终止向接收者域提供自己的施主业务。虽然没有任何图，但是也可以从接收者域触发相似的过程。

[0089]在代理实施例中，提供一种放置在接收者域和施主域之间所谓的代理业务引擎(代理SCS)，用来接入施主域的那些业务引擎(SCS-2)。更具体而言，实际的第一业务引擎(代理SCS)在接收者域为从接收者域中的应用到施主域的第二业务引擎(SCS-2)的请求起代理的作用，并且在从所述第二业务引擎到应用的另一个方向起同样的作用。从该施主域中的第二业务引擎来看，第一业务引擎(代理SCS)被看作应用。

[0090]而且，如图8A和8B所示，在代理建立中的代理业务引擎(代理SCS)负责与施主域中的实际的业务引擎(SCS-2)相通信，为来自接收者域的应用的请求起到代理的作用，并用来将所述应用中继到施主域中的实际业务引擎(SCS-2)。另外，代理业务引擎(代理SCS)负责执行应用提供商和接收者域之间的政策或协定。

[0091]施主域在代理建立中负责通告新注册的业务到注册的接收者框架。在这个方面，前面已经在为施主和接收者框架之间相互注册的业务协定划分实施例中讨论的方法，如图6和7A所示，也可以应用在该代理实施例之下。而且，如在替换实施例所进一步描述的那样，施主框架可以可选地提供业务引擎码到接收者域，从而相应的业务引擎能够被实例化，并且可以在所述接收者域中可选地调整执行局部政策。

[0092]另一方面，代理建立中的接收者框架负责注册代理业务引擎(代理SCS)并且使它们对于在接收者域中自己的客户应用可用。因此，根据该代理实施例，许多替换实施例被建议来建立代理业务引擎。

[0093]在建立代理的第一替换实施例中，在第一(接收者)域中建立代理业务引擎，用来与在第二(施主)域的业务引擎处所选择的第二业务能力特征的实例进行通信。在第一(接收者)域的这种情况下，这样的业务引擎代理的主要优点在于执行局部政策。该代理业务引擎能够在第一(接收者)域中基于从第二(施主)域接收的关于从元素集合中选择的至少一个信息元素自动地建立，该元素集合包括：业务标识符，业务类型、业务可用性，业务属性和业务接口。

[0094]在建立代理的第二替换实施例中，代理业务引擎在第一(接收者)域中通过从第二(施主)域下载源代码或运行时间代码来建立。该代码能够是这样的：它被调节来包括局部政策执行规则。例如，通过允许第一(接收者)域增加包括局部政策的源代码，或者通过在从第二(施主)域下载的运行时间代码中具有到存储在局部政策服务器中的政策的引用。在后一情况中，第一(接收者)域仅仅必须确保下载的代码被配置为使得能够查阅局部政策服务器。

[0095]在建立代理的第三替换实施例中，通过在第二(施主)域中选择业务引擎(SCS)、通过注册该业务引擎(SCS)到第一(接收者)域的框架用来起代理业务引擎的作用、以及通过允许该业务引擎(SCS)为两个域建立政策并执行这些政策，代理服务引擎在第一(接收者)域中被建立。该代理业务引擎可以基于第二(施主)域的实际业务引擎(SCS)的业务类型和属性值被建立。在这个方面，代理业务引擎的建立可以是如图8A所示的具有所谓联合介体(mediator)的专用元件的责任。更具体而言，所述代理业务引擎的引入可以是接收者框架的责任。另外，在施主域中的特定业务引擎可以在接收者框架中注册，并且从而在该接收者域中注册，以便实现如图8D所示的代理业务引擎的职能。

[0096]仍然在代理实施例下说明特征，图8C显示了业务协定在代理实施例中如何能够被终止的示例性实施例。

[0097]第三个详细实施例中，上述业务声明实施例，被发现为额外提供了上述两个实施例以外的优点。该业务声明实施例基于施主和接收者域之间业务声明的交换和实施。

[0098]在这个业务声明实施例之下，在施主域(施主框架)中的OSA/PARLAY框架能够通告业务(施主业务)到已经在所述施主域预订其通知的应用，如图9A所示，还能够以如业务协定划分实施例所期望的相似方式通告这些施主业务到接收者域(接收者框架)的OSA/PARLAY框架，如图6和7A所示。

[0099]因此，图9C显示了接收者框架如何请求通过施主框架分发业务声明。该过程可与图7D所示的相比，虽然其更加适合于使用基于声明的模型替代业务协定模型。一般来讲，声明是授权和/或验证语句，它能够包括许多属性。特别地，声明可以被看成包括在安全管理机制中。

[0100]因此，根据图9C，当在施主和接收者框架之间执行安全管理机制时，所述施主框架分发业务声明到所述接收者框架。以相似的方法，图9D显示了当执行所述接收者框架和诸如接收者域中的客户应用之类的任何其他请求实体之间的安全管理机制时，如何通过所述接收者框架分发相应的业务声明到所述客户应用。

[0101]概念上，业务声明描述了应用和特定业务之间的协定。声明能够被发送到来自某个实体的业务，然后该业务对于这种已经发送该声明的实体来说变得可用。该声明的“发送”在本文中可以被看作“实施”该声明。当发行该声明时，还不知道哪个应用或实体将要实施该声明。

[0102]该接收者框架能够通告它的由声明所示的可获得的能力，并且转交该声明到接收者域之内或之外的应用。然后该应用能够实施该声明，或者将该声明转交给另一个应用。通过这种方法，之前根据所述协定使用所述业务的协定伴随着授权权利，能够以非常轻松的方法交换。

[0103]另外，转交声明的实体，诸如应用，能够加上验证、授权，或者属性数据到声明中。通过这种方法，这样的应用能够定制声明。每个转交声明的域能够分发附加的数据，并使该附加的数据与声明相关联。例如，所指出的能力能够使用自己的能力被扩展或者限制，从而产生一种分层的声明。

[0104]因此在这个业务声明实施例之下联合建立的施主框架负责：

-建立如图9B所示，代表施主业务使用协定和权利的业务声明，或者使用如图6所示的上述离线操作模式建立业务声明。

-通告新的注册的业务，或者相当新的业务引擎(SCS-2)，如图9A所示；

-提供图9C所包含的用于分发业务声明到接收者框架的机制，该机制可以涉及由陈述双方的签名，该陈述显示声明被交换并且能够证明是无抛弃的，如果需要，优选地该声明或者其一部分被加密；

-记录分发给注册的接收者框架和驻留在施主域中的局部应用的声明；和

-处理检查被实施的声明的有效性的请求，这样的请求通常被施主业务发送或者，更特别地，由如图9E所示的优选地位于业务引擎(SCS-2)的业务管理器实体发送，其中施主框架检查声明是否是以便没有被实施过。

[0105]根据本发明所支持的一般原理，声明只能够实施一次。施主框架向优选地位于业务引擎(SCS-2)中的业务管理器实体指示，声明是仍然有效的还是无效的。然而，业务引擎能够让自己的机制来检查声明的有效性，而不涉及到框架，本领域普通技术人员将可以理解这一点。

[0106]另一方面，在该业务声明实施例下联合建立中的接收者框架负责：

-请求分发业务声明到施主框架，如图9C所示，其中用于获得这种声明的机制包括陈述双方的签名，如上所述，该陈述显示了声明被交换，并且能证明没有丢弃。如果需要，该声明或者其一部分优选地被加密；

-通告新获得的能力到接收者域中的应用，很可能地也在所述接收者域外；

-为声明数据加上元素集合的至少一个元素以便建立“分层”声明，该元素集合包括验证、授权和属性数据；

-提供声明到施主业务，即“实施”声明，这典型地发生在当接收者框架起代表施主域的作用时，接收者域预定起面向其他合作者域的引擎或者中间层的作用，从而屏蔽施主域的能力；并且

-一旦从这样的应用发出请求，就转交业务声明到接收者域中的应用，如图9D所示，该机制可以涉及陈述双方的签名，上面已经讨论，该陈述显示声明被交换并且能够证明是无抛弃的，如果需要，该声明或者其一部分优选地被加密；

[0107]在这个方面，当接收者框架已经转交业务声明，就不再允许实施该声明本身，但是只有在接收者域已经接收声明的应用然后才能实施该声明，或者将其转交给另一个应用。

[0108]最终，施主域的业务引擎(SCS)负责：

-向施主框架登记；

-验证声明是否已经被施主域框架签署和，可选地，该声明是否被修改；

-在第一次接收声明时，请求施主框架验证声明是否已经由所述施主框架分发，以及该声明是否仍然有效；和

-一旦由施主框架或者由业务引擎本身接受了该声明，那么就根据声明中描述的协定属性，允许专业人员接入它的业务。

[0109]本发明是以示例性而非限制性的方式，通过几个实施例来描述的。显然，按照上述教导，本发明的许多修改和变型是可以的。本发明的范围通过权利要求并适当参考说明书和附图来确定，任何在权利要求范围之内的实施例修改预定将被包含在这里。

Claims

1.一种电信系统，被安排用于通过OSA/PARLAY接口向客户业务应用(Appl-1)提供到第一网域(NDO-1)中的第一业务能力特征(SCF-1)的接入，该系统包括：

若干应用服务器(AS-1)，其中客户业务应用(Appl-1)运行在这些应用服务器中；

第一业务引擎(SCS-1)，其中在第一网域中指定第一业务能力特征；和

第一OSA/PARLAY框架(FW-1)，用于提供到第一网域(NDO-1)中的所述第一业务能力特征的受控接入，

该电信系统的特征在于：

所述第一OSA/PARLAY框架(FW-1)被安排用来与至少一个第二OSA/PARLAY框架(FW-2)通信，预定用于提供到第二网域(NDO-2)的第二业务引擎(SCS-2)中指定的第二业务能力特征(SCF-2)的受控接入。

2.如权利要求1所述的电信系统，其中第一和第二OSA/PARLAY框架(FW-1，FW-2)包括协议装置(S-60)，用于允许框架-框架通信。

3.如权利要求2所述的电信系统，其中所述协议装置包括用于向第一网域(NDO-1)中的第一OSA/PARLAY框架(FW-1)通告可以与之共享业务能力特征(SCF-2；SCF-1)的第二网域(NDO-2)中的第二OSA/PARLAY框架(FW-2)的存在的装置。

4.如权利要求3所述的电信系统，其中所述的协议装置包括用于从第二网域(NDO-2)中的第二OSA/PARLAY框架(FW-2)向第一网域(NDO-1)中的第一OSA/PARLAY框架(FW-1)通告可以从所述第二网域(NDO-2)的业务引擎(SCS-2)给所述第一网域(NDO-1)的客户应用(Appl-1)提供的业务能力特征(SCF-2)的装置。

5.如权利要求3所述的电信系统，其中用于向第一OSA/PARLAY框架(FW-1；FW-2)通告第二OSA/PARLAY框架(FW-2；FW-1)的存在的装置包括用于第二OSA/PARLAY框架在第一OSA/PARLAY框架中注册它自己的装置。

6.如权利要求3所述的电信系统，其中用于向第一网域(NDO-1)中的第一OSA/PARLAY框架通告第二网域(NDO-2)中的第二OSA/PARLAY框架的存在的装置包括用于所述第一网域的运营商在第一OSA/PARLAY框架中注册第二OSA/PARLAY框架的装置。

7.如权利要求4所述的电信系统，其中用于通告能够从第二网域(NDO-2)的业务引擎(SCS-2)提供的业务能力特征的装置包括用于从所述第二网域中的第二OSA/PARLAY框架(FW-2；FW-1)向第一网域(NDO-1)中的第一OSA/PARLAY框架(FW-1；FW-2)通知从元素集合中选择的至少一个业务信息元素的装置，其中该元素集合包括：业务标识符、业务类型、业务可用性、业务属性和业务接口。

8.如权利要求7所述的电信系统，其中用于通告在第二网域的业务引擎上可用的业务能力特征的存在的装置包括用于从第一网域中的第一OSA/PARLAY框架(FW-1)向第二网域中的第二OSA/PARLAY框架(FW-2)建立用于通知这种业务信息元素的标准的装置。

9.如权利要求1所述的电信系统，进一步包括用于在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)和第二网域(NDO-2)的第二OSA/PARLAY框架(FW-2)之间执行安全管理机制的装置。

10.如权利要求9所述的电信系统，其中用于在所述第一和第二OSA/PARLAY框架之间执行安全管理机制的装置包括用于捕获在第一和第二网域(NDO-1，NDO-2)之间的业务协定的装置，所述业务协定代表在所述第一和第二网域之间应用的政策。

11.如权利要求9所述的电信系统，其中用于在所述第一和所述第二OSA/PARLAY框架之间执行安全管理机制的装置包括用于转交业务声明和签名的装置。

12.如权利要求1所述的电信系统，进一步包括用于发现在第一网域中的第一OSA/PARLAY框架(FW-1)和第二网域中的第二OSA/PARLAY框架(FW-2)之间的第二网域(NDO-2)的业务引擎(SCS-2)上可用的业务能力特征的装置。

13.如权利要求12所述的电信系统，其中用于发现在所述第一OSA/PARLAY框架(FW-1)和所述第二OSA/PARLAY框架(FW-2)之间可用的业务能力特征的装置包括用于协商在第一网域(NDO-1)中的客户应用(Appl-1)所请求的特定能力的装置。

14.如权利要求13所述的电信系统，进一步包括用于从第二网域中的第二OSA/PARLAY框架(FW-2)向第一网域中的第一OSA/PARLAY框架(FW-1)返回在所述第二网域的业务引擎(SCS-2)上建立的业务实例的引用的装置，以允许第一网域中的应用(Appl-1)使用第二网域的相应业务。

15.如权利要求1所述的电信系统，进一步包括放置在第一网域和第二网域之间的业务引擎代理(SCS代理)，并且该业务引擎代理预定充当用于从第一网域中的应用(Appl-11)向第二网域的业务引擎(SCS-2)的业务请求以及在相反方向中的通信的代理。

16.如权利要求15所述的电信系统，其中所述业务引擎代理(SCS代理)被提供在第一网域中，并包括所述第一网域的若干专用的业务能力特征(SCS-1)，用于存储第二网域的相应的业务能力特征(SCS-2)的引用。

17.如权利要求15所述的电信系统，进一步包括用于基于从第二网域中的第二OSA/PARLAY框架接收到的信息在第一网域中自动建立业务引擎代理(SCS代理)的装置，所述信息包括从元素集合中选择的至少一个业务信息的元素，其中该元素集合包括业务类型、业务属性和业务接口。

18.如权利要求15所述的电信系统，还包括用于从第二网域下载源代码或运行时间代码的装置，预定用于在第一网域中建立业务引擎代理(SCS代理)。

19.如权利要求15所述的电信系统，其中第二网域的特定业务引擎在第一网域的第一OSA/PARLAY框架(FW-1)中注册，用于朝向第二网域充当业务引擎代理(SCS代理)。

20.如权利要求1所述的电信系统，其中第一网域(NDO-1)包括用户的归属核心网(CN-1)，而第二网域(NDO-2)包括用户正在其中漫游的被访问核心网(CN-2)。

21.一种通过OSA/PARLARY接口向客户业务应用提供到业务能力特征的接入的方法，该方法包括以下步骤：

(a)利用第一OSA/PARLAY框架(FW-1)在第一网域(NDO-1)中注册第一业务能力特征(SCF-1)，以及利用第二OSA/PARLAY框架(FW-2)在第二网域(NDO-2)中注册第二业务能力特征(SCF-2)；

(b)在每个网域(NDO-1，NDO-2)中，通过每个各自的OSA/PARLAY框架(FW-1，FW-2)，执行用于验证和授权从包含用户、网络(CN-1，CN-2)、请求者应用(Appl-1，Appl-2)及其组合的一组中选出的若干玩家的安全管理机制；和

(c)发现可以被所述第一网域(NDO-1)中的请求者应用(Appl-1)使用的第一业务能力特征(SCF-1)；

该方法的特征在于，包括以下步骤：

(d)在第一网域(NDO-1)中确定在第二网域(NDO-2)上的第二业务能力特征(SCF-2)对于请求者应用(Appl-1)是可用的；

(e)通过所述第二网域(NDO-2)的第二OSA/PARLAY框架(FW-2)，执行用于从所述第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)进行验证和授权的安全管理机制；和

(f)发现可以被所述第二网域(NDO-2)中的所述请求者应用(Appl-1)使用的第二业务能力特征(SCF-2)。

22.如权利要求21所述的方法，其中确定第二业务能力特征(SCF-2)在第二网域上是可用的步骤包括为请求者应用(Appl-1)向第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)请求接入到第二网域(NDO-2)中可用的第二业务能力特征(SCF-2)的步骤。

23.如权利要求22所述的方法，其中确定第二业务能力特征(SCF-2)在第二网域(NDO-2)上是可用的步骤包括从第一网域(NDO-1)中选择的第一业务能力特征(SCF-1)接收这种信息的步骤。

24.如权利要求21所述的方法，其中发现在第二网域(NDO-2)中是可用的第二业务能力特征(SCF-2)的步骤包括与第二网域(NDO-2)的第二OSA/PARLAY框架(FW-2)协商来自第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)的能力的步骤。

25.如权利要求24所述的方法，其中协商能力的步骤包括在第二网域(NDO-2)的业务引擎(SCS-2)上建立选择的第二业务能力特征(SCF-2)的实例的步骤，和从第二网域的第二OSA/PARLAY框架(FW-2)返回对该实例的引用到第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)的步骤。

26.如权利要求21所述的方法，还包括利用第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)注册第二网域(NDO-2)的第二OSA/PARLAY框架(FW-2)的步骤。

27.如权利要求26所述的方法，其中注册OSA/PARLAY框架的步骤包括在第一OSA/PARLAY框架(FW-1)中注册第二OSA/PARLAY框架(FW-2)本身的步骤和在第二OSA/PARLAY框架(FW-2)中注册第一OSA/PARLAY框架(FW-1)本身的另一个步骤。

28.如权利要求26所述的方法，其中注册OSA/PARLAY框架的步骤包括其中第二网域(NDO-2)的运营商在第二OSA/PARLAY框架(FW-2)中注册第一网域的第一OSA/PARLAY框架(FW-1)的步骤，和其中第一网域(NDO-1)的运营商在第一OSA/PARLAY框架(FW-1)中注册第二网域的第二OSA/PARLAY框架(FW-2)的另一个步骤。

29.如权利要求26所述的方法，还包括公布至少一个允许所述第一和第二OSA/PARLAY框架接入分别由对方控制的业务能力特征的接口的步骤。

30.如权利要求21所述的方法，进一步包括利用或不利用接入这样的业务能力特征所需的接口的明确指示在第一OSA/PARLAY框架(FW-1)和第二OSA/PARLAY框架(FW-2)之间交换关于分别地在第一和第二网域(NDO-1，NDO-2)中可用的业务能力特征(SCF-1；SCF-2)的信息的步骤。

31.如权利要求30所述的方法，进一步包括向第一网域(NDO-1)中的至少一个第一业务能力特征(SCF-1)指示在第二网域(NDO-2)中可用的至少一个第二业务能力特征(SCF-2)的步骤，并且反之亦然。

32.如权利要求21所述的方法，进一步包括捕获在网域(NDO-1，NDO-2)的网络运营商和请求者应用的业务提供商(AP-1，AP-2)之间的业务级别协定的步骤。

33.如权利要求32所述的方法，进一步包括通过相应的第一OSA/PARLAY框架(FW-1)和第二OSA/PARLAY框架(FW-2)捕获在第一和第二网域(NDO-1，NDO-2)之间的业务级别协定的步骤。

34.如权利要求33所述的方法，其中所述业务级别协定在第一和第二网域之间被扩展，该方法进一步包括以下步骤：

-在第二网域(NDO-2)的第二OSA/PARLAY框架(FW-2)上建立和分配联合业务简档；

-在第二网域(NDO-2)的第二OSA/PARLAY框架(FW-2)上签署联合业务协定；

-在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)中注册有关第二网域(NDO-2)的第二业务引擎(SCS-2)的必需信息，以便客户应用(Appl-1)能够发现业务引擎(SCS-2)；和

-从第二OSA/PARLAY框架(FW-2)请求在联合业务协定的范围内的接收者应用业务协定。

35.如权利要求34所述的方法，其中接收者应用业务协定充当联合业务协定的划分。

36.如权利要求21所述的方法，其中执行安全管理机制的步骤包括分发和转交声明的步骤，其中该声明赋予专业人员使用联合框架建立中的业务的权利。

37.如权利要求36所述的方法，还包括以下步骤：

-由第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)转交声明给任何其他的实体；

-签署有关分发和/或转交该声明的协定；

-请求该声明；和

-第二网域(NDO-2)的第二业务引擎(SCS-2)利用第二OSA/PARLAY框架(FW-2)检查接收到的声明的有效性。

38.如权利要求21所述的方法，还包括在第一网域(NDO-1)中建立业务引擎代理(代理SCS)的步骤，其中该业务引擎代理被安排用来充当用于与第二网域的第二业务引擎(SCS-2)上选择的第二业务能力特征(SCF-2)的实例进行通信的代理。

39.如权利要求38所述的方法，还包括在业务引擎代理(代理SCS)上执行业务协定和政策的步骤。

40.如权利要求38所述的方法，其中在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)中建立业务引擎代理(代理SCS)的步骤包括对于从元素集合中选择的至少一个业务信息的元素在第一网域上从第二网域(NDO-2)获得业务信息的步骤，其中该元素集合包括业务类型、业务属性和业务接口。

41.如权利要求38所述的方法，其中在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)中建立业务引擎代理(代理SCS)的步骤包括从第二网域(NDO-2)下载源代码或运行时间代码的步骤。

42.如权利要求41所述的方法，其中下载源代码或运行时间代码的步骤包括下载局部政策执行规则的步骤。

43.如权利要求38所述的方法，其中在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)中建立业务引擎代理(代理SCS)的步骤包括在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)中注册第二网域的第二业务引擎(SCS-2)的步骤，其中允许两个网域建立需要由第二业务引擎(SCS-2)执行的协定和政策。

44.如权利要求38所述的方法，其中对于每个客户应用(Appl-1)，通过第一OSA/PARLAY框架(FW-1)建立业务引擎代理(代理SCS)。

45.如权利要求38所述的方法，其中在第一网域(NDO-1)的第一OSA/PARLAY框架(FW-1)中建立业务引擎代理(代理SCS)的步骤包括为每个客户应用建立所述业务引擎代理的实例的步骤。