一种IP多媒体子系统业务交互的实现方法

摘要

本发明公开了一种IP多媒体子系统业务交互的实现方法，提供一种简单易行的业务交互方法。为每个业务逻辑具有一个唯一的业务标识符，所述方法包括以下步骤：(a)服务呼叫会话控制功能即S-CSCF向用户请求业务的应用服务器即AS或业务能力交互管理器即SCIM发送初始会话协议请求消息即SIP请求；(b)所述AS或SCIM收到所述SIP请求，执行完本次业务后，将该业务的业务标识符插入到所述SIP请求中，将带有业务标识符的SIP请求返回给所述S-CSCF。

权利要求

1.一种IP多媒体子系统业务交互的实现方法，其特征在于，每个业务逻辑具有一个唯一的业务标识符，所述方法包括以下步骤：(a)服务呼叫会话控制功能即S-CSCF向用户请求业务的应用服务器即AS或业务能力交互管理器即SCIM发送初始会话协议请求消息即SIP请求；

(b)所述AS或SCIM收到所述SIP请求，执行完本次业务后，将该业务的业务标识符插入到所述SIP请求中，将带有业务标识符的SIP请求返回给所述S-CSCF；

(c)当所述S-CSCF向其他AS或SCIM发送SIP请求时，所述SIP请求中包含所有执行过的业务的业务标识符，其他AS或SCIM根据执行过的业务逻辑决定自己的处理逻辑；

(d)当所有业务处理完毕后，S-CSCF需要向用户设备发送所述携带有业务标识符的SIP请求，边界网元收到所述SIP请求后，在发出请求消息时将其中的所有的业务标识符删除并保存到本地，待用户返回响应消息后，将保存的业务标识符插入到所述响应消息中，返回给所述S-CSCF，所述S-CSCF将响应消息带回给上游AS或SCIM，上游AS或SCIM根据执行过的业务逻辑决定后续业务逻辑。

2.如权利要求1所述的方法，其特征在于，当所述S-CSCF收到所述携带有业务标识符的响应消息后，根据初始过滤规则和所述响应消息中的业务标识符向相关AS或SCIM发送所述响应消息，触发相关业务。

3.如权利要求1所述的方法，其特征在于，在所述步骤(a)中，S-CSCF根据初始过滤规则和/或所述初始会话协议消息中记录的业务标识符确定发送SIP请求的AS或SCIM。

4.如权利要求3所述的方法，其特征在于，所述初始过滤规则中记载了以下内容的一种或几种：业务执行的优先级顺序、业务的互斥、业务的部分互斥、业务的依赖、业务的部分依赖。

5.如权利要求1所述的方法，其特征在于，所述业务标识符至少包含所执行的业务信息以及执行所述业务的应用服务器标识。

6.如权利要求1所述的方法，其特征在于，所述业务标识符为IP多媒体子系统通信业务标识符。

7.如权利要求1所述的方法，其特征在于，AS或SCIM将业务标识符插入到所述初始会话协议消息中的业务执行历史列表中。

8.如权利要求7所述的方法，其特征在于，所述S-CSCF为主叫S-CSCF或被叫S-CSCF，AS或SCIM执行完业务后插入业务标识符时，在所述业务执行历史列表中区分主叫业务的业务标识符和被叫业务的业务标识符；或者，接收主叫S-CSCF的SIP请求的AS或SCIM执行完业务后，将该业务的业务标识符添加到所述SIP请求中的主叫业务执行历史列表中，接收被叫S-CSCF的SIP请求的AS或SCIM执行完业务后，将该业务的业务标识符添加到所述SIP请求中的被叫业务执行历史列表中。

说明书

一种IP多媒体子系统业务交互的实现方法

技术领域

[0001] 本发明涉及在IP多媒体子系统网络中业务交互的实现方法。

背景技术

