CN100426922C - 一种智能网系统中呼叫接续的实现方法 - Google Patents

Abstract

本发明公开了一种智能网系统中呼叫接续的实现方法，该方法包括：智能网设备在接收交换设备向其发送的业务请求后，判断其中是否发生故障，如果发生故障智能网设备向交换设备返回消息指示其继续进行呼叫，交换设备接收该消息后，继续进行呼叫；否则执行正常的智能业务处理流程。本发明通过智能网设备在判断出其中发生故障后，向交换设备返回消息通知继续进行呼叫，实现了呼叫的接续，减少了用户和运营商的损失；此外，本发明也实现了对VPN短号的呼叫和普通被叫号码的区别处理，并且通过故障标志位的设置，减少了智能网设备的负担。

Description

一种智能网系统中呼叫接续的实现方法

技术领域

本发明涉及智能网通信技术领域，特别是指一种智能网系统中呼叫接续的实现方法。

背景技术

随着智能网系统在通信系统的广泛应用，智能业务和用户量的快速发展，智能用户的呼叫越来越依赖智能网系统的处理，即智能用户呼叫过程中产生的信令必须经过智能网设备正常处理和回应后才能保证智能业务的实现和呼叫的正常接续。

实现智能网功能的智能网设备主要是业务控制点(SCP)，现有技术中，SCP在收到用户交换设备向其发送的呼叫相关信息后，如果其中的重要组成部分如业务数据单元(SDU)或数据库发生故障，无法执行用户的智能业务，一般是直接向用户交换设备返回消息拒绝呼叫，用户交换设备在收到该消息后，拒绝用户呼叫。

由以上技术方案可以看出，现有技术中，在SCP发生故障后，签约在该SCP上的智能用户的智能业务全部失败，造成了签约在该SCP上的智能用户的呼叫无法接续，给运营商和用户都造成了巨大的损失。

发明内容

有鉴于此，本发明的目的在于提供一种智能网系统中呼叫接续的实现方法，该方法能够在SCP发生故障的情况下实现呼叫的接续，减少用户和运营商的损失。

为了达到上述目的，本发明提供了一种智能网系统中呼叫接续的实现方法，该方法包括：

A、智能网设备在接收交换设备向其发送的业务请求后，判断是否智能网设备发生故障而业务控制单元能够正常运行，如果是，则执行步骤B；否则执行正常的智能业务处理流程；

B、智能网设备向交换设备返回消息指示其继续进行呼叫，交换设备接收该消息后，继续进行呼叫。

较佳地，上述判断是否智能网设备发生故障而业务控制单元能够正常运行为：判断智能网设备中的业务数据单元或数据库是否发生故障。

较佳地，上述步骤A之前进一步包括：在智能网设备中设置故障标志位，当智能网设备获知其中发生故障后，将该故障标志位设置为发生故障，当智能网设备获知其恢复正常后，将该故障标志位设置为正常状态；

则步骤A中上述判断其中是否发生故障为：查询故障标志位，判断故障标志位指示是否为发生故障。

较佳地，上述步骤A之前进一步包括：在智能网设备中设置故障处理模块；则步骤B中上述智能网设备向交换设备返回消息指示其继续进行呼叫为：

智能网设备中的故障处理模块向交换设备返回消息指示其继续进行呼叫。

上述步骤B可以包括：

B10、智能网设备中的故障处理模块向发送请求的交换设备返回请求报告基本呼叫状态模型消息，配置需要上报的基本呼叫状态模型，并发送应用计费消息；

B11、故障处理模块向交换设备发送连接消息或继续消息，通知其与被叫当前所在的交换设备建立连接；

B12、话路接续到被叫当前所在的交换设备，被叫振铃，应答。

上述智能网设备中的故障处理模块向交换设备返回消息指示其继续进行呼叫可以包括：

B20、智能网设备中的故障处理模块向发送业务请求的交换设备返回业务请求响应消息；

则所述交换设备接收该消息后，继续进行呼叫包括：

B21、交换设备接收业务请求响应消息后，向智能网设备发送分析消息；

B22、智能网设备中的故障处理模块收到分析消息后，向交换设备返回分析响应消息；

B23、被叫用户应答后，主被叫开始通话，交换设备向智能网设备发送被叫应答消息。

进一步地，上述步骤B后包括：

C、呼叫结束后，交换设备向智能网设备发送消息上报呼叫结束，智能网设备中的故障处理模块收到该消息后，为主叫和/或被叫生成话单。

