CN1973526B

CN1973526B - 在事件处理系统中处理业务初始请求消息的事件处理方法

Info

Publication number: CN1973526B
Application number: CN200580014641.1A
Authority: CN
Inventors: 多米尼克·奥尼尔; 迈克·伊尔斯; 乔治·皮亚基斯; 贝农麦·图特切尔; 马克·埃文
Original assignee: France Telecom SA; Orange SA
Current assignee: Orange SA
Priority date: 2004-04-07
Filing date: 2005-04-07
Publication date: 2014-01-15
Anticipated expiration: 2025-04-07
Also published as: WO2005099239A1; EP2375715A2; EP1741277A1; CN1973526A; US8472945B2; US20080146201A1; EP2375715B1; EP2375715A3; EP1741277B1

Abstract

本发明提供了事件处理系统。本发明实施例涉及通信网络中的事件处理的方法和系统，并适于响应于业务启动触发协调对业务的提供。实施例特别适用于控制多个业务节点的操作，所述多个业务节点中的每一个被设置为在移动网络、或者固定网络或二者的组合中提供特定业务。更具体的是，本发明实施例提供在事件处理系统中用于处理业务启动请求消息的事件处理装置，所述事件处理装置可连接到用户在处理网络事件期间能够从其接收业务的多个业务节点，各所述业务节点能够响应于业务请求消息发送业务响应消息，所述事件处理装置包括如下功能，该功能被设置为在接收到由当前涉及处理所述网络事件的网络中的服务节点发送的第一业务启动请求消息时，控制涉及处理同一网络事件的所述多个业务节点中的至少一些业务节点的操作，其中，所述功能被设置为修改至少一个所述业务启动触发，并基于所述经修改的业务启动触发制定业务请求消息。业务节点可包括提供对网关之外的诸如根据开放式业务架构配置的业务节点的其他多个业务节点的访问的网关节点。在操作中，所述装置可用于监视对业务响应消息、业务启动触发消息的接收，并协调各种业务与给定用户已向其注册了业务的服务节点间的通信。

Description

在事件处理系统中处理业务初始请求消息的事件处理方法

技术领域

本发明涉及一种用于通信网络中的事件处理的方法和系统，本发明特别地但非排它地适合协调响应于业务触发而提供业务。本发明的实施例尤其适用于控制业务节点的操作，这些业务节点中的每一个都被设置为在移动网络、或固定网络或者上述二者的组合中提供特定业务。

背景技术

典型的移动运营商包括两个或更多个运营伙伴，其中每一个运营伙伴都提供定制网络业务。因此，被看作是一个整体的运营伙伴通常包括不同而多样的业务以及相应的业务设备。对网络业务进行开发、整合和运作是每个运营伙伴的责任，从整体上看，提供这种多样性通常对于运营商而言是极为昂贵的，这是因为与开发、支持和对多种业务进行市场推广相关联的成本是巨大的。此外，当面对整合多种网络业务的任务时，网络运营商要克服若干棘手问题，不仅仅因为传统业务应用通常不是向上兼容的，而且正如已经提到的，许多网络业务是由不同业务供应商来开发和管理的。

图1是表示常规移动网络布置的示意图，该常规移动网络布置包括移动站MS、业务节点交换网络组件MSC以及归属位置寄存器HLR，还有各种节点IN1、IN2、IN3，每个节点都被设置为提供智能网络业务。MSC被设置为：根据移动站MS向MSC注册时从归属位置寄存器HLR接收到的业务参数数据或者根据静态配置在本地网络内的设置，向业务节点IN1、IN2、IN3发送消息并从这些业务节点接收消息。当MS向MSC注册时，MSC监测业务触发的发生（所谓的检测点（DP）），且当识别出触发时，交换MSC联系与该触发相关联的任何业务节点。在一些已知系统中，每一个业务IN1、IN2、IN3相互独立操作（例如，每种业务可由不同业务提供商提供），经常出现不同业务被设计为响应于同一触发的情况。通常，在这种情形中，MSC简单地激活一种网络业务，因此实际地未能为MS提供其他业务。国际专利公报第WO97/50232号描述了一种被设计来缓解这个问题的系统，并描述了一种具有所谓的中间点的网络，其可接入对应于同一触发的多种业务并且确定该多种业务的配合规则，并且控制从单个点对各种业务的调用。然而，WO97/50232要求将应用分类为简单类别且仅允许业务间的预配置且表列交互集，其为规定的且不灵活。此外，仅可根据规则而调用每种业务，即仅关于给定触发来调用。

除存在不同的业务节点竞争同一触发外，电信、计算以及多媒体领域间的技术趋同已引发了开发并提供电信业务的新环境。这已迫使电信运营商和业务供应商开发并开展新的住宅和企业业务及应用。为迎接该挑战，运营商和业务供应商已寻求用标准化的、开放的、能共同使用的、且公共的平台替代封闭、私有系统，这种开放平台中包含前述业务中的至少一些。

Parlay是一个开放的多销售商联盟，其被形成为开发独立于API的这种开放技术，使得互联网业务销售商、网络设备销售商、软件开发商、业务供应商、ASP以及企业能够创建可跨多个移动和固定运营商网络运行的应用程序。Parlay/OSA（开放式业务架构）标准定义了API（应用程序编程接口），该API是技术不可知的，且被配置为使用诸如SIP（会话启动协议）、JAIN（智能网络的Java应用程序编程接口）以及网络业务的协议和技术来与不同领域中的第三方设备和业务通信。

尽管该构架大大地改善了业务的互操作性，但是仍存在与注册关注网络事件的全异业务相关联的实现问题。在以下描述中假定，“注册关注……的应用/业务”意指“被设置为对……起反应的应用/业务”，并且“网络事件”意指例如来自网络（或实际上另一业务或应用节点）的关于指定目的地地址和源地址的触发。

目前有14种业务控制功能（SCF），包括多种通用呼叫控制（GCC）SCF和多方呼叫控制（MPCC）SCF；在二者间，GCC/MPCC SCF映射到所有智能网络（IN）消息，并因此能调用所有网络功能。使用ParlayAPI，任何给定业务都能注册并注销网络事件（例如对于GCC SCF，分别通过利用enableCallNotification()和disableCallNotification()方法，而对于MPCC SCF，分别通过利用createNotification()和destroyNotification()方法），每个注册请求对应于一个或多个用户（源地址）和/或目的地地址（例如，在号码翻译业务的情况下的指定号码）。网络和OSA领域的简化表示示于图2中，OSA与网络设备间的GCC注册消息的路由示例示于图3中。在该示例中，应用程序App1被设置为在分配网络资源前检查指定用户的平衡，并因此每当App1确定在关于请求业务分配网络资源前需要检查用户平衡时，App1调用enableCallNotification()方法。这导致MAPAnyTimeModification()消息被发送到HLR以激活必需的预订信息（O-CSI、D-CSI（关于用户地址而被激活））。成功注册了该网络事件后，当这种指定用户随后请求业务（即，O-CSI（标识用户的数据））时，App1被调用并用来至少控制业务提供过程的启动部分。

enableCallNotification()方法对于应用来说完全是用来指示其希望在发生特定呼叫事件时被通知。可以为整个地址范围预订特定事件，例如，应用可指示其希望在呼叫以800开头的任何号码时被通知。如果应用已利用与指定准则交叠的准则请求了通知，则例如对GCC注册消息使用P_GCCS_INVALID_CRITERIA并对MPCC注册消息使用P_INVALID_CRITERIA来拒绝该请求。如果起始和终止目的地地址交叠，并且采用相同编号的计划和相同的CallNotificiationType（例如，网络触发），则称准则是交叠的。结果，在大多数配置中，针对一组给定准则，仅一个应用能进行请求。

英国电信精密技术部门（British Telecommunications ExactTechnologies）已确定具有硬性且快速的“不共存任何交叠”规则是过于严格的，并提出了解决方案，由此Parlay GW包含政策管理业务能力功能（SCF），其被设置为当应用试图向网关注册时与图2所示的呼叫控制SCF协作。其政策管理SCF管理用户配置文件库，其中存储有给定用户可以访问的业务的详情以及相应的触发事件。用户配置文件仅在政策管理SCF已检查出应用可共存后才被填入，通过用元数据指定应用交互规则（所谓的“特征交互”规则）提供的特征交互处理功能检查了应用的共存。因此该解决方案要求指定应用与业务（其要被预存储并可响应于应用注册请求对其进行访问）间的交互的规则。当随后从网络中接收到网络事件时，呼叫控制SCF访问对应于与该网络事件相关联的用户的任何用户配置文件，并检索存储于其中的应用和业务的详情，用来依次地控制它们各自的调用。该解决方案存在若干问题，这些问题不仅仅是由以下事实产生的，即鉴于已注册的应用来解决注册请求。考虑如下情形可看到该解决方案的缺点，其中第一个应用A已为用户注册，更新了用户配置文件以包括表示应用A的数据。如果随后接收到来自应用B的注册请求，并且如果交互规则指出A与B不兼容，则来自应用B的注册请求将失败。如果，随后应用A向用户注销，则没有办法重新捕获应用B，即使现在没有使用户不能从应用B接收业务的理由。

本发明的目的是为网络业务提供更高程度的整合性和灵活性。

发明内容

根据本发明第一方面，提供了一种在事件处理系统中用于处理业务启动请求消息的事件处理装置，所述事件处理装置可连接到多个业务节点，用户在处理网络事件期间能够从所述多个业务节点接收业务，各所述业务节点能够发送包括专用于该业务节点的操作的数据的业务响应消息，所述事件处理装置包括如下功能：在接收到由当前涉及处理所述网络事件的网络中的服务节点发送的第一业务启动请求消息时，从多个业务节点请求业务响应消息，并基于所述业务响应消息中包含的数据，控制处理同一网络事件所涉及的所述多个业务节点中的至少一些业务节点的操作。

