CN100356803C - 控制业务承载方式改变的方法 - Google Patents

Abstract

本发明公开一种控制业务承载方式改变的方法，应用于通信核心网中，所述通信核心网包括有交换节点。该方法主要包括以下步骤：预设呼叫建立后交换节点间用于控制业务承载方式改变的综合业务数字网用户部分协议消息；当呼叫建立后，交换节点间根据所述预设的综合业务数字网用户部分协议消息控制业务承载方式改变。基于本发明提出的核心网信令增强，能在基于电路交换的核心网中，提供业务承载方式改变的特性，满足不断出现的新用户需求，呼叫流程也非常简单，易于实现。

Description

控制业务承载方式改变的方法

技术领域

本发明涉及通信技术领域，具体涉及一种通信核心网中在呼叫建立后控制业务承载方式改变的方法。

背景技术

随着第三代移动通信系统(3G，3rd Generation)的发展，各种新业务不断涌现。为提高移动用户对业务的感受，开始出现控制承载方式改变的新技术，这种新技术是指在一定条件下通过修改业务的承载属性参数实现承载方式的改变，利用这种改变进而可实现各种业务间的切换。

以电路域可视电话业务和语音业务为例，电路域可视电话被普遍认为是3G特色的多媒体业务，具有良好的发展前景，目前在3G移动网络中已提出电路域多媒体业务回落和改变这一特性。所谓电路域多媒体业务回落和业务改变特性，是指在一定条件下可视电话业务回落到语音业务，以及在通讯过程中可视电话业务和语音业务之间的相互切换。其应用情形可例举如下：主叫方发起一个可视电话呼叫，由于各种情况，例如被叫方不愿意承担可视电话较贵的费用，或者被叫用户终端不支持可视电话功能；或者主叫或被叫用户没有签约该种可视电话业务等多种情况，被叫用户因此希望选择该呼叫为普通语音接收；另外，在通讯过程中有可能一方用户希望将语音业务改变为可视电话业务，或从可视电话业务改变为语音业务等。

以实现所述电路域多媒体业务回落和改变为例，其中涉及到用户终端、接入网和核心网的各个方面。而在电路域交换核心网中，可视电话业务一般使用64k非受限数据信息(UDI，Unrestricted Data Information)的业务承载方式，语音业务一般使用语音(speech)或3.1k音频(3.1k audio)的业务承载方式。对核心网而言，要实现上述不同业务承载方式的改变，其前提是需要核心网信令流程支持修改承载属性参数。

目前，时分复用(TDM，Time-division multiplexing)电路域交换核心网中广泛使用ISDN用户部分(ISUP，ISDN User Part)信令，国际电联(ITU，International Telecommunication Union)规范了ISUP的信令消息、消息编码方式以及相关信令处理流程。

其中在ITU-T Q.764的ISUP信令协议中详细定义了有连接类型回退的信令及处理流程用于实现业务承载方式的改变，其处理流程可参考图1所示，主要包括以下步骤：

1、主叫用户终端发送呼叫建立消息setup，消息中携带重复指示参数RI和两个承载属性参数BC。其中RI＝02，表示支持回退，BC1优选，当BC1失败时选择BC2；BC1设为H.324多媒体呼叫，BC2设为语音。

2、发端MSC将收到的BC参数转换成ISUP相应的参数，在初始地址消息IAM中携带这些参数，发给后续MSC。其中传输介质需求(TMR，Transmissionmedium requirement)设为优选64k不受限(64k unrestricted preferred)，基本传输介质需求(TMR′，Transmission medium requirement prime)设为语音(speech)，这两个参数是必须的。非受限数据信息(UDI，Unrestricted DataInformation)设为语音，基本用户业务信息(UDI′，User service informationprime)设为优选64k不受限，这两个参数是可选的，可以有，也可以没有。

3、正常情况下，汇接MSC将IAM消息透传送给终端MSC。

4、终端MSC收到IAM消息后，向被叫终端发呼叫建立setup消息，消息中携带重复指示参数RI和两个承载属性BC参数。RI＝02，表示支持回退，BC1优选，当BC1失败时选择BC2；BC1设为H.324多媒体呼叫，BC2设为语音。

