一种呼叫数据主备同步的方法

文档序号:7614635阅读:221来源:国知局
专利名称:一种呼叫数据主备同步的方法
技术领域
本发明属于通讯领域,特别涉及网络设备中呼叫IP语音包NAT(Network Address Translation)功能接口板IPI(IP Interface)相关呼叫动态数据主备同步的一种方法。
背景技术
在网络设备中,以下以媒体信令网关为例,但不限于媒体信令网关设备,还适用于其他网关,交换设备处理实时呼叫的功能单元。以媒体信令网关为例,IP接口单板作为IP接入处理线卡,网关通过该接口板提供媒体报文的负荷分担转发以及NAT替换功能,实现将外部IP/UDP/RTP(Real-timeTransportProtocol实时传输协议)包转发至处理电路交换的TDM(Time Division Multiplexed)时隙语音与分组交换的IP/UDP/RTP包接口设备VTC(Voice TransCoder),同时反向接收并转发VTC设备产生的IP语音包到网关外部接口设备。
在由H.248(网关控制协议)协议的控制下,IPI单板上语音包转发通道,伴随着呼叫实时变化,在呼叫建立,呼叫参数修改,以及呼叫结束情况下,IPI完成相关呼叫转发通道的创建(Open),修改(Modify),关闭(Close)等操作。对于大容量媒体信令网关设备中与呼叫密切相关的硬件,将IPI单板进行主备1+1配置,并保持主备数据的一致性,对于防止硬件或者其他异常引起呼叫功能故障是十分必要的。
以往参与呼叫的单板的主备同步,采用的实时同步或定时缓冲同步方式。实时同步即主板除完成必要的呼叫消息业务逻辑处理之外,必须将消息实时同步到备板,此时主板采用阻塞等待备板响应,或者直接返回处理新的呼叫消息两种模式,这种处理方法最大限度的保证了主备板相关数据的高度一致性。但是由于与呼叫的高度相关性,大规模的用户呼叫与硬件处理能力存在矛盾,上述做法不可避免的引入了一些问题。首先,对于主板,每条消息需要进行额外的同步操作,增加了单板的处理负荷,对于板间通讯占用大量CPU时间的情况尤为突出,直接导致在大量呼叫存在情况下,呼叫消息处理延迟;另外随着呼叫量加大,主备之间消息增多,将导致通讯队列的溢出,消息丢失,增加了系统的不稳定因素。这些问题在板级CPU能力弱的情况下,尤为突出。
传统的定时缓冲同步采用将所有待同步数据缓存的模式,此种模式下主用设备开辟一个以呼叫决定的动态数据缓冲区,设定一个定时器,接收呼叫数据后,除控制呼叫而保存呼叫的数据外,另分配一个跟呼叫数据大小一致的缓冲区域,将所有呼叫相关数据保存在该缓冲区中,如此反复,直至定时器超时,将所有缓冲区中的数据同步至备板,释放缓冲区。由于消息长度的不确定性,以及发生频度的随机性,另外在同步定时间隔内产生的所有呼叫数据要完全保存两份,从而产生的缓冲区过大的问题,单板级设备资源不能满足该模式需求。
此外还有一种方式,除本地必须保存的数据外,另外创建一个失步数据区以及一个失步数据索引队列,每次失步数据产生,将相关失步数据特征保存入失步数据区,同时将数据索引追加到对尾。也由相应的定时器控制,定时器超时,同步过程开始。在同步过程中,遍历该队列,根据队列索引查失步数据区取失步数据特征,然后根据失步特征再从保存数据提取数据,生成同步数据包,进行同步。该方法的缺点是,对所有失步索引均进行入队操作,不能针对呼叫数据的连续性特征,对频繁变化的呼叫索引进行归并,即如果对于某一特定呼叫频繁产生变更操作,则对于同一呼叫在队列中的索引记录在某一时间段内产生很多重复,队列长度不可控,资源浪费严重。极端的情况下,如果呼叫通道Open(打开),Modify(修改),Close(关闭)在很短时间内产生,根据此种方式在同一失步队列中会有多条索引相同的记录。造成同步过程中不必要的数据流。实际上,此种方法主要用于数据相对稳定,变更不频繁的数据库表的同步,即数据库表本身即为本地保存数据,而数据表条目变化特征保存于失步数据区。不适用于实时大话务量呼叫数据的同步。
因此,提出一种更为高效的主备同步方法,是十分必要的。