在处理诸如呼叫的网络事件期间，该方面可以协调例如第一业务节点与作为处理网络事件的一部分的另一（第二）业务节点的操作，所述第一业务节点在执行期间取决于来自所述另一业务节点的数据内容。任何给定业务节点实际上表现为对所述装置的开放系统，这意味着所述装置能在处理网络事件期间，在一个或更多个点处与所述业务节点交互。

本发明实施例还提供了一种用于根据可选择的预定规则和条件来整合来自不同业务的功能的手段。优选的是，响应于接收到所述业务启动请求消息来检索规则，并且所述规则例如可包括建立有条件等待事件和当满足等待条件时指定要调用哪个业务节点的规则。因此所述装置提供了一种灵活地处理网络事件的手段，其中所述业务实际上是根据所选规则和条件数据而动态地“混合并匹配”的。

方便的是，所述功能可被配置为基于所述业务响应消息的内容，在同一网络事件期间控制给定业务节点的操作一次以上。所述功能实际上参与了各种业务节点与服务节点间的整个对话；这与诸如WO97/50232中描述的系统的已知系统完全不同，在WO97/50232中，随后接收到的触发可仅被视为独立的事件，这使得中间点执行对业务的查找，好像所关注的触发是作为无关网络事件的一部分而被接收到的。该特征对使用如下业务尤为有利：需要响应于各种事件（例如，当被呼叫方繁忙或无法接通时）发出告警，并且每当以被呼叫方的另选联系详情进行响应时，可在多个情形下对其进行查询。

在一种配置中，所述功能将表示业务请求信息中的一个或更多个业务启动触发的数据传输给相应的业务节点，所述触发是从所述服务节点发送至所述装置的一个或多个触发和/或经所述功能修改的触发。所述功能基于检索出的数据和/或基于从所述网络事件所涉及的业务节点接收到的业务响应消息的内容，还可修改诸如伴随着所述业务启动请求的业务密钥、协议和/或被呼叫数位的数据。然后可基于修改后的数据来制定后续业务请求消息。提供修改触发的手段的一个特别优点在于：因为不同的业务和应用响应于不同的触发，所以扩大了所述功能可执行的功能范围使之超过已知系统可能的范围。基本上，通过改变给定网络事件所涉及的触发，增加了关于所述网络事件可调用的业务数（并由此增大了功能范围）。另外，所述功能可被设置为由于所述操作而监视对其他业务启动请求消息（特别是触发数据）的接收，并基于对应于新接收到的触发数据而检索出的数据来控制业务节点的操作。

在某些情况下，业务节点可以在业务响应消息中请求诸如触发点的不与来自所述网络事件中涉及的其他业务节点的类似请求冲突的启动请求消息。通过求助于用于指定从所述不同业务节点接收到的数据与取决于该数据的条件之间的优先次序的优先选择数据，可以避免这种潜在的冲突。所述装置因此保证所有随后发送的与所述网络事件相关联的启动请求消息（或业务调用消息）都不冲突。

更具体的是，响应于接收到所述第一业务启动请求消息，所述装置被设置为以选定顺序发送第二业务启动请求消息至两个或更多个所述业务节点。所述顺序是根据指定呼叫处理逻辑而选定的，并包括取决于来自一个或更多个所述业务节点的响应的事件。例如，所述装置可被设置为在发送第二业务启动请求消息至第二业务节点前，处理来自第一业务节点的业务节点响应消息。

优选的是，将所述呼叫处理逻辑存储在数据存储系统中，该数据存储系统可由所述装置来访问并被设置为存储关于多个用户的数据。在一种配置下，所存储的数据包括用于指定由多个所述业务节点提供的业务的业务数据，和用于指定所述业务间的关系的一个或更多个条件。业务间的这种关系有效地定义所述呼叫处理逻辑，并是根据所述业务启动触发而编制索引的。

业务启动触发的示例包括但并不限于：与呼叫控制、交互、以及诸如Camel和智能网络检测点（INAP、扩展INAP、CAP）的协议载送的消息收发相关联的事件和触发；诸如位置更新和ForwardSM消息的MAP事件；与发送诸如MMS和SMS消息的数据消息相关联的事件；配置号（例如，B＃）和SIP事件，诸如由MSCML、VXML、CCXML和NETANN载送的配置号和SIP事件。

在一种配置下，一个业务节点是网关节点，该网关节点提供对所述网关之外的多个其他业务节点的访问；优选的是，所述装置包括被设置为经由所述网关节点向该装置提供访问的接口组件。其他业务节点可被设置为找出所述装置的功能，并使用找出的信息据此前摄性地设计业务。

概而言之，所述装置可视为工作在两种模式下：第一种模式，其中检索出与所述业务启动请求相对应的可执行数据；和第二种模式，其中所述装置基于检索出的数据调用业务节点，所述第二种模式还包括监视从经执行的业务节点以业务响应消息的形式接收到的数据，并对其作出反应。

在一种配置下，当接收到由当前涉及处理同一网络事件的网络中服务节点发送的第二业务启动请求消息时，所述功能可控制所述多个业务节点中的至少一个业务节点，并且由于所述操作，将业务响应消息发送至从其接收到所述第二业务启动请求消息的所述服务节点。所述第一和第二业务启动请求消息可发自相同的或不同的业务节点；所述装置在如下情形中的任一个下例如可用于将事件处理从访问者网络中的服务节点转移到本地网络中的服务节点：在提供国际无缝语音业务期间；当将短号码翻译为全连接号码时；当实现各种消息收发业务以及这些和其他其他已知及未来全异业务的组合时。

根据本发明第二方面，提供了一种用于处理业务启动触发的事件处理系统，该事件处理系统包括：

多个业务节点，用户在处理网络事件期间能够从所述多个业务节点接收业务；

服务节点，其被设置为存储为用户定义一组不同业务启动触发的数据，各所述业务启动触发分别对应于不同的第一业务启动请求消息；

存储系统，其被设置为存储关于多个用户的数据，所述存储的数据包括用于指定可从所述多个业务节点获得的业务的业务数据，以及用于指定所述业务间的关系的一个或更多个条件；

处理系统，其被设置为响应于接收到从所述服务节点发送的关于所述用户的所述第一业务启动请求消息，从所述存储系统检索与所述用户相关联的业务数据，其中，所述处理系统被设置为根据检索到的数据发送至少一条第二业务启动请求消息到一组预定的不同业务节点中的每一个。

在本发明的这一方面，所述存储系统可从物理上和逻辑上与所述处理系统分离，这意味着可以完全与所述处理系统的操作以及业务节点、服务节点以及处理系统间的消息传送无关地修改对用于指定业务间的关系的业务数据和条件的更新。

根据本发明第三方面，提供了一种在事件处理系统中用于处理业务启动请求消息的装置，所述装置可连接到涉及处理网络事件的网络中的服务节点并可连接到多个业务节点，用户在处理网络事件期间能够从所述多个业务节点接收业务，所述服务节点能够存储为用户定义一组不同业务启动触发的数据并且能够发送一组第一业务启动请求消息到多个不同业务节点，各所述第一业务启动请求消息分别对应于不同的一个所述业务启动触发，其中，所述装置在处理同一网络事件期间响应于不同的所述第一业务启动请求消息，并被设置为响应于接收到一条所述业务启动请求消息而发送至少一条第二业务启动请求消息到一组预定的不同业务节点中的每一个。

根据第三方面配置的装置能响应于在同一网络事件期间接收到的不同触发，并确定所述触发是同一网络事件的一部分。这提供了控制例如如下操作的尤为便利的方式：切换与呼叫相关联的装置；和在不同网络间转移呼叫，在处理同一呼叫期间可从这些不同网络接收不同的触发。

此外，在本发明这一方面的配置中，诸如交换机的服务节点发送第一业务启动请求消息到所述装置，所述装置能够将第二业务启动消息发送到两个或更多个业务节点。这些第二业务启动消息可与第一业务启动请求消息相同，且任何一个第二业务启动消息可与另一第二业务启动消息相同或不同。

根据本发明的另一方面，提供了一种在网络事件处理系统中用于处理业务启动请求消息的装置，所述装置可连接到多个业务节点，用户在处理呼叫期间能够从所述多个业务节点接收业务，所述装置包括如下功能，该功能被设置为在接收到由当前涉及处理呼叫的网络中的服务节点发送的第一业务启动请求消息时，控制所述多个业务节点中的至少一个业务节点的操作，其中，由于所述操作，该功能被设置为生成第一业务响应消息并将该第一业务响应消息发送到从其接收到所述第一业务启动请求消息的所述服务节点，并且在接收到由目前涉及处理同一网络事件的所述网络中的服务节点发送的第二业务启动请求消息时，所述功能被设置为继续控制所述多个业务节点中的至少一个业务节点。

本发明的这一方面使得所述装置能够在对事件的处理已经在网络中的不同服务节点间传递后，仍保持涉及处理网络事件。通常，所述装置将被配置为监视对所述第二业务启动请求消息的接收，并在接收到所述第二请求消息时继续控制事件处理。

根据本发明的另一方面，提供了一种在网络事件处理系统中用于处理业务启动请求消息的装置，所述装置可连接到涉及处理网络事件的网络中的服务节点并可连接到多个业务节点，用户在处理所述网络事件期间能够从所述多个业务节点接收业务，所述服务节点能够存储为用户定义一组不同业务启动触发的数据并且能够发送一组第一业务启动请求消息中的各个第一业务启动请求消息到所述装置，各所述第一业务启动请求消息分别对应于不同的一个所述业务启动触发，其中，所述装置响应于所述第一业务启动请求消息中的一个，以将所述相关联的业务启动触发变换为表示第二业务启动触发的数据，并基于所述第二业务启动触发从至少一个所述业务节点请求业务响应消息。