除上述步骤B10、B11、B12中所提及的智能网设备外，上述描述中的智能网设备可以为被叫签约的智能网设备。

上述描述中的智能网设备均可以为主叫签约的智能网设备。

如果智能网设备为主叫签约的智能网设备，上述步骤B之前可以进一步包括：

b1、智能网设备判断业务请求中的被叫号码是否为VPN短号，如果是VPN短号，执行步骤b2；否则，执行上述步骤B；

b2、智能网设备向放音设备发送包括播放提示音的消息，放音设备向主叫终端播放提示音，然后释放呼叫。

上述智能网设备可以为业务控制点。

从以上技术方案可以看出，本发明中，智能网设备在判断出其中发生故障后，向交换设备返回消息通知其进行呼叫处理，从而在智能网设备出现故障后，实现了呼叫的接续，减少了用户和运营商的损失；

此外，本发明中智能网设备在判断出其中重要部分发生故障后，对被叫号码是否为虚拟专用网(VPN)短号进行了判断，实现了对VPN短号的呼叫和普通被叫号码的区别处理；

进而，本发明通过故障标志位的设置，避免了智能网设备在每次业务中都对其中的设备是否发生故障进行判断，减少了智能网设备的负担。

附图说明

图1为本发明的总体流程图；

图2为本发明第一实施例的主叫流程图；

图3为本发明第一实施例的被叫流程图；

图4为本发明第二实施例的主叫流程图；

图5为本发明第二实施例中向主叫播放提示音的流程图；

图6为本发明第三实施例的主叫流程图；

图7为本发明第三实施例的被叫流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

本发明的主要思想是，智能网设备在接收交换设备向其发送的业务请求后，判断其中是否发生故障，如果发生故障，智能网设备向交换设备返回消息指示其继续进行呼叫，交换设备接收该消息后，继续进行呼叫；否则执行正常的智能业务处理流程。本发明的总体方法流程图如图1所示，具体步骤如下：

步骤101、智能网设备在接收用户交换设备向其发送的业务请求后，判断其中是否发生故障，如果发生故障执行步骤102；否则，执行步骤103；

步骤102、智能网设备向交换设备返回消息指示其继续进行呼叫，交换设备接收该消息后，继续进行呼叫；

步骤103、智能网设备执行正常的智能业务处理流程。

以下以具体实施例进一步说明本发明。

本发明方法在GSM智能网系统中的实现为第一实施例。本实施例中，预先在SCP中设置故障处理模块，并设置故障标志位。当SCP中的重要部分，如业务数据单元(SDU)或数据库发生故障后，只要其中的业务控制单元(SCU)能够正常运行，就可以通过故障处理模块实现呼叫的接续。下面分别以智能用户作为主叫和智能用户作为被叫的两种情况对本实施例进行说明。

当智能用户为主叫时，其实现流程如图2所示，具体步骤如下：

步骤201、智能用户作为主叫发起呼叫，交换设备，即移动交换中心/业务交换点(MSC/SSP)收到主叫对应的终端发送的呼叫请求后，根据该主叫的用户签约信息得知该用户为智能用户，向用户签约信息中SCP地址参数对应的SCP发送初始检测点消息(IDP)触发业务，该消息中包含呼叫相关信息；

步骤202、SCP在收到MSC/SSP发送的IDP消息后，查询其中的故障标志位，并判断故障标志位指示是否为发生故障，如果故障标志位指示为发生故障，执行步骤203；否则，执行正常的智能业务处理流程；

在SCP中，当SCP连接业务数据单元或连接数据库发生失败后，设置故障标志位指示为发生故障；当SCP连接业务数据单元或连接数据库成功后，设置故障标志位指示为正常状态；

步骤203、SCP中的故障处理模块按照普通呼叫处理方式向MSC/SSP发送请求报告基本呼叫状态模型消息(RRBE)，配置需要上报的基本呼叫状态模型(BCSM)，并发送应用计费消息(AC)；

此外本步骤中还可以向MSC/SSP发送提供计费信息消息(FCI)，FCI消息根据运营商在计费时挑选话单的方式确定是否下发，如果是FCI挑单则下发该消息，如果是根据业务键挑单，由于MSC中的用户签约信息已经包含了业务键，则不需要下发FCI消息；

