基于主叫站的完全识别的智能呼叫处理的制作方法

文档序号:7564413阅读:176来源:国知局
专利名称:基于主叫站的完全识别的智能呼叫处理的制作方法
技术领域
本发明一般地涉及智能呼叫处理,其中根据呼叫的特性,特别是包括主叫站的标识,各个电话呼叫提供不同的特征,特别是本发明涉及这样的处理,在该处理中主叫站的整个标识被用于确定参数和给每个呼叫提供适当特征的信息。
已经研制了各种智能呼叫处理系统,用于给电信系统的用户提供用户化的特征。一些智能通信系统基于拨号的或被叫的号码区分呼叫处理。例如,到800用户的呼叫在始发交换机中被识别,然后它询问相关的数据库,呼叫网络控制点(NCP)并检索那个用户专用的信息。这使每个800用户能够提供最适合那个用户的不同路由选择或呼叫处理。例如,一个用户可使用呼叫日时或星期几路由选择的呼叫时间,另一个用户可使用不同的路由选择图,和第三个用户可根据各个呼叫处理中心的业务量情况提供不同的业务。
其它的智能系统包括“虚专用网”或“软件定义网”(SDN)系统,这些系统提供适合于主叫方或主叫站的用户化特征。作为这种系统的一个例子,从用户的执行来的出境呼叫可接受从另一个雇员始发的呼叫来的不同处理。为了提供合适的呼叫处理,识别主叫方和该主叫站的信息今天从接收呼叫的始发交换机发送到保持与该主叫方相关的呼叫处理记录(CPR)的一个特定NCP。这个路由选择要求将呼叫者的自动号码识别(ANI)信息映射到用户的标识符和具有相应的CPR的NCP的网络地址。当ANI的数量很小时这个翻译可使用最少量的信息进行,通常是前三至六位数字。但是,随着预订的ANI数量的增加,研究已经表明,在一些情况下,接收询问的第一个NCP不具有正确的记录。在这种场合,该询问必须经过互连NCP的SS7信令网络再发送到正确的NCP。这就不希望地增加拨号后的时延,特别是在响应对路由选择和处理指令的询问的始发交换机中呼叫的拨号与接收之间的时间。而且,它增加路由选择差错的可能性,因为当需要一个附加的数据库的“深度”(dip)时,必须通过SS7网络实际发送的信令消息的数量相应地增加了;额外的深度也增加处理呼叫的费用,因为数据库容量是一个资源。
如果全部10个数字都用于确定用户标识符和具有CPR的NCP,则翻译变得很复杂,要求具有可用于百万个潜在记录的10位号簿。在过去,已有两种方法解决电信业务的大号簿问题(1)建立用于执行所有翻译的大的、集中的号簿或者(2)在处理来话呼叫的所有交换机中间分配ANI翻译。这两种技术有显著的缺点。
如果建立大的、集中的号簿,所有进入网络的呼叫导致起始一个对集中的号簿的询问以便翻译。集中的号簿使得措施简单,因为所有的ANI翻译信息被发送到相同地点,消除了数据库同步问题。困难是增加了每个呼叫的拨号后的时延,要求集中号簿具有大量的处理能力和将集中号簿作为所有呼叫的单个故障点。
如果ANI翻译是在所有来话交换机中间分配,则特定的ANI的翻译信息驻留在首先接收该呼叫的交换机中。由于该信息是在100或更多的交换机中间分配,时延的影响和处理能力的要求减至最少了,而且故障只影响进入特定交换机的呼叫。这个实现的困难是在所有交换机中间数据的规定。为了具体地分配翻译数据,需要复杂的ANI对交换机的翻译号簿和数据库同步机制。
根据本发明,安排始发交换机以便使用称为“全局名称翻译(GTT)”数据库的本地数据库提供智能呼叫处理。当该交换机接收呼叫时,如果求智能呼叫处理的SDN呼叫或800呼叫,则该交换机典型地以其10位号码(即三位(NPA)地码,三位(NXX)交换局,和四位线路识别)发送完全识别主叫站的询问,到该GTT数据库。GTT数据库通过识别用户ID和包含接通该呼叫的适当记录的电信网络中的特定NCP响应该询问。如果GTT数据库不包含入口或存在差错情况,则发出进一步的询问到中央数据库,称为“通用全局翻译(UGT)”数据库。然后UGT数据库检索识别用户ID和包含接通该呼叫的适当记录的电信网络中的特定NCP的信息,并把这个信息提供给始发交换机。根据本发明的一个方面,相同的信息也提供并存储在GTT数据库中。因此,GTT数据库是“自规定的”,此后它包含合适的信息以避免当呼叫随后从相同的主叫站始发时另一个询问到UGT数据库。
根据本发明的安排,避免了NCP到NCP的询问如果GTT数据库具有必须的信息,则一个询问直接地发送到合适的NCP。如果GTT数据库没有必须的信息,则到UGT数据库的询问是必须的,但是这使路由选择能够直接从始发交换机到正确的NCP。这个安排又更有效地使用信令网络和减少拨号后时延。
此外,本发明平衡了集中和分配实现二者的优点,同时避免它们各自的缺陷。
参阅应结合附图阅读的下面详细叙述将更全面理解本发明,其中