[0002] 3GPP R5(3rd Generation Partner Project，第三代伙伴计划——WCDMA的标准化组织)阶段引入了IMS(IP Multimedia Subsystem，IP多媒体子系统)，其与软交换网络相比特点是将呼叫控制与业务逻辑完全独立，IMS核心网只进行呼叫控制，业务逻辑完全由业务层实现，IMS核心网S-CSCF(Serving-Call Session Control Function，服务呼叫会话控制功能)与AS(Application Server，应用服务器)交互的接口称之为ISC(IP多媒体业务控制)接口，仍然采用SIP(Session Initiation Protocol，会话发起协议)。

[0003] IMS网络中业务层可能有多个独立的应用服务器来处理一个用户的签约业务，这样就带来了多个业务之间交互处理的问题，不同的业务逻辑之间是存在关联关系的，有的必须要保证先后关系，有的业务是相互依赖，有的是互斥，为了保证客户能够得到期望的服务，网络必须保证这些业务逻辑之间的关系得到满足，从而保证整个呼叫得到正确的处理。

[0004] 目前的协议标准中主要依赖于iFCs(Initial filter criteria，初始过滤规则)来实现触发多个业务，一个用户可以签约多个iFC，iFC之间有优先关系，每个iFC对应一个应用服务器实例。iFC触发的原理是对整个初始请求进行文本的正则表达式匹配，可以做到依据SIP消息中的任何特征子串进行业务触发，这一点结合iFC签约的AS名称可以携带部分特征参数可以做到以下简单的业务交互：1)决定多个AS的触发顺序；2)根据SIP请求中包含的特定内容决定是否触发下一个AS；3)当一个AS实现多种业务逻辑时，可以通过将iFC中的AS名称签约上特征子串，该子串将带在触发到该AS的请求中Route头部中，AS可以根据此特征子串决定该执行何种业务逻辑；4)两个在签约中顺序相临的AS，可以根据前一个AS转发的请求中的SIP消息特征子串决定是否触发后一个AS。

[0005] 但是仅仅依据iFC实现业务嵌套有其局限性，1)呼叫链中的任何一个中间AS可能充当B2BUA(Back to Back User Agent，背靠背用户代理——SIP服务器的一种实现模式)角色，完全重新生成SIP请求，从而将前一个AS的处理结果在SIP消息中的特征完全抹去，签约中的后续iFC匹配无法根据以往处理的业务进行决策；2)签约中顺序位于上游的AS无法获得任何下游的AS处理信息，当存在业务部分特性冲突时将导致呼叫处理出错。

[0006] 目前业界已经提出在S-CSCF和AS之间设置一个SCIM(Service Capability Interaction Manager，业务能力交互管理器)来实现中众多业务的交互，3GPP R8中已经有专题研究。SCIM的部署分为以下三种：1)集中式，所有的AS都通过同一个SCIM和S-CSCF接口；2)分布式，每个AS可以内置SCIM；3)混合式，部分AS可以通过同一个SCIM和S-CSCF交互，部分AS可以内置SCIM。集中式SCIM设置时，SCIM可以全权控制AS之间的交互关系，得到一次呼叫所有参与AS的处理状态也相对容易，但由于性能考虑、部署成本、主被叫位于不同域等情况存在，一个SCIM控制所有的AS比较困难。当分布或混合模式时，SCIM之间需要增加交互。但总体来说SCIM的能力定义还比较模糊，成熟尚有待时日。

发明内容

[0007] 本发明要解决的技术问题是提供了一种IP多媒体子系统业务交互的实现方法，提供一种简单易行的业务交互方法。

[0008] 为了解决上述技术问题，本发明提供了一种IP多媒体子系统业务交互的实现方法，每个业务逻辑具有一个唯一的业务标识符，所述方法包括以下步骤：

[0009] (a)服务呼叫会话控制功能即S-CSCF向用户请求业务的应用服务器即AS或业务能力交互管理器即SCIM发送初始会话协议请求消息即SIP请求；

[0010] (b)所述AS或SCIM收到所述SIP请求，执行完本次业务后，将该业务的业务标识符插入到所述SIP请求中，将带有业务标识符的SIP请求返回给所述S-CSCF。

