CN103814583A - 实施主服务控制功能以用于促进增强型载波间增值服务的方法 - Google Patents

Abstract

公开了一种用于扩展的交叉运营商特征的主SCP。本发明涉及电信网络，并且更特别地涉及利用主服务控制点来向属于各种并且独立的网络运营商和服务提供商的订户提供运营商间的增值服务和补充服务的系统和方法。主SCP充当中央节点，使用diameter协议消息来提供不同网络运营商的多个SCP之间的通信。它促进了将运营商特定服务供应为运营商独立的服务，用于由与各种网络运营商相关联的订户来使用或者在这些订户之间使用。

Description

实施主服务控制功能以用于促进增强型载波间增值服务的方法

下列的说明书特别描述并且确定了本发明的本质以及其将被执行的方式：

技术领域

本发明涉及电信网络，并且更特别地涉及利用主服务控制点来将与电信运营商相关联的基于接入权限的运营商间的增值服务和补充服务提供给另一个运营商的订户的系统和方法。

背景技术

现今电信服务由网络运营商和服务提供商的主机来提供。这些网络运营商和服务提供商以有限的互操作性相互独立地操作。然而，随着电信技术和竞争压力的增长，网络运营商和服务提供商需要提供更新的应用连同改进的顾客订户服务。

每个运营商网络利用智能网络来控制和管理由该运营商以及任何第三方应用所提供的各种服务。智能网络（IN）是运营商特定的网络架构，其促进各种网络组件之间的通信以向订户提供运营商特定的增值服务和补充服务。IN利用服务交换点—SSP、服务控制点—SCP、被称为SS7（信令系统7）的信令系统以及各种信号传送点来向用户提供服务。智能网络利用服务控制点（SCP）来控制和管理网络服务。SCP与服务交换点—SSP或信令传送点—STP相连接。这取决于网络服务提供商的网络架构。

向服务提供商注册过的每个订户与网络内部的特定服务控制功能相关联，该特定服务控制功能将该订户连接至运营商的智能网络逻辑。连接至一个单个智能网络的任何订户能够经由服务控制点来订购和接入由该运营商网络所提供的所有服务。该订户被局限于由该服务提供商所提供的服务，并且不能接入由其他运营商所提供的服务。备选地，大多数增值/补充服务供应要求两个订户之间的交互（如点对点补充（peer-to-peer refill）），并且需要这些订户属于相同的运营商。

随着服务提供商的数量的增长，订户趋向于具有对各种服务提供商的多个订购，以便从每个服务提供商得到最好的服务。在这样的场景中，订户需要独立地管理各种订购。运营商间的服务通常被局限于基本服务，归因于迎合它们自己的订户基础集合的运营商特定SCP的隔离运行。此外，因为每个服务提供商的网络架构可能不同，提供运营商间的服务变得具有挑战性。

发明内容

鉴于前述内容，本文的实施例提供了一种用于通过采用主服务控制点（SCP）来向多个网络运营商的多个订户提供运营商间的服务的方法。除了交叉运营商的服务之外，它还提供了一种在SCP之间动态地共享其他相关信息的机制。该方法包括：由主SCP从运营商网络“A”的SCP接收服务请求消息，用于提供/请求对运营商间的服务的接入连同对于处理对运营商网络“B”的请求所需要的相关参数；由主SCP验证该服务请求消息，以用于分析该运营商网络A对于该运营商网络B的接入权限；由该主SCP处理该服务请求，如果需要的话，包括与运营商网络B的SCP的交互；以及由主SCP向运营商A的SCP发送回响应消息，该响应消息指示了肯定的接入确认或者对服务的拒绝。这些接入权限定义了由一个运营商的服务控制点对另一个运营商的服务控制点所支持/授权的服务。居中的SCP使用diameter协议，用于发送和接收请求和响应消息。对请求消息的处理包括使用主服务控制点的服务器上可用的信息。

实施例进一步公开了一种用于向多个网络运营商的多个订户提供运营商间的服务的主服务控制点。该主服务控制点包括：从运营商网络A接收针对与运营商网络B有关的服务的服务请求消息；验证该服务请求消息，以用于分析该运营商网络A对于该运营商网络B的接入权限；如果该服务被准许，则处理可以包括与运营商B的SCP的交互的该服务请求；以及向该运营商网络A发送回复消息。接入权限定义了由一个运营商的服务控制点用于对另一个运营商的服务控制而支持的服务。居中的SCP使用diameter协议，用于发送和接收消息。对回复消息的处理包括使用主服务控制点的服务器上可用的信息。

