CN102158472A - 智能业务故障处理方法及stp - Google Patents
智能业务故障处理方法及stp Download PDFInfo
- Publication number
- CN102158472A CN102158472A CN2011100374311A CN201110037431A CN102158472A CN 102158472 A CN102158472 A CN 102158472A CN 2011100374311 A CN2011100374311 A CN 2011100374311A CN 201110037431 A CN201110037431 A CN 201110037431A CN 102158472 A CN102158472 A CN 102158472A
- Authority
- CN
- China
- Prior art keywords
- scp
- stp
- ssp
- message
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提供一种智能业务故障处理方法及STP。该方法包括STP接收SSP发送的用于触发智能业务的消息；STP在接收到所述用于触发智能业务的消息后，判断SCP是否出现异常；如果所述SCP出现异常，且如果需要放通处理，STP向SSP发送用于指示SSP继续业务接续的消息。本发明实施例可以不受端局限制，适用范围更广。
Description
技术领域
本发明涉及移动通信技术，尤其涉及一种智能业务故障处理方法及STP。
背景技术
业务交换点(Service Switching Point，SSP)判断用户有业务控制点(Service Control Point，SCP)相关的智能业务时，触发启动检测点(InitialDetect Point，IDP)消息，该IDP消息从SSP通过信令转接点(SignalingTransfer Point，STP)发送给业务控制点(Service Control Point，SCP)。当SCP故障或者SCP不可达时，STP会将该IDP消息丢弃。如果SSP是按照SCP的命令来完成智能用户的通话接续过程，则SCP故障或者不可达时，由于SSP无法接收到SCP返回的命令，则无法保证智能用户的通话。另外，为了保证智能用户的通话，也可以是SSP发现自身与SCP之间出现业务异常情况时，SSP可以关闭自身本次呼叫的所有智能触发器，不再向SCP发送消息，并在未接收到SCP发来命令的情况下继续进行呼叫接续过程。
但是，SSP是端局节点，在其上实现该方案具有如下问题：能且仅能为本地用户设备(User Equipment，UE)提供该项功能，当本地UE漫游到其他网络后无法再实现上述功能；并且，SSP作为端局可能随时接入新的SSP，如果新接入的SSP不支持上述功能，则会影响整个网络功能的使用，网络兼容性差，适用范围比较少。
发明内容
本发明实施例提供一种智能业务故障处理方法及STP，用以解决现有技术中在SSP侧处理时存在的问题。
本发明实施例提供了一种智能业务故障处理方法，包括：
信令转接点STP接收业务交换点SSP发送的用于触发智能业务的消息；
所述STP在接收到所述用于触发智能业务的消息后，判断业务控制点SCP是否出现异常；
如果所述SCP出现异常，且如果需要放通bypass处理，STP向SSP发送用于指示SSP继续业务接续的消息。
本发明实施例提供了一种STP，包括：
接收模块，用于接收业务交换点SSP发送的用于触发智能业务的消息；
第一判断模块，用于在接收到所述用于触发智能业务的消息后，判断业务控制点SCP是否出现异常；
处理模块，用于如果所述SCP出现异常，且如果需要放通bypass处理，STP向SSP发送用于指示SSP继续业务接续的消息。
由上述技术方案可知，本发明实施例通过STP在智能业务时判断SCP是否异常，由于STP并不是端局设备，可以避免由端局的SSP处理时造成的问题，由于对端局无要求不受端局限制，可以适用于漫游、非漫游场景以及新增端局设备的场景，扩大适用范围。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明第一实施例的方法流程示意图；
图2为本发明第二实施例的方法流程示意图；
图3为本发明实施例中SCP通知STP异常的情况示意图；
图4为本发明实施例中STP自身获知SCP不可达的情况示意图；
图5为本发明实施例中STP通过另一个STP获知SCP不可达的情况示意图；
图6为本发明第三实施例的方法流程示意图；
图7为本发明第四实施例的方法流程示意图；
图8为本发明第五实施例的STP的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明第一实施例的方法流程示意图，包括：
步骤11：STP接收SSP发送的用于触发智能业务的消息；
例如，该用于触发智能业务的消息可以为IDP消息。
其中，接收SSP发送的用于触发智能业务的消息，包括：接收发起智能业务的终端所属网络的SSP发送的所述用于触发智能业务的消息；或者，
接收发起智能业务的终端漫游到的拜访网络的SSP发送的所述用于触发智能业务的消息；或者，
接收新入网的SSP通过新入网的STP发送的所述用于触发智能业务的消息。
其中，所述STP可以为独立设置的设备，或者所述STP位于其他设备中，例如网关MSC(GMSC)中。
步骤12：STP在接收到所述用于触发智能业务的消息后，判断SCP是否出现异常；
其中，判断SCP是否出现异常，包括：
接收SCP发送的网络管理消息(subsystem-prohibited)后，则判断所述SCP出现异常，所述网络管理消息为所述SCP在发生故障后发送的；或者，
采用媒体传输协议(Media Transfer Protocol，MTP)/信令连接控制部分(Signalling Connection Control Part，SCCP)的网络状态管理方式获知所述SCP不可达，则判断所述SCP出现异常；或者，
接收另一个STP发送的网络管理消息后，则判断SCP出现异常，所述另一个STP采用MTP/SCCP的网络状态管理方式获知所述SCP不可达后发送所述网络管理消息。
另外，本发明实施例中的SCP出现异常是指该SCP不能再进行智能呼叫业务，但是依然可以进行普通的呼叫业务。
步骤13：如果所述SCP出现异常，且如果需要放通(bypass)处理，STP向SSP发送用于指示SSP继续业务接续的消息。
现有技术中，通过SSP实现智能业务故障处理，当本地UE漫游到其他网络后无法再实现上述功能；并且，SSP作为端局可能随时接入新的SSP，如果新接入的SSP不支持上述功能，则会影响整个网络功能的使用，网络兼容性差，适用范围比较少。本实施例通过STP在智能业务时判断SCP是否异常，由于STP并不是端局设备，可以避免由端局的SSP处理时造成的适用范围少的问题，可以适用于漫游、非漫游场景以及新增端局设备的场景，扩大适用范围。
图2为本发明第二实施例的方法流程示意图，本实施例以在本地进行智能业务为例。参见图2，本实施例包括：
步骤21：UE向其归属SSP发起智能业务，例如预付费业务。
步骤22：归属SSP判断该智能业务是与SCP有关的智能业务时，则向归属地的STP发送IDP消息。
其中，SSP可以位于移动交换机(Mobile Switching Center，MSC)中，也可以独立设置或者位于其他设备中。
步骤23：STP判断归属地的SCP是否出现异常，若是，执行步骤24，否则，执行步骤27。
其中，本实施例可以采用MTP/SCCP网络状态管理方式来确定SCP是否异常，异常包括SCP故障或者SCP不可达，其中，在SCP故障时可以采用网络管理消息(subsystem-prohibited)通知STP，以避免采用业务层通知时的延迟较长的问题；本发明实施例的不可达包括直连链路不可达，也包括非直连链路不可达，避免现有只将直连链路不可达作为链路故障造成的不准确问题。
例如，图3为本发明实施例中SCP通知STP异常的情况示意图，参见图3，SCP在自身出现故障后，可以向STP发送网络管理消息，通知SCP出现了异常。
图4为本发明实施例中STP获知SCP不可达的情况示意图，参见图4，STP可以采用MTP/SCCP获知SCP不可达，其中，该不可达包括STP与SCP之间的直连链路断开，也包括STP与SCP之间的迂回链路断开。
图5为本发明实施例中STP通过另一个STP获知SCP不可达的情况示意图，参见图5，STP～1为需要判断是否需要bypass的STP，当STP～1通过STP～2与SCP相连时，如果STP～2采用MTP/SCCP获知SCP不可达后，可以采用网络管理消息来通知STP～1该SCP不可达。
步骤24：STP判断是否需要bypass处理，若是，执行步骤25，否则执行步骤27。
其中，可以在STP中预设条件表明哪些情况下需要进行bypass处理，预设条件可以为如下信息中的至少一项：用户信息、时段信息、局向信息、业务信息。具体地，用户信息可以用于标识用户，例如用户的移动台国际综合业务数字网(Integrated Services Digital Network，ISDN)号码(Mobile Stationinternational ISDN number，MSISDN)；时段信息可以用于定义此功能的有效时长；局向信息可以用于表明从哪个SSP上来的消息有此功能；业务信息可以用于表明此功能具体如何实现，譬如可以选择中止呼叫或继续呼叫。
步骤25：STP向归属SSP发送用于指示SSP继续呼叫接续的消息，例如继续(continue)消息，也就是将本次呼叫作为普通呼叫而不是智能呼叫来处理。
另外，对于需要bypass的情况，STP可以生成详细记录，记录用户号码、SCP地址、发起时间等详细信息，以备后续通话信息核对。例如，可以用于客户核对，具体如用于网络影响、话单记录影响的各种分析与核对，还可用于以后的功能拓展。
步骤26：归属SSP继续接续呼叫。
即，将该呼叫作为普通呼叫而不是智能呼叫来处理，例如发起请求路由消息(SendRoutingInfo，SRI)以查询路由信息进行呼叫处理。
步骤27：按照通常方式处理。
例如，在SCP正常时，STP将IDP消息发送给SCP，继续处理智能呼叫；
或者，在不需要bypass处理时，STP丢弃IDP消息，本次智能呼叫失败。
本实施例通过STP在智能业务时判断SCP是否异常，由于STP并不是端局设备，可以避免由端局的SSP处理时造成的问题，可以适用于非漫游场景，扩大适用范围。另外，本实施例在进行SCP异常判断时是采用MTP/SCCP网络状态管理，可以避免只判断直连链路引起的不准确问题，以及采用业务层通知故障时引起的延时较大的问题。本实施例可以应用于UE在本地的处理场景。
图6为本发明第三实施例的方法流程示意图，本实施例以在漫游场景下进行智能业务为例。参见图6，本实施例包括：
步骤601：UE漫游到外地时，向漫游地的拜访SSP发起智能业务，例如预付费业务。
步骤602：拜访SSP判断该智能业务是与SCP有关的智能业务，则向漫游地的拜访关口局(GMSC)发送IDP消息。
步骤603：拜访关口局向UE归属地的归属关口局发送IDP消息。
步骤604：归属关口局将该IDP消息转发给UE归属地的STP。
步骤605：STP判断归属地的SCP是否出现异常，若是，执行步骤606，否则，执行步骤611。
其中，判断是否出现异常的具体内容可以参见步骤23。
步骤606：STP判断是否需要bypass处理，若是，执行步骤607，否则执行步骤611。
具体判断是否需要bypass处理的内容可以参见步骤24。
步骤607：STP向归属地的GMSC发送用于指示SSP继续呼叫接续的消息，例如继续(continue)消息，也就是将本次呼叫作为普通呼叫而不是智能呼叫来处理。
另外，对于需要bypass的情况，STP可以生成详细记录，记录用户号码、SCP地址、发起时间等详细信息。
步骤608：归属GMSC将该继续消息发送给拜访GMSC。
步骤609：拜访GMSC将该继续消息转发给拜访SSP。
步骤610：拜访SSP继续接续呼叫。
步骤611：STP按照通常方式处理。
具体内容可以参见步骤27。
本实施例通过STP在智能业务时判断SCP是否异常，由于STP并不是端局设备，可以避免由端局的SSP处理时造成的问题，可以适用于漫游的场景，扩大适用范围。另外，本实施例在进行SCP异常判断时是采用MTP/SCCP网络状态管理，可以避免只判断直连链路引起的不准确问题，以及采用业务层通知故障时引起的延时较大的问题。本实施例可以应用于UE在漫游地的处理场景。
图7为本发明第四实施例的方法流程示意图，本实施例以在新增端局设备时进行智能业务为例。参见图7，本实施例包括：
步骤701：UE向新增的SSP发起智能业务，例如预付费业务。
步骤702：新增的SSP判断该智能业务是与SCP有关的智能业务，则向新增的STP发送IDP消息。
步骤703：新增的STP向原有的STP发送IDP消息。
其中，该原有的STP为上述实施例中具有判断SCP是否出现异常以及是否需要bypass处理功能的STP。
步骤704：原有的STP判断归属地的SCP是否出现异常，若是，执行步骤705，否则，执行步骤709。
其中，判断是否出现异常的具体内容可以参见步骤23。
步骤705：原有的STP判断是否需要bypass处理，若是，执行步骤706，否则执行步骤709。
具体判断是否需要bypass处理的内容可以参见步骤24。
步骤706：原有的STP向新增的STP发送用于指示SSP继续呼叫接续的消息，例如继续(continue)消息，也就是将本次呼叫作为普通呼叫而不是智能呼叫来处理。
另外，对于需要bypass的情况，STP可以生成详细记录，记录用户号码、SCP地址、发起时间等详细信息。
步骤707：新增的STP将该继续消息发送给新增的SSP。
步骤708：新增的SSP继续接续呼叫。
步骤709：STP按照通常方式处理。
具体内容可以参见步骤27。
本实施例通过STP在智能业务时判断SCP是否异常，由于STP并不是端局设备，可以避免由端局的SSP处理时造成的问题，可以适用于新增端局设备的场景，扩大适用范围。另外，本实施例在进行SCP异常判断时是采用MTP/SCCP网络状态管理，可以避免只判断直连链路引起的不准确问题，以及采用业务层通知故障时引起的延时较大的问题。本实施例可以应用于新增端局设备的处理场景。
图8为本发明第五实施例的STP的结构示意图，包括接收模块81、第一判断模块82和处理模块83；接收模块81用于接收SSP发送的用于触发智能业务的消息；第一判断模块82用于在接收到所述用于触发智能业务的消息后，判断SCP是否出现异常；处理模块83用于如果所述SCP出现异常，且如果需要放通处理，STP向SSP发送用于指示SSP继续业务接续的消息。
所述接收模块81具体用于接收发起智能业务的终端所属网络的SSP发送的所述用于触发智能业务的消息；或者，接收发起智能业务的终端漫游到的拜访网络的SSP发送的所述用于触发智能业务的消息；或者，接收新入网的SSP通过新入网的STP发送的所述用于触发智能业务的消息。
所述第一判断模块82具体用于接收SCP发送的网络管理消息后，判断出SCP出现异常，所述网络管理消息为所述SCP在发生故障后发送的；或者，采用MTP/SCCP的网络状态管理方式获知所述SCP不可达，则判断出所述SCP出现异常；或者，接收另一个STP发送的网络管理消息后，判断出SCP出现异常，所述另一个STP采用MTP/SCCP的网络状态管理方式获知所述SCP不可达后发送所述网络管理消息。
还可以包括：第二判断模块，用于根据预设条件，判断是否需要放通处理，所述预设条件包括如下项中的至少一项：用户信息、时段信息、局向信息、业务信息。
还可以包括：记录模块，用于记录需要放通处理的用户号码、SCP地址或者发起时间。
所述STP为独立设置的设备，或者所述STP位于其他设备中，例如，位于具备信令中继功能的GMSC中。
本实施例通过STP在智能业务时判断SCP是否异常，由于STP并不是端局设备，可以避免由端局的SSP处理时造成的问题，可以适用于漫游、非漫游场景以及新增端局设备的场景，扩大适用范围。
本发明实施例可以应用在不同的***中，例如C网、G网或者固网中。
可以理解的是，上述方法及设备中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种智能业务故障处理方法，其特征在于，包括：
信令转接点STP接收业务交换点SSP发送的用于触发智能业务的消息；
所述STP在接收到所述用于触发智能业务的消息后，判断业务控制点SCP是否出现异常；
如果所述SCP出现异常，且如果需要放通bypass处理，STP向SSP发送用于指示SSP继续业务接续的消息。
2.根据权利要求1所述的方法，其特征在于，所述接收SSP发送的用于触发智能业务的消息，包括：
接收发起智能业务的终端所属网络的SSP发送的所述用于触发智能业务的消息；或者，
接收发起智能业务的终端漫游到的拜访网络的SSP发送的所述用于触发智能业务的消息；或者，
接收新入网的SSP通过新入网的STP发送的所述用于触发智能业务的消息。
3.根据权利要求1所述的方法，其特征在于，所述判断SCP是否出现异常，包括：
接收SCP发送的网络管理消息后，则判断所述SCP出现异常，所述网络管理消息为所述SCP在发生故障后发送的；或者，
采用媒体传输协议MTP/信令连接控制部分SCCP的网络状态管理方式获知所述SCP不可达，则判断所述SCP出现异常；或者，
接收另一个STP发送的网络管理消息后，则判断SCP出现异常，所述另一个STP采用MTP/SCCP的网络状态管理方式获知所述SCP不可达后发送所述网络管理消息。
4.根据权利要求1所述的方法，其特征在于，还包括：
根据预设条件，判断是否需要放通处理，所述预设条件包括如下项中的至少一项：用户信息、时段信息、局向信息、业务信息。
5.根据权利要求1所述的方法，其特征在于，还包括：
记录需要放通处理的用户号码、SCP地址或者发起时间。
6.一种STP，其特征在于，包括：
接收模块，用于接收业务交换点SSP发送的用于触发智能业务的消息；
第一判断模块，用于在接收到所述用于触发智能业务的消息后，判断业务控制点SCP是否出现异常；
处理模块，用于如果所述SCP出现异常，且如果需要放通bypass处理，STP向SSP发送用于指示SSP继续业务接续的消息。
7.根据权利要求6所述的STP，其特征在于，所述接收模块具体用于接收发起智能业务的终端所属网络的SSP发送的所述用于触发智能业务的消息；或者，接收发起智能业务的终端漫游到的拜访网络的SSP发送的所述用于触发智能业务的消息；或者，接收新入网的SSP通过新入网的STP发送的所述用于触发智能业务的消息。
8.根据权利要求6所述的STP，其特征在于，所述第一判断模块具体用于接收SCP发送的网络管理消息后，判断出SCP出现异常，所述网络管理消息为所述SCP在发生故障后发送的；或者，采用MTP/SCCP的网络状态管理方式获知所述SCP不可达，则判断出所述SCP出现异常；或者，接收另一个STP发送的网络管理消息后，判断出SCP出现异常，所述另一个STP采用媒体传输协议MTP/信令连接控制部分SCCP的网络状态管理方式获知所述SCP不可达后发送所述网络管理消息。
9.根据权利要求6所述的STP，其特征在于，还包括：
第二判断模块，用于根据预设条件，判断是否需要放通处理，所述预设条件包括如下项中的至少一项：用户信息、时段信息、局向信息、业务信息。
10.根据权利要求6所述的STP，其特征在于，还包括：
记录模块，用于记录需要放通处理的用户号码、SCP地址或者发起时间。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011100374311A CN102158472A (zh) | 2011-02-14 | 2011-02-14 | 智能业务故障处理方法及stp |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011100374311A CN102158472A (zh) | 2011-02-14 | 2011-02-14 | 智能业务故障处理方法及stp |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN102158472A true CN102158472A (zh) | 2011-08-17 |
Family
ID=44439657
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2011100374311A Pending CN102158472A (zh) | 2011-02-14 | 2011-02-14 | 智能业务故障处理方法及stp |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102158472A (zh) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1420605A1 (en) * | 2001-08-07 | 2004-05-19 | Huawei Technologies Co., Ltd. | Method for roaming call implement to foreign intelligent client |
| CN101102365A (zh) * | 2007-08-24 | 2008-01-09 | 华为技术有限公司 | 一种业务放通方法、***及装置 |
| CN101291460A (zh) * | 2008-06-17 | 2008-10-22 | 中兴通讯股份有限公司 | 一种移动智能网业务转固定智能网业务的触发方法 |
| CN101697639A (zh) * | 2009-09-16 | 2010-04-21 | 中兴通讯股份有限公司 | 一种完整旁路被叫智能的方法及*** |
| CN101707780A (zh) * | 2009-11-19 | 2010-05-12 | 东方通信股份有限公司 | 一种基于智能网信令监控的网络问题监控方法和网络问题监控*** |
-
2011
- 2011-02-14 CN CN2011100374311A patent/CN102158472A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1420605A1 (en) * | 2001-08-07 | 2004-05-19 | Huawei Technologies Co., Ltd. | Method for roaming call implement to foreign intelligent client |
| CN101102365A (zh) * | 2007-08-24 | 2008-01-09 | 华为技术有限公司 | 一种业务放通方法、***及装置 |
| CN101291460A (zh) * | 2008-06-17 | 2008-10-22 | 中兴通讯股份有限公司 | 一种移动智能网业务转固定智能网业务的触发方法 |
| CN101697639A (zh) * | 2009-09-16 | 2010-04-21 | 中兴通讯股份有限公司 | 一种完整旁路被叫智能的方法及*** |
| CN101707780A (zh) * | 2009-11-19 | 2010-05-12 | 东方通信股份有限公司 | 一种基于智能网信令监控的网络问题监控方法和网络问题监控*** |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4059348B2 (ja) | 話中の加入者に対するショートメッセージサービスを行うためのフロー制御方法 | |
| US9264922B2 (en) | Method and system for ensuring service continuity in case of a proxy profile gateway failure or interruption | |
| FI105972B (fi) | Älyverkkopalvelut pakettivälitteisessä verkossa | |
| EP2003913A9 (en) | A call recovery method during the network failure and the system thereof | |
| CN101287163B (zh) | 一种视频呼叫回落到语音呼叫的方法、***和装置 | |
| CN100450309C (zh) | 移动通信网络中被叫业务的承载网络模式的选择方法 | |
| CN1332584C (zh) | 防止移动终结呼叫失败的方法及*** | |
| CN101267678A (zh) | 呼叫前转的方法、设备及*** | |
| US20130237214A1 (en) | Inter-plmn roaming | |
| CN102047639A (zh) | 刀片集***换中心服务器和用于信令的方法 | |
| CN100574476C (zh) | 视频电话回落方法 | |
| CN102075501A (zh) | 使用ims业务的方法、设备及*** | |
| CN101754146A (zh) | 一种呼叫遇忙处理方法、***及移动交换中心设备 | |
| WO2008057472A1 (en) | Method and system for providing roaming services to outbound roamers using home network gateway location register | |
| EP1895788B1 (en) | Short message filtering method, signaling processing system and short message service center | |
| CN101426258B (zh) | 一种终端信息的处理方法和装置 | |
| CN101453752B (zh) | 通信网中实现业务优先级的方法、***及设备 | |
| WO2000078061A1 (en) | Paging in a mobile telecommunications network | |
| CN101507196B (zh) | 呼叫仲裁节点失败路由重选方法、交换机和*** | |
| CN102158472A (zh) | 智能业务故障处理方法及stp | |
| WO2010043184A1 (zh) | 一种限制主叫用户呼叫的方法、***和装置 | |
| CN101437214A (zh) | 一种回呼的实现方法和装置 | |
| CN102131163A (zh) | 在电路域接入终端与as之间交互控制信息的方法及设备 | |
| CN100499865C (zh) | 一种呼叫处理方法 | |
| CN101686454A (zh) | 一种平滑信令流量的实现方法、***及归属位置寄存器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20110817 |