这一方面对如下情形尤为便利，即服务节点（交换机）可获得的一组触发不包括对应于特定业务的触发。在本发明这一方面的配置中，所述装置优选地利用包含在业务启动请求消息中的诸如被呼叫方ID的数据，来变换其所接收到的触发数据，以推进否则可能不被正确处理的网络事件；一个这种示例是对B＃呼叫的处理，处理B＃呼叫所需的一组触发仅被提供给CAMEL 3使能网络中的交换设备。另一示例是对固定线路操作者号码、号码范围、移动操作者号码或号码范围的处理，其中每一个都对应于特定业务或业务范围。

根据本发明的又一方面，提供了一种移动网络，该移动网络包括多个所述事件处理装置，所述多个事件处理装置中的每一个都包括被设置为提供对其他业务节点的访问的一个或更多个网关业务节点。有利的是，所述移动网络被设置为使得任何一个网关都可访问任何一个其他业务节点，从而为所述移动网络提供了一组合并业务。

本发明实施例可用于直接控制通过所述网关业务节点可访问的所述一个或更多个其他业务节点。因此，有利的是，本发明能在实际上为“网关的另一侧”上实现，并控制例如OSA业务应用的操作。

需要注意的是，通常各业务节点被配置为提供特定网络业务，在以下描述中，这被称作网络业务和/或业务应用。

根据本发明的又一方面，提供了一种在事件处理系统中用于处理业务注册请求消息的装置，各所述业务注册请求消息包括识别业务节点、业务启动触发以及所述注册请求与之相关的用户的注册数据，所述装置可连接到涉及事件处理的网络中的服务节点并可连接到一业务节点，用户在事件处理期间能够从该业务节点接收业务，所述服务节点能发送多个业务启动请求消息到所述装置，各业务启动请求消息分别对应于不同的业务启动触发，其中，所述装置响应于对从注册业务节点发送的一条所述业务注册请求消息的接收，而存储表示所述经注册的业务节点以及与所述用户相关联的对应业务启动触发的注册数据，所述注册数据用于处理从所述服务节点发送的关于所述用户的业务启动请求消息，所述装置被设置为存储多个业务注册请求消息的注册数据，所述多个业务注册请求消息中的每一个都用来识别不同的业务节点和同一用户，其中，所述装置被设置为在接收到所述注册数据后定义所述不同业务节点间的优先次序。

因此通过本发明这一方面的实施例，在通过利用定义节点间的优先次序的数据完成注册后解决业务节点间的交互。结果，与已知系统对比，注册请求不再以准则交叠的理由被拒绝（非法或不支持的请求仍会被拒绝），而是相反地加以记录，并且随后根据优先选择数据而调用应用。与本发明这一方面相关联的明显优点是，因为注册请求不被拒绝，所以用户为业务签订的所有这些应用可在接收到相应的业务启动请求消息时被激活。应当明白，优先选择数据考虑业务间的任何潜在冲突。

在一种设置下，所述装置被设置为如果从被确定为所述用户可访问的业务节点接收到所述注册请求消息，则存储所述注册数据，由此提供了一种验证手段，否则，用户实际上可以访问所述正请求的业务节点。

另外，响应于接收到第二和以后的注册请求消息，所述装置可被设置为检索用于指定对应的两个或更多个业务节点间的后续实时交互的交互数据，并存储所述交互数据。所述交互数据定义所述不同的业务节点间的优先次序。随后，响应于接收到第一业务启动消息，所述装置可按照取决于所述优先选择数据的选定顺序来发送第二业务启动请求消息到两个或更多个所述业务节点，并包括取决于来自一个或更多个所述业务节点的响应的事件。方便的是，可将所述装置设置为在同一网络事件期间，在发送第二业务启动请求消息到第二业务节点前，处理来自第一业务节点的业务节点响应消息。

另选的是，可将所述装置设置为在按上述方式进行操作前，响应于接收到业务启动请求消息而检索用于指定对应的两个或更多个业务节点间的交互的交互数据。

方便的是，所述装置与根据本发明的上述多个方面配置的功能有效关联。

根据以下参照附图对仅以示例形式给出的本发明的优选实施例的描述，本发明的其他特征和优点将变得显见。

附图说明

图1是表示被设置为将业务递送给用户的常规移动网络的运行的示意图；

图2是表示如下网络的示意图，该网络可访问OSA域、OSAAPI接口以及API类方法被映射到多种网络协议的协议；

图3是表示OSA域与网络域之间的消息流的示例的示意图；

图4是表示根据本发明实施例的事件处理系统的组件的示意性框图；

图5是表示根据本发明实施例的第二配置的事件处理系统的组件的示意性框图；

图6是表示根据本发明实施例的第三配置的事件处理系统的组件的示意性框图；

图7是表示根据本发明的注册方面的实施例的OSA网关的注册组件的示意性框图；

图8是表示根据第一注册实施例的注册过程的示例的示意图；

图9是表示根据图8中所示的第一注册实施例的图5中的业务提供系统的内容的示意图；

图10是表示根据第二注册实施例的注册过程的示例的示意图；

图11是表示根据图10中所示的第二注册实施例的图5中的业务提供系统的内容的示意图；

图12是表示根据本发明又一实施例的事件处理系统的组件的示意性框图；

图13是更详细地表示图6所示的事件处理系统的组件的示意性框图；

图14是更详细地表示图4、5、6、12和13所示的事件处理系统的业务交互组件的示意性框图；

图15是表示根据本发明事件处理方面的实施例的事件处理过程的示例的示意图；

图16是描述图14中所示的业务交互组件在图15所示的事件处理过程期间执行的步骤的流程图；

图17是描述图14中所示的业务交互组件在OSA间事件处理过程期间执行的步骤的示意图；

图18是描述图14中所示的业务交互组件在OSA-IN事件处理过程期间执行的步骤的示意图；以及

图19至23是表示根据本发明实施例的事件处理过程的其他示例的示意图。

需要注意的是，关于给定附图首次给出的并且与在随后附图中出现的部分和步骤相同或相当的部分和步骤，将在随后附图中以相同的附图标号予以描述，并在随后附图中不再更详细地进行描述。

具体实施方式

本发明的实施例涉及业务网络的多个方面，更具体地涉及高效地中介（broker）用户可获得的多种且有可能冲突的网络业务，并提供被设置为提供该功能的事件处理系统和装置。这些业务具体地但非排他地包括：语音邮件（国际无缝语音应用，或ISVA）；虚拟专用网络号码翻译业务（iVPN）；以及选择性本地路由（SHR）业务、预付费消息、后付费消息、一键通（Push-to-Talk）业务（基于B＃决议）、滞后呼叫转发、临时呼叫/资源交互、涉及SMS和MMS消息收发的业务和SIP会话启动业务，以及其他业务。本发明实施例的一个特定特征是除了在不同IN业务之间进行中介之外，还能够控制IN和OSA业务以及不同OSA业务间的运作。本发明实施例还涉及非智能网络业务与非OSA业务之间的中介（例如：涉及SMS和MMS消息收发以及SIP会话启动业务）。

网络环境

参照图2，由表现为OSA接口中的业务能力特征的不同业务能力服务器（SCS）来提供并控制对网络功能（包括智能网络的功能）的访问。该OSA接口通常被称作Parlay/OSA GW 101。诸如App1的OSA应用通过OSA接口与OSA GW 101通信，而基础核心网络功能（智能网络能力、MSC 107（移动交换中心）和HLR 115（归属位置寄存器））则使用其特定协议（例如，CAP（CAMEL应用协议）和MAP（移动性应用部分））与OSA GW 101通信。如上所述，存在14种SCF，包括多种通用呼叫控制（GCC）和多方呼叫控制（MPCC）SCF，它们共同映射到所有CAP、MAP和INAP消息，并因此能调用所有网络能力。

上文提到的核心网络功能通常被认为是公共陆地移动网络（PLMN）的一部分，该公共陆地移动网络可具体化为诸如GSM或UMTS网络的蜂窝式网络，并进一步包括涉及在无线电级发射并递送数据的组件（未示出）。在操作中，MSC 107考虑无线电资源分配和用户的移动性质的影响，并执行位置注册及移动站切换所必需的过程。如图1所示，MSC 107与HLR 115连接，HLR 115被设置为存储标识移动用户的位置的数据（例如，为了能够将呼叫择路到该移动用户）；附于各移动签约的标识号码（例如：国际移动用户识别码（IMSI）；国际移动用户ISDN号码（MSISDN））；通信业务签约信息，业务限制（例如：漫游限制）；普通用户属性和偏好；以及包括与这些业务相关联的参数的附加业务信息。

对于网络的各种组件间的通信，MSC 107和HLR 115通过多种信号收发协议发送并接收数据，这些信号收发协议包括但并不限于信号收发系统号113（SS＃7）移动应用部分（MAP），而MSC 107与无线电组件间的信号收发使用SS＃7的基站系统应用部分（BSSAP）。

概述：系统架构

下面转至图4，来描述根据本发明实施例的事件处理系统的第一配置。在该第一配置中，处理系统被设置为根据一条或更多条规则控制各种智能网络业务IN1、IN2、IN3的操作，并包括业务交互功能SIF 301和用户配置文件库303。图4示意性地例示了系统的各种组件间的数据流，并能看出，MSC 107并非直接与智能网络业务节点IN1…IN3通信，而是单独与SIF 301交互，并至少部分根据从SPS 303接收到的数据将消息发布至多种网络节点。

如在下文中将更详细描述的，SIF 301承担与多种网络业务节点IN1…IN3通信的任务，根据从SPS 303接收到的数据来控制与之的任何通信的性质和次序。SPS 303本质上是数据库，用来存储用户特定触发和业务相关信息。此外，它也能存储业务间数据，该数据可被SIF构造并组合以指定业务节点间的交互（例如：关于访问优先权）。如图4中示意性示出的，可以从诸如位于更广泛网络中的网络业务的供应业务向SPS提供数据。