本文的实施例进一步公开了一种在通信网络中用于向多个网络运营商的多个订户提供运营商间的服务的系统，该系统包括多个服务控制点、主服务控制点，进一步地，该主服务控制点被配置用于：从运营商网络A接收针对与运营商网络B有关的服务的服务请求消息；验证该服务请求消息，以用于分析该运营商网络A对于该运营商网络B的接入权限；如果该服务被准许，则为该运营商网络A处理该服务；以及向该运营商网络A发送回响应消息。该系统验证该消息以确定这些接入权限，其中这些接入权限定义由一个运营商的服务控制点用于对另一个运营商的服务控制而支持的服务。该系统使用diameter协议来发送和接收该请求和回复消息。该系统通过使用主服务控制点的服务器上可用的信息来处理该回复消息。

本文的实施例还公开了用于运营商间的订户到订户协同计费、运营商间的存款和提款、以及采用主SCP用于基于运营商间凭单的充值的方法。

实施例进一步公开了一种用于处理网络运营商与服务控制点之间的消息的方法，该方法包括定义各种服务以及针对这些服务控制点之间的相关消息发送，来创建新的“属性值配对”。该方法中，服务的定义包括由使用主服务控制点（SCP）相互连接的这些网络运营商所供应的运营商间的服务。属性值配对针对由主SCP所提供的每个服务被定义。

当结合下列描述和附图考虑时，本文的实施例的这些和其他方面将更好地被领会和理解。

附图说明

根据下列参考附图的详细描述，将更好地理解本文的实施例，在附图中：

图1图示了根据如本文所公开的实施例的被连接至主服务控制点的电信运营商的网络的框图；

图2图示了根据如本文所公开的实施例的主服务控制点的框图；

图3A和3B图示了根据本文所公开的实施例的被用作通信协议的diameter分组格式的示例；

图3C和3D图示了根据本文所公开的实施例的呼叫控制请求消息和呼叫控制应答消息以及它们的定义；

图4示出了根据本文所公开的实施例的描述了由呼叫/请求运营商网络的SCP与其他服务提供商的服务控制点所共享的接入权限的示例；

图5图示了根据本文所公开的实施例的全球MSISDN—SCPID—SCP地址映射表格；

图6图示了根据本文所公开的实施例的全球简档到功能映射器表格；

图7A、7B、7C是根据本文所公开的实施例的描述了一种方法—运营商间的订户（属于OP1）到订户（属于OP2）的信用存款的示例流程图；

图8A、8B、8C是根据本文所公开的实施例的描述了一种运营商间的订户（属于OP1）到订户（属于OP2）的信用提款的方法的示例流程图；

图9A、9B、9C是根据本文所公开的实施例的描述了一种运营商间的订户到订户协同计费的方法的流程图；

图10A、10B图示了描述主SCP被用于基于运营商间凭单的充值的使用情况的流程图；以及

图11图示了根据本文所公开的实施例的本地SCP功能。

具体实施方式

参考被图示在附图中并且在下列描述中详述的非限制性实施例，以更完全地解释本文的实施例、以及它们的各种特征和有利细节。对公知组件和处理技术的描述被省略以便于不必要地使本文的实施例晦涩难懂。本文所使用的示例仅旨在促进对本文的实施例可以被实行的方式的理解，以及进一步使得本领域的技术人员能够实行本文的实施例。据此，这些示例不应当被解释为限制了本文的实施例的范围。

图1图示了根据本文所公开的实施例的被连接至主服务控制点—主SCP的电信运营商的网络的框图。基础运营商102中的主SCP101充当集线器，以用于所示出的运营商—OP1、OP2、OP3和OP4之间的通信。基础运营商102通常是网络环境中现有的运营商之一。基础运营商102是提供如下的基础网络架构的运营商，所有其他运营商可以在他们自己的运营商网络上使用和实施该基础网络架构。每个运营商（OP1、OP2、OP3、OP4）使用服务控制点—SCP来连接至大量的订户（在图中被示出为移动电话）。例如，OP1包括与订户A和订户C通信的SCP1，并且OP2包括与订户B和订户D通信的SCP2。运营商网络的SCP是运营商网络的标准组件，其托管核心呼叫控制逻辑以用于控制和处理由相应的SSP—服务交换点所发起的呼叫（语音、数据、SMS）。SCP实施这些服务。订户经由服务交换点—SSP来与SCP通信。SSP负责由一个运营商的订户所发起的去往相同/其他运营商的另一个订户的呼叫的路由。它实施呼叫状态机，该呼叫状态机的转换由SCP所给定的指令来引导。SCP还与服务数据点—SDP通信，用于在服务的处理期间接入订户相关的信息。该图示出了与每个运营商网络相关联的单个SCP。然而，多个SCP可以存在于每个运营商的网络中。基础运营商102可以被考虑为是包含主SCP101的运营商，并且其他运营商（OP1、OP2、OP3、OP4）可以被称为本地运营商。主SCP101使用diameter协议来与其他运营商的SCP—SCP1、SCP2、SCP3、SCP4通信。diameter协议确保在通信的每个阶段的验证、授权和计费—AAA。diameter协议提供属性值配对—AVP，该属性值配对允许新的命令、属性和功能由运营商网络来定义。在图1中，主SCP101可以被考虑为是包含处理装置的中央diameter节点以及具有对于运营商间的通信所要求的信息的服务器。其他运营商—OP1、OP2、OP3、以及OP4充当客户端diameter节点。图1仅示出了与本发明的实施例相关的网络组件。没有示出电信运营商网络的所有组件。任何移动计算设备能够被用来连接至运营商网络。此外，所示出的订户是一种示例，并且现实中数十万的订户可以作为一个运营商网络的一部分。示出为云的每个移动运营商网络可以使用不同架构框架。所示出的网络运营商可以使用不同的信令和通信方法，如GSM架构、基于互联网协议的多媒体系统（IMS）或者甚至是用于音频和视频通信的会话发起协议（SIP）。主SCP101被配置使得其能够在任何类型的运营商网络之间通信和处理信息。