图1是说明一个始发交换机,它的GTT数据库和UGT数据库之间的相互关系的方框图;
图2是表示在确定图1的始发交换机101中接收呼叫的呼叫处理的步骤顺序的流程图;
图3是说明在规定(在其中存储信息)图1的UGT数据库170和更新这种信息的步骤顺序的流程图;
图4是说明在管理存储在图1的GTT数据库161或162中的信息的步骤顺序的流程图;
图5说明存储在UGT数据库170中的记录的格式。
首先参看图1,示出了说明根据本发明在始发交换机、其相关GTT数据库和UGT数据库之间的相互关系的方框图。为了提供各部分之间的关系,图1还表示这些单元和电信载波的电信交换与信令系统中的一些其它单元之间的互连。
交换机101和103可以是可从AT&T公司买到的4ESS电子交换系统,它们彼此互连并与一般以105表示的其它交换机互连,以构成用于发送从用户电话机111始发的呼叫的电信网络。在图1中,用户电话机111被连接到并被认为是“自动寻的”(homed on)的特定交换机,在这个例子中为交换机101,连接是经过一般以113表示的本地交换载波(LEC)网络,根据公知的能力它提供自动号码识别(ANI)信息给交换机101。这个ANI信息指示出始发呼叫的主叫站。
交换机101和103,当然和所有其它交换机105是与信号转发点(STP)互连的,信号转发点包括在一般以120表示的信令网络内。STP是成对地安排,而每个交换机直接地连接到一个STP对。每个交换机与其STP对之间的连接是通过一个接口进行,该接口可以是一个所谓的“CNI环”。具体说,交换机101通过CNI环131连接到STP对121,122,而交换机103通过CNI环132连接到STP对123,124。交换机(或者更准确地讲CNI环)和STP之间的连接是经过7号信令系统(SS7)信令链路,如图1中的信令链路141和142进行的,这些信令链路以虚线表示以便将传递信令消息的信令链路与以实线表示的、进行通信的电路区别开。如众所周知的,SS7信令网络主要是数字分组网,其安排是本领域技术人员公知的。例如,参见1992年IEEE会刊第80卷第4期第618-627页R.Brown等人的文章“在AT&T公司的5EEE交换机中的公共信道信令”,1986年9月在联邦德国幕尼黑的第八届国际计算机通信会议的会刊“新的通信业务对计算机技术的挑战”第370-374页D.Rouse等人的文章”2号信号转发点AT&T公司公共信道信令分组交换的概述”和1986年在通信中选择领域的IEEE杂志第SAC-4卷第3期第360-365页由G.Schlanger撰写的文章“No.7信令系统概述”。注意各个STP121-124也经过信令链路彼此互连。CNI环在1988年6月21日授予J.W.Darnell等人的专利4752924中叙述了。
图1表示了网络控制点(NCP)180连接到STP对123,124,根据本发明,在下面更详细地讨论的通用全局翻译(UGT)数据库170连接到STP对121,122。在实际安排中,多个NCP(未示出)与信令网络120中的STP互连,以致任何STP可以通过经一条信令链路直接连接到NCP或者使用其它的STP和多条信令链路间接连接到NCP来询问任何的NCP。每个NCP是包含呼叫处理记录的一个数据库,根据以询问形式提供给该NCP的信息,该呼叫处理记录识别呼叫应如何处理和发送。说明性地,该查询可根据ANI信息识别主叫站或始发地点。UGT数据库170包含了包括全局名称翻译表的记录,该全局名称翻译表存储在与每个交换机相关的全局翻译表(GTT)数据库中,如在下面更详细地讨论的。
如上面所指出的,图1还表示了交换机101和103是经过一些信令通路与信令网络120互连和彼此互连的,此外经过为了后备和灾害恢复的目的包含CNI环的通路互连。特别是,交换机101和103分别具有一个相关的迁回信令接口(ASI)151和152,它经过一条信令链路提供到一个STP对的连接,这个STP对不同于经过CNI环131或132连接到相同交换机的STP对。因此,交换机101通过ASI151连接到STP对123,124,而交换机103通过ASI152连接到STP对121,122。此外,交换机101和103通过一条迂回信令传送网络(ASTN)的信令链路155直接地互相连接。
如上面所指出的,根据本发明,全局名称翻译(GTT)数据库是与每个交换机如交换机101和103相连的。该GTT数据库161在图1中表示为是在CNI环131内和连接到交换机101,而GTT数据库162表示为是在CNI环132内并连接到交换机103。在每个GTT数据库161,162中的信息把由该交换机处理的每个呼叫方的ANI信息翻译为“点码”,该点码识别包含完成该呼叫的路图选择和处理所需的用户呼叫处理记录(CPR)的合适的NCP。该翻译还提供子系统号码(SSN)和用户ID,子系统号码识别在NCP内的应用,而用户ID,识别在所识别的应用内的CPR。在每个GTT数据库中的信息是唯一的,以致与每个交换机相连的GTT包含自动寻的那个特定交换机的主叫线路(ANI)的记录。(如在下面讨论的,还可包括一些附加的记录,以致存储在每个GTT数据库中的记录被“重叠”和不完全是唯一的)因此,在特定交换机的记录与保持在其它交换机的记录组不一样。如果“翻译”是基于整个(10位)主叫电话机的号码,这对于要求保持大量记录是必需的。GTT的其它互连安排也是可能的,这些将在下面详细地讨论。因此,可以说,根据本发明一个GTT数据库与每个交换机相连。
现在参见图2,示出了当从用户电话机111始发的呼叫在交换机101中被收到时的过程的流程图。在步骤201通过接收一个呼叫,在交换机101中起动了该过程,该呼叫可能是普通的长途电话、到800号的呼叫或者是SDN呼叫。假定该呼叫方信息包括识别用户电话机111为该呼叫源的ANI信息。接着在步骤203,检查与交换机101相连的GTT数据库161以便确定是否有为那个特定的ANI存储的入口(记录)。如果找到一个入口,该记录包括典型地以“点码”或地址的形式用于那个特定NCP(可能是NCP180)的标识,以及子系统号码和我们需要处理该呼叫的用户ID,特定的NCP包含该呼叫的呼叫处理记录。在响应该识别中,在步骤205发送一个询问到适当的NCP,如果在步骤207没有碰到差错,则执行CPR,并在步骤209检索的路由选择和呼叫处理指示再送回到交换机101。根据我们的发明,如果在步骤203不能找到入口,或者如果在步骤207碰到差错情况,则在步骤211从交换机101经过信令网络120向UGT数据库170发送询问以便获得“应该”已在GTT数据库161中第一位置的信息。在步骤213再检索这个信息,并且根据本发明的一个方面,在步骤215该信息被返回并插入GTT数据库161。这样,在GTT数据库161(和在该系统中的其它GTT)的记录被自动地更新,而且该系统被认为是“自规定的”。在记录加到GTT数据库161之后,该过程完成了,好象该记录已经找到在步骤209执行CPR并指示该交换机进行呼叫处理和接续。
如前面所述的,GTT的其它互连安排是在本发明的预期内的。特别是GTT可包括但不限于GTT与该交换机的主处理器之间、该GTT与该交换机信令接口之间或者GTT与相邻的GTT之间的互连安排。
现在参见图3,表示在规定(在其中存储信息)图1的UGT数据库170并更新这种信息的步骤顺序的流程图。这个过程使用了一个图1中所示出的前述未提及的单元,即规定与管理系统190,它由一个微处理器和一个数据库组成。在图3中随后的过程在步骤301当规定与管理系统190发送一个更新到UGT数据库170时开始。这个步骤可以周期地执行,例如一天一次,或者在规定与管理系统190已经累加了预定数量的变化信息时间断地执行。发送到UGT数据库170的信息通常包括(a)被更新的ANI的标识,和(b)变化的详情,它可能是增加、删除或者信息的变化。当收到在步骤301发送的信息时,在步骤303中UGT数据库170存储该信息;而且在步骤305,UGT数据库170通知受影响的交换机如交换机101正在进行更新事务处理。响应在步骤305中的通知,在步骤307,交换机101要执行在GTT数据库161中的相应的更新。如果在步骤309确定由于更新还没有或不能进行而被返回,和如果在步骤311确定还没有发生两次尝试,则通过返回到并重复步骤305来重复该更新过程。在已进行了两次不成功的更新尝试之后,在步骤313向UGT数据库170发送一个通知,以便在步骤315把一个例外报告给并存储在规定与管理系统190中。如果在步骤309更新成功地进行并且出现肯定的结果,则图3的过程在步骤315终止。
现在参见图4,表示了在管理存储在图1的GTT数据库161或162中的信息的步骤顺序的流程图。在步骤401过程开始之后,在步骤402进行确定更新是否已从UGT数据库170收到。如果未收到,可能要求例行维护,并且在步骤403进行测试看看自从上一次维护活动以来是否已经过了预定的时间,说明性地为24小时。如果在步骤403得到肯定的结果,则过程执行步骤407、409和411;否则该系统在步骤405“等待”,然后返回到步骤402和405,以便随后的更新或例行维护。
如果在步骤403出现肯定的结果,则在步骤407中删除漫游者的记录。这样做是因为这些记录在实质上是瞬变的,因此一般不要求长期在GTT数据库中存储。接着在步骤407,在GTT数据库中彼此的入口(而不是被确定与漫游者有关的那些入口)的寿命在步骤409中被更新。如果确定一个特定的入口是比预定的时间更长,则在步骤411中除去该入口。这里注意,提供给漫游者记录的相同处理对于有关软件定义网络(SDN)远地接入的呼叫的记录也可使用,即所述的呼叫是由SDN用户从网络外的地点始发的呼叫。此外,如果该数据库满了,则在步骤411可以删除最少使用的记录,虽然该入口的寿命没有超过预定值。
如果在步骤402得到肯定的结果,表明更新被处理了,则在步骤413确定该更新是否可成功地存储在GTT数据库161或162中。如果得到肯定的结果,则在步骤415具体地存储该更新,并且重复图4的过程;如果在步骤413得到否定的结果,则在步骤417一个适当的差错消息被发送到UGT数据库170,图4的过程再次重复。
在一些网络单元故障的情况下,利用图1的安排可利用各种过程。特别是,如果在交换机101的CNI环131中发生故障,那个交换机将依靠ASTN链路155询问UGT数据库170和/或NCP180。这改变了上面叙述的呼叫流程。在这些环境下,呼叫流程如下假定交换机101是“受害”交换机,而交换机103是“帮助者”交换机。在这个例子中,交换机101不能检验其GTT数据库161,而是经过“帮助者”交换机103向UGT数据库170发出一个询问。GTT数据库162不被检验,因为那个数据库不包含所需的记录。因此;由于“受害”交换机中断而调用ASTN时,从那个交换机来的所有呼叫都询问UGT数据库170。
存储在UGT数据库170中的典型记录的格式示于图5中。如图所示,每个记录使用以NPA-NXX-XXXX格式的10位电话号码作为该存储和检索关键词。每个记录包括在字段502中的用户ID,它是用于管理目的。主要的和后备的NCP点码(地址)分别存储在字段503和505中,并代表特定NCP的标识,该标识包含从具有指定的10位号码的电话机始发的呼叫的记录。主要的和后备NCP子系统号码(SSN)分别存储在字段504和506中,而且还表明到合适的NCP的路由选择。最后在字段507中存储当该记录最后被更新时的数据。
本领域的技术人员可对本发明进行各种变化。因此,本发明仅由所附的权利要求限制。
权利要求
1.一种系统,用于按照与始发电话呼叫的电话机相关的预存储的指令智能的处理该电话呼叫,所述系统包括一个本地数据库和一个集中数据库,每个数据库包含指明多个电信网络数据库的位置的信息,这些数据库包含用于接续电话呼叫的呼叫处理记录;响应电话呼叫和识别始发所述电话呼叫的特定电话机的信息的接收的装置,用于发送一个询问到所述本地数据库,以便检索所述多个电信网络数据库的特定数据库的位置,它包含用于接续所述电话呼叫的呼叫处理记录;和用于发送一个询问到所述集中数据库的装置,以便检索所述电信网络数据库的特定数据库的所述位置,它包含只在所述本地数据库不包含与所述特定电话机相关的入口时用于接续所述电话呼叫的所述呼叫处理记录。
2.根据权利要求1的系统,其中所述系统进一步包括用于以从所述集中数据库得到的信息更新所述本地数据库的装置。
3.根据权利要求1的系统,其中所述系统进一步包括用于周期地删除存储在所述本地数据库中的信息的装置。
4.根据权利要求1的系统,其中识别始发所述电话呼叫的特定电话机的所述信息包括ANI信息。
5.一种方法,用于按照与始发电话呼叫的电话机相关的预存指令智能的处理电话呼叫,所述方法包括步骤存储指明多个电信网络数据库地点的信息,在本地数据库和集中数据库中包含用于接续电话呼叫的呼叫处理记录;响应电话呼叫和识别始发所述电话呼叫的特定电话机的信息的接收,发送一个询问到所述本地数据库以检索多个电信网络数据库的特定数据库的位置,它包含用于接续所述电话呼叫的电话处理记录;和发送一个询问到所述集中数据库,以便检测所述电信网络数据库的特定数据库的所述位置,它包含只在所述本地数据库不包含与所述特定电话机相关的入口时用于接续所述电话呼叫的所述呼叫处理记录。
6.根据权利要求5的方法,其中所述方法进一步包括以从所述集中数据库得到的信息更新所述本地数据库的步骤。
7.根据权利要求5的方法,其中所述方法进一步包括周期地删除存储在所述本地数据库中的信息的步骤。
8.根据权利要求5的方法,其中识别始发所述电话呼叫的特定电话机的所述信息包括ANI信息。
全文摘要
安排一种智能呼叫处理系统,以致每个始发交换机装备GTT数据库,它接收完全识别主叫站的一个询问。GTT数据库通过识别电信网络中的特别NCP来响应该询问,如果GTT数据库不包含入口,或者存在一个差错情况,进一步的询问被发到UGT数据库。然后UGT数据库检索识别电信网络中的特定NCP的信息,并且提供给始发交换机。该相同信息也可提供并存储在GTT数据库中,使得GTT数据库是“自规定的”。
文档编号H04Q3/00GK1109248SQ94115139
公开日1995年9月27日 申请日期1994年9月8日 优先权日1993年9月28日
发明者富兰克林·古蒂尔瑞滋, 罗伯特·耶格尔·彼得斯, 阿鲁纳·西鲁纳加里, 乔尔·克里格·扬 申请人:美国电报电话公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1