5、被叫用户终端得到H.324可视电话呼叫的指示，被叫用户选择不接收可视电话，而当作普通语音呼叫接收，此时被叫终端向终端MSC发送呼叫确认消息，携带一个承载属性参数BC，BC设为语音。

6、终端MSC向汇接MSC发送ISUP应答消息ANM，携带所用传输介质参数所使用的传输介质(TMU，Transmission medium used)，TMU为语音。

7、正常情况下，汇接MSC将ANM消息透传给发端MSC。

8、发端MSC收到ANM消息后，向主叫终端发呼叫确认消息，消息中携带一个承载属性参数BC，BC设为语音。

在核心网ISUP流程中，另两个参数用户业务信息(USI，User serviceinformation)和基本的用户业务信息(USI′，User service information prime)，在上述流程中可以有，也可以没有。

上述为现有技术中呼叫建立阶段的控制业务承载方式改变的实现方案，但是，对于呼叫连接建立之后的业务承载方式改变，现有ISUP信令协议还无法实现，即在呼叫话路连接已建立之后，现有ISUP信令协议中并没有定义合适的消息和处理流程来实现业务承载方式的改变。

发明内容

本发明解决的技术问题是提供一种可实现在呼叫建立后控制业务承载方式改变的方法，以适应用户对新业务的需求。

为解决上述问题，本发明的控制业务承载方式改变的方法，包括以下步骤：

A、预设呼叫建立后交换节点间用于控制业务承载方式改变的综合业务数字网用户部分协议消息；

B、当呼叫建立后，交换节点间根据所述预设的综合业务数字网用户部分协议消息控制业务承载方式改变。

其中，所述预设的综合业务数字网用户部分协议消息包括：承载修改请求消息、承载修改确认消息以及承载修改拒绝消息。

其中，步骤B所述根据综合业务数字网用户部分协议消息控制业务承载方式改变包括：

B1、发起交换节点向目的交换节点发送承载修改请求消息；

B2、目的交换节点判断是否接受修改请求，若判断结果为是，则返回承载修改确认消息并控制业务传输承载方式改变，同时，发起交换节点收到承载修改确认消息后也相应控制业务传输承载方式改变；否则，返回承载修改拒绝消息。

其中，所述发起交换节点为呼叫发端交换节点，所述目的交换节点为呼叫收端交换节点，步骤B1包括：

B11、呼叫发端交换节点向呼叫汇接交换节点发送承载修改请求消息；

B12、呼叫汇接交换节点向呼叫收端交换节点转发承载修改请求消息；

步骤B2包括：

B21、呼叫收端交换节点判断是否接受修改请求，若判断结果为是，则执行步骤B22；否则执行步骤B23；

B22、呼叫收端交换节点向呼叫汇接交换节点发送承载修改确认消息，并同时控制业务承载方式改变，所述呼叫汇接交换节点向呼叫发端交换节点转发承载修改确认消息，相应控制业务承载方式改变，呼叫发端交换节点在收到承载修改确认消息后也相应控制业务承载方式改变；

B23、呼叫收端交换节点向呼叫汇接交换节点发送承载修改拒绝消息，所述呼叫汇接交换节点向呼叫发端交换节点转发承载修改拒绝消息。

其中，步骤B12可由下述的步骤B111所替代：

B111、呼叫汇接交换节点直接向呼叫发端交换节点发送承载修改拒绝消息拒绝其承载修改请求。

其中，所述发起交换节点为呼叫收端交换节点，所述目的交换节点为呼叫发端交换节点，步骤B1包括：

B13、呼叫收端交换节点向呼叫汇接交换节点发送承载修改请求消息；

B14、呼叫汇接交换节点向呼叫发端交换节点转发承载修改请求消息；

步骤B2包括：

B23、呼叫发端交换节点判断是否接受修改请求，若判断结果为是，则执行步骤B24；否则执行步骤B25；

