CN1889704A - 一种业务控制点负荷分担方法及装置 - Google Patents
一种业务控制点负荷分担方法及装置 Download PDFInfo
- Publication number
- CN1889704A CN1889704A CN 200510080258 CN200510080258A CN1889704A CN 1889704 A CN1889704 A CN 1889704A CN 200510080258 CN200510080258 CN 200510080258 CN 200510080258 A CN200510080258 A CN 200510080258A CN 1889704 A CN1889704 A CN 1889704A
- Authority
- CN
- China
- Prior art keywords
- control point
- service control
- message
- module
- access device
- 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
- Telephonic Communication Services (AREA)
Abstract
本发明公开一种业务控制点负荷分担方法及装置,其中该方法为:业务交换点发起呼叫请求;No.7信令接入装置将该呼叫请求对应的对话消息进行缓存;确定该对话消息的目的业务控制点,并将该对话消息发送至目的业务控制点。通过本发明简化了SCP群集组网结构及SCP软件的复杂程度,提高了SCP群集的处理效率。
Description
技术领域
本发明涉及通信领域,更确切地说是涉及一种业务控制点负荷分担方法及装置。
背景技术
随着七号信令系统中2M信令链路的出现,单个信令点间信令链路容量较之以前64k信令链路有较大提升。由于单套业务控制点SCP(Service ControlPoint)处理能力比较低,为了满足需求,往往多个SCP组成一个SCP集群共享同一个信令点,智能网业务分布在SCP群集中的各个SCP内。业务交换点SSP(Service Switch Point)或其他实体例如归属位置寄存器HLR上报的智能业务请求在SCP群集内的多个SCP之间实现负荷分担。采用SCP群集技术,可以集合多套小容量SCP来实现大容量SCP功能。
在智能业务中,SCP不仅与SSP交互,而且还可能与智能外设IP(IntelligentPeripherals)进行交互。IP可能集成于SSP中,也可能独立于SSP,独立于SSP而单独成为一个设备的IP我们称为独立IP。以智能网应用规程INAP(IntelligentNetwork Application Protocol)智能网协议为例,在一个智能呼叫处理过程中,SCP往往即与SSP交互,也与IP交互。如果IP设备是独立IP,则一个智能呼叫中将包含多个事务处理能力应用部份TCAP(Transaction Capabilities ApplicationPart)对话。CAMEL应用部分CAP(CAP-CAMEL Application Party,移动网络增强逻辑客户化应用CAMEL-Customized Applications for Mobile networkEnhanced Logic)智能网电路域协议与INAP协议情况类似,而在CAP智能网分组域协议以及码分多址CDMA(Code Division Multiple Access)无线智能网WIN(Wireless Intelligent Network)协议中一个智能呼叫往往包含更多的TCAP对话。
由于No.7信令接入装置按负荷分担方式分发TCAP消息到各个信令接入单元SCU(Signaling Access Unit),有可能出现属于同一个呼叫的不同TCAP消息被No.7信令接入装置分发到不同的SCP设备上。因此,SCP实现负荷分担前必须解决一个呼叫中包含多个对话消息的问题。
现有SCP负荷分担方案系统结构如图1所示:
群集内所有SCP共用同一个信令点地址。由于多个SCP共用同一个信令点,SSP和IP将整个SCP群集看成是一个大容量的SCP,所有的SCP都相互建立通信连接。No.7信令接入装置将信令链路上传的TCAP对话消息在SCP群集内所有SCP之间均匀或按比例地或其他负荷分担策略分发。
以INAP为例,假如SSP触发了一个智能呼叫到1号SCP,1号SCP在呼叫处理过程中指示SSP将呼叫接续到IP以便其与呼叫方进行用户交互,IP与SSP之间建立连接后,IP设备会向SCP群集发起一个新的TCAP对话,由于No.7信令接入装置按负荷方法分发TCAP消息,因此,IP设备向SCP群集发起的这个新的TCAP对话可能被No.7信令接入装置分发到该SCP群集内其他SCP(例如2号SCP)上。由于SSP触发的智能呼叫在1号SCP处理,而IP发起的TCAP对话消息上报到2号SCP,则1号SCP和2号SCP都无法正确处理该呼叫。
为解决一个呼叫包含多个对话消息问题。集群内的所有SCP实现相互连接并建立消息转发通道。如果某个SCP收到其不能处理的消息,则该SCP需要将收到的TCAP对话消息转发给目的SCP。本例中2号SCP根据收到的IP上报的TCAP对话消息中“辅助请求指令”操作携带的“相关标识”来确定是否应该由自己处理,并进一步根据相关标识判断该消息应该由1号SCP处理,则将从IP收到TCAP消息转发给1号SCP,1号SCP收到2号SCP转发过来的TCAP消息后,1号SCP通过2号SCP中转与IP设备建立通信通路,此后1号SCP与IP设备之间的所有消息都通过2号SCP来转发,2号SCP充当了1号SCP和IP设备之间的中转设备,其具体的信令处理流程如图2所示。
现有技术方案中,所有SCP之间相互建立通信连接,建立消息转发通道,这个SCP群集构成了一个网状结构,组网复杂且维护困难;因为要实现SCP之间网状互连以及TCAP消息转发,SCP软件的复杂度增加,也增加了SCP出故障的概率;每套SCP不仅需要处理SSP的呼叫请求,而且还需要相互担当其他SCP与IP之间TCAP消息转发中转设备,消耗系统大量的处理性能,降低了每套SCP的呼叫处理能力。
发明内容
本发明提供一种业务控制点负荷分担方法及装置,以解决现技术中SCP群集组网结构复杂和处理效率低的问题。
本发明提供以下技术方案:
一种业务控制点负荷分担方法,包括如下步骤:
A、业务交换点发起呼叫请求;
B、No.7信令接入装置将该呼叫请求对应的对话消息进行缓存;
C、No.7信令接入装置确定该对话消息的目的业务控制点,并将该对话消息发送至目的业务控制点。
所述步骤A进一步包括:
业务交换点发起呼叫请求将呼叫触发至业务控制点,业务控制点在处理呼叫的过程中向业务交换点或者通过业务交换点向智能外设下发自身业务控制点标识,在业务交换点或智能外设该呼叫对应的对话消息中携带该业务控制点标识。
所述步骤A进一步包括:
业务控制点在处理呼叫的过程中向业务交换点下发建立临时连接指令,在该指令相关标识参数中填上自身的标识信息;
业务交换点收到业务控制点下发的建立临时连接指令后,将呼叫接续到智能外设,并将建立临时连接指令相关标识参数透传给智能外设,智能外设在与业务交换点建立连接后向业务控制点发起新的TCAP对话消息,该对话消息中携带相关标识参数以确定其对应的目的业务控制点。
所述步骤C进一步包括:
No.7信令接入装置将对话消息转发至业务控制点,接收的业务控制点依据该消息所携带的业务控制点标识信息判断不应该由自己处理该对话消息时,向No.7信令接入装置发送携带该业务控制点标识的对话结束消息结束当前对话;
No.7信令接入装置依据对话结束消息中的目的业务控制点标识将缓存的对话消息发送至该目的业务控制点。
所述步骤C进一步包括:
No.7信令接入装置依据对话消息中携带的业务控制点标识,将该对话消息直接发送至该目的业务控制点。
所述步骤A进一步包括业务交换点发起呼叫请求将呼叫经由No.7信令接入装置触发至业务控制点,No.7信令接入装置建立呼叫唯一标识与该业务控制点标识的对应关系表;
步骤C进一步包括No.7信令接入装置依据对话消息中携带的呼叫唯一标识查找呼叫唯一标识与业务控制点标识的对应关系表确定该对话消息对应的业务控制点,将所述对话消息转发至该目的业务控制点。
No.7信令接入装置将呼叫请求对应的对话消息进行缓存后将其发送至业务控制点,步骤C进一步包括:
判断该对话消息是否呼叫流程中的第一条消息,如果是,将其进行呼叫处理,并建立呼叫唯一标识与该业务控制点标识的对应关系。
步骤C进一步包括:
如果该对话消息不是呼叫流程中的第一消息,则业务控制点依据该对话消息的呼叫唯一标识判断该消息不应由自己处理时,向No.7信令接入装置下发对话结束消息,该消息中携带呼叫唯一标识,No.7信令接入装置根据对话结束消息中携带的呼叫唯一标识通过所述呼叫标识与业务控制点对应关系表确定该呼叫的目的业务控制点后,将对话消息转发至目的业务控制点。
所述步骤C进一步包括:
如果该对话消息不是呼叫流程中的第一消息,No.7信令接入装置依据对话消息确定其对应的呼叫唯一标识,再依据所述呼叫唯一标识与业务控制点标识的对应关系确定该对话消息目的业务控制点,并将该对话消息发送到目的业务控制点。
一种No.7信令接入装置,包括注册模块、回退模块及缓存模块,其中:
注册模块用于接受SCP发送的呼叫请求,根据请求中携带的呼叫唯一标识建立呼叫唯一标识同SCP标识的对应关系,并将呼叫对话消息缓存至缓存模块;
回退模块用于依据SCP发送的回退请求中携带的参数同缓存模块交互将缓存的消息重定向到目的SCP;
缓存模块用于缓存对话消息。
一种No.7信令接入装置,包括接收模块、缓存模块、解析模块及发送模块,其中:
接收模块用于接收外部发送的呼叫对话消息,与缓存模块交互将其缓存;
解析模块用于解析该呼叫对话消息与SCP的对应关系,确定其目的SCP,并将其转发至发送模块;
发送模块用于呼叫对话消息发送至目的SCP;
缓存模块用于缓存呼叫对话消息。
一种业务控制点装置,包括请求回退模块及请求注册模块,其中,请求注册模块用于向No.7信令接入装置发送呼叫注册请求,指示No.7信令接入装置建立呼叫唯一标识与SCP标识的对应关系;请求回退模块用于当SCP发现现有呼叫消息不应该由自己处理时,指示No.7信令接入装置将缓存的消息重定向到目的SCP。
一种业务控制点接入装置,包括SCP接口模块、中央控制模块、负荷分担模块、No.7信令收发模块,其中:
No.7信令收发模块用于接收来自No.7信令接入装置的上行消息并将其转发至中央控制模块,依据上行消息解码出其对应的路由信息,将从SCP收到的下行信令消息转发给No.7信令接入装置;
负荷分担模块用于提供SCP负荷分发策略;
SCP接口模块用于与SCP及中央控制模块交互,将SCP发送的消息转发至中央控制模块及将中央控制模块发送的消息转发至SCP;
中央控制模块与SCP接口模块、负荷分担模块、No.7信令收发模块相连用于进行模块间消息转发,接受并执行负荷分担策略。
在本发明中群集的SCP各自独立,不需要相互连接构成一个网状结构,简化了SCP群集组网结构;SCP软件简化,提升了SCP可用性;每个SCP只需要负责呼叫处理即可,不必进行TCAP消息的中转,提高SCP群集的处理效率,降低SCP群集的网络复杂程度。
附图说明
图1为现有技术的智能业务系统组网示意图;
图2为现有技术呼叫处理流程图;
图3为本发明所述智能业务系统组网示意图;
图4为本发明的No.7信令接入装置的结构示意图;
图5为本发明的SCP结构示意图;
图6为本发明的另一种No.7信令接入装置的结构示意图;
图7为本发明呼叫处理方法流程示意图;
图8为本发明另一呼叫处理方法流程示意图;
图9为本发明另一种SCP接入装置示意图。
具体实施方式
本发明的系统结构如图3所示,各SCP之间没有通信连接和消息接口。各个SCP相互独立但共用同一个信令点,多个SCP构成一个SCP群集,在SSP或IP看来只有一套SCP。No.7信令接入装置按负荷分担算法均匀或按比例或其他负荷分担策略(例如按SCP系统处理能力)将收到的TCAP消息转发给各个SCP。
本发明提供的第一种No.7信令接入装置可以缓存对话消息,No.7信令接入装置与SCP之间增加消息回退接口和呼叫注册接口,No.7信令接入装置根据呼叫注册接口中携带的参数建立呼叫唯一标识与SCP标识的对应关系,No.7信令接入装置根据消息回退接口中携带的参数将缓存的消息重定向到目的SCP。相应的本发明的SCP上增加No.7信令接入装置与SCP之间的消息回退接口和呼叫注册接口,通过呼叫注册接口,可以指示No.7信令接入装置建立呼叫唯一标识与SCP标识的对应关系,对于不应该由自己处理的消息,可以主动释放掉当前处理的对话消息并通过消息回退接口指示No.7信令接入装置将缓存的消息重定向到目的SCP。
本发明提供的该No.7信令接入装置除了可以按负荷分担算法均匀或按比例或其他负荷分担策略(例如按SCP系统处理能力)将收到的TCAP消息转发给各个SCP外,还包括注册模块、回退模块及缓存模块,如图4所示。其中,注册模块用于接受SCP发送的呼叫请求,根据请求中携带的呼叫唯一标识建立呼叫唯一标识同SCP标识的对应关系,并将呼叫对话消息缓存至缓存装置,回退模块用于依据SCP发送的回退请求中携带的参数(可以是呼叫唯一标识或者是目的SCP标识)同缓存模块交互将缓存的消息重定向到目的SCP。
相应的,本发明提供的该SCP包括请求回退模块及请求注册模块,请求注册模块用于向No.7信令接入装置发送呼叫请求,指示No.7信令接入装置建立呼叫唯一标识与SCP标识的对应关系,当SCP发现现有呼叫消息不应该由自己处理时,释放当前处理的对话消息并通过请求回退模块指示No.7信令接入装置将缓存的消息重定向到目的SCP。
本发明提供第二种No.7信令接入装置,包括接收模块、缓存模块、解析模块及发送模块。其中,接收模块用于接收外部(可以是IP设备或者SCP)发送的呼叫消息,将其缓存,并由解析模块解析出呼叫消息与SCP的对应关系,确定其目的SCP,由发送模块将该呼叫消息发送至目的SCP。
如图7所示,作为第一实施例,仍然以INAP为例,假定SSP触发呼叫到1号SCP,1号SCP在呼叫处理过程中向SSP下发“建立临时连接”,指示SSP将呼叫接续到IP设备,SCP在下发的“建立临时连接”操作参数“相关标识”中填写上自身标识信息,SSP在收到SCP下发“建立临时连接”操作后,会将呼叫接续到IP设备,并将“建立临时连接”操作参数“相关标识”透传给IP设备,IP设备在与SSP建立连接后向SCP发起新的TCAP对话消息,其中携带“辅助请求指令”操作;No.7信令接入装置在收到IP发起的TCAP消息后先将其缓存起来后将收到的TCAP消息向SCP转发。假定NO.7信令接入装置将从IP设备收到的TCAP消息分发给了2号SCP,2号SCP从收到的“辅助请求指令”中解码出“相关标识”参数,并进一步从“相关标识”解析出SCP标识信息,由于“相关标识”中包含的SCP标识信息为1号SCP,2号SCP发现不应该由自己处理,2号SCP向No.7信令接入装置发送对话结束消息结束当前对话,并在对话结束信息中携带从“相关标识”中解码处理的SCP1标识信息。No.7信令接入装置从对话结束消息中获取该对话消息的目的SCP1标识,然后将缓存的TCAP消息重定向到1号SCP。1号SCP收到No.7信令接入装置上报的TCAP消息,经过解码分析后确认该消息应该由自己处理,然后建立与IP设备的TCAP对话。
以上处理过程虽然以INAP为例,但也完全适用于CAP等其他协议。
作为本发明的第二实施例,其处理流程如图8所示。以CDMA智能网WIN协议为例,既使SCP不与IP设备交互,一个呼叫中SCP与SSP之间也存在多个TCAP对话。在本实施例中No.7信令接入装置缓存每一条新TCAP对话消息并将消息转发给SCP,SCP在收到一个新的TCAP消息后判断该消息是否是一个“呼叫请求”消息(呼叫处理流程中的第一个消息),如果是“呼叫请求消息”,将从“呼叫请求”消息中解析出来的呼叫唯一标识(billingID)在本地保存并进行呼叫处理,然后将该呼叫唯一标识(billingID)与本SCP标识发送给No.7信令接入装置进行呼叫登记注册,No.7信令接入装置根据SCP的呼叫登记消息内容建立起每个呼叫唯一标识(billingID)与SCP标识的对应关系。SCP在收到一个新的TCAP对话且判断出该消息不是“呼叫请求”消息后从该对话携带的操作消息中解析出来呼叫唯一标识(billingID),SCP根据解析处理的呼叫唯一标识(billingID)判断该消息是否应该由自己处理,如果不应该由自己处理,SCP结束该对话,并在对话结束消息中携带解析处理的呼叫唯一标识(billingID)。No.7信令接入装置从呼叫结束消息中解析出呼叫唯一标识(billingID),并根据呼叫唯一标识(billingID)与SCP标识对应关系查询出该消息的目的SCP然后将消息转发给目的SCP。
作为本发明的第三实施例,对于INAP/CAP协议,对IP设备上报的“辅助请求指令”消息可以由No.7信令接入装置来处理,No.7信令接入装置先从“辅助请求指令”消息中解析出“相关标识”参数,然后从“相关标识”中解析出SCP标识,然后直接将消息转发给目的SCP。
作为本发明的第四实施例,业务交换点发起呼叫请求将呼叫经由No.7信令接入装置触发至SCP,No.7信令接入装置中建立呼叫唯一标识与该SCP标识的对应关系表;
No.7信令接入装置接收到SSP或IP上报的后续对话消息,依据对话消息的呼叫唯一标识查找呼叫唯一标识与SCP标识的对应关系表确定该对话消息对应的SCP,将所述对话消息转发至该目的SCP。
作为本发明的第五实施例,对于CDMA智能网WIN协议。No.7信令接入装置在将呼叫请求下发时建立呼叫唯一标识与该下发的目的SCP标识对应关系表。对呼叫唯一标识(billingID)的解码也可以由No.7信令接入装置来处理。No.7信令接入装置直接解码WIN操作中携带的呼叫唯一标识(billingID)并记录每个呼叫唯一标识(billingID)与SCP的对应关系,并根据从消息中解码出来的呼叫唯一标识(billingID)判断消息的目的SCP,然后将消息转发给正确的目的SCP。
作为本发明的第六实施例,在No.7信令接入装置与SCP群集之间增加一个称之为接入SCP的装置。该装置将从SCP群集内每个SCP发送的消息转发给No.7信令接入装置,并且将从No.7信令接入装置接受到的消息分发给群集SCP内每个SCP。接入SCP装置的结构如图9所示,包括SCP接口模块、中央控制模块、负荷分担模块、No.7信令收发装置,还可以包括管理、统计和告警模块。其中No.7信令收发模块负责接收来自No.7信令接入装置的上行消息以及将从SCP收到的下行信令消息转发给No.7信令接入装置,No.7信令收发模块在将来自No.7信令接入装置的上行消息转发给中央控制模块时需要将从上行消息中解码出路由相关信息。负荷分担模块提供转发策略例如按比例、按SCP系统处理能力或多个SCP轮循等负荷分发策略。SCP接口模块负责与SCP交互,进行消息收发功能。中央控制模块与SCP接口模块、负荷分担模块、No.7信令收发模块相连用于进行模块间消息转发,接受并执行负荷分担策略。管理、统计和告警模块负责系统数据的配置以及系统运行状况的监测、统计。
No.7信令接入装置将收到的TCAP信令消息转发给该接入SCP装置。对于INAP/CAP协议,对IP设备上报的“辅助请求指令”消息由该接入SCP装置来处理,接入SCP装置先从“辅助请求指令”消息中解析出“相关标识”参数,再从“相关标识”中解析出SCP标识,然后直接将消息转发给目的SCP。对于CDMA智能网WIN协议。对呼叫唯一标识(billingID)的解码也可以由接入SCP装置来处理。接入SCP装置直接解码WIN操作中携带的呼叫唯一标识(billingID)并记录每个呼叫唯一标识(billingID)与群集SCP中每个SCP的对应关系,并根据从消息中解码出来的呼叫唯一标识(billingID)判断消息目的SCP,然后将消息转发给群集SCP中正确的目的SCP。
在本发明方案中,No.7信令接入装置和SCP之间的关系仅仅为逻辑关系,在实际组网过程中,No.7信令接入装置可以与SCP合设在同一个物理设备中,也可以分别设置在不同的物理设备中。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (15)
1、一种业务控制点负荷分担方法,其特征在于,包括如下步骤:
A、业务交换点发起呼叫请求;
B、No.7信令接入装置将该呼叫请求对应的对话消息进行缓存;
C、No.7信令接入装置确定该对话消息的目的业务控制点,并将该对话消息发送至目的业务控制点。
2、如权利要求1所述的方法,其特征在于,步骤A进一步包括:
业务交换点发起呼叫请求将呼叫触发至业务控制点,业务控制点在处理呼叫的过程中向业务交换点或者通过业务交换点向智能外设下发自身业务控制点标识,在业务交换点或智能外设该呼叫对应的对话消息中携带该业务控制点标识。
3、如权利要求2所述的方法,其特征在于,步骤A进一步包括:
业务控制点在处理呼叫的过程中向业务交换点下发建立临时连接指令,在该指令相关标识参数中填上自身的标识信息;
业务交换点收到业务控制点下发的建立临时连接指令后,将呼叫接续到智能外设,并将建立临时连接指令相关标识参数透传给智能外设,智能外设在与业务交换点建立连接后向业务控制点发起新的TCAP对话消息,该对话消息中携带相关标识参数以确定其对应的目的业务控制点。
4、如权利要求2所述的方法,其特征在于,步骤C进一步包括:
No.7信令接入装置将对话消息转发至业务控制点,接收的业务控制点依据该消息所携带的业务控制点标识信息判断不应该由自己处理该对话消息时,向No.7信令接入装置发送携带该业务控制点标识的对话结束消息结束当前对话;
No.7信令接入装置依据对话结束消息中的目的业务控制点标识将缓存的对话消息发送至该目的业务控制点。
5、如权利要求2所述的方法,其特征在于,步骤C进一步包括:
No.7信令接入装置依据对话消息中携带的业务控制点标识,将该对话消息直接发送至该目的业务控制点。
6、如权利要求2所述的方法,其特征在于,步骤A进一步包括业务交换点发起呼叫请求将呼叫经由No.7信令接入装置触发至业务控制点,No.7信令接入装置建立呼叫唯一标识与该业务控制点标识的对应关系表;
步骤C进一步包括No.7信令接入装置依据对话消息中携带的呼叫唯一标识查找呼叫唯一标识与业务控制点标识的对应关系表确定该对话消息对应的业务控制点,将所述对话消息转发至该目的业务控制点。
7、如权利要求1所述的方法,其特征在于,No.7信令接入装置将呼叫请求对应的对话消息进行缓存后将其发送至业务控制点,步骤C进一步包括:
判断该对话消息是否呼叫流程中的第一条消息,如果是,将其进行呼叫处理,并建立呼叫唯一标识与该业务控制点标识的对应关系。
8、如权利要求7所述的方法,其特征在于步骤C进一步包括:
如果该对话消息不是呼叫流程中的第一消息,则业务控制点依据该对话消息的呼叫唯一标识判断该消息不应由自己处理时,向No.7信令接入装置下发对话结束消息,该消息中携带呼叫唯一标识,No.7信令接入装置根据对话结束消息中携带的呼叫唯一标识通过所述呼叫标识与业务控制点对应关系表确定该呼叫的目的业务控制点后,将对话消息转发至目的业务控制点。
9、如权利要求7所述的方法,其特征在于,步骤C进一步包括:
如果该对话消息不是呼叫流程中的第一消息,No.7信令接入装置依据对话消息确定其对应的呼叫唯一标识,再依据所述呼叫唯一标识与业务控制点标识的对应关系确定该对话消息目的业务控制点,并将该对话消息发送到目的业务控制点。
10、如权利要求1所述的方法,其特征在于,所述智能业务系统中还包括业务控制点接入装置,步骤A进一步包括:业务交换点发起呼叫请求将呼叫经由No.7信令接入装置及业务控制点接入装置触发至业务控制点,业务控制点接入装置建立呼叫唯一标识与该业务控制点标识的对应关系;
步骤C进一步包括依据对话消息确定其对应的呼叫唯一标识,并依据所述对应关系解析出该呼叫唯一标识对应的目的业务控制点标识,直接将对话消息转发至目的业务控制点。
11、一种No.7信令接入装置,其特征在于,包括注册模块、回退模块及缓存模块,其中:
注册模块用于接受业务控制点发送的呼叫注册请求,根据请求中携带的呼叫唯一标识建立呼叫唯一标识同业务控制点标识的对应关系,并将呼叫对话消息缓存至缓存模块;
回退模块用于依据业务控制点发送的回退请求中携带的参数同缓存模块交互将缓存的消息重定向到目的业务控制点;
缓存模块用于缓存对话消息。
12、一种No.7信令接入装置,其特征在于,包括接收模块、缓存模块、解析模块及发送模块,其中:
接收模块用于接收外部发送的呼叫对话消息,与缓存模块交互将其缓存;
解析模块用于解析该呼叫对话消息与业务控制点的对应关系,确定其目的业务控制点,并将其转发至发送模块;
发送模块用于呼叫对话消息发送至目的业务控制点;
缓存模块用于缓存呼叫对话消息。
13、一种业务控制点装置,其特征在于,包括请求回退模块及请求注册模块,其中,请求注册模块用于向No.7信令接入装置发送呼叫注册请求,指示No.7信令接入装置建立呼叫唯一标识与业务控制点标识的对应关系;请求回退模块用于当业务控制点发现现有呼叫消息不应该由自己处理时,指示No.7信令接入装置将缓存的消息重定向到目的业务控制点。
14、一种业务控制点接入装置,其特征在于,包括业务控制点接口模块、中央控制模块、负荷分担模块、No.7信令收发模块,其中:
No.7信令收发模块用于接收来自No.7信令接入装置的上行消息并将其转发至中央控制模块,并依据上行消息解码出其对应的路由信息,将从业务控制点收到的下行信令消息转发给No.7信令接入装置;
负荷分担模块用于提供业务控制点负荷分发策略;
业务控制点接口模块用于与业务控制点及中央控制模块交互,将业务控制点发送的消息转发至中央控制模块及将中央控制模块发送的消息转发至业务控制点;
中央控制模块与业务控制点接口模块、负荷分担模块、No.7信令收发模块相连用于进行模块间消息转发,接受并执行负荷分担策略。
15、如权利要求14所述的方法,其特征在于,所述装置还包括管理、统计和告警模块,用于进行系统数据的配置及对系统运行状况进行监测、统计。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200510080258 CN1889704A (zh) | 2005-06-30 | 2005-06-30 | 一种业务控制点负荷分担方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200510080258 CN1889704A (zh) | 2005-06-30 | 2005-06-30 | 一种业务控制点负荷分担方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1889704A true CN1889704A (zh) | 2007-01-03 |
Family
ID=37578963
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200510080258 Pending CN1889704A (zh) | 2005-06-30 | 2005-06-30 | 一种业务控制点负荷分担方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1889704A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101291442B (zh) * | 2008-06-06 | 2011-03-02 | 中兴通讯股份有限公司 | 用于智能业务呼叫系统的负荷均衡方法 |
CN105828382A (zh) * | 2015-01-04 | 2016-08-03 | 中国移动通信集团江苏有限公司 | 一种业务负荷处理方法及装置 |
-
2005
- 2005-06-30 CN CN 200510080258 patent/CN1889704A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101291442B (zh) * | 2008-06-06 | 2011-03-02 | 中兴通讯股份有限公司 | 用于智能业务呼叫系统的负荷均衡方法 |
CN105828382A (zh) * | 2015-01-04 | 2016-08-03 | 中国移动通信集团江苏有限公司 | 一种业务负荷处理方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1203681C (zh) | 在电信网络内变换路由选择地址的系统 | |
CN1251523C (zh) | 用于处理呼叫的移动通信系统和备份网络网关单元 | |
CN1378368A (zh) | 网关系统及故障管理方法 | |
CN1400843A (zh) | 一种实现异地智能用户漫游呼叫的方法 | |
CN100352246C (zh) | 一种短消息监管的方法及设备 | |
CN1315288C (zh) | 双网络通信系统的不间断切换方法 | |
CN101068376A (zh) | 短消息系统、流量控制配置方法和流量控制方法 | |
CN1237826C (zh) | 移动无线通信系统中提供集成业务的方法和系统 | |
CN1929629A (zh) | 一种触发智能业务的方法、系统及信令处理装置 | |
CN1866886A (zh) | 一种网络监听系统及实现监听的方法 | |
CN1882109A (zh) | 用于提供电信服务的服务器布局、服务分发模块和方法 | |
CN1157909C (zh) | 一种网关和用于控制网关中连接的方法 | |
CN1889704A (zh) | 一种业务控制点负荷分担方法及装置 | |
CN1567835A (zh) | 智能网中的分布式集群业务管理系统及业务管理方法 | |
CN101577875B (zh) | 路由请求消息前转方法和装置 | |
CN1842171A (zh) | 一种呼叫接续方法 | |
CN101076062A (zh) | 彩铃系统、以及在该彩铃系统中进行业务呼叫的方法 | |
CN1282330C (zh) | 在七号消息分配单元实现对业务应用信令的控制选通方法 | |
CN1842170A (zh) | 跨业务控制点呼叫转移方法 | |
CN1738263A (zh) | 软交换系统媒体流的监听方法及采用的监听网关处理装置 | |
CN1852352A (zh) | 一种线路测试系统以及实现线路测试的方法 | |
CN1624690A (zh) | 一种移动通信商标查询系统及方法 | |
CN1286342C (zh) | 一种全球移动通信网络和码分多址网络共用基站的方法 | |
CN1248476C (zh) | 一种开放业务访问设备及其处理方法 | |
CN1889610A (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 |
Open date: 20070103 |