图2图示了根据如本文所公开的实施例的主服务控制点的框图。所描绘的主SCP101的框图没有示出SCP的所有模块。它示出了与本发明相关的模块。主SCP是基础运营商网络的一部分。主SCP101包含接收机201、发射机202、处理单元203和服务器204。接收机201从不同运营商的各种SCP接收数据和消息，并且将其发送给处理逻辑。处理单元203可以包括控制逻辑205、解码器206和编码器207。解码器206解码由处理单元203所接收的消息，并且控制逻辑205决定针对所接收的消息的适当回复。编码器207然后将该回复编码为SCP可理解的格式。控制逻辑205利用服务器204中可用的所有信息来决定一个回复。控制逻辑205还可以具有所存储的事件的序列。服务器204包括基于SCP IP/SS7的地址数据库208、SCP_ID到MSISDN范围的映射表213、运营商简档数据209、运营商ID210。基于SCP IP/SS7的地址数据库208存储用于主SCP到本地SCP通信所要求的运营商网络的IP/SS7地址。SCP_ID211包含所有连接的运营商网络的SCP的预定义ID，运营商简档数据集209包含每个运营商网络的简档。运营商简档209定义每个运营商提供给其他运营商的权限。这些权限定义了一个运营商网络对于其他运营商网络的运营商间的特征接入权限。例如，运营商OP2可能想要允许从OP1的订户向其旧有的（OP2的）订户的余额结转。主SCP针对来自OP1的结转功能来检查由OP2所给定的接入权限，并且允许从OP1的订户向OP2的订户的任何结转功能。MSISDN范围通常针对运营商网络而被定义。SCP_ID到MSISDN范围的映射表213对于标识请求的/响应的订户的托管SCP是有用的。尽管某些运营商间的特征要求呼叫方和被叫方之间预先达成的协定，但是要求OP1SCP存储链接至呼叫方（自身的订户）的相应被叫方号码。对于其他情况，决定准则/特征可以通过由响应方对服务请求的动态呼叫中的认可/不认可来接入。接入权限因此可以被定义在两个级别。订户到订户接入决定规则/数据可以被限制于进行调用的订户的本地SCP，并且定义运营商的接入能力的运营商到运营商接入权限可以进一步被定义在主SCP。

图3A和3B图示了根据本文所公开的实施例的被用作通信协议的diameter协议分组格式300的示例。diameter协议将主SCP101用作中央节点而充当用于客户端运营商网络之间的通信的装置。消息、命令和功能能够被配置在diameter分组300上，并且跨越网络被发送。diameter协议分组格式300包括消息头部301和消息有效载荷302。消息头部301包括diameter版本303、命令代码版本304、命令代码305、应用ID306、逐跳标识符307以及端到端标识符308。命令代码版本304通常包括7比特。某些比特被保留来指示消息的类型。例如，请求（R）比特可以被设置为指示请求；可代理比特（P）可以被设置为指示需要被代理、重复和重定向消息。这些版本还能够被配置和设置在主SCP的服务创建环境中。命令被指配具有命令代码305。这些命令代码305被定义用于请求和回复/应答消息两者。例如，命令代码CCR代表信用控制请求。应用ID306指代该分组中的应用。应用ID306可以指代第三方应用、验证或计费。应用ID306还能够被定义在主SCP101。逐跳标识符307被用来将请求与回复相匹配。端到端标识符308帮助标识重复消息。消息有效载荷302包括可变数目的属性值配对—AVP309，这些属性值配对封装与该diameter消息相关的信息。图3B进一步详细地描述了消息有效载荷和AVP309。AVP代码310包含与命令代码305相同的代码。标志311被用来定义AVP。标志在长度上是7比特，具有某些被保留的比特。AVP长度312定义了该消息的长度。供应商ID313是可选的字段。数据字段314包含被发送/被接收的所有数据。AVP能够根据要求被创建和使用。

