移动电信网络中的呼叫处理

1.一种操作移动电话网络的方法，所述网络具有多个平台，所述平台用于处理至所述网络的至少一个移动电话或为所述网络的至少一个移动电话所生成的呼叫、事件或会话，以及具有和所述多个平台相互作用以确定所述处理的至少一个功能，所述至少一个功能存储执行所述呼叫、事件或会话的业务和/或呼叫处理操作所需的数据；所述方法包括以下步骤：
a)在所述功能确定要应用于所述呼叫、事件或会话的业务和/或呼叫处理操作；
b)在所述功能确定所述多个平台中的第一个平台是否能够执行所述业务和/或呼叫处理操作；
c)当所述功能确定所述多个平台中的所述第一个平台能够执行至少一些所述业务或呼叫处理操作时，使所述多个平台中的所述第一个平台使用所述数据处理所述呼叫；
d)在所述功能确定所述多个平台中的另一个平台能够执行其他的所述业务或呼叫处理操作；
e)将所述呼叫发送到所述另一个平台；以及
f)在所述另一个平台使用所述数据执行所述其他的所述业务或呼叫处理操作。
2.如权利要求1所述的方法，还包括：
g)当所述呼叫被所述多个平台中的所述第一个平台接收时，在所述功能采集执行所述业务和/或所述呼叫处理操作所需的所述数据，由此在所述平台存储所述数据。
3.如权利要求1或2所述的方法，其中所述功能执行进一步的步骤：
h)将所述呼叫、事件或会话从所述第一个平台的协议转换到所述另一个平台的协议，以便所述一个协议可由所述第一和/或所述另一个平台处理。
4.如权利要求1或2所述的方法，其中所述功能配置用于执行进一步的步骤：
i)确定在所述第一个和/或所述另一个平台处理所述呼叫、事件或会话所需的步骤的顺序。
5.如权利要求4所述的方法，其中，当所述功能确定需要步骤的顺序时，使所述第一个和/或所述另一个平台以所述顺序执行所述步骤。
6.一种移动电话网络，所述网络具有多个平台，所述平台用于处理至所述网络的至少一个移动电话或为所述网络的至少一个移动电话所生成的呼叫、事件或会话，以及具有和所述多个平台相互作用以确定所述处理的至少一个功能，所述至少一个功能存储执行所述呼叫、事件或会话的业务和/或呼叫处理操作所需的数据；所述网络配置用于：
a)在所述功能确定要应用于所述呼叫、事件或会话的业务和/或呼叫处理操作；
b)在所述功能确定所述平台中的第一个平台是否能够执行所述业务和/或呼叫处理操作；
c)当所述功能确定所述平台中的所述第一个平台能够执行至少一些所述业务或呼叫处理操作时，使所述多个平台中的所述第一个平台使用所述数据处理所述呼叫；
d)在所述功能确定所述多个平台中的另一个平台是否能够执行其他的所述业务或呼叫处理操作；
e)将所述呼叫传送到所述另一个平台；以及
f)在所述另一个平台使用所述数据执行所述其他的所述业务或呼叫处理操作。

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