下面转至图5，能看到SIF 301也被设置为通过OSA网关101（为清晰起见仅示出一个）与各种OSA应用交互，并控制其操作。如稍后将在说明中更详细描述的，在这种配置中，SPS 303中存储的业务相关信息包括关于IN业务与OSA业务间的交互的规则和条件。

图6示出了第三配置，其中SIF 301被设置为控制位于网关101后的业务的操作。该配置提出了对常规OSA网关设计的限制，即，任何给定触发/用户被有效地硬连线到单个OSA应用（并因此实际上与上述在交换MSC提供的智能网络业务的环境下一样缺乏灵活性）。因此该配置为响应于特定业务触发和/或用户数据而灵活地调用多个OSA应用提供了一种方法。事件处理系统可包括两个SIF装置，一个位于网络中，如第一和第二配置（图4、5），并且另一个位于OSA域（图6），这意味着两个SIF装置可以逻辑上和物理上彼此区分。另选的是，该事件处理系统可包括单个SIF，它是物理分散在但逻辑集成在网络与OSA域之间。这些不同配置将在下文中予以更详细的讨论。

业务注册

用户配置文件库SPS 303被设置为针对所有用户存储关于网络事件处理的业务（IN和OSA）及其间关系的列表。优选的是，根据用户标识和业务触发来键入业务，从而，对于任何给定用户标识和触发，当要处理涉及特定触发的呼叫时，可选择用户可获得的业务。另外，可按照与触发相关联的“呼叫模式逻辑”的形式来检索所选业务间的关系。

如从图4和5中可以看到的，可从诸如位于更广泛网络中的网络业务的供应业务向SPS 303提供数据311，且供应过程优选地与注册过程无关。下面展示了关于给定用户存储在SPS 303中的数据311（此处被称作所提供的数据）的一种可能数据结构：

用户－MSISDN密钥或IMSI或公司Id

属性：-DP

应用

GT

业务密钥

协议

执行优先

同步或异步执行

连接优先；转发DRA/InitialDP中的修改呼叫PN

转发优先

释放优先

错误优先

在网/离网/任何

是搜寻应用

是本地路由应用

属性：－EventId

业务组：参考在另一SPS表中指定的一组特定的应用和应用规则。

超时

位置[rw]

这些属性包括使得适当配置的SIF 301能够基于从网络和其他业务接收到的各个响应以及消息而使业务相互作用的数据。SPS 303能存储应用间和业务间规则，这些规则指定了当从网络接收到各种响应和消息（例如：关于访问优先权）时，业务节点间的交互；下文中更详细地对这些方面进行描述。在触发方面，仅仅通过示例方式，可将SPS 303配置为支持如下非限制性业务触发列表：INAP DP1至DP18；CAP V1O-CSI，T-CSI；MAP非DP事件，例如：locationUpdate、forwardSM；CAP V2V3V4触发；MMS、SMS、SS、USSD、SIP。

如上文背景技术部分所描述的，捕捉OSA应用感兴趣的网络事件的起始点通常是在事件处理SCS中的，该事件处理SCS检查enableCallNotification()消息（或对于MPCC呼叫为createNotification()消息）中指定的参数以识别是否应用已注册了这些参数。基于该检查，SCS允许或拒绝该应用对这些参数的注册。

相反，本发明实施例的起始点是无条件注册请求应用，这意味着，与已知方法相反，并不相对先前注册的应用来检查包括在注册请求中的参数。当然，依然需要处理先前在注册时以有些严格的方式管理的潜在冲突，本发明的实施例在事件处理循环中的不同位置处提供了对冲突管理的另选且灵活的方法。这将在下文中更详细地描述，但是将参照图7至13来描述OSA应用的注册过程的第一方面。

首先转至图7，可见Parlay GW 101包括被配置为与呼叫控制SCS 103和库SPS 303都通信的注册功能305。除了上文引入的所提供的数据311（用户特定触发和业务相关信息）外，SPS 303还存储动态数据313，该动态数据313表示在所提供的数据311中列出的任何给定应用的实时状态。这种实时状态信息的示例包括识别应用是否有效的数据，以及用户和当前针对该应用注册的网络事件的详情；在随后描述中，这些实时数据另选地被称为“应用句柄（handle）”。优选的是，根据用户标识和业务触发来键入应用，使得对于任何给定用户标识和触发，当要处理涉及特定触发的呼叫时可选择用户可获得的应用。

图8表示根据第一实施例中的注册过程中包括的步骤：在步骤81，App1发送GCC enableCallNotificaition()请求到SCS 103，这使得注册功能305关于App1指配assignmentId。在步骤82，将assignmentId与触发、enableCallNotification()请求中指定的源地址数据和目的地地址数据一起发送到SPS 303，随后在步骤83将确认消息发送回App1。在步骤82从注册功能305接收到消息时，SPS更新动态库313，从而包括App1（以及步骤81中接收到的触发、源地址和目的地地址的详情），或者，如果已关于其他触发/用户参数将App1存储于其中，则更新参数以包括与步骤81中接收到的数据相对应的参数。图9是示出数据如何分布在SPS 303的多个组件间的示意图：对应于动态数据313的圆圈代表关于已按照上述方式（如图8中所示）从注册功能305接收到的数据的应用，而对应于所提供的数据311的圆圈代表用户已就其签约但是还未向网关101注册的应用。应当明白，在这个和随后的实施例中，注册请求就像与单个用户相关一样，可同样地与多个用户相关（例如，批注册）。

图10示出了根据第二实施例的注册过程中包括的步骤：在步骤81，App1发送enableCallNotification()请求到SCS 103，这使得注册功能305关于App1发送请求到SPS 303，用来在SPS 303中查询步骤81处接收到的请求中包括的用户/触发/App1组合（步骤1001）。这使得SPS 303查阅所提供的数据311的库，并在步骤1003，SPS 303将查询结果返回到注册功能305。假定结果是肯定的，注册功能305将assignmentId指配给App1，并在步骤1005将已指配的assignmentId与enableCallNoticifcation()请求中指定的触发、源地址数据和目的地地址数据一起发送到SPS 303。随后在步骤1007将确认消息发送回App1。在步骤1005处接收到来自注册功能305的消息时，SPS更新动态库313，从而包括App1（以及步骤81中接收到的触发、源地址和目的地地址的详情），或者，如果已关于其他触发/用户参数将App1存储于其中，则更新参数以包括那些与步骤81中接收到的数据相对应的参数。图11是示出数据如何分布在SPS 303的多个组件间的示意图：对应于动态数据313的圆圈代表关于已按照上述方式（如图10中所示）从注册功能305接收到的数据的应用，而对应于所提供的数据311的圆圈代表用户已就其签约但是还未向网关101注册的应用。

从图9和11的比较可以看出，两个注册过程的不同之处在于，在第一注册方法中，动态数据库313能保持实际上对该特定用户/触发事件来说无效的应用数据，而在第二注册方法中，动态库313将只保持用户真实访问的应用子集。同时，在第一配置中，这意味着动态数据库313能保持无效数据，这是比第二配置稍微快些的过程（其包含的步骤比第二过程所需的步骤少两个步骤）；然而，第二注册过程比第一注册过程更安全。根据第二实施例的注册应用的特别优势在于，注册过程对注册应用是透明的，这意味着其能方便地与任何OSA标准兼容配置整合。

如下的另一过程也是可能的（未示出），其中，SPS保持指定了应用的所有可能组合以及与其相关联的交互条件的数据。这些数据是离线汇集的，使得在注册过程中，SPS用作一种相关应用间规则的查找功能。当注册功能305（通过SCS 103）接收到应用注册请求时（步骤81），注册功能305将assignmentId指配给应用App 1并将已指配的识别码发送到SPS 303（步骤82）。响应于接收到该识别码，SPS 303基于此来检索交互规则、以及已为该用户注册的任何其他应用，并将检索到的交互规则与步骤81处接收到的触发、源地址和目的地地址相关联。另外，SPS更新动态库313，从而包括App1（以及步骤81中接收到的触发、源地址和目的地地址的详情），或者，如果已关于其他触发/用户参数将App1存储于其中，则更新参数以包括那些与步骤81中接收到的数据相对应的参数。可参照以下示例来描述根据该实施例的SPS的操作：

SPS 303被设置为存储如下所示的交互规则：

假定仅从应用X接收到了应用请求的用户记录，那么响应于来自应用Y的随后注册请求，SPS 303除了更新动态数据库313以反映应用Y向该用户的注册以及步骤81处接收到的触发数据之外，还检索对应用组合X&Y的交互规则（此处为beta），并且针对用户和触发标记检索到的交互规则。如果随后应用Z向该用户注册，则SPS 303查出对应用组合X、Y和Z的交互规则（alpha），并由此更新SPS 303和动态数据库313。如果应用X随后注销（或者自身或者关于用户），则SPS 303检索交互规则gamma并由此更新库信息。当从网络中接收到有关相关联的触发的事件时，这些交互规则指定两个或更多个应用间的有效交互。需要注意的是，这些交互取决于从业务（应用）接收到的与业务相关联的响应和/或消息类型；该行为可方便地在交互规则中被指定，或可在与有关业务相关联的数据中被指定。

需要注意的是，该配置明显不同于由BT给出的配置（其被描述为“特征交互/业务选择”）。在BT方法和系统中，在应用注册时查阅交互规则以确定多个应用关于同一触发是否能共存。如果交互规则允许请求应用与已关于相关联的用户/触发注册的应用共存，则将该请求应用的详情记录在用户配置文件中。当随后接收到对应网络触发时，按照根据应用在用户配置文件中的列出次序（其是由应用向网关注册的次序确定的）而确定的次序依次调用这些应用。相反，根据本发明实施例，注册过程中选择的是应用间的潜在交互，已离线解决了实际的和可允许的应用间关系和随之发生的行为。结果，应用被调用的次序不受制于应用向网关注册的次序，或者实际上甚至与之无关。相反，按照预先设定的规则（其可被优化为应用本身的功能）指定对应用的调用。这是优于BT设计的一个明显优点。