图3C和3D图示了根据本文所公开的实施例的呼叫控制请求消息和呼叫控制应答消息以及它们的定义。图3c描绘了CCR请求消息和属于CCR请求的AVP定义。图3d描绘了CCA消息和属于CCA消息的AVP定义。

图4示出了根据本文所公开的实施例的描述了由呼叫/请求运营商网络的SCP与其他服务提供商的服务控制点所共享的接入权限的示例。图4示出了呼叫运营商SCP_ID401、链接运营商402、与链接运营商相关联的SCP_ID403以及可应用的运营商SCP简档404。SCP简档404定义了针对特定运营商到运营商组合所给定的接入权限。在这里呼叫运营商106是XXX，其具有呼叫运营商SCP_ID为XXX_SCP1。链接运营商402包括YYY_1和ZZZ_1。YYY_1运营商包含两个SCP，一个具有YYY_SCP1为SCP_ID403，并且另一个为YYY_SCP2为SCP_ID403。运营商_SCP_简档404在由每个相关联的运营商供应给它的链接运营商的运营商间的特征/功能的方面定义了接入权限。YYY_SCP1仅允许账户余额查询，而YYY_SCP2授权对XXX_SCP1的账户余额查询以及账户余额提款准许。ZZZ_SCP2授权与XXX_SCP1有关的余额结转，而ZZZ_SCP1没有给出以任何方式对任何运营商间的功能的接入。图6中给出了所允许的功能映射的简档。在其他实施例中，对属于一个运营商的不同SCP被授权的功能可以允许相同的接入权限/功能。考虑当ZZZ_SCP2和ZZZ_SCP1两者都允许所有运营商间的功能时的示例。

图5图示了根据本文所公开的实施例的全球MSISDN—SCPID—SCP地址映射的表格。MSISDN范围501示出了与运营商相关联的MSISDN号范围。运营商ID502示出了与MSISDN范围相关联的运营商。SCP_ID403标识如下的SCP，该SCP托管运营商的相应MSISDN范围的订户数据。SCP IP/SS7地址503定义了用于通信目的的各种运营商的相应SCP的SS7/IP地址。SS7/IP地址将由主SCP用来促进链接运营商的SCP之间的通信。

图6图示了根据本文所公开的实施例的全球简档到功能映射器的表格。运营商SCP简档404示出了可用的对另一个运营商的接入，并且所支持的功能601示出了可接入到属于特定简档的运营商的所支持的功能/服务。考虑其中OP1的订户C想要接入来自OP2的服务的示例。如果运营商OP2仅向OP1授权了余额存款功能，则属于运营商OP1的订户将具有对运营商OP2的另一个订户“D”的仅余额存款功能的接入。对任何其他功能的接入将被拒绝。