[0011] 进一步地，上述方法还可具有以下特点，在所述步骤(b)后，还有一步骤(c)，当所述S-CSCF向其他AS或SCIM发送SIP请求时，所述SIP请求中包含所有执行过的业务的业务标识符，其他AS或SCIM根据执行过的业务逻辑决定自己的处理逻辑。

[0012] 进一步地，上述方法还可具有以下特点，当所有业务处理完毕后，所述S-CSCF需要向用户设备发送所述携带有业务标识符的SIP请求，边界网元收到所述SIP请求后，保存其中所有的业务标识符，待用户返回响应消息后，将保存的业务标识符插入到所述响应消息中，返回给所述S-CSCF，所述S-CSCF将响应消息带回给上游AS或SCIM，上游AS或SCIM根据执行过的业务逻辑决定后续业务逻辑。

[0013] 进一步地，上述方法还可具有以下特点，当所述S-CSCF收到所述携带有业务标识符的响应消息后，根据初始过滤规则和所述响应消息中的业务标识符向相关AS或SCIM发送所述响应消息，触发相关业务。

[0014] 进一步地，上述方法还可具有以下特点，在所述步骤(a)中，S-CSCF根据初始过滤规则和/或所述初始会话协议消息中记录的业务标识符确定发送SIP请求的AS或SCIM。

[0015] 进一步地，上述方法还可具有以下特点，所述初始过滤规则中记载了以下内容的一种或几种：业务执行的优先级顺序、业务的互斥、业务的部分互斥、业务的依赖、业务的部分依赖。

[0016] 进一步地，上述方法还可具有以下特点，所述业务标识符至少包含所执行的业务信息以及执行所述业务的应用服务器标识。

[0017] 进一步地，上述方法还可具有以下特点，所述业务标识符为IP多媒体子系统通信业务标识符。

[0018] 进一步地，上述方法还可具有以下特点，AS或SCIM将业务标识符插入到所述初始会话协议消息中的业务执行历史列表中。

[0019] 进一步地，上述方法还可具有以下特点，所述S-CSCF为主叫S-CSCF或被叫S-CSCF，AS或SCIM执行完业务后插入业务标识符时，在所述业务执行历史列表中区分主叫业务的业务标识符和被叫业务的业务标识符；或者，接收主叫S-CSCF的SIP请求的AS或SCIM执行完业务后，将该业务的业务标识符添加到所述SIP请求中的主叫业务执行历史列表中，接收被叫S-CSCF的SIP请求的AS或SCIM执行完业务后，将该业务的业务标识符添加到所述SIP请求中的被叫业务执行历史列表中。

[0020] 本发明提供了一种简单易行的在IMS网络中实现业务交互的方法，它无需网络设置复杂的SCIM就可以满足大部分场景下的业务交互需求，包括1)业务之间完全互斥；2)业务之间部分互斥；3)业务之间完全依赖；4)业务之间部分依赖。但对于更为复杂的交互要求，如业务执行顺序动态调整(根据每次呼叫请求的特征来决定将请求发送给多个AS的先后顺序，而不是在签约中固定一个顺序)等则需借助其它技术实现，不再赘述。本发明的目标不是取代SCIM，而是对IMS网络功能的一种扩展，并且这种扩展可以为SCIM所用，亦即本发明如下流程中应用服务器执行的相关业务交互操作可以在设置SCIM的网络中由SCIM和AS分工负责，SCIM可以利用本发明提供的手段决定AS的互斥、依赖关系。

附图说明

[0021] 图1为本实施例的实体框图；

[0022] 图2为本实施例应用于设置了SCIM的网络实体框图；

[0023] 图3为本发明第一实施例包含了实现互斥、部分互斥两种业务交互关系的流程图；

[0024] 图4是本发明第二实施例包含了实现依赖及部分依赖两种业务交互关系的流程图。

具体实施方式

[0025] 本发明的思路如下：