如上所述，除存储表示可用应用的数据以及在注册阶段指配的相关联的实时状态信息外，SPS 303还被设置为存储表示业务与应用间的关系（关于应如何处理输入的网络事件）的数据；按照与网络事件（或触发）相关联的“呼叫模式逻辑”的形式来存储这些数据。根据前文应当明白，在第三注册方法的情况下，在应用注册时选择这种交互规则或呼叫模式逻辑。如以下将更详细地描述的，在根据第一和第二方法来实现对应用的注册的情况下，当从网络接收到事件时从交互规则库中选择相关联的交互规则。

从前文可明白，在OSA和IN应用的情况中，应用间的冲突问题在注册阶段完全被忽略。相反，当从网络中收到业务请求时，由SIF 301来控制应用间管理。关于这些组件的配置，参照图12，在第一配置中，SIF301位于网关101中，并承担与各个网络应用服务器节点App1…Appn通信的任务。图13示出了一种另选配置，其中SIF 301位于网关101外，因此直接与OSA应用App1、App2和SPS 303通信，同时通过接口与网关101通信。在两幅图中，虚线表示与网关接口进行通信，以与外部设备（例如，在图12的情况下为SPS 303和应用App1、App2，在图13的情况下为SCS 101）进行通信。

业务调用

将参照图14来描述SIF 301的组件及由此提供的功能，图14是示出将SIF 301分解为其组成部分的框图。优选的是，这些组件被实现为一个或更多个软件组件，并分布在一个或一套计算机设备上，所述计算机设备包括标准CPU、存储器、数据总线、输入/输出端口、数据存储器以及操作系统程序（未示出）。

一般而言，SIF 301被设置为提供IN间到IN和/或IN到OSA和/或OSA间到OSA的应用中介（mediation），使得多个业务应用可以共享触发点，例如以上列出的智能网络应用协议（INAP）和Camel应用协议（CAP）检测点事件。在一种配置中，SIF被配置为从MSC 107或者从任何SCF（例如，包括图2中所示的SCS 103的SCF）接收包括某种触发的业务请求消息；根据接收到的触发，执行对SPS数据库303的查询；响应于该查询从SPS 303接收数据；根据与SPS 303返回的数据相关联的呼叫模式逻辑（其是由SPS 303返回的）调用并协调该数据识别的任何业务应用；并比较总体响应以发送回SCS 103或MSC 107来使得业务能够继续。该呼叫模式逻辑包括在呼叫建立期间根据从其他业务接收到的响应和消息而开展业务；该逻辑是足够灵活和精细的，对于给定网络事件，在事件建立中可涉及MSC 107和其他网络交换设备，且可调用任何给定业务应用一次以上。

在本实施例中，SIF 301包括：业务接口140，用于与网络业务应用IN1…Inx、App1…Appn以及诸如MSC 107的交换设备通信；SPS接口141，用于与SPS 303、逻辑引擎142以及事件处理引擎143通信。业务接口140被设置为至少支持CAP、INAP、MAP、SIP和诸如CORBA和SOAP的API，从而使SIF 301能与一系列全异的网络设备通信。

逻辑引擎142被设置为依据触发和用户数据，从SPS 303请求业务数据以及标识业务应用的规则和详情的数据（按照固定规则145、动态规则147和/或脚本规则149（其中至少一些规则是从SPS 303实时接收到的）的形式）。逻辑引擎142被设置为在接收到了这些数据之后，生成一个或更多个网络处理事件，这些网络处理事件涉及通过业务接口140调用业务以及使得事件处理引擎143监视来自如此调用的业务的输出并对此作出反应。具体的是，事件处理引擎143被设置为执行事务管理、相关性管理（例如，从不同交换机接收到的相关DP）、超时控制（关于从业务IN1…INx、App1…Appn以及SPS 303接收到的响应）；程序管理（关于业务排序，和对多项同时独立操作的支持）；以及正如统计和告警管理的普通管理任务。因此，事件处理引擎143能响应于OSA callEventNotify()消息和/或IN InitialDP而实现一个或更多个网络业务以及OSA应用，比较来自一些或全部执行过的业务的全部响应并发送数据到SCS 103或MSC 107以将用户与必需的网络业务相连。

下面将更详细地描述网络事件处理引擎143的特征和功能。有效地采用从SPS 303返回的呼叫模式逻辑（通常以数据145、147的形式）来控制以启动和随后的消息调用IN和OSA业务应用IN1…INx、App1…Appn的顺序，由此解决了由触发点产生的发布单个触发的问题。在一个业务应用的输出影响另一业务应用的操作的情况下，调用优选地为同步的，但如果通过事件处理引擎143简单地组合来自多个业务应用的输出，则优选地异步调用业务应用以改善等待时间。因此可以看到，可通过利用从SPS 303检索到的规则，在处理呼叫时对应用间处理进行管理。除了SPS 303返回关于诸如callEventNotify()的OSA触发和诸如InitialDP触发的IN触发的排序规则外，还有用于处理事件通知（ERB（IN）、RouteRes()（OSA））applyCharging（AC/ACR（IN）、superviseCallReq()/superviseCallRes()（OSA））消息、临时呼叫以及资源访问（ETC/CTR）和从其得到的任何响应的规则。

简言之，SIF 301的操作可被看作包括两个不同阶段：第一阶段，其中SIF 301检索与触发相对应的可执行数据；和第二阶段，其中SIF 301基于可执行数据调用应用，所述调用包括监视从执行过的应用接收到的数据并对其作出反应。

另外，事件处理引擎143还被设置为控制产生冲突事件和动作的多个业务应用的操作。举一简单示例，如果多个业务应用返回CONNECT(IN)或routeRequest()（OSA）消息，则事件处理引擎143应用多种规则以确定哪条消息“胜出”；在另一简单示例中，如果不同业务应用返回CONNECT/routeRequest()消息和RELEASE(IN)或release()（OSA）消息，则事件处理引擎143应用多种规则以确定采取哪两个冲突动作。因此，基本上根据从与冲突事件和/或动作相关联的SPS 303检索到的适当规则来处理输出。

事件处理引擎143被设置为依照故障类型根据从SPS 303检索到的动态（即可配置）规则147来处理通信故障。例如，如果第一业务应用中止，则一个选项是中止整个事务，而另一选项可能是如果第一业务应用完成但第二业务应用失败，则来自第一业务应用的响应应优先。

事件处理引擎143还被配置为监视预定时间段内的响应，其中，如果业务应用响应未能到达或MSC响应失败，则SIF 301执行多个动作中的一个。例如，在业务应用未能在指定时间段里响应的情况下，SIF可根据相关联的错误规则发送TCAP失败响应到MSC 107。该错误和超时规则可以是由SIF 301存储并保持的静态规则145。

概述之，逻辑引擎142和事件处理引擎143根据固定、动态和静态规则145、147、149指定的条件控制如下动作：

i．业务应用被调用的次序；

ii．如何合并来自业务应用的响应；

iii．应如何执行基于来自业务应用的响应的后续事务；

iv．呼叫控制是由SIF管理，还是委派给业务应用；以及

v．是否应将应用从作为网络类型（例如，本地或漫游）的功能的调用中排除。

下面将对固定规则145的非限制性示例列表进行描述：

●请求是累积的：如果业务应用A请求请求报告BCSM DPx并且应用B请求RRB DPy，则结果是应当请求RRB DPx和DPy。（请求报告BCSM在这里被称为RRB，是用来创建稍后通信流中的触发点的请求——例如，繁忙、断线、应答、无应答。如果这些点被触发，则自动生成事件报告BCSM（ERB））；

●如果存在对同一DP的多个RRB请求，则应仅请求单个调用；

●如果存在对同一DP的多个RRB请求，则应最高地请求监测模式；

●如果所有业务应用都指示继续，则应仅返回CONTINUE；

●如果仅为用户/DP列有一个业务应用，则SIF应当退出呼叫，即，将InitialDP转发到业务应用，将响应直接择路回起始MSC；

●如果没有定义业务应用，则SIF应当返回CONTINUE响应；

●SIF应当在最早可能时机退出该流程；例如，如果仅将CONTINUE、CONNECT或RELEASE返回到MSC，或如果所有期望MSC响应都是针对单个应用的；

●等等。

下面将对动态规则147的非限制性示例列表进行描述：

●InitialDP中继到业务应用的次序应当为配置的优先次序。

●如果可异步调用业务应用，则应当异步调用它们，这是因为这将改善等待时间；

●如果响应是RELEASE，则总体响应应当由业务应用的释放优先次序来管理。如果具有较高释放优先权的业务应用还没有返回RELEASE（即，CONTINUE或者CONNECT），则应当忽略来自较低优先权业务应用的RELEASE。如果RELEASE是来自最高释放优先权的应用，则无需执行其余业务应用；且应当返回RELEASE和TCAPEND；

●如果返回CONNECT，则返回到MSC的被呼叫/呼叫方应当来自具有最高连接优先次序的业务应用。

●等等。

下面将对优选编写的规则149的非限制性示例列表进行描述：

●收费报告（ACR）应当仅被发布给那些有助于先前生成的AC的应用。针对各业务应用发送ACR到适当形式可能需要复杂计算；

●当动作取决于消息内的内容时，可使用脚本来识别消息内的内容并调用适当的动作；

●等等。

除上述固定、动态和静态规则145、147、149外，SIF 301依照几条通用规则操作，这些规则包括如下内容：

●当对MSC的响应是简单的CONNECT、CONTINUE或RELEASE（基本结束）时，SIF应当以TC_END结束TCAP对话；

●如果SIF确定没有更多期待的消息（例如，接收到的ACR指示呼叫结束，且以后不再提供触发点），则SIF应当不使用TC_END地结束事务——这已知为预置结束，且不再发送更多消息；