图7A、7B、7C是根据本文所公开的实施例的描述了一种运营商间的订户到订户的信用存款的方法的流程图。OP1的订户A发起请求（701），用于在订户B的账户中的存放资金（F1）。订户B属于运营商2—OP2。包含将被结转的金额连同收款方MSISDN细节的请求由订户A以USSD格式或SMS格式发送。OP1的SCP1接收（702）该请求，该请求包含将被结转的金额连同订户B的MSISDN号。SCP1然后请求（703）订户A输入用于验证订户A的PIN号。SCP1然后检查（704）由用户输入的PIN是否正确。如果PIN是不正确的，则订户A被请求（705）再次输入PIN号。如果PIN是正确的，则SCP1检查（706）订户A是否订购该服务。如果该用户没有订购该服务，则订户A被发送（707）请求订购该服务的消息。接下来，SCP应该检查被调用的运营商间的功能是否需要A方与B方之间的预定义协定，或者该接入是否将在呼叫期间由响应方“B”动态地授权。对于诸如余额提款/存款的情况，可以不需要预定义协定。OP2订户B（响应实体）可以被要求在它自己被触发的请求期间允许/不允许来自OP1的订户的服务请求。然而，对于诸如余额查询的情况，被叫方和呼叫方之间的一次性预定义协议可以被存储在OP1的SCP，消除了对于来自OP2的订户的呼叫中请求的需要。SCP1然后检查（708）订户A在账户中是否具有足够的余额。如果订户A不具有足够的余额，则拒绝该服务（709）并且订户A被发送示出了账户余额的消息。如果订户A具有足够余额用于交易，则SCP1向主SCP101发送（710）CCR—信用控制请求。使用如下的diameter协议消息来发送（711）该CCR请求，该diameter协议消息包含将被结转的金额、收款方MSISDN和订户A的运营商ID，并且该CCR请求由主SCP101接收711。主SCP101使用MSISDN—SCP_ID—SCP地址映射表来确定（712）订户B的运营商ID。主SCP101然后检查（713）OP1的SCP_ID403是否有效。如果SCP_ID403是无效的，则OP1的SCP1被拒绝（714）接入主SCP101服务。如果OP1的SCP_ID403是有效的，则主SCP检查（717）OP2是否给予OP1用于执行形式—F1的信用存款的权限。如果OP2没有给予717对OP1的针对功能F1的接入权限，则功能不被支持的消息被发送（718）给SCP1和订户A。如果OP2给予对OP1的接入权限，则主SCP将CCR请求发送（719）给OP2的SCP2，SCP2的地址从MSISDN—SCP_ID—SCP地址映射表中导出。OP2的SCP2接收（720）如下的请求，该请求包含将被存款/被记入贷方的金额连同订户B的细节。SCP2向主SCP发送（721）针对接收CCR请求的确认。OP2的SCP2在订户B的账户中将该金额记入贷方（722）并且向订户B发送（722）消息。SCP2然后经由主SCP向SCP1发送（723）CCR请求成功的消息。SCP1然后将所请求的金额记入订户A的账户借方（724）。SCP1最后向订户A发送（725）消息，指示成功的交易连同被记入借方的金额。方法700中的各种动作可以以所呈现的顺序来执行、以不同的顺序来执行或者同时地执行。进一步地，在一些实施例中，在图7A、7B、7C中所列出的一些动作可以被省略。

图8A、8B、8C是根据本文所公开的实施例的描述了一种运营商间的订户到订户的信用提款的方法的流程图。OP1的订户A发起请求（801），用于从订户B的账户提取资金（F2）。订户B属于运营商2—OP2。该请求由订户A以USSD格式或SMS格式发送。OP1的SCP1接收（802）该请求，该请求包含将被提款的金额连同订户B的MSISDN号。SCP1然后请求（803）订户A输入用于验证订户A的PIN号。SCP1然后检查（804）由订户A输入的PIN是否正确。如果PIN是不正确的，则订户A被请求（805）再次输入PIN号。如果PIN是正确的，则SCP1检查（806）订户A是否订购该服务。如果订户A没有订购该服务，则订户A被发送（807）请求订购该服务的消息。接下来，SCP应该检查被调用的运营商间的功能是否需要A方与B方之间的预定义协定，或者该接入是否将在呼叫期间由响应方“B”动态地授权。对于诸如余额提款/存款的情况，可以不需要预定义协定。OP2订户（响应实体）可以被要求在它自己被触发的请求期间允许/不允许来自OP1的订户的服务请求。然而，对于诸如余额查询的情况，被叫方和呼叫方之间的一次性预定义协议可以被存储在OP1的SCP，消除了对于来自OP2的订户的呼叫中请求的需要。SCP1向主SCP发送（808）CCR—信用控制请求。使用如下的diameter协议消息来发送该CCR请求，该diameter协议消息包含（809）将被结转的金额、“B”的MSISDN和订户A的运营商ID。主SCP101使用MSISDN—SCP_ID—SCP地址映射表来确定（810）订户B的运营商ID。主SCP然后检查（811）OP1的SCP_ID是否有效。如果SCP_ID是无效的，则OP1的SCP1被拒绝（812）接入主SCP服务。如果OP1的SCP_ID是有效的，则主SCP101检查（815）OP2是否给予OP1用于执行信用提款功能F2的权限。如果OP2没有给予815对OP1的针对功能F2的接入权限，则功能不被支持的消息被发送（816）给SCP1和订户A。如果OP2给予OP1接入权限，则主SCP使用MSISDN—SCP_ID—SCP地址映射表来将CCR请求发送（817）给OP2的SCP2IP地址。OP2的SCP2接收（818）如下的请求，该请求包含将被提款的金额连同订户B的细节。SCP2然后检查（820）订户B在账户中是否具有足够的余额用于交易。如果订户B不具有足够的余额，则该服务被拒绝（821）并且失败消息被发送给订户A和SCP1。如果订户B具有足够的余额，则针对该交易，SCP2向订户B发送（822）USSD菜单/消息，请求针对提款的准许。OP2的订户通过选择允许选项或不允许选项来响应基于USSD菜单的请求。如果订户B不给予（823）针对提款的准许，则服务对订户A被拒绝（824）并且失败消息经由主SCP101被发送给订户A。如果订户B允许提款，则OP2的SCP2从订户B的账户提取825该金额，并且向订户B发送825消息。SCP2然后向主SCP101发送（826）CCR请求成功的消息。SCP1然后将所请求的金额记入（827）订户A的账户贷方。SCP1最后向订户A发送（828）消息，指示成功的交易连同被记入贷方的金额。方法800中的各种动作可以以所呈现的顺序来执行、以不同的顺序来执行或者同时地执行。进一步地，在一些实施例中，在图8A、8B、8C中所列出的一些动作可以被省略。