步骤204、故障处理模块向MSC/SSP发送连接消息(CONNECT)或继续消息(CONTINUE)，通知其与被叫当前所在的交换设备建立连接；

步骤205、MSC/SSP获取被叫路由信息，然后把呼叫接续到被叫当前所在的交换设备，被叫振铃，应答；

本步骤中，获取被叫路由信息的方法，根据被叫的归属系统，如GSM系统、CDMA系统等来确定，具体的实现方法与现有技术相同，这里不再详述；

步骤206、被叫应答，主被叫开始通话，通话结束后，MSC/SSP向SCP上报申请计费报告(ACR)消息；

步骤207、SCP中的故障处理模块在收到该消息后，根据呼叫类型、主被叫号码、通话开始时间及时长等信息为主叫用户生成话单，然后向MSC/SSP发送释放呼叫消息。

当智能用户作为被叫时，其实现流程如图3所示，具体步骤与上述主叫流程基本相同，只是步骤301、步骤305和步骤307稍有区别；在步骤301中，MSC/SSP在获得被叫的用户签约信息后，根据被叫用户签约信息中的SCP地址参数向被叫的SCP发送IDP消息；在步骤305中，把呼叫接续到被叫当前所在的交换设备；在步骤307中，被叫SCP中的故障处理模块为被叫用户生成话单。

以上是对本发明的第一实施例的说明，本实施例中也可不设置故障处理模块，而直接由SCP执行故障处理模块的工作。

在现有的智能网中，通常会有VPN短号业务，VPN短号是指非0、1、2、9开头的，并且长度小于等于6位的号码，VPN短号业务中，当主叫用户播打的被叫用户号码是VPN短号时，必须经过SCP查询业务数据单元或数据库，才能获得该被叫VPN短号对应的真实号码，所以，当被叫号码是VPN短号时，按第一实施例中的流程执行就会出现问题。由此，提出了本发明的第二实施例，以下对其进行说明。

在本发明的第二实施例中，只有主叫流程与第一实施例有所区别，本实施例中的主叫流程如图4所示，其中步骤401和步骤402与第一实施例中的步骤201和步骤202相同，在步骤402中判断出故障标志位指示为发生故障后执行下述步骤：

步骤403、故障处理模块判断被叫号码是否是VPN短号，如果是VPN短号执行步骤404；否则，执行步骤405；

步骤404、故障处理模块向MSC/SSP返回消息指示其向主叫用户播放提示音，提示用户播打VPN号码对应的真实号码；

由于智能外设也能够作为放音设备向用户播放提示音，所以本步骤中也可以是故障处理模块向智能外设(IP)返回消息指示其向主叫用户播放提示音，然后由智能外设向用户播放提示音；此外，由于VPN短号必须经过SCP查询业务数据单元或数据库才能获得其对应的真实号码，只有在获得了VPN短号对应的真实号码之后才能够进行呼叫的接续，因此在SCP发生故障后，就无法通过查询业务数据单元或数据库获取真实号码，需要向用户播放提示音提示用户播打真实号码；

步骤405、故障处理模块向MSC/SSP返回消息指示其对呼叫进行接续，MSC/SSP对该呼叫进行接续；本步骤实际上就是执行图2中的步骤203至步骤207。

在上述步骤404中，故障处理模块向MSC/SSP返回消息指示其向主叫用户播放提示音的流程如图5所示，具体包括以下步骤：

步骤501、故障处理模块向MSC/SSP发送请求报告基本呼叫状态模型消息(RRBE)，配置主叫需要上报的基本呼叫状态模型(BCSM)；这里主要配置主叫用户放弃事件，例如主叫用户挂机，MSC/SSP向SCP发送消息通知其主叫用户放弃呼叫，则SCP停止对呼叫进行处理；

步骤502、故障处理模块向MSC/SSP发送连接资源消息(CTR)，通知MSC/SSP与播放提示音的资源建立连接；

步骤503、SCP中的故障处理模块向MSC/SSP发送放音(PA)消息，MSC/SSP在收到放音消息后，向主叫播放放音消息中所包含的录音通知音号对应的提示音；

本步骤中，放音消息中包含MSC/SSP所要向主叫用户播放的提示音类型，提示音类型即录音通知音号，本实施例中所使用的音号，可以利用标准化音中目前暂不使用的音号，在其上加载标准化音；

步骤504、主叫SCP向MSC/SSP发送释放呼叫(RC)消息释放呼叫，放音结束后，MSC/SSP释放呼叫。

