WO2006111053A1 - A method for ensuring intelligent user to talk - Google Patents

Description

一种保证智能用户通话的方法

技术领域

本发明涉及移动通信技术， 特别是涉及一种当业务交换点 （Service Switching Point, SSP ) 与业务控制点 （Service Control Point, SCP )之 间出现业务异常情况时保证智能用户通话的方法。 发明背景

目前， 智能业务不断发展， 智能用户的数量越来越多， 因此， 如何 保证智能用户的正常通话是关系到业务服务质量的一个重要因素。

图 1是预付费用户的始呼流程图。 参见图 1 , 以预付费用户作为智 能用户为例， 现有技术建立预付费用户之间连接实现通话的过程具体包 括以下步骤： .

步骤 101 : 始发 SSP接收主叫预付费用户的呼叫并检测到智能触发 器 Origination— Attempt— Authorized。

步骤 102: 始发 SSP 据该触发器中的地址发送 ORREQ消息至相 应的 SCP。

步驟 103: 该 SCP接收到 ORREQ消息后对主叫预付费用户进行鉴 权，判断该用户是否合法，如果是，则执行步骤 105 ,否则执行步骤 104。

步骤 104: 该 SCP 在返回的 orreq 消息中携带参数 ACCEDN 和 ANNLIST来通知始发 SSP拒绝本次呼叫， 并结束当前流程。

步骤 105：该 SCP在返回的 orreq消息中携带参数 DMH— SVCIDLIST 来通知始发 SSP继续本次呼叫。 *

步 骤 106 ： 始 发 SSP 检 测 到 智 能 触 发 器 Calling— Routing— address— Available， 根据该触发器中的地址发送 ANLYZD消息至相应 SCP。

步驟 107: 该 SCP收到 ANLYZD消息后， 判断用户余额是否足以发 起本次呼叫， 如果是， 则执行步骤 108, 否则该 SCP通知始发 SSP中断 本次呼叫， 并结束本流程。

步骤 108: 该 SCP通知始发 SSP继续本次呼叫， 始发 SSP建立主叫 到被叫的连接， 被叫用户应答后， 主、 被叫用户进行通话。

由上述图 1所示流程可以看出， 在智能业务中， SCP是整个智能网 的核心，当智能呼叫到达时， SCP会向 SSP发送一系列相应的操作命令， 指示 SSP按照既定业务逻辑执行操作， SSP自身是无法独立完成整个智 能呼叫过程的。

然而， 在实际的智能业务实现中， SSP与 SCP之间经常会出现业务 异常情况， 包括： SSP与 SCP之间的链路发生断开或拥塞等故障， 使得 SSP与 SCP之间无法进行消息的交互； SCP 自身繁忙或故障， 无法向 SSP发送操作指令等。 这样， 当 SSP与 SCP之间出现业务异常情况时， SSP就无法获得 SCP发来的操作命令， 也就无法执行相应操作， 从而导 致智能用户的通话过程无法进行， 大大妨碍了智能业务的正常运营。 发明内容

本发明的主要目的在于提供一种保证智能用户通话的方法， 在 SSP 与 SCP之间出现业务异常情况时， 保证 SSP可不依靠 SCP的指示来完 成智能用户通话过程。

为了达到上述目的， 本发明的技术方案是这样实现的：

一种保证智能用户通话的方法， 包括以下步骤：

A、 SSP判断自身与 SCP之间是否出现业务异常情况， 如果是， 则 执行步骤 B, 否则， 执行现有的智能呼叫接续过程， 结束本流程； B、 SSP关闭自身中本次呼叫涉及的智能触发器，执行普通呼叫接续 过程。

所述 SSP在与 SCP进行消息交互时， 执行步骤 A中所述的判断自 身与 SCP之间是否出现业务异常情况的步骤。

该方法进一步包括： 在 SSP上设置智能用户的标识、 异常原因以及 是否执行呼叫接续三者之间的对应关系；

在步骤 A中， 在 SSP判断自身与 SCP之间出现业务异常情况之后， 并在执行步骤 B之前， 进一步包括： 所述 SSP获取当前智能用户的标识 以及当前异常原因， 然后根据所获取的当前智能用户的标识、 当前异常 原因以及所设置的对应关系， 判断对当前智能用户是否执行呼叫接续过 程， 如果是， 则执行步骤 B， 否则， 结束当前流程。

所述智能用户的标识为智能用户的优先级或智能用户的号码或智能 用户所属的 SCP的地址。