B24、呼叫发端交换节点向呼叫汇接交换节点发送承载修改确认消息，同时控制业务承载方式改变，所述呼叫汇接交换节点向呼叫收端交换节点转发承载修改确认消息，并相应控制业务承载方式改变，呼叫发端交换节点在收到承载修改确认消息后也相应控制业务承载方式改变；

B25、呼叫发端交换节点向呼叫汇接交换节点发送承载修改拒绝消息，所述呼叫汇接交换节点向呼叫收端交换节点转发承载修改拒绝消息。

其中，步骤B14可由下述的步骤B131所替代：

B131、呼叫汇接交换节点直接向呼叫收端交换节点发送承载修改拒绝消息拒绝其修改请求。

其中，所述发起交换节点为呼叫汇接交换节点，所述目的交换节点为呼叫发端交换节点以及呼叫收端交换节点，步骤B1包括：

呼叫汇接交换节点分别向呼叫发端交换节点和呼叫收端交换节点发送承载修改请求消息；

步骤B2包括：

B26、呼叫发端交换节点和呼叫收端交换节点均接受修改请求，并控制业务承载方式改变，进而分别向呼叫汇接交换节点发送承载修改确认消息，呼叫汇接交换节点在收到所述承载修改确认消息后也相应控制业务承载方式改变；或

B27、呼叫发端交换节点或呼叫收端交换节点均拒绝修改请求，进而分别向呼叫汇接交换节点发送承载修改拒绝消息；或

B28、呼叫发端交换节点或呼叫收端交换节点中其中一个接受修改请求，向呼叫汇接交换节点发送承载修改确认消息，并相应控制业务承载方式改变；另一个拒绝修改请求，并向呼叫汇接交换节点发送承载修改拒绝消息；呼叫汇接交换节点向接受修改请求的交换节点再次发送承载修改请求消息，接受修改请求的交换节点在收到所述承载修改请求消息后，将承载方式改为修改前的承载方式，并向呼叫汇接交换节点发送承载修改确认消息。

其中，步骤B1发起交换节点根据主叫用户终端或被叫用户终端主动发起呼叫中的承载修改请求触发发起业务承载方式改变；或

发起交换节点根据系统和资源情况，决定是否修改当前承载属性，若判定当前承载方式不能继续保持时，则触发发起业务承载方式改变。

其中，所述承载修改请求消息中包含承载属性参数；所述承载修改确认消息中包含或不包含承载属性参数，其包含的承载属性参数值与承载修改请求消息中携带的承载属性参数值保持一致；所述承载修改拒绝消息中包含拒绝原因参数、包含或不包含承载属性参数，其包含的承载属性参数值为当前的承载属性参数值。

与现有技术相比，本发明具有以下有益效果：

首先，基于本发明提出的核心网信令增强，能在基于电路交换的核心网中，提供业务承载方式改变的特性，满足不断出现的新用户需求，如3G系统的电路域多媒体业务回落和业务改变，为运营商提供了一种切实有效的解决方案；

其次，本发明仅通过新增三条ISUP信令协议消息，不需要改变现有ISUP信令协议的承载属性参数，定义的呼叫流程也非常简单，易于实现。

附图说明

图1为现有技术控制业务承载方式改变的实现流程图；

图2为本发明控制业务承载方式改变的实现流程图；

图3为本发明由呼叫发端交换节点发起的一种成功的业务承载方式改变的呼叫流程示意图；

图4为本发明由呼叫发端交换节点发起的一种失败的业务承载方式改变呼叫流程示意图；

图5为本发明由呼叫发端交换节点发起的另一种失败的业务承载方式改变呼叫流程示意图；

图6为本发明由呼叫收端交换节点发起的成功的业务承载方式改变的呼叫流程示意图；

图7为本发明由呼叫收端交换节点发起的失败的业务承载方式改变的呼叫流程示意图；

图8为本发明另一种由呼叫收端交换节点发起的失败的业务承载方式改变的呼叫流程示意图；

图9为本发明由汇接交换节点发起的成功的业务承载方式改变的呼叫流程示意图；

图10为本发明由汇接交换节点发起的失败的业务承载方式改变的呼叫流程示意图；