[0026] 为每种业务逻辑分配一个唯一的业务逻辑标识符，该标识符可以是一个字符串，同时设置一个SIP语法成分SEH(Services Execution History，业务执行历史列表)，其关键特征是可以存放多个业务逻辑标识符，当呼叫经过每个应用服务器时，应用服务器应在SEH插入自己所处理的业务逻辑标识符，这样下游服务器可以查看该头部中已经执行的业务逻辑决定自己的处理逻辑，从而实现下游与上游业务的交互；同时，当所有业务处理完毕时，SEH必须从响应消息中带回给上游服务器，上游服务器可以查看此其内容决定后续业务逻辑，从而实现了上游业务与下游业务的交互。

[0027] 本发明所定义的SEH可以是一种SIP头部字段，也可以作为一个消息体形式存在，无论何种形式均只影响相关功能实体操作SIP消息的方式，对本发明的实施流程无影响。为简化起见且不致引起歧义，以下一律采用SEH的称谓。

[0028] 具体描述如下：

[0029] 1)为每一种业务逻辑分配一个标识符，该标识应在全网保证唯一，可以采用已有的标准组织建议或运营商进行统一分配。应用服务器可以定义该业务处理的子状态(即是将业务分成多个步骤，多个步骤是在呼叫中的多次消息交互中逐步完成的，因此可以根据本发明实现部分步骤不予/予以执行，达到业务之间部分互斥/依赖的交互关系)，一个应用服务器可以处理多种业务逻辑，因此也可以具有多个业务标识符。业务标识符至少包含所执行的业务信息以及执行该业务的应用服务器标识。

[0030] 这一标识符可以采用3GPP R7中提出的ICSI(IMS CommunicationService Identifier，IMS通信业务标识符)，也可以采用其它类型的标识符。运营商可以定义应用之间的关系矩阵，这种关系可以是依赖、互斥、部分依赖、部分互斥中的一种或多种关系，AS/SCIM可以根据这一关系矩阵作为后续的业务处理依据。

[0031] 2)每一种业务逻辑处理完毕后必须将自己的业务标识符插入到SIP消息中的业务处理历史列表SEH中，如果AS收到触发请求，但由于配置或业务互斥原因未执行任何逻辑，则不应向SEH中追加任何信息。由于SEH需要贯穿整个呼叫真实反映业务处理历史以便实现业务交互，因此AS无论是B2BUA、Proxy(代理)都必须只能追加自己的标识符信息，不能删除、修改已有的业务处理列表。

[0032] 3)签约的iFC可以根据SEH匹配来实现不同业务之间的互斥、依赖关系，无论两种有联系的业务之间签约顺序是否相临。iFC是一种字符串匹配规则，由S-CSCF执行匹配，它可以匹配SEH中是否存在/不存在某种业务逻辑标识符，匹配结果为是否将呼叫送至某个应用服务器进行处理。

[0033] 4)呼叫链上后续的AS可以根据上游AS记录下的SEH内容来决定自己的业务逻辑是否执行，或者采用不同的业务逻辑细节行为。

[0034] 5)SEH必须保证有序，以便后续能够根据多个已执行业务的组合、时序关系决定下一步的业务逻辑。

[0035] 6)某些情况下需要实现始呼和终呼侧的业务交互，可以在SEH内容中加上始呼/终呼标签，也可以用不同的头部表示始呼、终呼的业务处理历史，不管是在SEH中还是分别表示的，本文中均将其分别称之为O-SEH、T-SEH，采用后种方式可以减轻签约iFC正则表达式的复杂程度。

[0036] 7)SEH为业务信息，无需暴露到非信任域或用户侧。边界网元(包括P-CSCF)应删除所有发往非信任域、终端SIP消息中的SEH；对于初始SIP请求，边界网元在删除SEH前应保存其内容，当收到对端初始SIP请求的任何非100Trying的响应后应插入保存的SEH。例如AS将消息发到P-CSCF，P-CSCF发送给UE之前应删除SEH，当收到UE响应后，应该重新插入SEH。这样做的目的是为了让呼叫链中位于上游的AS可以感知下游的业务处理，并据此决定是否开启已经执行业务后续逻辑中的部分特性。

