专利名称：一种保证智能用户通话的方法
技术领域：
本发明涉及移动通信技术，特别是涉及一种当业务交换点(ServiceSwitching 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建立主叫到被叫的连接，被叫用户应答后，主、被叫用户进行通话。
由上述流程可以看出，在智能业务中，SCP是整个智能网的核心，当智能呼叫到达时，SCP会向SSP发送一系列相应的操作命令，指示SSP按照既定业务逻辑执行操作，SSP自身是无法独立完成整个智能呼叫过程的。
然而，在实际的智能业务实现中，SSP与SCP之间经常会出现业务异常情况，包括SSP与SCP之间的链路发生断开或拥塞等故障，使得SSP与SCP之间无法进行消息的交互；SCP自身繁忙或故障，无法向SSP发送操作指令等。这样，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之后进一步包括C1、步骤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中所述本次呼叫为三方通话或会议呼叫或呼叫保持(CALLHOLD)或呼叫等待(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发送消息，并在未接收到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在自身产生的呼叫详细记录(CallDetail Record，CDR)详单中增加一个计费标识。
这里，所增加的计费标识是用于表明本次呼叫的用户是智能用户，而SCP没有对该智能用户进行相应的计费。
步骤207始发SSP将CDR详单发送至计费中心。
在本发明中，SSP在关闭自身中智能触发器后，不会向当前智能用户所属的SCP发送与本次呼叫相关的消息，使得该当前智能用户所属的SCP没有对本次呼叫的智能用户进行计费。因此，本发明在SSP产生的CDR详单中增加一个计费标识以表明智能用户的通话正常进行但该智能用户所属的SCP未计费，计费中心可根据该CDR详单进行计费，从而在保证通话正常进行的情况下，进一步保证了对智能用户计费的正常进行。
图3是本发明实施例中被叫用户局间呼叫流程图。参见图3，对于被叫智能用户局间呼叫，本发明保证通话的过程具体包括以下步骤步骤301始发呼叫，始发SSP接收到被叫号码并检测到智能触发器Mobile_Termination，根据触发器标识的地址向对应的归属位置寄存器(HLR)发送LOCREQ消息。
步骤302HLR接收到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或者CALLWAIT等智能业务时，也就是说，当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地址以及所设置的对应关系来判断，是否对智能用户执行呼叫接续过程，其具体实现过程的原理与上述流程的原理相同。
总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种保证智能用户通话的方法，其特征在于，该方法包括以下步骤A、业务交换点SSP判断自身与业务控制点SCP之间是否出现业务异常情况，如果是，则执行步骤B，否则，执行现有的智能呼叫接续过程，结束本流程；B、该SSP关闭自身中本次呼叫涉及的智能触发器，执行普通呼叫接续过程。
2.根据权利要求1所述的方法，其特征在于，所述SSP在与SCP进行消息交互时，执行步骤A中所述的判断自身与SCP之间是否出现业务异常情况的步骤。
3.根据权利要求1所述的方法，其特征在于，该方法进一步包括在SSP上设置智能用户的标识、异常原因以及是否执行呼叫接续三者之间的对应关系；在步骤A中，在SSP判断自身与SCP之间出现业务异常情况之后，并在执行步骤B之前，进一步包括所述SSP获取当前智能用户的标识以及当前异常原因，然后根据所获取的当前智能用户的标识、当前异常原因以及所设置的对应关系，判断对当前智能用户是否执行呼叫接续过程，如果是，则执行步骤B，否则，结束当前流程。
4.根据权利要求3所述的方法，其特征在于，所述智能用户的标识为智能用户的优先级或智能用户的号码或智能用户所属的SCP的地址。
5.根据权利要求1或3所述的方法，其特征在于，该方法进一步包括在呼叫结束后，所述SSP在自身产生的呼叫详细记录中增加一个计费标识，然后将该呼叫详细记录发送至计费中心，其中，所述计费标识表明智能用户的通话正常进行但该智能用户所属的SCP未计费。
6.根据权利要求1或3所述的方法，其特征在于，当本次呼叫关联多个SSP，且步骤A中的SSP不是呼叫关联的最后一个SSP时，在步骤B之后进一步包括C1、步骤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或2或3所述的方法，其特征在于，发起步骤B中所述呼叫的智能用户同时发起其它呼叫；该方法进一步包括所述SSP在为发起步骤B中所述呼叫的智能用户建立另一次呼叫连接时，判断自身与SCP之间是否出现业务异常情况，如果是，则关闭自身中该另一次呼叫的智能触发器，执行普通呼叫接续过程，否则，执行现有的智能呼叫接续过程。
10.根据权利要求9所述的方法，其特征在于，步骤B中所述本次呼叫为三方通话或会议呼叫或呼叫保持CALL HOLD或呼叫等待CALL WAIT智能业务中的一次呼叫。
全文摘要
本发明公开了一种保证智能用户通话的方法，包括业务交换点(SSP)判断自身与业务控制点(SCP)之间是否出现业务异常情况，如果是，则该SSP关闭自身中本次呼叫涉及的所有智能触发器，执行普通呼叫接续过程，否则，该SSP执行现有的智能呼叫接续过程。因此，本发明在SSP与SCP之间出现业务异常情况时，仍可保证智能用户的正常通话。另外，在本发明中，SSP在判断出自身与SCP间出现业务异常情况时，进一步根据预先设置的智能用户标识、异常原因以及是否执行呼叫接续三者之间的对应关系，判断是否执行呼叫接续过程，而不是盲目地对所有智能用户进行呼叫接续，从而可保证不会为SSP增加过多业务负荷。
文档编号H04M3/42GK1852450SQ20051006633
公开日2006年10月25日 申请日期2005年4月22日 优先权日2005年4月22日
发明者李世前, 严天军 申请人:华为技术有限公司