图11为本发明由汇接交换节点发起的另一种失败的业务承载方式改变的呼叫流程图；

图12为本发明由主叫用户发起的可视电话业务与语音业务的业务承载方式改变的具体实施例示意图；

图13为本发明由网络发起的一种成功的可视电话业务与语音业务的业务承载方式改变的具体实施例示意图。

具体实施方式

本发明应用于通信核心网中，所述通信核心网包括有交换节点，其中所述交换节点涉及端局交换节点，也可能涉及汇接交换节点。

为克服现有技术在呼叫建立后不能实现承载方式改变的缺点，本发明通过对现有通信核心网中的ISUP信令协议进行增强，实现了核心网内部呼叫连接建立之后的承载改变功能，其核心在于：预设呼叫建立后交换节点间用于控制业务承载方式改变的ISUP信令协议消息；并在呼叫建立后，交换节点间根据所述ISUP信令协议消息控制业务承载方式改变。

本发明中所述预定协议采用ISUP信令协议，新增的ISUP信令协议消息包括：承载修改请求消息、承载修改确认消息和承载修改拒绝消息。其中所述承载修改请求消息中包含承载属性参数；所述承载修改确认消息中包含或不包含承载属性参数，其包含的参数值与承载修改请求消息中携带的承载属性参数值保持一致；所述承载修改拒绝消息中包含拒绝原因参数、包含或不包含承载属性参数，其包含的承载属性参数值为当前的承载属性参数值。所述拒绝原因参数可包括：消息不识别、网络不支持、用户不支持等，由于不能穷举，且不是本发明的关键，这里不再对拒绝原因赘述。

另外，可按照现有ISUP信令协议的编码方式对上述消息进行编码以便网络中识别。

为了便于区分涉及的网络实体并更好的理解本发明，对以下涉及的网络实体做下面的定义：

发起交换节点，定义为呼叫建立后核心网中发起承载方式改变的交换节点；

目的交换节点，定义为呼叫建立后核心网中呼叫对端配合承载方式改变的交换节点；

呼叫发端交换节点，定义为建立呼叫时发起呼叫的主叫用户所在的交换节点；

呼叫收端交换节点，定义为建立呼叫时被叫用户所在的交换节点；

汇接交换节点，定义为呼叫过程中传送呼叫信息的、位于呼叫发端交换节点与呼叫收端交换节点之间的交换节点。

参考图2，为本发明控制业务承载方式改变的实现流程图，主要包括以下步骤：

步骤s1、发起交换节点向目的交换节点发送承载修改请求消息，所述承载修改请求消息中携带所请求的承载属性参数；

其中发起交换节点根据各种情况发起修改请求，例如：根据主叫用户终端或被叫用户终端主动发起呼叫中的承载修改请求触发主动发起业务承载方式改变；或

发起交换节点根据系统和资源情况，决定是否修改当前承载属性，如识别到当前承载属性不能继续保持时，则触发主动发起业务承载方式改变。

s2、目的交换节点判断是否接受修改请求，若判断结果为是，则执行步骤s3，返回承载修改确认消息并根据承载修改请求消息中携带的承载属性参数控制业务传输承载方式改变，同时，发起交换节点收到承载修改确认消息后控制业务传输承载方式改变；否则，执行步骤s4，返回承载修改拒绝消息，所述承载修改拒绝消息中携带拒绝原因参数，另外还可携带当前的承载属性参数。

其中目的交换交换节点也根据各种情况判断是否接受修改请求，例如根据当前系统和资源情况，或者其他的原因进行判断，进而确定采用相应的承载方式。

下面以发起交换节点为呼叫发端交换节点，目的交换节点为呼叫收端交换节点的具体实施例进行说明。

参考图3，为呼叫发端交换节点发起的一种成功的业务承载方式改变的呼叫流程示意图，主要包括以下步骤：

A1、呼叫发端交换节点根据情况决定发起呼叫中的承载修改请求，向中间的汇接交换节点发送承载修改请求消息，消息中携带所请求的承载属性参数；