该方法进一步包括： 在呼叫结束后， 所述 SSP在自身产生的呼叫详 细记录中增加一个计费标识， 然后将该呼叫详细记录发送至计费中心， 其中， 所述计费标识表明智能用户的通话正常进行但该智能用户所属的 SCP未计费。

当本次呼叫关联多个 SSP，且步骤 A中的 SSP不是呼叫关联的最后 一个 SSP时， 在步驟 B之后进一步包括：

Cl、 步驟 A中的 SSP通知后续关联的 SSP将本次呼叫作为普通呼 叫处理；

C2、 后续关联的 SSP关闭自身中本次呼叫涉及的智能触发器， 执行 普通呼叫接续过程。

所述呼叫为被叫用户局间呼叫； 步骤 A所述的 SSP为始发 SSP; 在步骤 C1中， 所述步骤 A中的 SSP通知后续关联的 SSP的步骤包 括： 始发 SSP在向服务 SSP发送的初始地址消息（IAM )消息或带有附 加信息的初始化地址消息（IAI )消息或呼叫建立（SETUP )消息中， 携 带表明将本次呼叫作为普通呼叫处理的呼叫接续业务标识。

在步骤 C1中， 所述在 IAM消息中携带呼叫接续业务标识的步骤包 括： 在 IAM消息或 IAI消息或 SETUP消息中的被叫号码或者主叫号码 或者其它信元前增加呼叫接续业务前缀。

发起步骤 B中所述呼叫的智能用户同时发起其它呼叫；

该方法进一步包括： 所述 SSP在为发起步骤 B中所述呼叫的智能用 户建立另一次呼叫连接时， 判断自身与 SCP之间是否出现业务异常情 况， 如果是， 则关闭自身中该另一次呼叫的智能触发器， 执行普通呼叫 接续过程， 否则， 执行现有的智能呼叫接续过程。

步骤 B 中所述本次呼叫'为三方通话或会议呼叫或呼叫保持（CALL HOLD )或呼叫等待（CALL WAIT )智能业务中的一次呼叫。

可见， 本发明提出的方法具有以下优点：

1、 在本发明中， 当 SSP需要与 SCP交互消息时， 如果发现自身与 SCP之间出现业务异常情况， 则关闭自身中本次呼叫涉及的所有智能触 发器，将本次呼叫作为普通呼叫而不是智能呼叫，不再向 SCP发送消息， 并在未接收到 SCP发来命令的情况下继续进行呼叫接续过程， 因此在 SSP与 SCP之间出现业务异常情况时，本发明仍可保证智能用户的正常 通话。

2、 在本发明中， 预先在 SSP上设置智能用户标识、 异常原因以及 是否执行呼叫接续三者之间的对应关系，当 SSP需要与 SCP交互而又发 现自身与 SCP之间出现业务异常情况时， SSP首先根据所设置的对应关 系来判断是否执行呼叫接续过程， 而不是盲目地对所有智能用户进行呼 叫接续， 从而可保证不会为 SSP增加过多业务负荷。 3、 在本发明中， SSP在自身产生的呼叫详细记录（CDR )详单中增 加一个计费标识， 以表明智能用户的通话正常进行但该智能用户所属的 SCP未计费， 从而在保证通话正常进行的情况下， 进一步保证了计费的 正常进行， 维护了智能用户和运营商双方的利益。 附图简要说明

图 1是预付费用户的始呼流程图。

图 2是本发明实施例中主叫智能用户的始呼流程图。

图 3是本发明实施例中被叫用户局间呼叫流程图。 实施本发明的方式

在现有技术中 , SSP必须按照 SCP发来的一系列命令来完成智能用 户的通话接续过程。 这样， 当 SSP与 SCP之间出现业务异常情况时， 则 无法保证智能用户的通话。 针对这一缺点， 本发明提出了一种保证智能 用户通话的方法，其核心思想是： 当 SSP发现自身与 SCP之间出现业务 异常情况时， 关闭自身中本次呼叫的所有智能触发器， 不再向 SCP发送 消息， 并在未接收到 SCP发来命令的情况下继续进行呼叫接续过程， 也 就是， 将本次呼叫作为普通呼叫而不是智能呼叫处理。 并且， 如果本次 呼叫关联多个 SSP,那么，发现业务异常情况的 SSP通知后续关联的 SSP 将本次呼叫作为普通呼叫处理。