发明内容
本发明的所要解决的技术问题是通过提供一种采取主备数据冗余的呼叫数据主备同步的方法,最大限度的降低单板CPU使用率以及板间通讯消息流量,同时保证对正常呼叫业务逻辑处理的影响降至最低。满足资源有限,而实时性,健壮性要求高的呼叫处理单板的数据同步要求。
本发明提出的呼叫数据主备同步的方法,包括以下步骤完成第一步,设定循环同步定时器,为后续同步提供触发开关;第二步,设立呼叫数据缓存和同步索引缓存,呼叫数据缓存和同步索引缓存通过呼叫通道索引相对应。
第三步,接收各种呼叫相关的操作消息;第四步,主板根据呼叫相关数据进行逻辑处理,例如建立呼叫转发通道,或其他业务相关操作,同时保存全部(通道打开)或者部分(通道修改)数据到呼叫数据缓存;
第五步,保存呼叫索引到同步索引缓冲区,如果同步定时器超时,或者索引缓冲区满,则根据缓冲索引组织取出呼叫数据,向备板同步,否则继续处理下一个呼叫。
进一步的,为了最大限度减少板间消息,将缓冲索引指向的待同步数据打包发出到备板。
同步定时器时长(在大话务量呼叫的情况下,例如每秒60到100个呼叫,通常设定为100ms到200ms。)的设定比较重要,如果设定时间间隔比较长,则导致索引缓冲区满而引发同步操作的几率增大。通常呼叫数据的同步以定时器触发为主,突发大量呼叫情况下,索引缓冲区满作为补充的同步触发机制。
本发明采取主备数据冗余的呼叫数据主备同步的方法,最大限度的降低单板CPU使用率以及板间通讯消息流量,同时保证对正常呼叫业务逻辑处理的影响降至最低,以解决现有呼叫数据同步模式所产生的问题。也可为资源,处理能力有限的板级设备的动态呼叫数据主备同步提供参考。
下面仍以媒体信令网关为例,进一步说明本发明的优点运用本发明定时同步方法,媒体信令网关IP接口处理板,处理能力得到了很大的提高。在相同呼叫情况下(200(主叫)*200(被叫),间隔0.1s,呼叫时长持续4s),实时同步情况下的CPU占有率比非同步CPU平均占用率高20%以上,而定时同步方式CPU平均占用率几乎没有增加。
同时以单板支持最大同时存在3600路RTP通道计算,每个通道存在时长为1分钟。则每秒RTP通道创建为60/s,以一个RTP通道伴随3个操作,即打开,修改,关闭呼叫通道,则每秒钟实时同步方案主备通讯消息个数为60*3=180/s。
由于定时同步缓存只需保存呼叫相关索引,而对于同一个呼叫,其呼叫生命周期索引ID(Identification标识)不变,且呼叫后续消息对相同呼叫前一个控制消息存在继承关系,则当一个呼叫到达修改通道阶段,不必同步前面的通道打开操作,最后到达的关闭通道消息,则不必同步此前产生的打开,修改通道操作。因此,对于每秒需处理的消息量可计为60(Modify)+60(Close)=120/s(以每秒产生以及关闭60个呼叫为例)。以定时同步间隔100ms,每同步间隔产生同步数据12个,定时同步索引缓冲区为32,同时每次定时同步将呼叫消息打包(以32为单位),则板间消息不超过10/s,低于实时同步方案。
本发明提供的同步方案,为提高业务逻辑处理速度,减少通讯队列提供了较好的优化。
与传统的定时缓冲以及失步队列缓冲方式相比,节省了待同步数据保存空间,减少了由于呼叫连续性,相关性而导致的同步数据冗余,保证了呼叫数据同步的实时性,为呼叫主备单板提供了高可靠性。