●如果SIF从MSC接收到TC_ABORT，则SIF应当结束所有公开对话——通过中继TC_ABORT；

●如果SIF从MSC接收到TC_END，则SIF应当结束所有公开对话——通过中继TC_END；

●如果发生意外错误，则SIF应当以TC_END结束对话；

●ERB繁忙报告之后，应当返回连接消息到不同的号码（这可能使先前与其他应用的所有交互无效，因此可使用脚本来中止某些应用或明确地修改行为，可能使用专为此目的生成的消息）。

应当明白，在这个和其他实施例中，规则中使用的协议和/或API是那些适于所涉及的业务的规则，且不限于INAP、CAP、GCC、MPCC。

下面将参照涉及对从移动站MS 2输入的呼叫进行处理的几个示例情形来对事件处理系统的功能进行描述。参照图15，在第一示例中，系统涉及控制各种IN业务的操作，包括用于当用户MS 2正漫游在访问者网络（visitor network）VPLMN中时改变服务节点的业务本地路由（SHR）应用，和其操作取决于本地网络中的服务节点的未指定业务应用IN1。该第一示例例示了SIF 301、SHR应用和一个其他应用间的交互，且同样地为一简单示例；它被包含进来以表明传递到SIF 301、服务节点107和业务节点以及从SIF 301、服务节点107和业务节点传递的规则类型、条件和消息，以帮助理解本发明的其他更复杂的实施例。

在该示例中，使用SIF 301来管理对取决于与用户MS 2相关的业务数据的各个业务应用SHR、IN1的输入以及来自其的输入（SHR业务允许在本地网络（HPLMN）范围内处理呼叫，只要这可以解决与由访问者网络（VPLMN）进行的处理相关联的问题或限制）。

图15是示出在系统的多个组件间转移（transfer）通信的示意图，而图16是示出由SIF 301执行的步骤的框图。在下文中，将一起参照图15和图16。在步骤1501，接收到了位置更新请求之后，HLR 115发送包括O-CSI（始发Camel签约信息）的信号到vMSC 107（访问者网络中的MSC），vMSC 107执行各种认证和建立（setup）过程以用网络VPLMN认证用户MS 2。在步骤1501发送到vMSC 107的信息包括SIF 301的网络地址和关于用户MS 2存储的业务触发。

在成功认证所述用户后，vMSC 107等待用户MS 2请求访问网络业务；一旦接收到请求（步骤1503），vMSC 107就发送（步骤1505）消息到SIF 301，该消息包括识别用户MS 2并指定业务触发类型（在本实施例中为CAP IDP DP2）的数据，以及CdPN（B）和CgPN（MS 2）的详情。转至图16，当SIF 301接收到消息时，它首先识别消息的类型（步骤1601）。在该示例中，将消息的类型识别为业务建立消息，并且，因为IDP代表新的呼叫，所以SIF 301使用例如目录访问协议（DAP）制定查询（步骤1603）以从SPS 303检索数据。在制定并执行适当查询后，SPS303根据该查询返回数据，该数据包括对用于指定用户MS 2可访问的业务以及业务可被访问的条件的规则和业务信息的选择（步骤1605）。在本示例中，SPS 303查询返回如下数据：

MS 2

●业务应用：

SHR，IN1：均被配置为响应于DP2事件

●条件：

规则（1）首先访问SHR；

规则（2）如果SHR返回CdPN的相关地址：

则（1）用相关地址替代CdPN；并且（2）当呼叫路由经过HPLMN时访问IN1。

然后根据这些条件来配置事件处理引擎143（步骤1607），有效地使之能监视从SHR输入的数据，并根据SHR应当返回相关地址的事件（1）和（2）进行响应。转回到图15，在步骤1507，SIF 301发送包含触发数据（IDP和DP2）的消息至SHR，并在步骤1509，接收来自于SHR的响应（SHR业务应用负责确定呼叫是否应当被本地路由）。

在该示例中，SHR业务应用发送相关地址到SIF 301，SIF 301根据图16所示的步骤进行相同处理：在步骤1601，SIF 301确定接收到的数据是来自SHR业务应用，并将该数据传递给事件处理引擎143（其先前被配置为监视这种输入）。接着，事件处理引擎143以接收到的数据作为输入运行从SPS 303检索到的规则，在这种情况下，所述输入包括用于指定要执行的本地路由及其相关地址的数据（步骤1611）。根据规则（2），要执行的下一步动作是将该相关地址发送到vMSC 107以改变用户MS 2连接的交换机，因此事件处理引擎143准备要发送到vMSC的消息（步骤1613），并随后准备事件处理引擎143以监视下一个连接事件（步骤1615）。在该特定情形中，事件处理引擎143被配置为监视与在步骤1505中被发送到SIF 301的初始检测点（IDP）相同的IDP。

转回到图15，在步骤1511，SIF 301发送CONNECT消息到vMSC，用来指示vMSC切换到与相关地址（CID）相对应的交换机。SIF 301还发送TCAP消息，用来关闭SIF 301与vMSC 107之间的对话。在步骤1513，vMSC 107将呼叫择路到GMSC，GMSC为具有对应于相关地址CID的网络地址的交换机且位于本地网络（HPLMN）内。接收到连接消息时，GMSC发送IDP消息到SIF 301，该消息包括相关地址CID和新的检测点DP3（步骤1515）。再转至图16，在确定消息源自交换机并包含与SIF 301先前保存的CID相关的初始检测点IDP后，事件处理引擎143以接收到的数据作为输入运行在步骤1603从SPS 303检索到的规则（步骤1611）。根据其余事件（事件（2）），从本地网络（HPLMN）的交换机接收到消息后，SIF 301要执行的下一动作是发送消息到业务应用IN1，并等待来自其的响应。因此，在步骤1517，事件处理引擎143发送消息到IN1并等待答复。

可能有取决于来自IN1的输出——取决于业务应用的性质——的若干其他事件，但上面给出的示例表明可如何采用SIF 301来协调SHR业务应用以及取决于与SHR相同的触发的至少一个其他业务应用IN1（在本示例中为DP2）。

下面将参照图17来描述仅涉及OSA应用的事件处理系统的功能，图17示出了涉及对从网络输入的触发进行处理的通常情形。参照图17，在步骤1701，SCS 103接收到IN事件并将其传递到SIF 301，该IN事件包括用来识别呼叫方（用户）并指定业务触发类型（例如，CAP IDP DP2）的数据，以及被呼叫方（CdPN）的详情。识别出这是来自网络的关于当前事件处理情形的第一条这样的消息后，SIF 301使用例如目录访问协议（DAP）制定查询（步骤1703）以与之相对应地从SPS 303检索数据。在接收到查询请求后，SPS 303从动态数据库313检索与用户和触发相对应的数据。回到参照图9，如果注册是根据第一配置发生的，则该步骤将涉及使用所提供的数据311对动态数据313进行过滤，并对于图9所示的示例将得到App1和App2的输出。另一方面，如果注册是根据第二配置发生的，则因为在注册过程中检查了用户对请求应用的访问，所以SPS303仅仅只需要检索动态库313的内容（App1和App2）。如果注册是根据第三配置发生的，则SPS 303将检索动态库313的内容（App1和App2），以及管理App1与App2间的交互的预选交互规则。

对于其中注册先前已根据第一或第二注册方法发生的情况，不同于第三注册方法，一旦识别了相关应用（App1，App2），SPS 303就必须执行单独的步骤，来选择用于指定可访问应用的条件的规则和业务信息；与注册方法无关，在步骤1705，随后将目前选择的交互规则发送到SIF 301。接下来，根据这些条件来配置事件处理引擎143，出于本示例的目的，可假设使App2在App1前被调用。因此，在步骤1707，通过例如callEventNotify()消息来调用App2，并在步骤1709，SIF 301，更具体地为事件处理引擎143（其已预先被配置为当在步骤1707发送通知消息时，监视这样的输入），接收并处理响应。接着，事件处理引擎143以在步骤1709接收到的数据为输入，运行在步骤1705从SPS 303检索到的规则。根据经处理的一条或多条规则，事件处理引擎143确定要执行的下一个动作是发送在步骤1709接收到的数据到App1，因此事件处理引擎143发送callEventNotify()消息到App1（步骤1711），并随后准备事件处理引擎143以监视下一连接事件。在接收到来自App1的响应（步骤1713）后，事件处理引擎143以在步骤1713接收到的数据为输入运行在步骤1705从SPS303检索到的规则。根据经处理的一条或多条规则，事件处理引擎143确定要执行的下一个动作是连接呼叫方（用户）与被呼叫方（邮箱VPS），因此SIF 301使得SCS 103发送CONNECT消息到网络（步骤1715），指示网络将用户连接到他的语音邮箱VPS，使他能够访问他的录音消息。步骤1717表示对其他网络事件（一个或更多个OSA应用已经注册了对其的关注）的发送。

图18示出了涉及OSA和IN应用的事件处理系统的示例，并示出本发明的实施例还可被用来控制作为与网络触发有关的整个事件处理业务的一部分的OSA应用和IN业务的操作。在该情形下，步骤1701、1703、1705如关于图17所描述地进行，但因为在本示例中假定所关注触发使得SPS请求与IN业务和OSA应用均相关的数据，所以SPS 303返回的数据将包括调用规则，该规则使得SCS 103使消息进入OSA域的发送与消息到IN域的发送相交替；图中给出了相关联的步骤的列表。

根据以上示例可以看到，根据本发明实施例配置的事件处理系统提供了业务整合功能，即整合并控制多个业务应用的操作。在包括多个事件处理系统的网络配置中，可开发业务应用中央库使之能被这种SIF中的任何一个或子集根据指配给特定事件处理系统的访问规则访问。另外，在提供对多个预约和/或传统业务应用的访问的任何给定SIF中，SIF被配置为将这些应用彼此并与新近开发的其他业务应用整合起来。本发明实施例的一个特别的优点是，SIF包括有效地广告其功能的装置，使得新近开发的业务应用能以前摄方式使用这种功能；在图14中，该功能被示意性地示出为SCS API 148。