在实际的业务实现中， 如果 SSP必须保证所有智能用户的通话， 则 会大大增加 SSP的业务负荷量。 因此， 本发明的一种优选实施方法是:' 预先在 SSP上设置智能用户标识、异常原因以及是否执行呼叫接续三者 之间的对应关系， 这样， 当 SSP需要与 SCP交互而又发现与 SCP之间 出现业务异常情况时， SSP首先获取当前智能用户的标识及当前异常原 因， 并根据所设置的对应关系判断在当前异常原因下， 是否允许当前智 能用户继续呼叫接续过程， 如果是， 再关闭自身中智能触发器以及进行 呼叫接续过程， 否则， 不进行呼叫接续过程， 即中断本次呼叫。 这里， 所述的智能用户标识可以是智能用户的优先级， 或智能用户的号码， 或 智能用户所属的 SCP的地址等。

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

在本实施例中， 所述智能用户的标识为智能用户的优先级。

图 2是本发明实施例中主叫智能用户的始呼流程图。 参见图 2, 本 发明完成主叫智能用户起呼的过程具体包括以下步骤：

步骤 201 : 始发 SSP接收主叫智能用户的呼叫， 检测自身与 SCP之 间是否出现业务异常情况， 如果是， 则执行步骤 202, 否则， 执行现有 的智能呼叫接续过程， 并结束本流程。

这里， 当始发 SSP接收到主叫智能用户的呼叫时， 由于需要与 SCP 进行消息交互， 则首先检测自身与 SCP之间是否出现业务异常情况。 该 检测过程是现有技术， 此处不再描述， 但可举例为， 始发 SSP在设定时 间内未接收到 SCP发来的响应消息。

步骤 202:始发 SSP获取当前智能用户的优先级以及当前异常原因。 这里， 始发 SSP从自身保存的用户信息中获取当前智能用户的优先 级，并根据底层上报的错误原因值或 SCP返回的错误原因值来获取当前 的异常原因。

步骤 203: 始发 SSP判断是否继续进行本次呼叫的接续过程， 如果 是， 则执行步骤 204, 否则， 中断本次呼叫， 并结束本流程。

这里， 始发 SSP根据自身中预先设置的智能用户优先级、 异常原因 以及是否执行呼叫接续三者之间的对应关系来判断， 在当前异常原因下 对当前智能用户是否继续执行呼叫接续即是否进行本次呼叫的接续过 程。 比如， 预先在始发 SSP上设置的对应关系中包括： 对于优先级较高 的全球通用户，该始发 SSP与 SCP之间无论是何种异常原因， 均执行呼 叫接续过程；对于优先级较低的预付费用户，在该始发 SSP与 SCP之间 的异常原因为链路断开时， 不执行呼叫接续过程， 而在异常原因为链路 拥塞或信令点故障时， 执行呼叫接续过程。 这样， 如果本次呼叫的智能 用户为全球通用户， 当前异常原因为链路断开， 那么， 该始发 SSP执行 呼叫接续过程； 如果本次呼叫的智能用户为预付费用户， 且当前异常原 因为链路断开， 那么该始发 SSP不执行呼叫接续过程。 '

步骤 204: 始发 SSP关闭自身中本次呼叫涉及的所有智能触发器。 这里， 始发 SSP关闭自身中本次呼叫涉及的智能触发器后， 可保证 不再向 SCP发送与本次呼叫相关的消息， 并在未接收到 SCP命令的情 况下继续进行呼叫接续过程， 也就是说， 始发 SSP将本次呼叫作为普通 呼叫而不再是智能呼叫。

步骤 205: 始发 SSP建立主叫到被叫的连接， 被叫用户应答后， 主、 被叫用户进行通话。

步骤 206: 在呼叫结束后， 始发 SSP在自身产生的 CDR详单中增加 一个计费标识。

这里， 所增加的计费标识是用于表明本次呼叫的用户是智能用户， 而 SCP没有对该智能用户进行相应的计费。

步骤 207: 始发 SSP将 CDR详单发送至计费中心。

在本发明中， SSP在关闭自身中智能触发器后， 不会向当前智能用 户所属的 SCP发送与本次呼叫相关的消息，使得该当前智能用户所属的 SCP没有对本次呼叫的智能用户进行计费。 因此， 本发明可以进一步在 SSP产生的 CDR详单中增加一个计费标识以表明智能用户的通话正常 进行但该智能用户所属的 SCP未计费， 计费中心可根据该 CDR详单进 行计费， 从而在保证通话正常进行的情况下， 进一步保证了对智能用户 计费的正常进行。

图 3是本发明实施例中被叫用户局间呼叫流程图。 参见图 3 , 对于 被叫智能用户局间呼叫， 本发明保证通话的过程具体包括以下步驟： 步驟 301 : 始发呼叫， 始发 SSP接收到被叫号码并检测到智能触发 器 Mobile— Termination, 根据触发器标识的地址向对应的归属位置寄存 器 （ HLR )发送 LOCREQ消息。