本发明方法在CDMA智能网系统中的实现为本发明的第三实施例，其实现思想与第一实施例和第二实施例相同，区别只是在于信令流程的不同，以下对其进行说明。

本实施例中的主叫流程如图6所示，具体步骤如下：

步骤601、智能用户作为主叫发起呼叫，主叫移动交换中心/业务交换点(MSC/SSP)收到主叫对应的终端发送的呼叫请求后，根据用户签约信息得知该用户为智能用户，向用户签约信息中SCP地址参数对应的SCP发送包含呼叫相关信息的初始呼叫请求消息(ORREQ)触发业务；

步骤602、SCP在收到MSC/SSP发送的ORREQ消息后，查询故障标志位，并判断故障标志位的指示是否为发生故障，如果故障标志位指示发生故障，则执行步骤603；否则，执行正常的智能业务处理流程；

步骤603、SCPa中的故障处理模块判断被叫号码是否是VPN短号，如果是VPN短号执行步骤604；否则，执行步骤606；

步骤604、故障处理模块向MSC/SSP返回拒绝呼叫的初始呼叫请求响应消息(orreq)，其中带有拒绝原因、录音通知音号和业务键；

步骤605、MSC/SSP向主叫播放orreq消息中所包含的录音通知音号对应的提示音，然后结束本流程；

本步骤中向主叫播放提示音也可以由智能外设(IP)来完成，其放音流程与现有技术相同，这里不再详述；

步骤606、SCP中的故障处理模块按照普通呼叫处理方式向MSC/SSP返回orreq消息，其中包括业务键(DMH SVCID)，用于采用业务键挑单时与其他呼叫的话单进行区分；

步骤607、MSC/SSP在获得被叫信息，并且被叫可用后，向SCP发送分析消息(ANLYZD)，SCP中的故障处理模块收到该消息后，向MSC/SSP返回带有业务键的分析响应消息(anlyzd)；

本步骤中，获取被叫信息的方法与现有技术相同，被叫可用是指主叫可以与被叫建立连接；

步骤608、被叫用户应答后，主被叫开始通话，MSC/SSP向SCP发送主叫应答消息(OANSWER)；

步骤609、主被叫一方挂机后，MSC/SSP向SCP发送主叫释放(ODISCONNECT)消息，SCP中的故障处理模块为主叫生成话单，并向MSC/SSP返回主叫释放响应消息(odisconnet)，通知MSC/SSP释放链路并生成话单，然后结束本流程。

本实施例的被叫流程与主叫流程的区别是，在被叫流程中，由于已经确定了真实的被叫号码，所以不对被叫号码是否是VPN号码进行判断。被叫流程如图7所示，具体步骤如下：

步骤701中，MSC/SSP在获得被叫的用户签约信息后，向被叫用户签约信息中SCP地址参数所对应的SCP发送ANLYZD消息；

本步骤中，MSC/SSP通过与被叫的归属位置寄存器进行交互，获得被叫用户签约信息，具体实现流程与现有技术相同，这里不再详述；

步骤702、SCP在收到ANLYZD消息后，查询故障标志位，并判断故障标志位的指示是否为发生故障，如果故障标志位指示为发生故障，执行步骤703；否则，执行正常的智能业务处理流程；

步骤703、SCP中的故障处理模块向MSC/SSP返回带有业务键的anlyzd消息；

步骤704、MSC/SSP向SCP发送ANLYZD消息，该消息及步骤702中的ANLYZD消息均与现有技术相同；

步骤705、故障处理模块向MSC/SSP返回带有业务键的anlyzd消息；

步骤706、被叫用户应答后，主被叫开始通话，MSC/SSP向SCP发送被叫应答消息(TANSWER)；

步骤707、主被叫一方挂机后，MSC/SSP向SCP发送被叫释放消息(TDISCONNECT)，SCP中的故障处理模块为被叫生成话单，并向MSC/SSP返回被叫释放响应消息(tdisconnet)，通知MSC/SSP释放链路并生成话单，然后结束本流程。

本发明方法在公众电话网络(PSTN)智能网系统中的实现为第四实施例，其实现过程与本发明第一实施例和第二实施例基本相同，其区别在于业务触发方式不同，以及被叫没有智能业务流程。业务触发方式不同，就是在智能业务触发时不是根据签约用户信息触发，而是根据接入码来触发智能业务；而被叫没有智能业务流程就是主叫交换机在收到主叫SCP向其发送的连接消息(CONNECT)或继续消息(CONTINUE)连接被叫时，直接连接被叫交换机。