图19至23中给出了与本发明实施例相关联的用于例示灵活性的其他示例，其中第一个示例例示了SIF 301协调诸如iVPN业务的搜寻应用（App1）的操作与国际无缝语音应用（App2）的操作。在该示例中，搜寻应用App1被配置为确认被呼叫方（用户）的哪个注册设备是有效的，并提供与之相关的号码翻译业务。另外，该示例还可包括SHR应用（其或者在SIF内或者作为单独的应用（未示出）），该应用可被用来指示vMSC按照以上示例中描述的方式切换呼叫控制给GMSC。响应于接收到来自vMSC的连接请求（步骤1901），SIF被配置为（如上所述，通过利用从SPS 303检索到的规则（下文中给出））发送对号码翻译业务的请求（步骤1903）到App1。如上所述，App1是iVPN搜寻应用，其可以访问为用户注册的预先指定设备列表，并且响应于在步骤1903从SIF发送的业务请求消息，发送回（步骤1905）与该列表中第一个设备相对应的经翻译的、全数位号码，并且如果该设备不可用则发送回ERB繁忙消息请求。响应于从App1接收到第一个设备的经翻译号码，SIF为来自vMCS的RRB繁忙消息建立等待事件（步骤1907），并发送包括经翻译号码的详情的消息到App2（步骤1909）。App2然后向SIF发送连接指令（步骤1911），并且如果第一个设备不可用则发送ERB繁忙消息请求。

SIF 301然后合并来自应用App1、App2的输入，并发送关于第一个设备的连接请求到vMSC（步骤1913）。在本示例中，第一个设备不可用，所以vMSC返回ERB繁忙消息到SIF（步骤1915）；根据可用于本示例的规则，SIF被设置为优先接收ERB繁忙消息，并首先将它们发送到搜寻应用App1，同时标记如下事实，即App2需要被告知第一个设备不可用。在接收到ERB繁忙消息后，SIF发送ERB繁忙消息到App1（步骤1917），App1响应于此检索用户列表中的第二个设备的详情，并将其发送到SIF（步骤1919）。接收到该第二个设备的标识（标识长Y）时，SIF结束与App2有关第一个设备的会话（步骤1921），并开始关于第二个设备的第二段会话（步骤1923）。App2随后发送连接请求到SIF（步骤1925），这次是关于第二个设备（与以前相同，如果第二个设备不可用，则连接请求伴有ERB繁忙消息请求）。SIF 301再次合并来自应用App1和App2的输入，并发送关于第二个设备的连接请求到vMSC（步骤1927），随后的步骤（未示出）根据第二个设备的可用性或不可用性继续进行（即，如果第二个设备不可用，则有效地重复步骤1915至1927，反之如果第二个设备可用，则vMSC继续处理呼叫）。

关于该其他示例可应用的规则（如从SPS 303检索到并可由SIF 301执行以提供上述功能的规则）如下：

在本示例中，对于CAP T-CSI触发和用户MS 2，SPS 303查询返回如下业务数据和条件集：

●业务应用：

SHR，搜寻应用（若干经注册的设备），iSVA

●条件：

检查SHR是否可用（即，MSC是否在VPLMN中？）；

如果可用，则发送相关地址到VPLMN中的交换机；

规则（1）：首先访问搜寻应用；

规则（2）：如果来自搜寻应用的响应指示与目的地路由地址（DRA）集（对应于第一个设备）的连接，则修改IDP中的被呼叫方号码为DRA，并发送经修改的IDP到ISVA应用。否则，或者在其他任何情况下，发送未经修改的IDP到ISVA。

规则（3）：如果响应来自ISVA业务（CdPN），则存储CdPN直到MS 2连接到HPLMN的交换机；

规则（4）：如果搜寻应用和ISVA都请求RRB繁忙消息，则发送任何接收到的ERB繁忙消息到搜寻应用，检索新的目的地路由地址（即，对应于第二个设备的DRA），结束基于第一个DRA与ISVA的对话，并发送经修改的DRA到ISVA。

规则（5）：一旦MS 2通过HPLMN连接，则发送连接消息到HPLMN的交换机。

下面将参照图20来描述另一示例，图20示出SIF 301协调智能业务节点（VPN）和OSA业务节点（搜寻应用VPX）的操作的另一示例。在该示例中，假设用户已经签订了VPN业务作为智能网络业务，并希望该业务能与他新开始的OSA业务整合起来。因此，转至图20，响应于从MSC接收到连接请求（步骤2001），SIF被配置为（如上所述，通过利用从SPS 303检索到的规则）发送请求（步骤2003）到VPN业务。作为响应，VPN返回（步骤2005）对应于被呼叫方号码的全数位号码。作为响应，SIF发送包括全数位号码的详情的消息（步骤2007）到VPX。VPX应用向SIF发送（步骤2009）关于与被呼叫方的全数位号码相对应的第一个设备（标识E）的连接指令，并且如果第一个设备不可用则还发送ERB繁忙消息请求。SIF为来自MCS的RRB繁忙消息建立等待事件（步骤2011），合并来自应用VPN、VPX两者的输入，并发送关于第一个设备的连接请求到MSC（步骤2013）。在本示例中，第一个设备不可用，所以MSC返回ERB繁忙消息到SIF（步骤2015），使得SIF发送ERB繁忙消息到VPX（步骤2017），VPX响应于此检索用户列表中的第二个设备的详情并将其发送到SIF（步骤2019）。在接收到该第二个设备的标识（标识F）时，SIF发送关于第二个设备的连接请求到MSC（步骤2021），随后的步骤（未示出）根据第二个设备的可用性或不可用性而继续进行（即，如果第二个设备不可用，则有效地重复步骤2017至2021）。

图21示出另一示例，图21示出使用SIF 301协调后付费和预付费业务的操作：在该示例中，SIF 301被配置为执行关于后付费价目的处理以将它们修改为适于预付费业务的格式。这种后付费应用包括VPN应用和“办公室区”应用，其中后者识别用户的位置并据此修改标准价目（即，VPN价目）。响应于接收到来自MSC的连接请求（步骤2101），SIF首先基于伴随着连接请求的业务密钥SK(a)以及从SPS 303请求的数据，识别出用户是预付费类型，该类型用户已被准予访问各种后付费OSA业务（每一个都可分别通过业务密钥SK(b)和SK(c)识别）。因此，在步骤2103，SIF 301被配置为发送请求到网关101，通过利用业务密钥SK(b)识别该阶段要被查询的应用；在接收到业务密钥SK(b)和相关联的呼叫数据时，网关101发送calleventNotify()消息到对应于业务密钥SK(b)的应用（其在这种情况下为App2）（步骤2105）。App2是VPN搜寻应用，其能访问为用户注册的预先指定设备列表，并且，App2响应于发自GW 101的业务请求消息，发送回（步骤2107）对应于列表中的第一个设备的经翻译、全数位号码以及与此业务相关联的价目。鉴于App2是后付费应用，OSAGW 101将价目信息与相关联的SCI收费响应消息打包并发送到SIF（步骤2109）。根据发自SPS 303的规则，SIF随后确定要查询的下一个应用是办公本地应用App1，并发送请求到网关101，该请求包括通过利用业务密钥SK(c)识别App1的数据以及识别被呼叫方的数据（步骤2111）；在接收到业务密钥SK(c)时，网关101识别出请求要被发送给办公应用App1，并向之发送被呼叫方号码（长B）（步骤2113）。作为响应，App1通过OSA GW 101发送指示与呼叫方的位置相关联的价目——价目Y——的数据到SIF（步骤2115、2117）。一旦接收到全异的价目信息，SIF就处理数据以识别适于向用户提供这些业务——在用户的能力之内——的价目作为预付费用户类型（步骤2119）。该评估过程的输出是发送包含合并的价目数据和业务请求的消息到预付费业务IN1（步骤2121）。一旦被接收到，预付费业务IN1就执行标准收费评估过程并（假设用户有足够资金）发送呼叫连接请求和繁忙消息请求（步骤2123）到SIF 301。响应于此，SIF 301为来自MSC的RRB繁忙消息建立等待事件，并发送关于第一个设备的连接请求到MSC。

图22示出了又一示例，图22示出SIF 301与SPS 303间的交互（这被假定为在之前的示例已被执行）以及与网络中业务节点的交互。在该示例中，SIF 301和SPS 303和谐地相互作用以解决用户在不是Camel 3的网络中漫游时遇到的问题，即，当HLR 115仅发送O-CSI业务到VLR时出现的问题。当仅配备O-CSI业务时，vMSC无法在已指定前缀的呼叫与需要本地路由（和其他业务）的事件之间加以区分；结果，不正确地处理vMSC未识别的具有前缀的呼叫。（这些前缀被称为“B＃”，且相应事件需要N-CSI/D-CSI业务数据以使VLR知道呼叫应当通过“一键通”业务节点处理。）在该示例中，假设已提供SPS 303使得能够基于B＃——基本上，除用户和触发数据外，都基于B＃键入数据——确定输入呼叫是否应当被发送到一键通节点还是本地路由。然后参照图22，在步骤2201，vMSC发送消息到SIF，该消息包括作为被呼叫方号码的前缀的B＃。作为响应，SIF 301联系SPS 303，请求有关被呼叫方号码（步骤2203）和用户的特定业务信息。在步骤2205，SPS 303执行某些内部处理，用来将该前缀与针对该用户关于B＃业务存储的数据进行比较。如果所存储的数据表示该用户已经签订一键通业务，则将表示该业务的数据发送到SIF 301（步骤2207），这使得SIF 301能够发送有所相同的消息到适当的业务（此处为PTT）。如果用户还没有调用PTT业务，则SPS 303相反将发送表示该呼叫应当是本地路由的数据，使得SIF 301与图22中所示的SHR节点通信。