B1、中间的汇接交换节点将所述承载修改请求消息转发给呼叫收端交换节点；

C1、呼叫收端交换节点根据情况判断是否接受呼叫中的承载修改请求，经判断为是，则向汇接交换节点返回承载修改确认消息，消息中携带或不携带请求的承载属性参数，并根据承载修改请求消息中携带的承载属性参数控制业务传输承载方式改变；汇接交换节点收到承载修改确认消息后也相应控制业务承载方式改变；

D1、汇接交换节点向呼叫发端交换节点转发承载修改确认消息，消息中携带请求的承载属性参数；发端交换节点收到承载修改确认消息后相应控制业务承载方式改变。

参考图4，为呼叫发端交换节点发起的一种失败的业务承载方式改变实施例呼叫流程示意图，该实施例与图3所示的实施例步骤A1、B1相同，其不同主要在于以下步骤：

C2、呼叫收端交换节点根据情况判断是否接受呼叫中的承载修改请求，经判断为否，即呼叫收端交换节点不接受修改请求，则向汇接交换节点返回承载修改拒绝消息，该拒绝消息中携带拒绝原因参数，可携带或不携带当前的承载属性参数；

D2、汇接交换节点向呼叫发端交换节点转发承载修改拒绝消息，同样，该拒绝消息中携带拒绝原因参数，可携带或不携带当前的承载属性参数。

参考图5，为本发明呼叫发端交换节点发起的另一种失败的业务承载方式改变实施例呼叫流程示意图，在该种情况下，呼叫发端交换节点发起修改请求，若中间某个汇接交换节点收到该承载修改请求后，根据网络情况或一定设置决定拒绝承载修改请求，则直接向呼叫发端交换节点返回承载修改拒绝消息，该拒绝消息中携带拒绝原因参数，携带或不携带当前的承载属性参数，并不再向呼叫收端交换节点发起承载修改请求。

上述以发起交换节点为呼叫发端交换节点，目的交换节点为呼叫收端交换节点为例进行了说明，事实上所述发起交换节点还可以为呼叫收端交换节点，相应的，目的交换节点为呼叫发端交换节点，其实现与上述流程大致相同，但消息方向相反。

下面参考图6～图8进行说明，图6为呼叫收端交换节点发起的成功的业务承载方式改变的呼叫流程，图7为呼叫收端交换节点发起的失败的业务承载方式改变的呼叫流程，图8为另一种呼叫收端交换节点发起的失败的业务承载方式改变的呼叫流程。

其中图6实现的呼叫流程与图3所示的呼叫流程大致相同，其不同点主要在网络中的实体变换，即原呼叫发端交换节点在本实施例中变为呼叫收端交换节点，原呼叫收端交换节点变在本实施例中变为呼叫发端交换节点。

同样的，图7为呼叫收端交换节点发起的失败的呼叫流程，与图4所示意的呼叫流程大致相同，其不同点主要在网络中的实体变换，原呼叫发端交换节点在本实施例中变为呼叫收端交换节点，原呼叫收端交换节点在本实施例中变为呼叫发端交换节点。

同样的，图8为呼叫收端交换节点发起的另一种失败的呼叫流程。与图5类似的，本实施例中呼叫收端交换节点发送的承载修改请求消息，被传送到某一中间汇接交换节点，该中间汇接交换节点收到该承载修改请求消息后，根据网络情况或一定设置决定拒绝承载修改请求，并直接向呼叫收端交换节点返回承载修改拒绝消息，该消息中携带拒绝原因参数，携带或不携带当前的承载属性参数，并不再向呼叫发端交换节点发起承载修改请求。

上述描述了由呼叫发端交换节点和呼叫收端交换节点发起的承载方式改变，事实上，本发明还可以由汇接交换节点发起承载方式改变，汇接交换节点发起的情况较少，需向呼叫发端交换节点和呼叫收端交换节点都发送承载修改请求消息，若两端都返回承载修改确认或承载修改拒绝消息，则流程与上述类似；若一端不成功另一端成功，其处理则不同。

