专利名称：移动电信网络中的呼叫处理的制作方法
技术领域：
本发明涉及移动电话网络，特别是所述网络中的呼叫或者其它用户事件或会话的 处理。这些呼叫、事件和会话可包括，例如，消息(SMS)的发送和接收、通用分组无线系统 (GPRS)事件、因特网和内部网会话、以及多媒体业务的提供。其次，术语“呼叫”用于指任何 或所有所述呼叫、事件或会话。呼叫处理是由网络和网络内提供的业务响应于用户发起的 呼叫而执行的操作或多个操作。呼叫处理(call processing)可被认为包括呼叫处理(call handling)和业务处理的一种或两者都包括，前者是在网络上实现呼叫相关的操作，而后者 是业务递送相关的操作，该业务是呼叫的一部分。
背景技术：
移动电信网络提供比从一个电话(移动或陆线)到另一个电话(移动或陆线)通 信路径的简单建立更多的业务。例如，可为用户提供到网络的诸如语音消息的业务，以及网 络运营商也可提供诸如呼叫禁止、呼叫转移、消息接发功能(SMS)、语音信箱、WAP、因特网接 入、定位服务以及内容服务的功能。进一步的问题是移动电信网络通常具有比基于陆地的 网络更复杂的计费结构，而且呼叫预付费的功能意味着网络必须能够确定使用的移动电话 是否能被允许执行功能。为了做到这一点，移动电信网络可拥有一系列呼叫处理和/或业务处理平台，每 个都能实现一个或多个特定功能。呼叫的处理可涉及多个平台，各自平台执行部分呼叫处 理，以及呼叫在处理呼叫的不同阶段从一个平台传送到另一个。因此，例如，如果一个预付 费用户希望读写语音消息，访问用户是否有足够的余额来使用这项业务的操作和语音消息 提供本身可能会在不同的平台上实现。应注意到平台是一个逻辑结构，也就是说，实现所述 功能或由平台提供的功能所需的硬件/软件可分布于网络。在当前的一些配置中，每个平台必须充当相对自足的单元，因此它们必须能够访 问每一个用户的信息。因此，在已知配置中，呼叫处理平台必须具有或者能访问一个专有数 据库，而且必须同样能够明白所有可能使用的指令(即，从用户或网络来的处理命令)。这就造成了三个问题。第一，这使得每个呼叫处理平台很复杂。第二，由于不同的 平台可能运行不同的协议，就会出现兼容问题，比如说当呼叫在呼叫处理的不同阶段从一 个平台传送到另一个的时候。第三，如果移动电话通信网络的用户移动(“漫游”)到另一 个网络例如从一个国家移动到另一个国家，由本地网络提供的业务可能就不能由新网络提 供，这样在用户移动(“漫游”)时就不能给用户提供这些功能。这第三个问题对预付费用 户来说尤其突出；他们的余额存储在本地网络但是他们漫游的网络不能访问到他们的余额 状态，因此当前的配置不允许预付费用户像其他用户那样广泛的漫游。
发明内容
发明的第一方面本发明寻求解决这些问题，并且最广泛的，本发明的第一方面提出网络提供管理 或“调度”功能，它们在平台或多个平台(包括呼叫处理和业务处理平台之一或两个)的呼 叫处理中互相作用以确定如何处理呼叫。这样，例如，当用户发起一个呼叫，该呼叫在用于 呼叫处理的平台处接收到，该平台将有关呼叫的信息和呼叫所需的功能传送给所述调度功 能，使得调度功能来确定如何处理该呼叫。所述调度功能接着执行下面动作的任一个或全部1.确定呼叫所需的将被应用于呼叫和/或呼叫处理操作的业务。2.确定当前处理呼叫的平台是否能执行呼叫所需的功能。如果不能，则促使该平 台将呼叫传递给另一个能够提供适当功能的平台或促使业务处理平台操作呼叫，并因此确 定需要哪个业务平台来提供呼叫所需的作为业务处理的一部分的业务。3.合并处理呼叫将需要的这个或每个平台所要求的数据。接着提供适当的数据给 一个或多个平台。这在呼叫由多于一个的平台处理的时候尤为重要，因为相同的数据可能 会由多个平台使用。也同样允许数据依据不同的协议进行适应性改变。4.执行所需的任何协议转换以确保处理所述呼叫所需的一个或每个平台能正确 的工作。5.如果处理呼叫需要一系列步骤，确保这些步骤能以正确的顺序执行。实际上，任一呼叫至少需要有动作1和2，而且所述调度功能至少应确保在动作4 上平台能正确地处理呼叫。根据呼叫可能会需要动作3和5，但并不总是必要的。调度功能合并处理呼叫所需的数据意味着每个平台可被简化，因为每个平台不再 需要具有完整的用户信息数据库。代替的，信息可由调度功能在处理呼叫的时候提供。再 者，由于所述调度功能确定呼叫所需的处理和由此确定处理涉及的平台，调度功能可提供 协议转换信息以使得呼叫能在多个不兼容的平台间传递。第三，因为能触发一个平台将呼 叫传递给另一个平台，当第一个平台不能执行呼叫所需的功能或多个功能时，调度功能可 允许在用户漫游时，通过将用户漫游至的网络内的平台的呼叫处理传递给另一个平台，比 如在本地网络，提供给用户在本地网络所有可获得的功能。这种特性也可在本地网具有拥 有不同能力的平台时用于该本地网。为了执行这些操作，所述调度功能必须能够访问网络的一个或多个数据库提供的 适当用户信息，以及能够建立所需的呼叫处理次序和/或业务处理次序。因此，如上所述，调度功能可执行以下的某些或全部动作识别呼叫处理的第一阶段是为业务调度识别用于呼叫的业务和/或呼叫所需的 呼叫处理操作。所述业务处理和呼叫处理操作主要通过呼叫本质(nature)来确定，但为了 实现所述识别业务调度必须向其它数据库发送请求，和/或检查内部数据。协商呼叫处理的第二阶段是为业务调度确定所述平台、特别是平台的业务交换 功能是否能执行已经识别的所有业务和处理操作。如果不能，确定一个合适的其它平台来 执行所述业务和/或呼叫处理，或至少其中的某些。相关如前所述，所述业务调度能合并(使相互关联)平台或多个平台需要的数 据。这种相关可包括来自不同平台的数据的合并，其中呼叫需要这些多个平台，以便业务调度为呼叫处理建立一个唯一的数据集。仲裁当呼叫处理涉及的平台的协议不同时，由业务调度来执行必要的协议转换 是可取的。接着业务调度确保在呼叫处理过程中相关的协议和过程相符。排序在呼叫处理涉及多个步骤的地方，业务调度确保那些步骤以正确的顺序执 行。当提供多个业务时，也进行排序。本发明的第二方面本发明的第二方面涉及呼叫可能是多媒体消息的情况。多媒体消息是一种可以包 含图象、视频、文本和/或语音或其它声音数据或其它这些媒体的结合。在接下来的讨论 中，这样的呼叫被称为MMS呼叫。设计出专有的用于匪S呼叫处理的装置是可能的，考虑到允许这些呼叫到和来自 一个制造商专门为它们设计的设备。然而，在一个大型移动电话网络中，MMS呼叫可能从网 络外发起(例如，从其它网络)，或者使用来自不同制造商的发起设备。因此，很必要开发更 广泛适用的用于处理MMS呼叫的装置。最广泛的，本发明的第二方面提出了呼叫最初由协议转换单元进行处理，该协议 转换单元将至少部分表示呼叫的数据转换为标准协议。获得的信号接着发送至传输设备， 在那里该信号被用作处理呼叫的触发。如果呼叫指定为另一个网络，它将被从传输设备发 送至另一个转换单元，该单元将其从标准协议转换成该另一个网络的协议，或者由传输设 备为网络中的前向分布返回至发起网络的相同或等同的转换单元。在任一种情况下，呼叫 的处理响应于通用协议中的触发而处理。应注意到尽管本发明的第二方面已披露了对MMS呼叫的处理，但所述第二方面并 不限制于这类呼叫的处理。以上讨论的第二方面的原理可适用于其他类型的呼叫，例如电 子邮件的处理、其它文本消息或万维网信号和地址。然而，在下面的讨论中，为了术语的简 洁，当讨论第二方面时，以下将仅参照MMS呼叫。为了响应所述触发，需要一个合适的暂时存储MMS呼叫的单元，以便可以执行适 当的分析来确定接着MMS呼叫需要如何处理。所述分析可由本发明的第一方面中的调度功 能来执行，这样它能确定需要哪个平台来为MMS呼叫提供适当功能。通用协议中的数据的使用被用作触发意味着安排计费根据呼叫的来源并基于消 息的大小是可能的。MMS消息可包括大量数据，取决于发送的诸如声音和/或图象的媒体的 复杂性，以及触发的使用允许网络运营商根据MMS呼叫加在网络上的负载量来计费。同样 也使得预付费装置的一体化成为可能。
现在将通过范例结合附图详细描述本发明的实施方式图1是显示调度功能到移动电信网络的其它功能的链接的原理图；图2是显示由图1中的调度执行的操作的流程图；图3是说明使用本发明第一方面进行的呼叫处理的第一个例子的框图；图4是说明使用本发明第一方面进行的呼叫处理的第二个例子的框图；图5是说明使用本发明第一方面进行的呼叫处理的第三个例子的框图；图6是说明本发明第一方面的一个实施方式的框图7是说明本发明第二方面的一个进一步的实施方式的框图；以及图8是说明图7的实施方式中的处理的流程图。
具体实施例方式第一实施方式本发明的第一实施方式涉及一个实施本发明第一方面的移动电信网络，即管理或 “调度”功能的提供。首先参考图1，移动电信网络执行多种功能，并且这些功被认为能分配给多个平 台。那些平台中的一些参与网络的内部操作和从网络的一个点到另一个点的电信链接的建 立，而另一些则是执行业务操作的平台。图1标识了五个网络(或业务处理)平台PCF10，为预付费控制功能SLR12，为位置寄存器(业务位置寄存器)，相当于在W0/GB95/02352中描述的寄存 器，该寄存器包含将每个电话号码与网络的多个归属位置寄存器(HLR)中相应的一个相关 联的信息，该归属寄存器在图1中未显示。HCF13，为归属位置寄存器控制功能SCF14表示普通业务平台，用于执行与呼叫相关的其它业务。PCF10、SLR12和 HCF13的每一个都可被认为是一个特定类型的SCF。图1中所示的呼叫处理平台包括MSC 20，为移动交换中心，用于为呼叫提供一个适当的通信路由。实际上，通信网 络会具有许多MSC20。SGSN21，为服务GPRS支持节点。SMC 23，为短消息中心。VPS24，为用于接收语音消息的语音处理系统。Wilefire25,为语音激活的语音邮件以及个人助理业务。服务节点26，为实体(设备和/或功能)移动业务控制、业务细目和专门化资源功 能WAP服务器27，是能够提供可被发送给移动电话的格式的网页的网页服务器。根据本发明的第一方面，所有这些平台通过调度功能30链接起来，所述调度控 制平台10-14和20-27的动作，依靠这种方式处理呼叫和业务。所述调度功能链接至网 络功能10-14和呼叫处理平台20-27，并同样链接至数据库31。数据库31可以是一个如 W099/35867中描述的分布式数据库。图2接着说明由图1中的调度功能30执行的主要操作。当呼叫涉及平台10-14 和/或20-27中的一个时，所述调度功能30建立仲裁操作40，该操作与呼叫被接收的平台 相互作用，也可能基于呼叫的种类(nature)与其它的平台相互作用。为允许调度功能30执行所述的仲裁操作，调度功能30执行一个识别操作41，该操 作识别呼叫要求的业务或多个业务，收集(assemble)允许业务处理所需的数据，以及收集 (assemble)呼叫处理所需的数据。为了实现这些，调度功能30访问数据库31来确定涉及 呼叫和/或用户的相关数据。
根据由操作41识别出的呼叫所需的业务或多个业务的种类，然后调度功能30 必须确定接收到呼叫的平台是否有能力处理呼叫，以及哪一种或哪一些业务是该呼叫需 要的。因此，该调度功能执行链接到适当平台20-27的业务交换功能(SSF)上的能力 (capability)操作41，来确定SSF的性能。如果该平台20-27不能提供适当的操作，该调 度功能30接着建立到其它能够执行那些业务的平台的链接并操作以完成其它平台的这些 功能。所述业务交换功能(SSF)是接收来自呼叫的点(points in call PIC)已经到达的 呼叫处理平台的指示的功能。SSF接着请求来自业务控制功能(SCF)的指令。SCF实现业 务逻辑并对SSF给出指令来接续、拒绝和/或执行诸如修改呼叫指令、待命(arm)小区报告 和测量呼叫时间的其它操作。SSF通过一个预定状态装置采用指令和步骤，将指令和信息传 回适当的呼叫处理软件和SCF。SSF位于称为业务交换点(SSP)的物理节点中，SCF位于称 为业务控制点(SCP)的物理节点中。因此，如果呼叫要求多个业务，那么调度功能30必需执行一个相关操作43来使任 一平台10-14和20-27提供适当操作(呼叫处理、业务处理)所需的信息相关。所述相关 通常涉及若干个平台，调度功能从数据库31获得一个用于呼叫的唯一数据集，该数据集可 由所述调度功能30和适当的平台10-14和20-27使用以执行所需的操作。这样，调度功能 能够执行用于能力协商的相关，该相关通常涉及平台20-27，以及多个业务相关，通常涉及 平台10-14。在涉及这些多个平台的地方，调度功能30必需执行排序操作44，该操作确定 提供所述多个操作的顺序，和由此平台10-14和20-27提供那些操作的顺序。甚至在不需 要多个平台的时候也需要该排序操作44，以及因此在单个平台提供多个业务的时候，不执 行相关操作43。现在将参考图3-5描述在图1中说明的功能网络操作的三个例子。在所述图中， 圈中的数字表示呼叫处理的阶段。第一实施方式的范例1在该例中，假设呼叫要求多个业务。来话在平台的SSP40处接收，呼叫已经在该平台接收，而这触发一个信号至调度 功能30而且调度功能30访问数据库31来确定要执行的操作。所述触发包含表示响应于该 呼叫而要被执行的操作的数据。在图3的例子中，假设所述操作需要访问SCP41、42。然而， 在与SCP41、42通信之前，调度功能30与数据库31通信以收集(assemble)所有将要由呼叫 和/或业务处理平台执行的所有业务所必需的数据。调度功能30接着顺序询问SCP41、42 来触发每一个SCP41、42生成适当信息，该信息由调度功能30整理，接着将响应传至SCP40， 以实现呼叫的接续。在某些情况中，由各自SCP41、42执行的操作是彼此独立的。因此，例如，SCP41、 42之一可能仅仅将呼叫号码转换成另一种号码，而且在这种情况下，调度功能30仅仅收 集(assemble)这些操作的集合。尽管这样，在某些情况，在呼叫的自始至终可能需要涉及 SCP4U42中的一个。例如，如果SCP中的一个链接到预付费呼叫涉及到的SCF14，那么调度 功能30就可能需要产生一个集合结果给SSP40。第一实施方式的范例2图4显示一个范例，其中首先接收呼叫的SSP不能执行所有需要的操作。因此，如果呼叫在平台的第一个SSP50处接收，而该SSP50不具备足够的能力来
8执行需要的操作，则SSP50与调度功能30通信。在范例1中，调度功能访问数据库31来 获得处理呼叫所必需的所有数据，接着给呼叫分配一个临时相关身份，其相关身份被传回 SSP50。该相关身份使得SSP50将呼叫传至能提供呼叫所需操作的平台的第二个SSP51，以 及由SSP51进行的呼叫的接收则生成一个对调度功能的触发，该功能访问适当的SCP52来 获得传送给SSP51的适当的响应信息，接着允许呼叫在处理它的平台内接续。这样，调度功能30依据处理呼叫需要执行的操作来选择该第二个SSP50，并由此 识别来自数据库31的数据来处理呼叫，适当的SSP51来处理呼叫，在生成所述传送至SSP50 的相关身份之前。应指出，在范例2中，假设呼叫仅要求到一个SCP52的访问。在某些情况下，需要 如范例1 一样询问多个SCP，而且一旦呼叫被传递至SSP2，所述询问可以以范例1相同的方 式出现，尽管已经指出，到那时为止，调度功能30将已经访问了数据库31。第一实施方式的第三范例第三范例是关于当呼叫处理涉及不同的协议时的情况。参考图5，在SSP60接收呼 叫，SSP60生成发送到调度功能30指示需要的业务的信号。在这个范例中，假设SSP60以 及此后它生成的信号，工作于第一协议A。调度功能30可像之前那样访问数据库31来获得 用于呼叫处理的数据，如果来自网络的触发本身没有包括足够的信息，则询问适当的SCP61 以获得处理呼叫的信息。如果SCP61以及此后将要接收和发送的信号，工作于第二协议B， 那么调度功能30如图5中所示的那样在不同协议间仲裁。如果调度功能30已经从数据库 31和SCP61那里收集(assemble) 了所有处理呼叫的信息，那么它以适合于SSP60的协议A 将响应传递至SSP60。正如可从以上三个范例中看出的那样，调度功能30每次访问数据库31，它就得知 呼叫处理平台中的一个已经接收到呼叫，对于所有种类的呼叫，调度功能30进行识别，并 将处理呼叫必需的数据收集在一起。因此，呼叫处理平台可以相对简单，仅存储最少的数 据。所需的特定用于呼叫处理的任何数据都可从调度功能30传送，该调度功能30已经从 数据库31接收到了所述数据。第二实施方式现在将描述本发明的第二实施方式，该实施方式是本发明第一方面的具体实施。参考图6，在例如用户的移动电话手持机100处发起一个多媒体消息(MMS)呼叫， 该消息(呼叫的多媒体内容)从用户发送到多媒体消息业务中心(MMSC) 110。该始发手持 机100通过GPRS140和WAP网关118发送MMS至MMSC 110。MMSC充当MMSC呼叫的临时存 储器，并且为了这个目的，匪SC可具有与此相关的消息存储器112。匪SC 110依照它所在的网络确定的协议工作。在本范例中，匪SC 110通过中间件 接口 131与业务调度单元114通信，该业务调度单元执行以上参考图1-5讨论的本发明的 第一方面的调度功能。因此，业务调度单元114确定呼叫必需的处理。图6说明一个实施方式，其中匪S呼叫计划送至始发网络自身中的目的地。因此， 一旦业务调度114确定了呼叫必需的处理，就将呼叫处理返回MMSC 110。实际上，MMSC可 发送WAP消息给一个推送代理网关115，该网关将消息转发至SMSC 116和适当的能显示该 MMS呼叫消息的手持机117上。这由图6中的箭头5和6表示。该推送代理网关115用作 格式化和传送源自匪SC 110向上传送到构成SMSC 116的短消息业务(SMS)结构的信号，以便产生适当的传送。可使用WAP网关来实现所述推送代理网关115和WAP网关118，由于这些网关可 包含两种单元的必要功能性。在负载平衡配置中优选使用这样的两个网关，一个网关用作 WAP网关，而另一个用作推送代理网关。尽管如此，由于每个网关具有两种功能，例如，如果 一个出现故障，使用一个这样的WAP网关来执行两种功能也是可能的。如在图1中所示说明的，业务调度可连接到如在PCTW099/35867中详细说明的业 务数据功能(SDF)单元120上，以及如在PCTW096/11557中详细说明的寄存器单元(SLR单 元)121上。这样，SDF单元120可以存储匪SC 110将要求的匪S用户数据。在执行功能 中，业务调度单元114可因此从SDF单元120获得信息来确定如何处理呼叫。同样，业务调 度单元114也可从SLR单元121中提取相关信息来获得始发和目的地方MSISDN号码。那么有两种可能性。第一种是始发手持机100具有后付费配置，网络运营商运行 MMSC 110。在这种情况下，应准备适当的计费配置。但是，如果始发手机110工作于预付费 配置(arrangement)，那么必须在转发MMS呼叫之前核对适当的余额(credit)。为达到这 个目的，业务调度单元110可发送一个信号给预付费控制功能(PCF) 122，该信号指示始发 方以及MMS呼叫消息的种类和大小的指示。该预付费控制功能122接着发送适当的信号给 在123图示的网络计费操作。计费操作包括网络仲裁系统(匪S)单元124，该单元生成信号 以使估计和计费功能125、126得以执行。图6也说明WS单元124接收来自匪SC 110自 身的触发信号。匪SC 110可包含用户数据库接口单元(在图6中未示出)，该单元通过中间件接 口 131将MMSC 110生成的请求传递至业务调度单元114。这样业务调度单元114可以通过 MMSC 110控制随后的呼叫处理。假设现在有图6中的手机100生成了一个MMS呼叫，而作为目的地终端的手机117 不支持多媒体功能。这种情况下，MMSC 110将该呼叫路由到一个存储该MMS呼叫的传统手 机网关141。另外，它生成SMS格式的消息至SMSC 116，在那儿被转发至手机117来通知手 机117的用户已经存储了一个多媒体消息。给手机117的信号也可以是标准消息。用户例 如手机117的用户可以使用合适的计算机144通过因特网115连接到传统手机网关141，以 允许取回该多媒体消息。传统手机网关141可包括网页服务器以提供适当的接入。而且， 多媒体消息被发送至一个电子邮件地址也是可能的。这由邮件传送代理146执行，该邮件 传送代理从MMSC 110接收呼叫并将其转换成电子邮件通过因特网145发送至适当的计算 机 144、147。该实施方式可能有许多变形。例如，图6假设始发手机100和目的地手机117都 是同一个网络的用户并且都在它们的本地网。然而它们是不同网络的用户也是可能的，在 这种情况下，呼叫需要从始发网络的MMSC 110传送至目的地网络的对等匪SC。业务调度 114的运作就更为重要。实际上，业务调度114必须确定哪个网络拥有目的地手机117的号码和因此将MMS 发送到哪里以及如何适当地更改消息的地址以确保能到达正确的网络。拥有目的地号码的网络不具备和匪SC 110的运营商的互连协议是可能的，这种 情况下，业务调度114可决定将消息发送到传统手机网关141。业务调度也将在发送该MMS时识别始发手机当前位于哪个网络。这可用于适当更改费率。当目的地手机117从本地网漫游的时候，匪SC将发送消息(例如，一个SMS消息) 到目的地手机117来告知用户与本地网匪SC 110联系，以便从本地网接收匪S消息。当始发手机100从本地网漫游时，匪S消息被路由至本地网的匪SC 110，接着以参 考图6描述的方式进行处理。这些操作在支持适当网络容量以便发送和接收MMS消息的访 问(漫游到的)网络是可靠的。如果假设从一个网络发送到另一个网络的任意多媒体消息都只有一个接收者，那 么在发送消息之前需要有一个递送地址，该地址允许消息直接路由到正确的网络。目的地 手机所在的网络需要某种肯定确认消息确认从始发网络的合法始发手机接收到消息。这需 要免除欺骗或其它问题的危险。在MMS呼叫被成功的接收和通过适当的接受核对之后，需 要由目的地网络的运营商来生成合适的计费信息，这些接受核对可包括，例如，内容类型和 大小标准、消息大小、跨接保护、以及每个目的地网络的运营商或目的地手机用户自身采用 的编块规则是否相符。应当注意，讨论的用于处理MMS呼叫的一些组件的详细构造已经在本领域公知规 范3GPP (第三代合作项目)、特别是规范23. 140中描述了。第三实施方式现在将参考图7描述本发明的第三实施方式。该第三实施方式是本发明第一方面 和第二方面的具体实施。该实施方式的许多特征与图6的第二实施方式相同，将使用相同 的附图标记来表示相同的部分。本发明的第二方面中，呼叫转换成预定的通用协议，用通用协议生成事件触发，事 件触发用于启动呼叫处理。为了实现这些，MSC呼叫转换成标准协议，例如简单邮件传送协 议(SMTP)，并传至SMTP代理113。SMTP代理113触发呼叫处理。在这个实施方式中，SMTP代理113连接到业务调度114，该业务调度114执行以上 参考图1-5和图6描述的本发明第一方面的调度功能。业务调度114依据来自SMTP代理 113的触发确定呼叫必需的处理。由于SMTP代理113工作于已知的非专有协议，设计生成 不依赖于MMSC 110的协议的触发是相对直接的。SMTP代理113从消息中的数据提取识别消息大小的信息，并也可从消息的数据中 提取识别消息中包含的媒体的种类和类型的信息。发送一个适当的信号给业务调度单元 114。另外，由业务调度单元114指令，SMTP代理113通过MM4接口发送响应至匪SC 110以 转换始发者和接收者的地址(应指出消息可被发回至同一个MMSC 110(回送)、相同网络的 另一个MMSC或不同网络的另一个MMSC)。因此，在上述的实施方式中，事件触发是在SMTP代理113中以诸如SMTP的协议生 成，该协议不同于匪S呼叫最初生成和由匪SC 110接收的协议。SMTP代理113可以是一个标准电子邮件服务器，临时配置为存储匪S消息以便生 成触发。触发可以是以轻型目录访问协议(LDAP)的形式扩展的包括相关信息的请求，所述 相关信息诸如呼叫的来源和目的地、消息的类型、消息的大小等等。所述信息被传送至业务 调度114，业务调度114接着确定如何处理该呼叫。在图7中，接口 131通过用户数据库单元130连接到匪SC 110，如参考图6描述的 那样，通过接口 131传送由MMSC 110生产的请求到业务调度单元114。
图7也显示了匪S呼叫发送到一个和匪SC 110不同网络的目的地的情况。在这 种情况下，SMTP代理113以SMTP格式将呼叫传送到不同运营商的匪SC 150，其中正如以上 描述的那样进行处理。这样，MMS呼叫以既不同于到达MMSC 110的呼叫的协议又不同于从 MMSC 150发送的呼叫的协议，从MMSC 110通过SMTP代理113传送到MMSC 150。通过工作 于一个通用协议，以这种方式，SMTP代理113生成的事件触发可以不考虑在不同网络内运 行的协议而可靠地生成。甚至可能由如MMSC 110的同一个运营商来操作MMSC150，其中运 营商具有多个匪SC。现在参考图8描述图7的实施方式的信号流。在图8中，标号1-9表示信令级。应 注意到在步骤7a、7b和7c有多种选择。因此，在匪S客户200发起信号并通过网关201发 送至MMSC 202，该MMS客户200是手机100中的软件。MMSC 202将信号传送到对应于传送 代理113的传送代理203，传送代理203在步骤4询问业务调度204。业务调度204本身询 问对应于图7中的SLR单元121的SLR 205或对应于预付费控制功能122的PCF 206。如 果业务调度确定呼叫不能被发送，则触发一个失败消息7c给始发方200。可选择的，如果业 务调度204确定能够处理呼叫，传送信号至传送代理203，在步骤7a中传送代理203可将 呼叫传送到MMSC 202的同一网络的MMSC 207 (实际上可以是同一个MMSC)，或者在步骤7b 中传送到另一个网络的MMSC 208。MMSC 207接着在步骤8将呼叫通过MMSC 209传送到对 应SMSC 116，以及在步骤9将呼叫传送到目的地210。
权利要求
一种操作移动电话网络的方法，所述网络具有一个平台，该平台用于处理至所述网络的至少一个移动电话或为所述网络的至少一个移动电话所生成的呼叫、事件或会话，以及具有一个和所述平台相互作用以确定所述处理的功能，其中所述平台能执行多个呼叫处理操作；所述功能执行以下步骤a)确定要应用于所述呼叫、事件或会话的呼叫处理操作；b)确定所述平台是否能够执行所述呼叫、事件或会话所需的所述呼叫处理操作；c)当所述平台能够执行至少一些所述呼叫、事件或会话所需的所述呼叫处理操作时，在所述功能确定执行所述至少一些所述呼叫处理操作所需的数据，以及为所述至少一些所述呼叫处理操作确定步骤的顺序以使所述平台处理所述呼叫、事件或会话；以及d)通过以所述顺序次序执行所述呼叫处理操作以及使用所述数据来使所述平台处理所述呼叫、事件或会话。
2.如权利要求1所述的方法，其中所述功能执行进一步的步骤e)收集所述一个平台处理所述呼叫所需的数据。
3.如权利要求1或2所述的方法，其中所述功能执行进一步的步骤f)转换所述呼叫、事件或会话的或所述平台的协议以便所述协议可由所述平台处理。
4.一种操作移动电话网络的方法，所述网络具有多个平台，所述平台用于处理至所述 网络的至少一个移动电话或为所述网络的至少一个移动电话所生成的呼叫、事件或会话， 以及具有一个和所述多个平台相互作用以确定所述处理的功能，所述方法包括以下步骤a)在所述多个平台的第一个平台上接收所述呼叫、事件或会话；b)在所述功能确定要应用于所述呼叫、事件或会话的业务和/或呼叫处理操作；c)在所述功能收集执行所述业务和/或呼叫处理操作所需的数据；d)确定所述第一个平台是否能够执行所述业务和/或呼叫处理操作，以及，当所述确 定结果是否定的时候；e)将所述呼叫传送给所述多个平台中的另一个平台，其中所述另一个平台能够执行所 述业务和/或呼叫处理操作；以及f)将所述数据从所述功能传送给所述多个平台中的所述另一个平台，由此，所述多个 平台中的所述另一个平台使用所述数据执行所述业务和/或呼叫处理操作。
5.如权利要求4所述的方法，其中所述步骤c)包括合并来自所述多个平台的至少一些 平台的数据以及形成用于处理所述呼叫、事件或会话的共用数据集。
6.如权利要求4所述的方法，其中所述功能执行进一步的步骤g)转换所述多个平台中的所述另一个平台的所述呼叫、事件或会话的协议以便所述协 议可由所述多个平台中的所述另一个平台处理。
7.如权利要求4至6中的任一个所述的方法，其中所述功能用于执行进一步的步骤h)确定所述多个平台的所述另一个平台是否需要处理所述呼叫、事件或会话的步骤的 顺序。
8.如权利要求7所述的方法，其中，当所述功能确定需要所述步骤的顺序时，使所述多 个平台的所述另一个平台以所述顺序执行所述步骤。
9.一种移动电话网络，所述网络具有一个平台，该平台用于处理至所述网络的至少一 个移动电话或为所述网络的至少一个移动电话所生成的呼叫、事件或会话，以及具有一个和所述平台相互作用以确定所述处理的功能，其中所述平台能够执行多个呼叫处理操作； 所述功能配置用于g)确定要应用于所述呼叫、事件或会话的呼叫处理操作；h)确定所述平台是否能够执行所述呼叫、事件或会话所需的所述呼叫处理操作；i)当所述平台能够执行至少一些所述呼叫、事件或会话所需的所述呼叫处理操作时， 在所述功能确定执行所述至少一些所述呼叫处理操作所需的数据，以及为所述至少一些所 述呼叫处理操作确定步骤的顺序以使所述平台处理所述呼叫、事件或会话；以及j)通过以所述顺序次序执行所述呼叫处理操作以及使用所述数据来使所述平台处理 所述呼叫、事件或会话。
10. 一种移动电话网络，所述网络具有多个平台，所述平台用于处理至所述网络的至少 一个移动电话或为所述网络的至少一个移动电话所生成的呼叫、事件或会话，以及具有一 个和所述多个平台相互作用以确定所述处理的功能，所述网络配置用于a)在所述多个平台的第一个平台上接收所述呼叫、事件或会话；b)在所述功能确定要应用于所述呼叫、事件或会话的业务和/或呼叫处理操作；c)在所述功能收集执行所述业务和/或呼叫处理操作所需的数据；d)确定所述第一个平台是否能够执行所述业务和/或呼叫处理操作，以及，当所述确 定结果是否定的时候；e)将所述呼叫传送给所述多个平台的另一个平台，其中所述另一个平台能够执行所述 业务和/或呼叫处理操作；以及f)将所述数据从所述功能传送给所述多个平台中的所述另一个平台，由此，所述多个 平台中的所述另一个平台使用所述数据执行所述业务和/或呼叫处理操作。
全文摘要
本发明涉及移动电信网络中的呼叫处理，其中，一种移动电话网络具有和平台(40)或多个平台互相作用来处理呼叫、事件或会话的功能(30)，用于a)确定用于所述呼叫、事件或会话的业务和/或呼叫处理操作；和b)确定平台(40)是否能够执行所述呼叫、事件或会话所需的业务和/或呼叫处理操作。然后所述功能可被安排用来为平台(40)提供适当的数据，或用来将呼叫、事件或会话传送到另一平台。
文档编号H04Q3/00GK101925205SQ201010224570
公开日2010年12月22日 申请日期2002年12月20日 优先权日2001年12月21日
发明者克里斯托弗·肖, 多米尼克·D·P·奥尼尔, 迈克尔·A.·威廉穆斯, 迈克尔·D.·伊尔斯 申请人:法国电信公司