图9A、9B、9C是根据本文所公开的实施例的描述了一种运营商间的订户到订户协同计费的方法的流程图。协同计费方法允许涉及语音/视频/sms呼叫的订户通过由呼叫订户所指定的部分来共享呼叫费用。OP1的订户A发起请求（901），请求订户B部分/全部支付接下来由订户A对他的呼叫。订户B属于运营商2—OP2。该请求由订户A通过USSD或SMS请求发送给他的/她的相应SCP。由呼叫方A所发送的用于建立与被叫方B的用于接下来的呼叫的协同计费关系的样本USSD请求是：*<ACCESS CODE>*<FRACTIONCHARGE>*<MSISDN of B>。OP1的SCP1接收（902）该请求，该请求指定将在被叫方“B”上被征收的总呼叫费用的分数（50—呼叫费用的50%；100—全部呼叫费用），连同订户B的MSISDN号。订户“B”的计费可以根据按照所订购的收费计划的可应用至订户“A”的计费比率来完成。SCP1然后请求（903）订户A输入用于验证订户A的PIN号。SCP1然后检查（904）由订户A输入的PIN是否正确。如果PIN是不正确的，则订户A被请求（905）再次输入PIN号。如果PIN是正确的，则SCP1检查（906）订户A是否订购该服务。如果订户A没有订购该服务，则订户A被发送（907）请求订购该服务的消息。接下来，SCP1应该检查被调用的运营商间的功能是否需要A方与B方之间的预定义协定，或者该接入是否将在呼叫期间由响应方“B”动态地授权。对于诸如余额提款/存款的情况，可以不需要预定义协定。OP2订户（响应实体）可以被要求在它自己被触发的请求期间允许/不允许来自OP1的订户的服务请求。然而，对于诸如这些的情况，被叫方和呼叫方之间的一次性预定义协议可以被存储在OP1的SCP，消除了对于来自OP2的订户的呼叫中请求的需要。SCP1基于从呼叫订户所请求的分数来计算被叫方应该被计费的比率。费用的剩余部分将由呼叫方负担。重要的是，注意到在这里运营商可以对于这样的呼叫向呼叫方征收定期费用或基于量的固定费用。SCP1向主SCP发送（908）CCR—信用控制请求。使用如下的diameter协议消息来发送该CCR请求，该diameter协议消息包含（909）被叫方需要被计费的比率、B的MSISDN、A的MSISDN和订户A的运营商ID。主SCP101使用MSISDN—SCP_ID—SCP地址映射表来确定（910）订户B的运营商ID。主SCP然后检查（911）OP1的SCP_ID是否有效。如果SCP_ID是无效的，则OP1的SCP1被拒绝（912）接入主SCP服务。如果OP1的SCP_ID是有效的，则主SCP101然后检查（913）OP2是否给予OP1用于执行协同计费功能F7的权限。如果OP2没有给予对OP1的针对功能F7的接入权限，则功能不被支持的消息被发送（914）给SCP1和订户A。如果OP2给予OP1接入权限，则主SCP将CCR请求发送（915）给OP2的SCP2IP地址，其地址从MSISDN—SCP_ID—SCP地址映射表中导出。OP2的SCP2接收（916）如下的请求，该请求包含被叫方“B”将被计费的比率连同订户A和B的MSISDN细节。SCP2向主SCP发送（917）CCR响应确认。SCP2然后检查（918）订户B在账户中是否具有足够的余额用于交易。如果订户B不具有足够的余额，则该服务被拒绝（919）并且失败消息被发送给订户A和SCP1。如果订户B具有足够余额，对于该交易，SCP2向订户B发送（920）USSD菜单/消息，以请求如下的准许，该准许用于允许接下来来自订户“A”的将被计费的呼叫将以所定义的比率在他的账户上被计费。OP2的订户B通过选择允许选项或不允许选项来响应基于USSD菜单的请求。如果订户B不给予（921）准许，则服务对订户A被拒绝（922）并且失败消息经由主SCP101被发送给订户A。如果订户B允许协同计费，则OP2的SCP2向主SCP101发送（923）CCR请求成功的消息。此外，SCP2还做出对如下事实的记录：对于接下来来自订户“A”的呼叫，订户“B”将以主SCP所指定的认定比率被计费。SCP1最后向订户A发送（924）消息，指示成功的操作。由订户“A”向订户“B”所做出的接下来的呼叫的呼叫费用在这两个订户之间共享。方法900中的各种动作可以以所呈现的顺序来执行、以不同的顺序来执行或者同时地执行。进一步地，在一些实施例中，在图9A、9B、9C中所列出的一些动作可以被省略。