步骤 302: HLR接收到 LOCREQ消息后， 向始发 SSP回送 locreq 消息。

步骤 303: 始发 SSP接收到 locreq响应消息后， 检测自身与 SCP之 间是否出现业务异常情况， 如果是， 则执行步骤 304, 否则， 执行现有 的智能呼叫接续过程并结束本流程。

这里， 始发 SSP在接收到 HLR发来的响应消息 locreq后， 需要与 SCP进行交互， 因此， 检测自身与 SCP之间是否出现业务异常情况。

步骤 304:始发 SSP获取当.前智能用户的优先级以及当前异常原因。 这里， 始发 SSP从自身保存的用户信息中获取当前智能用户的优先 级，并根据底层上报的错误原因值或 SCP返回的错误原因值来获取当前 的异常原因。

步骤 305: 始发 SSP判断是否继续进行本次呼叫的接续过程， 如果 是， 则执行步骤 306， 否则， 中断本次呼叫并结束本流程。

这里， 始发 SSP根据自身中预先设置的智能用户优先级、 异常原因 以及是否执行呼叫接续三者之间的对应关系来判断是否继续进行本次 呼叫的接续过程。

步骤 306: 始发 SSP关闭自身中本次呼叫涉及的所有智能触发器。 这里， SSP关闭自身中本次呼叫涉及的智能触发器后， 可保证不再 向 SCP发送与本次呼叫相关的消息， 并在未接收到 SCP命令的情况下 继续进行呼叫接续过程， 也就是说， SSP将本次呼叫作为普通呼叫而不 再是智能呼叫。

步骤 307: 始发 SSP通过 HLR从被叫的服务 SSP处获得被叫用户 的漫游号码 （TLDN )。

步骤 308:始发 SSP向服务 SSP发送携带有呼叫接续业务标识的 IAM 消息。

这里， 始发 SSP和服务 SSP是本次呼叫所关联的 SSP, 这样， 始发 SSP就必须通知后续的服务 SSP将本次呼叫作为普通呼叫处理。 因此， 始发 SSP在向服务 SSP发送的 IAM消息中携带呼叫接续业务标识， 以 通知服务 SSP将本次呼叫作为普通呼叫处理。所述的呼叫接续业务标识 可以是，在 IAM消息中的被叫号码或者主叫号码或其它信元前所增加的 呼叫接续业务前缀。

另外， 始发 SSP通知服务 SSP将本次呼叫作为普通呼叫处理时， 使 用的是 ISUP信令中的 IAM消息，始发 SSP也可采用其它中继信令的消 息来通知服务 SSP, 比如， 釆用 TUP信令中的 IAI消息， 或釆用 PRA 信令中的 SETUP消息。

步骤 309: 服务 SSP接收到 IAM消息， 通过该 IAM消息中的呼叫 接续业务标识获知应将本次呼叫作为普通呼叫处理， 则关闭自身中本次 呼叫涉及的所有智能触发器， 执行普通呼叫接续过程。

步骤 310: 在呼叫结束后，服务 SSP在自身产生的 CDR详单中增加 计费标识， 并将该 CDR详单发送至计费中心。

这里， 所增加的计费标识是用于表明智能用户的通话正常进行但该 智能用户所属的 SCP未计费， 计费中心可根据该 CDR详单进行计费。 当智能用户发起三方通话或者会议呼叫或者 CALL HOLD 或者 CALL WAIT等智能业务时， 也就是说， 当 SSP需要针对一个智能用户 进行多个呼叫接续过程时，本发明可以在每次呼叫中被单独应用。比如， 智能用户 A发起三方通话， 同时呼叫智能用户 B和智能用户 C。 在智能 用户 A呼叫智能用户 B的过程中， SSP与 SCP之间的链路断开， 那么， SSP不再针对智能用户 A的本次呼叫与 SCP交互消息，而是根据获取的 智能用户 A的优先级、 当前异常原因即链路发生故障以及所设置的对应 关系，来判断是否继续执行后续的智能用户 A对智能用户 B的呼叫接续 过程。 同时， 在智能用户 A呼叫智能用户 C的过程中， 当 SSP需要与 SCP交互时链路已恢复正常， 则 SSP仍按现有的智能呼叫流程， 在接收 到 SCP的命令后执行智能用户 A对智能用户 C的呼叫接续过程。 在此 次三方通话业务结束后， SSP在产生的 CDR详单中，标识出智能用户 A 在呼叫用户 B的过程中链路故障， 而智能用户 A所属的 SCP没有对该 次呼叫过程计费。