附图对本发明方法的结构和流程进行了阐述图1是本发明方法中IPI板呼叫相关转发通道建立,拆除示意图;图2是本发明方法中IPI板呼叫数据缓存以及同步索引链表关系示意图;图3是本发明方法的流程图。
具体实施例方式
下面对本发明方法作具体说明图1是本发明方法中IPI板呼叫相关转发通道建立,拆除示意图,简单说明本单板的呼叫数据转发基本原理。如图1所示,单板主板接收外部H248呼叫相关消息,上层软件运行于StrongArm芯片上,根据不同的消息建立,修改删除相关呼叫通道(转发表),同时底层的MicroEngine(微引擎)根据相应的呼叫通道(转发表)处理来自单板外部的以及来自VTC的媒体包,完成呼叫媒体包的出入向转发处理。每次呼叫都伴随呼叫通道打开,修改,媒体转发,呼叫通道关闭的过程。
图2是本发明方法中IPI板呼叫数据缓存以及同步索引链表关系示意图。
如图2所示,单板缓存呼叫相关数据结构,保存了呼叫相关数据,为呼叫通道建立,修改,完成提供依据,与呼叫密切相关,本方案中为最大限度增加业务逻辑处理速度,直接利用呼叫索引(由配置容量可预知其取值范围)决定呼叫通道数据的特点,直接按照索引保存数据。同时由于呼叫消息前后相关性以及连续性,例如呼叫建立阶段,通道Open(打开),Modify(修改)是连续出现的,后续Modify(修改)消息是对前面的Open(打开)操作的部分参数修正,因此某一特定呼叫数据每次的变化,只需将相应数据区部分数据进行修改,并将消息类型保存在消息类别字段中,完成了多个呼叫消息的合并,相对于实时同步模式,减少了需同步消息个数。另外对于该结构的另一个作用,就是在主备单板通讯状态中断,重新恢复后,作一次性同步使用。
图2右侧的同步索引缓存对同步过程提供了很大的优化。该结构采用了静态表结构,直接按照呼叫索引定位存在标志位,即如果该呼叫索引已经存在于静态链表,则无需分配新的链表单元,否则分配新链表单元,置位索引标志位。本方法即节省了数据空间,又避免了索引重复记录。
如上所述,图2所示的同步结构,在资源,处理能力有限的单板设备上,特别针对板间通讯损耗CPU过多的情况下,最大限度的利用了呼叫数据的相关性,连续性特点,从根本上减少了数据区中待同步呼叫数据的个数。
图3是本发明方法的流程图。如图所示1.首先,单板接收由H.248获取的打开,更新,关闭呼叫转发通道的操作;2.根据操作的不同对单板转发表作相应的改变,同时对操作数据作必要的保存或者修改。关于业务逻辑操作的细节与同步无关,只有按照呼叫通道索引缓存的操作数据与同步相关。
3.如果通道索引已经存在于索引缓存表中,则返回步骤1继续处理其他操作。否则继续步骤4。
4.分配索引缓存空闲元素,保存通道索引。
5.索引缓存表元素增1,如果表满,则依次读取索引缓存,根据通道索引取得相关操作数据,构造同步数据包,操作数据与操作类型关联。最终将索引缓存表清空,将打包数据发往备板,本次同步结束。
6.索引缓存表未满情况下,同步定时器超时,也触发同步流程。
另外,可以调整同步数据包大小,以及同步定时器间隔时长,以适应不同的话务呼叫环境。具体环境中,如果呼叫量在每秒70至100个,建议同步定时器间隔时长为100至200ms,同步索引缓存数量建议为32个。
本文的发明的方法是以媒体信令网关中H.248呼叫实例数据同步进行说明的,同时对其他种类的呼叫数据主备同步也适用。
综上所述,本发明提出的主备同步方法结合了呼叫过程的特点,利用了呼叫数据的相关性及连续性,最大限度的降低了单板CPU使用率以及板间通讯消息流量,同时保证了对正常呼叫业务逻辑处理的影响降至最低。满足了资源有限,而实时性,健壮性要求高的呼叫处理单板的数据同步要求。
权利要求
1.一种呼叫数据主备同步的方法,包括以下步骤第一步,设定循环同步定时器,为后续同步提供触发开关;第二步,设立呼叫数据缓存和同步索引缓存,呼叫数据缓存和同步索引缓存通过呼叫通道索引相对应;第三步,接收各种呼叫相关的操作消息;第四步,主板根据呼叫相关数据进行逻辑处理,例如建立呼叫转发通道,或其他业务相关操作,同时保存全部或者部分数据到呼叫数据缓存;第五步,保存呼叫索引到同步索引缓冲区,如果同步定时器超时,或者索引缓冲区满,则根据缓冲索引组织取出呼叫数据,向备板同步,否则继续处理下一个呼叫。
2.根据权利要求1所述的呼叫数据主备同步的方法,其特征在于所述的第五步包括下述步骤A、如果通道索引已经存在于索引缓存表中,则返回第三步继续处理其他操作。否则继续步骤B;B、分配索引缓存空闲元素,保存通道索引;C、索引缓存表元素增1,如果表满,则依次读取索引缓存,根据通道索引取得相关操作数据,最终将索引缓存表清空,将数据向备板同步,本次同步结束;D、索引缓存表未满情况下,同步定时器超时,也触发同步流程。
3.根据权利要求1或2所述的呼叫数据主备同步的方法,其特征在于上述的向备板同步是将缓冲索引指向的待同步数据打包发出到备板。
全文摘要
本发明公开了一种呼叫数据主备同步的方法,包括以下步骤第一步,设定循环同步定时器,为后续同步提供触发开关;第二步,设立呼叫数据缓存和同步索引缓存,呼叫数据缓存和同步索引缓存通过呼叫通道索引相对应;第三步,接收各种呼叫相关的操作消息;第四步,主板根据呼叫相关数据进行逻辑处理,例如建立呼叫转发通道,或其他业务相关操作,同时保存全部(通道打开)或者部分(通道修改)数据到呼叫数据缓存;第五步,保存呼叫索引到同步索引缓冲区,如果同步定时器超时,或者索引缓冲区满,则根据缓冲索引组织取出呼叫数据,向备板同步,否则继续处理下一个呼叫。本发明提供的方案,为提高业务逻辑处理速度,减少通讯队列提供了较好的优化。
文档编号H04L12/56GK1901501SQ20051003611
公开日2007年1月24日 申请日期2005年7月20日 优先权日2005年7月20日
发明者魏含宇, 张兵, 孙福清 申请人:中兴通讯股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1