图10A、10B是根据本文所公开的实施例的描述了针对订户到订户的基于运营商间凭单的充值的另一种运营商间的使用情况的流程图。基于运营商间凭单的充值允许属于运营商OP1的订户A对属于运营商OP2的另一个订户B的账户充值。OP1的订户A发起请求（1001），请求对另一个订户B充值。订户B属于运营商2—OP2。该请求由订户A通过USSD或者通过SMS请求或者通过OP1的交互式语音响应系统来发起，给出订户B的凭单号和MSISDN。凭单可以是由运营商OP1针对基于运营商间凭单的充值的特定情况而供应的特殊凭单卡。OP1的SCP1接收（1002）该请求，该请求指定了充值凭单细节和订户B的MSISDN。SCP1然后请求（1003）订户A输入用于验证订户A的PIN号。SCP1然后检查（1004）由订户A输入的PIN是否正确。如果PIN是不正确的，则订户A被请求（1005）再次输入PIN号。如果PIN是正确的，则SCP1检查（1006）订户A是否订购该服务。如果订户A没有订购该服务，则订户A被发送（1007）请求订购该服务的消息。SCP1导出验证凭单卡号并且导出将被记入账户贷方的相关联金额。SCP1向主SCP发送（1008）CCR—信用控制请求。使用如下的diameter协议消息来发送CCR请求，该diameter协议消息包含（1009）将被记入贷方的金额、订户B的MSISDN、订户A的MSISDN和OP1的运营商ID。主SCP101使用MSISDN—SCP_ID—SCP地址映射表来确定（1010）订户B的运营商ID。主SCP然后检查（1011）OP1的SCP_ID是否有效。如果该SCP_ID是无效的，则OP1的SCP1被拒绝（1012）接入主SCP服务。如果OP1的SCP_ID是有效的，则主SCP101然后检查（1013）OP2是否给予OP1用于执行基于凭单的充值—功能F8的权限。如果OP2没有给予对OP1的针对功能F8的接入权限，则功能不被支持的消息被发送（1014）给SCP1和订户A。如果OP2给予OP1接入权限，则主SCP向OP2的SCP2IP地址发送（1015）CCR请求，其地址从MSISDN—SCP_ID—SCP地址映射表中导出。OP2的SCP2接收（1016）如下的请求，该请求包含A的MSISDN、B的MSISDN以及将被记入到订户B的账户贷方的金额。SCP2向主SCP发送（1017）CCR接收响应确认。OP2的SCP2将该金额记入（1018）订户B的账户的贷方，向主SCP101发送（1019）CCR请求成功的消息。此外，SCP2还向订户B发送（1020）通知，指示他的账户已经把由MSISDN“A”的相应金额记入贷方。SCP1最后向订户A发送（1021）消息，指示成功的操作。方法1000中的各种动作可以以所呈现的顺序来执行、以不同的顺序来执行或者同时地执行。进一步地，在一些实施例中，在图10A、10B中所列出的一些动作可以被省略。

图11图示了根据本文所公开的实施例的本地SCP功能。主SCP可以允许属于运营商网络的一个本地SCP的订户持有与其他网络运营商的多个链接账户。这样的订户可以被允许管理和控制运营商间的服务以及每个运营商内的服务。例如，持有这样的账户的商业运营订户能够链接多个用户账户并且使用这个系统用于每周向用户结转收入。假如当订户使用不同城市中的不同运营商服务时，他可能希望控制和管理来自每个地方的所有他的用户账户，并且可能也要求运营商间的服务。发射机202向相应的运营商网络中的相应SCP发送交叉回复消息。本地SCP功能示出了基础账户连同该订户的基础账户号。屏幕示出了被链接至基础账户的账户连同运营商ID。本地功能示出了基础账户连同该订户的基础账户号。它示出了链接账户中的一个账户。它还示出了基础运营商的订户能够使用基础账户号在OP2上执行的服务。