从以上对本发明具体实施例的说明可以看出，本发明中，智能网设备在判断出其中发生故障后，向交换设备返回消息通知其进行普通呼叫处理，从而在智能网设备中出现故障后，实现了呼叫的接续，减少了用户和运营商的损失；此外，本发明中智能网设备在判断出其中发生故障后，对被叫号码是否为VPN短号进行了判断，实现了对VPN短号的呼叫和普通被叫号码的区别处理；进而，本发明通过故障标志位的设置，避免了智能网设备在每个业务中都对其中的设备是否发生故障进行判断，减少了智能网设备的负担。

在具体的实施过程中可根据本发明的方法进行适当的改进，以适应具体情况的具体需要。因此可以理解，根据本发明的具体实施方式只是起示范作用，并不用以限制本发明的保护范围。

Claims (11)

1、一种智能网系统中呼叫接续的实现方法，其特征在于，该方法包括：

A、智能网设备在接收交换设备向其发送的业务请求后，判断是否智能网设备发生故障而业务控制单元能够正常运行，如果是，则执行步骤B；否则执行正常的智能业务处理流程；

B、智能网设备向交换设备返回消息指示其继续进行呼叫，交换设备接收该消息后，继续进行呼叫。

2、根据权利要求1所述的方法，其特征在于，所述判断是否智能网设备发生故障而业务控制单元能够正常运行为：判断智能网设备中的业务数据单元或数据库是否发生故障。

3、根据权利要求1所述的方法，其特征在于，所述步骤A之前进一步包括：在智能网设备中设置故障标志位，当智能网设备获知其中发生故障后，将该故障标志位设置为发生故障，当智能网设备获知其恢复正常后，将该故障标志位设置为正常状态；

则步骤A中所述判断其中是否发生故障为：查询故障标志位，判断故障标志位指示是否为发生故障。

4、根据权利要求1所述的方法，其特征在于，所述步骤A之前进一步包括：在智能网设备中设置故障处理模块；则步骤B中所述智能网设备向交换设备返回消息指示其继续进行呼叫为：

智能网设备中的故障处理模块向交换设备返回消息指示其继续进行呼叫。

5、根据权利要求4所述的方法，其特征在于，所述步骤B包括：

B10、智能网设备中的故障处理模块向发送请求的交换设备返回请求报告基本呼叫状态模型消息，配置需要上报的基本呼叫状态模型，并发送应用计费消息；

B11、故障处理模块向交换设备发送连接消息或继续消息，通知其与被叫当前所在的交换设备建立连接；

B12、话路接续到被叫当前所在的交换设备，被叫振铃，应答。

6、根据权利要求4所述的方法，其特征在于，所述智能网设备中的故障处理模块向交换设备返回消息指示其继续进行呼叫包括：

B20、智能网设备中的故障处理模块向发送业务请求的交换设备返回业务请求响应消息；

所述交换设备接收该消息后，继续进行呼叫包括：

B21、交换设备接收业务请求响应消息后，向智能网设备发送分析消息；

B22、智能网设备中的故障处理模块收到分析消息后，向交换设备返回分析响应消息；

B23、被叫用户应答后，主被叫开始通话，交换设备向智能网设备发送被叫应答消息。

7、根据权利要求1所述的方法，其特征在于，所述步骤B后进一步包括：

C、呼叫结束后，交换设备向智能网设备发送消息上报呼叫结束，智能网设备中的故障处理模块收到该消息后，为主叫和/或被叫生成话单。

8、根据权利要求1至4，6和7中任一权利要求所述的方法，其特征在于，所述智能网设备为被叫签约的智能网设备。

9、根据权利要求1至7中任一权利要求所述的方法，其特征在于，所述智能网设备为主叫签约的智能网设备。

10、根据权利要求9所述的方法，其特征在于，所述步骤B之前进一步包括：

b1、智能网设备判断业务请求中的被叫号码是否为VPN短号，如果是VPN短号，执行步骤b2；否则，执行所述步骤B；

b2、智能网设备向放音设备发送包括播放提示音的消息，放音设备向主叫终端播放提示音，然后释放呼叫。

11、根据权利要求1至7中任一权利要求所述的方法，其特征在于，所述的智能网设备为业务控制点。

Images