[0037] 下面结合附图和具体实施方式对本发明作进一步详细描述。

[0038] 图1是本发明一个具体实施例的实体框图，其中101为S-CSCF，102-105分别为四个执行不同逻辑的AS。图2是本发明应用于设置了SCIM的网络中的实体框图，其中201为S-CSCF，202为集中设置的SCIM，负责管理多个AS之间的业务交互关系，204-206为四个执行不同逻辑的AS。

[0039] 图3示出了一种实现业务互斥的实施例，实施例中存在4个应用逻辑，分别为A、B、C、D，其中应用A与应用C互斥，B的逻辑又划分为两个子逻辑B1、B2，其中B2特性在会话建立后执行，并且与D逻辑互斥。

[0040] 步骤301-303，S-CSCF收到某用户设备发来的SIP请求消息，根据iFC初次匹配结果将呼叫触发给应用A；

[0041] 步骤304-305，应用A处理完业务逻辑后将自己的应用标识ICSIA插入SEH，以供后续业务交互使用，然后将请求消息返回给S-CSCF；

[0042] AS需结合业务交互关系以及AS本身对业务的一些配置信息进行判断是否执行该业务。

[0043] 步骤306-307，S-CSCF继续匹配iFC将收到的请求消息转发给B；

[0044] S-CSCF在后续的iFC匹配中还需要参考SEH的内容。

[0045] 步骤308-309，应用B处理完业务逻辑的B1特性后将自己的应用标识ICSIB插入SEH，然后将消息发送回S-CSCF，应用B的子功能B2将根据响应消息中的SEH内容决定是否执行；

[0046] 步骤310，S-CSCF继续匹配iFC，由于iFC中签约了“如果SEH表明已经执行A逻辑，则不执行C逻辑”，该iFC匹配失败，继续匹配下一个iFC；

[0047] “已经执行A逻辑”是根据SEH是否已经存在ICSIA来判断，这一步是根据SEH实现了A和C业务之间的互斥。

[0048] 如果有SCIM，iFCs的解析功能也有可能在SCIM执行。

[0049] 步骤311，S-CSCF继续匹配下一个iFC，将呼叫发送给D；

[0050] 步骤312-313，应用D处理完业务逻辑后将自己的应用标识ICSID插入SEH，然后将消息发送回S-CSCF；

[0051] 步骤314-318，S-CSCF将请求消息转发出去，稍后收到响应消息，响应消息中携带有完整的SEH，S-CSCF将消息依次转发给应用D、B；

[0052] 边界网元(P-CSCF等)在发出请求消息时将其中的SEH删除并保存到本地，P-CSCF收到UE的响应消息后再将保存的SEH插入到响应消息中，如果业务失败，P-CSCF没有收到响应消息，则会生成失败响应，仍在该响应消息中插入保存的SEH。因此S-CSCF收到的响应消息中携带了请求中生成的完整SEH。

[0053] 步骤319，应用B查看响应消息中的SEH，发现应用D已经执行，则记下，并且禁止后续B2子逻辑的执行；

[0054] 本步骤实现了应用B和D的部分互斥功能。

[0055] 步骤320，应用B将响应消息转发给S-CSCF。

[0056] S-CSCF、其它AS的后续消息处理过程略。

[0057] 如果是图2所示的设置了SCIM的网络，则本实施例的304-305、308-310、312-313步骤可以全部或部分由SCIM负责执行。如果SCIM能够了解AS的执行子状态，则319也可以由SCIM执行。

[0058] 本更进一步地，本实施例可以将A、B、C、D四个业务分别签在主被叫两个用户上，流程基本不变，例如A、B为主叫用户业务，C、D为被叫用户业务，那么除了在步骤310处增加主叫S-CSCF将消息发往被叫S-CSCF，后续C、D业务与被叫S-CSCF通信外，流程不变。