图23示出了再一示例，图23示出SIF 301与预付费业务IN2结合地控制滞后呼叫转发（LCFOR）以避免如下情形，其中当A方呼叫B方且B方正处于漫游时，在A方（在本地网络中）连接的交换机、访问网络中的与B方相关联的vMSC、以及本地网络中用户可访问的相关联业务节点之间建立语音回路。然后参照图23，在步骤2301，SIF 301接收到来自网关MSC的终止呼叫检测点；SIF 301从SPS 303请求与用户相对应的数据，并且，确定用户除了另一业务IN2（未指定）外签订了LCFOR业务，SIF 301确定它需要首先调用LCFOR节点。因此，在步骤2303，SIF 301发送表示呼叫是终止呼叫的数据到LCFOR业务节点，LCFOR业务节点在步骤2305发送对ERB繁忙信息/无应答/已放弃/已应答消息的请求到SIF 301。SIF 301内部地记录，一旦对呼叫的控制被传递给网关MSC，它就需要监视来自MSC的任何这种ERB消息，并发送消息给被呼叫用户可访问的其他业务节点（示出的一个业务节点是IN2）（步骤2307）。业务节点IN2发送关于正被应答的呼叫的收费消息和ERB应答消息请求到SIF 301（步骤2309），使得SIF 301记录它需要监视正被应答的呼叫，并通知业务节点IN2。SIF 301随后指示GMSC继续进行该呼叫（步骤2311），使得GMSC连接到vMSC（步骤2313）。响应于正被应答的呼叫，GMSC发送ERB消息到SIF（步骤2317）；鉴于在步骤2305为这种消息注册了LCFOR节点，SIF 301在步骤2319将消息转发到LCFOR节点，作为响应，LCFOR节点发送呼叫转发指令到SIF（步骤2321）。响应于接收到该消息，SIF 301在步骤2323结束先前与IN2节点的有效会话，相反开始有关呼叫转发事件的会话（步骤2325）。然后配置关于这种呼叫转发事件的呼叫收费，而且SIF 301在步骤2329指示GMSC连接到被转发的号码。

其他实施例详情

尽管实施例描述了SS7呼叫处理，但是本发明实施例可被应用到其他类型的网络事件，包括SIP（业务启动协议）呼叫处理和消息处理。

另外，SIF 301的操作可利用通过API（例如，CORBA、SOAP）调用的方法来开始，使得SIF能提供跨IN业务应用的业务中介设施。

尽管SIF 301被描述为单个实体，但应当明白这种实体可被分布在多个处理组件上。

以上实施例应被理解为本发明的说明性示例，并可以构想本发明的其他实施例。应当理解，关于任何一个实施例描述的任何特征可以被单独使用，或者与所描述的其他特征结合使用，并还可以与任何其他实施例的一个或更多个特征，或任何其他实施例的任何组合结合使用。此外，在不脱离所附权利要求中限定的本发明的范围的情况下，还可以采用以上未描述的等同物及修改。

Claims

1.一种在事件处理系统中用于处理业务初始请求消息的事件处理方法，所述事件处理系统包括业务交互功能(SIF)模块、服务节点和多个业务节点，用户在处理网络事件期间能从所述多个业务节点接收业务，各所述业务节点能够发送包括专用于该业务节点的操作的数据的业务响应消息，所述事件处理方法由所述SIF模块执行并且包括如下步骤：

在接收到由当前涉及处理所述网络事件的网络中的服务节点发送的第一业务初始请求消息时，

访问数据库以得到属性数据，

发送业务请求消息到所述多个业务节点，

从所述多个业务节点接收业务响应消息，并

基于所述业务响应消息中包含的数据，控制涉及处理同一网络事件的所述多个业务节点中的至少一些业务节点的操作，

其中，如果从所述多个业务节点中的一个业务节点接收到的业务响应消息内包含的数据表示与从所述多个业务节点中的另一业务节点接收到的业务响应消息内包含的数据相冲突的请求，则基于所述属性数据来处理相应的业务响应消息内包含的数据，

其中，所述属性数据指定用于在所述多个业务节点之间基于接收到的业务响应消息而相互作用的规则。

2.根据权利要求1所述的事件处理方法，其中，基于所述业务响应消息的内容，在同一网络事件期间控制给定业务节点的操作一次以上。

3.根据权利要求1或权利要求2所述的事件处理方法，其中，发送业务请求消息到相应的业务节点，至少一条所述业务请求消息包含表示与所述第一业务初始请求消息相对应的一个或更多个业务初始触发的数据。

4.根据权利要求3所述的事件处理方法，其中，修改至少一个所述业务初始触发，并基于所述经修改的业务初始触发制定所述业务请求消息。

5.根据权利要求1所述的事件处理方法，其中，由于所述操作而监视对其他业务初始请求消息的接收。

6.根据权利要求1所述的事件处理方法，其中，由于所述操作而监视对其他业务响应消息的接收。

7.根据权利要求1所述的事件处理方法，其中，在接收到由当前涉及处理同一网络事件的所述网络中的服务节点发送的第二业务初始请求消息时，控制所述多个业务节点中的至少一个节点的操作，并由于所述操作，发送业务响应消息到从其接收到第二业务初始请求消息的所述服务节点。

8.根据权利要求7所述的事件处理方法，其中，所述第一业务初始请求消息是从与从其接收到所述第二业务初始请求消息的服务节点相同的服务节点接收到的。

9.根据权利要求1所述的事件处理方法，其中，根据与用户相关联的数据以及所述第一业务初始请求消息中包含的所述数据来生成所述业务请求消息。

10.根据权利要求5所述的事件处理方法，其中，所述其他业务初始请求消息包括与所述第一业务初始请求消息内包含的触发数据不同的触发数据。

11.根据权利要求9或权利要求10所述的事件处理方法，其中，在分配与所述网络事件相关联的网络资源期间接收所述业务响应消息。

12.根据权利要求1所述的事件处理方法，其中，响应于接收到所述第一业务初始请求消息，以选定顺序发送第二业务初始请求消息到两个或更多个所述业务节点。

13.根据权利要求12所述的事件处理方法，其中，所述选定顺序取决于从一个或更多个所述业务节点接收到的业务响应消息。

14.根据权利要求1所述的事件处理方法，其中，所述事件处理方法包括监视步骤，用于监视来自第一个所述业务节点的业务响应消息，并且所述事件处理方法还包括响应于所述业务响应消息而发送第二业务初始请求消息到第二个所述业务节点。

15.根据权利要求1所述的事件处理方法，其中，响应于从第一业务节点接收到业务响应消息而调用监视步骤，用于监视基于所述业务响应消息而被执行的业务所输出的数据。

16.根据权利要求14所述的事件处理方法，其中，所述第二业务节点不同于所述第一业务节点。

17.根据权利要求14或权利要求15所述的事件处理方法，其中，监视从一服务节点发送的业务初始请求消息，该服务节点不同于从其发送所述第一业务初始请求消息的所述服务节点。

18.根据权利要求14所述的事件处理方法，其中，所述第二业务初始请求消息与所述第一业务初始请求消息的类型相同。

19.根据权利要求1所述的事件处理方法，响应于业务响应消息而生成业务指示消息，该业务指示消息包括请求改变所述事件处理所涉及的服务节点的数据，其中，发送所述业务指示消息到从其接收所述第一业务初始请求消息的所述服务节点。

20.根据权利要求19所述的事件处理方法，其中，所述生成的业务指示消息包括指示所述服务节点将所述网络事件切换到不同的服务节点的数据。

21.根据权利要求20所述的事件处理方法，其中，所述不同的服务节点位于与所述服务节点被设置在其中操作的网络不同的网络中。

22.根据权利要求21所述的事件处理方法，其中，所述多个业务节点中的一个业务节点是提供对网关之外的多个其他业务节点的访问的网关节点。

23.根据权利要求22所述的事件处理方法，其中，所述多个业务节点提供以下业务中的一种或多种：号码翻译业务、消息处理业务、消息修改业务、消息路由业务、语音邮件业务、呼叫转移业务、和/或设备搜寻业务。

24.根据权利要求1所述的事件处理方法，其中，响应于对从注册业务节点发送的一条业务注册请求消息的接收，以存储表示所述经注册的业务节点以及与所述用户相关联的对应业务初始触发的注册数据，所述注册数据用于处理从所述服务节点发送的关于所述用户的业务初始请求消息，

存储多个业务注册请求消息的注册数据，所述多个业务注册请求消息中的每一个都用来识别不同的业务节点和同一用户，

其中，在接收到所述注册数据后定义所述不同业务节点间的优先次序。

25.根据权利要求24所述的事件处理方法，其中，如果所述注册请求消息是从被确定为所述用户可访问的业务节点接收到的，则存储所述注册数据。

26.根据权利要求24或权利要求25所述的事件处理方法，其中，响应于接收到第二和以后的注册请求消息，检索用于指定对应的两个或更多个业务节点间的交互的交互数据，并存储所述交互数据，从而定义所述不同的业务节点间的优先次序。

27.根据权利要求24所述的事件处理方法，其中，响应于接收到业务初始请求消息，检索用于指定对应的两个或更多个业务节点间的交互的交互数据，从而定义所述不同的业务节点间的优先次序。

28.根据权利要求24所述的事件处理方法，其中，存储关于用于识别另一不同业务节点和同一用户的另一业务注册请求消息的另一注册数据，随后接收到所述另一业务注册请求消息，在存储了所述另一注册数据后定义所述不同的业务节点间的优先次序。

29.根据权利要求24所述的事件处理方法，其中，所述多个业务注册请求消息是在不同时刻被接收到的。

30.根据权利要求24所述的事件处理方法，其中，所述注册数据识别所述注册请求与之相关的多个用户。