在一个实施例中，该方法促进了通过Diameter接口经由主SCP在SCP之间或在其他网络实体（如运营商B的SSP和运营商A的SCP）之间的相关信息的动态共享。这个信息可以对应于与漫游者的CDR数据、在用于记账目的的在具有运营商A的SCP的运营商B覆盖范围下的漫游、等等有关的信息。

对特定实施例的前述描述将如此完全地揭示本文的实施例的一般本质，使得其他人通过应用当前的知识能够容易地修改和/或适配这样的特定实施例以用于各种应用，而不偏离一般概念，并且因此，这样的适配和修改应当并且旨在被包含在所公开的实施例的等价物的含义和范围内。将理解，本文所采用的措词或术语用于描述而非限制性的目的。因此，尽管已经根据优选实施例描述了本文的实施例，但是本领域的技术人员将认识到，在本文所描述的权利要求的精神和范围内能够带有修改地实行本文的实施例。

Claims (15)

1.一种用于通过采用主服务控制点（SCP）来向多个网络运营商的多个订户提供运营商间的增值电话服务和补充电话服务的方法，所述方法包括：

由所述主SCP从运营商网络A的订户接收针对与运营商网络B的第二订户有关的服务的服务请求消息；

由所述主SCP验证所述服务请求消息，以用于分析所述运营商网络A对于所述运营商网络B的接入权限；

如果所述服务被准许，则由所述主SCP为所述运营商网络A处理所述服务；以及

由所述主SCP向所述运营商网络B发送响应消息。

2.根据权利要求1所述的方法，其中所述接入权限定义了由一个运营商的服务控制点用于对另一个运营商的服务控制而支持的服务。

3.根据权利要求1所述的方法，其中所述方法提供了用于如下的运营商间的特征实施的通用机制，所述运营商间的特征实施要求相应的运营商SCP通过所述主SCP来共享相关的订户/计费数据。

4.根据权利要求1所述的方法，其中所述方法促进了属于不同运营商的订户协同地对特定服务付费，像诸如SMS、数据呼叫。

5.根据权利要求1所述的方法，其中所述方法促进了针对另一个运营商的订户所请求的运营商间的服务的动态订户认可。

6.根据权利要求1所述的方法，其中所述方法可应用至包括IP多媒体服务（IMS）、会话发起协议（SIP）、全球移动通信系统（GSM）的架构。

7.根据权利要求1所述的方法，其中所述方法进一步包括：通过所供应的diameter接口，经由主SCP，在SCP或其他运营商特定网络实体之间动态地共享相关信息。

8.根据权利要求1所述的方法，其中所述方法进一步包括：

定义用于处理网络运营商与服务控制点之间的消息的各种服务；以及

针对所述服务控制点之间的相关消息发送，为每个服务提供商创建新的属性值。

9.根据权利要求8所述的方法，其中服务的定义包括由使用主服务控制点（SCP）相互连接的所述网络运营商所供应的运营商间的服务。

10.一种用于向多个网络运营商的多个订户提供运营商间的服务的主服务控制点，所述服务控制点包括：

存储关于运营商SCP的合并网络信息、运营商到运营商的运营商间的服务协定；

从运营商网络A接收针对与运营商网络B有关的服务的服务请求消息；

验证所述服务请求消息，以用于分析所述运营商网络A对于所述运营商网络B的接入权限；

如果所述服务被准许，则为所述运营商网络A处理所述服务；以及

向所述运营商网络B发送回复消息。

11.根据权利要求10所述的主服务控制点，其中所述接入权限定义了由一个运营商的服务控制点对另一个运营商的服务控制所授权的运营商间的服务接入。

12.一种在通信网络中用于向多个网络运营商的多个订户提供运营商间的服务的系统，所述系统包括多个服务控制点、主服务控制点，进一步地，所述主服务控制点被配置用于：

从运营商网络A的订户接收针对与运营商网络B的第二订户有关的服务的服务请求消息；

验证所述服务请求消息，以用于分析所述运营商网络A对于所述运营商网络B的接入权限；

如果所述服务被准许，则为所述运营商网络A处理所述服务；以及

向所述运营商网络B发送回复消息。

13.根据权利要求12所述的系统，其中所述系统验证所述消息以确定所述接入权限，其中所述接入权限定义了由一个运营商的服务控制点用于对另一个运营商的服务控制而支持的服务。

14.根据权利要求12所述的系统，其中所述系统进一步被配置为促进属于不同运营商的订户协同地对特定服务付费，像诸如SMS、数据呼叫。

15.根据权利要求12所述的系统，其中所述系统进一步被配置为提供用于如下的运营商间的特征实施的通用机制，所述运营商间的特征实施要求相应的运营商SCP通过所述主SCP来共享相关的订户/计费数据。

Images