[0059] 图4示出了一种实现主被叫之间业务互斥的实施例，实施例中存在4个应用逻辑，分别为A、B、C、D，A、B属于主叫业务，C、D属于被叫业务，其中应用C依赖于应用A，B的逻辑又划分为两个子逻辑B1，B2，其中B2特性在会话建立后执行，并且与依赖于应用D，也即只有在应用逻辑D已经执行的情况下才会执行B2子逻辑。

[0060] 本示例将SEH分为主叫SEH(O-SEH)，被叫SEH(T-SEH)，用于区分主被叫不同的业务逻辑执行历史，实际实施时O-SEH、T-SEH可以是同一个SIP头部中不同的参数予以区分，也可以是独立的两个SIP头部。当仅称SEH时则表示包括O-SEH和T-SEH。

[0061] 步骤401-403，起呼S-CSCF收到一条SIP请求消息，根据iFC初次匹配结果将呼叫触发给应用A；

[0062] 步骤404-405，应用A通过解析消息或其它上下文信息，判断无需执行自身业务逻辑，仅仅简单将SIP请求消息转发回S-CSCF，并且也不向SEH插入任何内容；

[0063] 步骤406-407，起呼S-CSCF继续匹配iFC将呼叫发送给B；

[0064] 步骤408-409，应用B处理完业务逻辑的B1特性后将自己的应用标识ICSIB插入O-SEH，然后将消息发送回起呼S-CSCF；

[0065] 应用B的子功能B2将根据响应消息中的SEH内容决定是否执行。

[0066] 步骤410，起呼S-CSCF将请求发给终呼S-CSCF；

[0067] 步骤411，终呼S-CSCF匹配iFC，由于iFC中签约了“如果SEH表明已经执行A逻辑，则执行C逻辑，否则不执行C逻辑”，由于A逻辑没有执行，该iFC匹配失败，继续匹配下一个iFC；

[0068] “已经执行A逻辑”是根据SEH是否已经存在ICSIA来判断，这一步是根据SEH内容实现了A和C业务之间的依赖关系。

[0069] 步骤412，终呼S-CSCF继续匹配下一个iFC，将呼叫发送给D；

[0070] 步骤413-414，应用D处理完业务逻辑后将自己的应用标识ICSID插入T-SEH，然后将消息发送回终呼S-CSCF；

[0071] 步骤415-421，终呼S-CSCF将请求消息转发出去，稍后收到响应消息，边界网元(P-CSCF等)在发出请求消息时将其中的SEH删除并保存到本地中，收到响应消息后将保存的SEH插入到消息中，因此终呼S-CSCF收到的响应消息中携带了请求中生成的完整SEH，终呼、始呼S-CSCF将消息依次转发给应用D、B；

[0072] 步骤422，应用B查看响应消息中的SEH，发现应用D已经执行，则执行B2子逻辑，若未发现SEH中的ICSID值，表示应用D未曾执行过则不予执行B2子逻辑；

[0073] 本步骤实现了应用B和D的部分依赖功能。

[0074] 步骤423，应用B将响应消息转发给始呼S-CSCF。

[0075] S-CSCF、其它AS的后续消息处理过程略。

[0076] 如果是图2所示的设置了SCIM的网络，则本实施例的404-405、408-409、411、413-414步骤可以全部或部分由SCIM负责执行。

[0077] 本发明的核心在于采用了全新的扩展SIP语法成分SEH，并定义了相关网元对该成分的处理规则，呼叫处理中的应用服务器可以通过操作、查看SEH内容来决定本身的行为，从而实现IMS业务的交互的方法。

[0078] 采用本发明所述的IMS业务交互机制，不仅可以实现呼叫参与任何一方所签约业务之间的交互，而且可以实现呼叫参与方之间的业务交互，比如呼叫参与双方分属不同的运营商，因此也不可能采用同一个SCIM来控制业务交互，但应用本扩展后，SEH信息可以在呼叫双方网络传递，因此仍然可以采用本发明来实现主被叫之间的业务交互。