参考图9，为由汇接交换节点发起的成功的业务承载方式改变的实施例呼叫流程图，主要包括以下步骤：

A3、某个汇接交换节点根据情况决定发起呼叫中的承载修改请求，向呼叫发端交换节点和呼叫收端交换节点分别发送承载修改请求消息(没有确定的顺序)，中间可能经过其它多个汇接交换节点，该承载修改请求消息中携带所请求的承载属性参数；

B3、呼叫发端交换节点和呼叫收端交换节点根据情况判断是否接受呼叫中的承载修改请求，若两端都接受，则向发起修改请求的汇接交换节点返回承载修改确认消息，并根据承载修改请求消息中携带的承载属性参数控制业务承载方式改变，承载修改确认消息中间可能经过多个汇接交换节点，消息中携带或不携带请求的承载属性参数和请求的承载属性参数；汇接交换节点收到两边的承载修改确认消息后相应控制业务承载方式改变。

参考图10，为由汇接交换节点发起的失败的业务承载方式改变的呼叫流程图，该实施例中与上述图9实施例不同的呼叫流程主要在步骤B3，呼叫发端交换节点和呼叫收端交换节点在根据情况判断后，均不接受修改请求，然后向发起修改请求的汇接交换节点返回承载修改拒绝消息，中间同样可能经过多个汇接交换节点，消息中携带拒绝原因参数，携带或不携带当前的承载属性参数。

参考图11，为由汇接交换节点发起的另一种失败的承载方式改变的呼叫流程图，与图10所示实施例不同，本实施例中接收承载修改请求消息的交换节点有一端返回承载修改确认消息，另一端返回承载修改拒绝消息，本实施例中为呼叫发端交换节点返回承载修改拒绝消息，呼叫收端交换节点返回承载修改确认消息，并根据承载修改请求消息中携带的承载属性参数控制业务传输承载方式改变。为此，发起修改请求的汇接交换节点在收到承载修改拒绝消息后，再次向接受修改请求的呼叫收端交换节点发送承载修改请求消息，该消息中包含当前的承载属性参数，呼叫收端交换节点在收到所述承载修改请求消息后，修改当前的承载属性参数，重新将承载方式改变为原来的方式，并返回给汇接交换节点承载修改确认消息，消息中携带或不携带请求的承载属性参数，以此保持整个通信通道的承载一致性。

另外，当拒绝修改请求的交换节点为呼叫收端交换节点时，呼叫流程类似，只是相应的消息方向相反。

需要说明的是，对于本发明实现核心网节点内部的承载资源修改流程的协议消息，也即本发明新增的三个ISUP消息中携带的承载属性参数，可使用目前ISUP已定义的参数，如TMR或TMU参数以及USI参数，以支持现有网络，减少对ISUP信令的修改，其中USI是可选参数。

在某些情况下，除核心网节点内部的承载资源修改外，还需要核心网节点发起对核心网之外的节点的承载资源修改过程，可采用现有的信令协议实现。

另外，对于核心网节点与用户终端之间的交互同样不需改动，可利用现有技术实现，不再详述。

下面以具体的应用进一步说明本发明的方法，上述ISUP承载修改过程可应用于3G系统中可视电话业务与语音业务之间的承载改变，核心网侧可视电话业务的承载属性一般是64k UDI，语音业务的承载属性一般是语音(speech)或3.1k音频(3.1k audio)。图12是主叫用户发起的可视电话业务与语音业务的承载方式改变过程，发端MSC和收端MSC节点之间通过本发明增强的ISUP信令交互，用户端与MSC之间的承载改变采用现有信令支持，发端MSC和收端MSC之间应用上述的承载方式改变流程。主叫用户发起的承载方式改变的流程主要包括以下步骤：

A4、呼叫连接已建立的情况下，主叫用户发起可视电话承载改变为语音承载的修改请求，请求消息中携带请求改变的语音承载属性参数；

B4、发端MSC将用户侧消息中的语音承载属性参数转变为ISUP的承载属性参数，然后向收端MSC发送承载修改请求消息，该承载修改请求消息中携带请求的语音承载属性参数；