在上述实施例中， 智能用户的标识为智能用户的优先级。 对于其它 的智能用户标识， 比如为智能用户的号码， SSP是 居获取的当前异常 原因和智能用户号码以及所设置的对应关系来判断， 是否对智能用户执 行呼叫接续过程；而对于智能用户标识为该智能用户所属的 SCP地址的 情况， 在本发明中， SSP是根据获取的当前异常原因、 当前 SCP的地址 即该智能用户所属的 SCP地址以及所设置的对应关系来判断，是否对智 能用户执行呼叫接续过程， 其具体实现过程的原理与上述流程的原理相 同。

总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本发 明的保护范围。 凡在本发明的精神和原则之内， 所作的任何修改、 等同 替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求书

1、 一种保证智能用户通话的方法， 其特征在于， 该方法包括以下步 骤：

A、 业务交换点 SSP判断自身与业务控制点 SCP之间是否出现业务 异常情况， 如果是， 则执行步骤 B , 否则， 执行现有的智能呼叫接续过 程， 结束当前流程；

B、 该 SSP关闭自身中本次呼叫涉及的智能触发器， 执行普通呼叫 接续过程。

2、 根据权利要求 1所述的方法， 其特征在于， 当所述 SSP与 SCP 进行消息交互时， 执行步骤 A中所述判断的步骤。

3、 根据权利要求 1所述的方法， 其特征在于， 该方法进一步包括： 在 SSP上设置智能用户的标识、异常原因以及是否执行呼叫接续三者之 间的对应关系；

在步骤 A中， 在 SSP判断自身与 SCP之间出现业务异常情况之后， 并在执行步驟 B之前， 进一步包括： 所述 SSP获取当前智能用户的标识 以及当前异常原因， 然后根据所获取的当前智能用户的标识、 当前异常 原因以及所设置的对应关系， 判断对当前智能用户是否执行呼叫接续过 程， 如果是， 则执行步骤 B， 否则， 结束当前流程。

4、根据权利要求 3所述的方法， 其特征在于， 所述智能用户的标识 为： 智能用户的优先級， 或智能用户的号码， 或智能用户所属的 SCP的 地址。

5、根据权利要求 1至 4中任意一项所述的方法， 其特征在于， 该方 法进一步包括： 在呼叫结束后， 所述 SSP在自身产生的呼叫详细记录中 增加一个计费标识， 然后将该呼叫详细记录发送至计费中心， 其中， 所 述计费标识表明智能用户的通话正常进行但该智能用户所属的 SCP 未 计费。

6、根据权利要求 1至 4中任意一项所述的方法， 其特征在于， 本次 呼叫关联多个 SSP,且步骤 A所述的 SSP不是本次呼叫关联的最后一个 SSP;

在步骤 B之后进一步包括：

Cl、 步骤 A所述 SSP通知后续关联的 SSP将本次呼叫作为普通呼 叫处理；

C2、 后续关联的 SSP关闭自身中本次呼叫涉及的智能触发器， 执行 普通呼叫接续过程。

7、根据权利要求 6所述的方法， 其特征在于， 所述呼叫为被叫用户 局间呼叫； 步骤 A所述的 SSP为始发 SSP;

在步骤 C1中， 所述步骤 A中的 SSP通知后续关联的 SSP的步骤包 括： 始发 SSP在向服务 SSP发送的初始地址消息 IAM消息或带有附加 信息的初始化地址消息 IAI消息或呼叫建立 SETUP消息中，携带表明将 本次呼叫作为普通呼叫处理的呼叫接续业务标识。

8、 根据权利要求 7所述的方法， 其特征在于， 在步骤 C1中， 所述 在 IAM消息中携带呼叫接续业务标识的步骤包括： 在 IAM消息或 IAI 消息或 SETUP 消息中的被叫号码或者主叫号码或者其它信元前增加呼 叫接续业务前缀。

9、根据权利要求 1至 4中任意一项所述的方法， 其特征在于， 发起 步骤 B中所述呼叫的智能用户同时发起其它呼叫；

该方法进一步包括：所述 SSP在为发起步骤 B中所述呼叫的智能用 户建立另一次呼叫连接时， 判断自身与 SCP之间是否出现业务异常情 况， 如果是， 则关闭自身中该另一次呼叫的智能触发器， 执行普通呼叫 接续过程， 否则， 执行现有的智能呼叫接续过程。

10、 根据权利要求 9所述的方法， 其特征在于， 步驟 B中所述本次 呼叫为三方通话或会议呼叫或呼叫保持 CALL HOLD或呼叫等待 CALL WAIT智能业务中的一次呼叫。