C4、收端MSC将ISUP中的语音承载属性参数转变为用户侧消息的承载属性参数，向被叫用户发送承载修改请求消息，该请求消息中携带请求的语音承载属性参数；

D4、被叫用户接受承载改变为语音，向收端MSC发送承载修改确认消息，并根据承载修改请求消息中携带的承载属性参数控制业务承载改变，该确认消息中携带或不携带语音业务的承载属性参数，收端MSC收到确认消息后控制业务承载改变；

E4、收端MSC向发端MSC发送承载修改确认消息，发端MSC收到确认消息后控制业务承载改变；

F4、发端MSC向主叫用户发送承载修改确认消息，主叫用户收到确认消息后控制业务承载改变，至此修改完成。

对于被叫用户发起的承载改变，与主叫用户发起的承载改变类似。

上述以主叫用户触发的可视电话和话音之间的承载方式改变进行了说明，下面以网络发起的可视电话业务与语音业务的承载改变进行说明。

图13是由网络发起的一种成功的可视电话业务与语音业务的承载改变过程示意图。简单说明如下：

发端MSC向收端MSC发送承载修改请求消息，然后发端MSC和收端MSC分别向主叫用户和被叫用户发送承载修改请求消息，主叫用户和被叫用户均返回承载修改确认消息，并根据承载修改请求消息中携带的承载属性参数控制业务承载改变，收端MSC收到被叫用户的修改确认后控制业务承载改变，最后收端MSC向发端MSC发送承载修改确认消息，发端MSC控制业务承载改变，至此修改完成。

需要说明的是，本发明的承载修改机制的应用不局限于可视电话和语音承载之间的改变，还可用于其它情况。

综上，基于本发明提出的核心网信令增强，能在基于TDM电路交换的核心网中，提供业务改变的特性，满足不断出现的新用户需求，如3G系统的电路域多媒体业务回落和业务改变，为运营商提供了一种切实有效的解决方案；

并且本发明仅通过新增三条ISUP消息，不需要改变ISUP参数，定义的流程也非常简单，易于实现。

以上所述仅为本发明的优选实施方式，并不构成对本发明保护范围的限定。任何在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的权利要求保护范围之内。

Claims (10)

1、一种控制业务承载方式改变的方法，应用于通信核心网中，所述通信核心网包括有交换节点，其特征在于，包括步骤：

A、预设呼叫建立后交换节点间用于控制业务承载方式改变的综合业务数字网用户部分协议消息；

B、当呼叫建立后，交换节点间根据所述预设的综合业务数字网用户部分协议消息控制业务承载方式改变。

2、如权利要求1所述的控制业务承载方式改变的方法，其特征在于，所述预设的综合业务数字网用户部分协议消息包括：承载修改请求消息、承载修改确认消息以及承载修改拒绝消息。

3、如权利要求2所述的控制业务承载方式改变的方法，其特征在于，步骤B所述根据综合业务数字网用户部分协议消息控制业务承载方式改变包括：

B1、发起交换节点向目的交换节点发送承载修改请求消息；

B2、目的交换节点判断是否接受修改请求，若判断结果为是，则返回承载修改确认消息并控制业务传输承载方式改变，同时，发起交换节点收到承载修改确认消息后也相应控制业务传输承载方式改变；否则，返回承载修改拒绝消息。

4、如权利要求3所述的控制业务承载方式改变的方法，其特征在于，所述发起交换节点为呼叫发端交换节点，所述目的交换节点为呼叫收端交换节点，步骤B1包括：

B11、呼叫发端交换节点向呼叫汇接交换节点发送承载修改请求消息；

B12、呼叫汇接交换节点向呼叫收端交换节点转发承载修改请求消息；

步骤B2包括：

B21、呼叫收端交换节点判断是否接受修改请求，若判断结果为是，则执行步骤B22；否则执行步骤B23；

B22、呼叫收端交换节点向呼叫汇接交换节点发送承载修改确认消息，并同时控制业务承载方式改变，所述呼叫汇接交换节点向呼叫发端交换节点转发承载修改确认消息，相应控制业务承载方式改变，呼叫发端交换节点在收到承载修改确认消息后也相应控制业务承载方式改变；

B23、呼叫收端交换节点向呼叫汇接交换节点发送承载修改拒绝消息，所述呼叫汇接交换节点向呼叫发端交换节点转发承载修改拒绝消息。

5、如权利要求4所述的控制业务承载方式改变的方法，其特征在于，步骤B12由下述的步骤B111所替代：

B111、呼叫汇接交换节点直接向呼叫发端交换节点发送承载修改拒绝消息拒绝其承载修改请求。

6、如权利要求3所述的控制业务承载方式改变的方法，其特征在于，所述发起交换节点为呼叫收端交换节点，所述目的交换节点为呼叫发端交换节点，步骤B1包括：

B13、呼叫收端交换节点向呼叫汇接交换节点发送承载修改请求消息；

B14、呼叫汇接交换节点向呼叫发端交换节点转发承载修改请求消息；

步骤B2包括：

B23、呼叫发端交换节点判断是否接受修改请求，若判断结果为是，则执行步骤B24；否则执行步骤B25；

B24、呼叫发端交换节点向呼叫汇接交换节点发送承载修改确认消息，同时控制业务承载方式改变，所述呼叫汇接交换节点向呼叫收端交换节点转发承载修改确认消息，并相应控制业务承载方式改变，呼叫发端交换节点在收到承载修改确认消息后也相应控制业务承载方式改变；

B25、呼叫发端交换节点向呼叫汇接交换节点发送承载修改拒绝消息，所述呼叫汇接交换节点向呼叫收端交换节点转发承载修改拒绝消息。

7、如权利要求6所述的控制业务承载方式改变的方法，其特征在于，步骤B14由下述的步骤B131所替代：

B131、呼叫汇接交换节点直接向呼叫收端交换节点发送承载修改拒绝消息拒绝其修改请求。

8、如权利要求3所述的控制业务承载方式改变的方法，其特征在于，所述发起交换节点为呼叫汇接交换节点，所述目的交换节点为呼叫发端交换节点以及呼叫收端交换节点，步骤B1包括：

呼叫汇接交换节点分别向呼叫发端交换节点和呼叫收端交换节点发送承载修改请求消息；

步骤B2包括：

B26、呼叫发端交换节点和呼叫收端交换节点均接受修改请求，并控制业务承载方式改变，进而分别向呼叫汇接交换节点发送承载修改确认消息，呼叫汇接交换节点在收到所述承载修改确认消息后也相应控制业务承载方式改变；或

B27、呼叫发端交换节点或呼叫收端交换节点均拒绝修改请求，进而分别向呼叫汇接交换节点发送承载修改拒绝消息；或

B28、呼叫发端交换节点或呼叫收端交换节点中其中一个接受修改请求，向呼叫汇接交换节点发送承载修改确认消息，并相应控制业务承载方式改变；另一个拒绝修改请求，并向呼叫汇接交换节点发送承载修改拒绝消息；呼叫汇接交换节点向接受修改请求的交换节点再次发送承载修改请求消息，接受修改请求的交换节点在收到所述承载修改请求消息后，将承载方式改为修改前的承载方式，并向呼叫汇接交换节点发送承载修改确认消息。

9、如权利要求3所述的控制业务承载方式改变的方法，其特征在于，步骤B1发起交换节点根据主叫用户终端或被叫用户终端主动发起呼叫中的承载修改请求触发发起业务承载方式改变；或

发起交换节点根据系统和资源情况，决定是否修改当前承载属性，若判定当前承载方式不能继续保持时，则触发发起业务承载方式改变。

10、如权利要求2-9任一项所述的控制业务承载方式改变的方法，其特征在于，所述承载修改请求消息中包含承载属性参数；所述承载修改确认消息中包含或不包含承载属性参数，其包含的承载属性参数值与承载修改请求消息中携带的承载属性参数值保持一致；所述承载修改拒绝消息中包含拒绝原因参数、包含或不包含承载属性参数，其包含的承载属性参数值为当前的承载属性参数值。

Images