专利名称：可以进行快速数据库同步的通信系统的制作方法
技术领域：
本发明属电信技术领域。具体地说，本发明与提供一个可扩展的冗余数据库的方法和设备有关。
最近这几年内，无线电信有了飞速的发展。无线电信的最普遍的形式之一是蜂窝电话，然而，预期其他诸如在日本普遍采用的PHS(个人手持电话系统)之类的技术在未来的几年中会对世界的其他部分产生显著的影响。
PHS不同于蜂窝技术，诸如电话机、调制解调器之类的移动装置通过小区距离范围(半径)通常为100-500米左右的“基站”进行通信，而对于蜂窝小区来说小区距离范围则为1500-5000米左右。因此，基站的分布要比蜂窝小区的情况稠密得多。然而，PHS手机的输出可以比蜂窝的低许多。一个PHS手机的输出在10毫瓦左右，而一个蜂窝电话机的输出通常要达到0.6-1.0瓦。可以预料，在不久的将来PHS将以较低的价格提供优异的服务。
在PHS系统和其他无线电信系统中，都有一个或多个用户数据库，存储有关每个用户的帐户的信息，例如业务选项(如语音信箱)、限制(如呼叫禁止，长途限制)、计费信息和状态以及当前位置(即当前为用户服务的基站)。数据库中的信息对于所有的电话事务处理来说都是必需的，因此数据库通常设置在一些充分冗余的计算机内，使得一个计算机有故障并不妨碍对数据的存取。为了防止灾害性的故障，如由洪水、地震或其他自然灾害而引起的故障，这些冗余计算机通常在地理上要相隔好几百英里。
随着用户数量的增大，数据库的容量也就增大。最终，数据库将会大得使单个计算机不能有效地进行维护。
因此，有必要开发一种能提供一个可扩展的用户数据库的方法和设备。
在本发明中，冗余服务控制点子系统之间的数据通过在每个服务控制点子系统上存储数据库的一个备份和在每个服务控制点子系统中将每个所述数据库的备份组织成一个相应的文件来实现同步，其中每个服务控制点子系统具有多个处理器，而每个文件包括多个记录。在每个服务控制点子系统中，对所述服务控制点子系统中的处理器分配相应的所述文件组。对于每个服务控制点子系统中的每个文件，已改变的记录被标识，并将信息送到其它服务控制点子系统的相应处理器中以更新改变的记录，这样每个文件记录和其它文件的记录可以分开更新和并行更新。
本发明与现有技术相比具有一些明显的优点。通过使用单独处理器更新多个文件，两个冗余的数据库可以快速地进行同步。
为了更充分地理解本发明及其优点，可以参照以下结合附图所作的说明。在这些附图中
图1a为具有一个可随容量增大增添SCP(服务控制点)的AIN服务网的电话系统的方框图；图1b为例示在服务管理系统(SMS)、服务控制点(SCP)和它的对偶SCP与和用户电话设备进行无线通信的基站(BS)之间的关系的简化方框图；图1c为接至多个SCP对的各种装置的简化方框图；图2为按本发明构成的服务控制点(SCP)的方框图；图3为按本发明构成的SCP的详细方框图；图3A为按本发明进行文件分配和由于IPU故障而进行再分配的详细方框图；图4为平台管理器(PM)数据库管理器的对象图；图5为应用处理器组(APG)数据库管理器的对象图；图6为智能处理器单元(IPU)数据库管理器的对象图；图7为APG数据库管理器初始化过程的示范流程图；图8为IPU数据库管理器初始化过程的示范流程图；图9为PM从备用转为在用工作状态的过程的示范流程图；图10为处理IPU故障的过程的示范流程图；图11为IPU增添文件系统的过程的示范流程图12为从IPU除去文件系统的过程的示范流程图；图13为负荷平衡请求过程的示范流程图；图14为负荷平衡过程的示范流程图；图15为数据库重新配置过程的示范流程图；图16为共享存储器和磁盘同步过程的示范流程图；图17为同步一个SCP对的相应SCP的数据库的过程的示范流程图；图18为用于同步相应SCP数据库的IPU同步过程的示范流程图；图19为用于同步相应SCP数据库的IPU更新过程的示范流程图；图20例示了集中全局标题解释(CGTT)表的格式；图21和22例示了根据CGTT修改全局标题解释表的流程图；图23a至23e例示了在SCP之间信息迁移的过程。
下面将结合图1-23充分说明本发明，在这些图中同样的部分用同样的标号标示。
图1a例示了具有PHS能力的电话系统10的方框图。一系列诸如电话机、PBX(专用小交换机)、调制解调器和数字装置之类的装置14接到PSTN(公众电话交换网)12上。此外，还有一系列PHS基站16也接到PSTN12上。PHS手机(或诸如数字调制解调器之类的其他装置)18与连到PSTN 12上的其它装置通过利用无线通信的基站16进行通信。
AIN(高级智能网)系统22包括一个或多个接到PSTN12上的STP(信号传送点)24。这些STP相互连接，并且接到多个SCP(服务控制点)对26上。每个SCP对26包括两个全冗余SCP26a和26b，这将在下面详细说明。STP 24还接至与SCP对26连接的NCC(网络控制中心)28、SMS(服务管理系统)30和VMS(语音邮件系统)32。NCC28包括一个CGTT(集中全局标题表)34。
在工作中，由一个PHS装置18发起或终接的呼叫要利用AIN电路系统22来获取信息。除了其他信息，SCP 26提供一个数据库，其中所存储的信息包括与各移动装置18关联的当前基站16的暂态数据、预订语音信箱选项的各移动装置18的语音邮件信息、诸如呼叫闭锁之类的其他选项以及计费信息。在有一个呼叫发至或来自一个移动装置18时，就要向SCP查询，以确定有关信息。
例如，有一个呼叫从一个PSN(电话系统号码)为050-888-7777的第一移动装置18要发至一个PSN为050-888-6666的第二移动装置。首先，这两个装置由各自PSN中的一定数字标识为是移动装置(在本情况为PHS)。在本例中，假设“050”标识PHS装置，而“888”标识PHS提供方(当然可采用任何组合的号码)。因此，为了完成这个呼叫，PSTN必需确定当前是哪个基站16与接收装置关联。第二，如果有与呼叫或接收装置关联的语音邮件，那么这信息就应该转给装置(例如使电话机上的指示灯亮，以通知用户有语音邮件待取)。第三，呼叫或接收装置18可以预订一个或多个限制选项，防止进行或接收某些呼叫。因此，如果呼叫装置18在进行长途呼叫是受限制的，那么在接收装置是与一个需要长途呼叫的基站关联的情况下，这个呼叫将不能完成(并通知呼叫方)。或者，接收装置可以列出不愿从哪些呼叫装置接收呼叫的PSN。如果是这种情况，这个呼叫就会被闭锁(并通知呼叫方)。第四，其中一个装置18可能处在无业务区或可能已撤消了业务，在这种情况下，呼叫不能完成。
虽然上述事务处理是结合从一个第一PHS装置18至一个第二PHS装置18的呼叫说明的，然而每当有一个呼叫涉及一个PHS装置18，无论是作为呼叫方还是接收方，即使另一方不是一个PHS装置，也必需对至少一个SCP26进行查询。
由于SCP 26在任何涉及一个PHS装置18的呼叫中都要卷入，因此它们的数据库就会迅速增大。此外，随着数据库的增大，SCP服务的速度不能有显著降低。而且，各个SCP 26内的数据必需得到保护，防止由于单个SCP的故障而引起的任何损失。
在图1a所示的实施例中，各对SCP 26都是全冗余的，也就是说，每对中的SCP 26a和26b具有完全相同的数据库(短期会有所不同，这由下面要说明的同步处理解决)。每个SCP对26分管一个装置子集。在这里所说明的优选实施例中，每个SCP对26分管PHS系统的PSN内的一个或多个范围。例如，第一SCP对26分管888-0000至888-3333的PSN，而第二对可与888-3334至888-7777关联(在实际实施中，与每个SCP对关联的PSN的数量可以大得多)。CGTT34维护一个规定每个SCP对的负责范围的数据库。这信息在需要时分配给AIN系统内的其他装置。
在与一个SCP对26关联的PSN范围内，这个对26内的每个SCP都有一个冗余数据库。然而，为了提高效率，SCP 26a和26b各自分管对一半查询负荷的响应。如果一个SCP 26a或26成为不能工作，另一个SCP(对偶SCP)就能响应全部负荷，直至发生故障的SCP返回服务的时候。因此，对于每个PSN，有一个“主”SCP规定为在两个SCP都运行时将对这个PSN的查询进行响应的SCP。在工作期间，SCP 26a或26b之间的数据可能会失去同步。例如，在一个装置在基站之间改变时，这信息(在这里称为“暂态”信息)将报告给这对中指定为主SCP的那个SCP。类似，语音邮件信息将从VMS 32报告给这对中负责受影响装置的主SCP。为了维护数据库的冗余性，这两个SCP将交换暂态和语音信息，如以后结合图17-19所述。
图1a的AIN系统22利用多个SCP对26。每个SCP对26负责提供一部分用户数据库的服务。CGTT通过将一个或多个范围的电话号码与一个SCP对关联规定了哪些SCP对26负责哪些用户。由于每个SCP对26分管一部分用户数据库而不是整个用户数据库，因此SCP的响应时间大大增加。
此外，如下面要详细说明的那样，如果需要，AIN系统可以增添一些SCP对26。因此，随着用户数据库的增大，AIN的服务可以继续下去，通过增添SCP对和将用户记录迁移到新的SCP对及时进行响应，如下面结合图23a-e所述。增添新的SCP对可以在不中断服务和没有任何数据损失的情况下实现。
SCP 26可以通过专用的点对点x.25链路接至SMS 30。一对中的SCP 26a和26b通常分别配置在不同的市，可以通过某个通信链路，如点到点广域网(WAN)链路或媒体访问控制(MAC)桥，连接在一起。
在SMS 30、SCP 26和基站16之间发送的某些典型的消息示于图1b。在有一个使用便携手机18的新用户加入到通信网10时，SMS 30就颁发一个INSERT(插入)命令给如CGTT 34规定的适当的对中的SCP 26a和26b双方，以增添一个新的唯一个人用户号码或电话号码。一个不再希望获得无线服务的用户可以用类似的方式用发给SCP 26a和26b双方的DELETE(删除)消息删去。SMS 30还可以向SCP 26a和26b双方发送UPDATE(更新)消息，以提供诸如增添一项新的业务之类的信息。这些消息是静态数据更新的一些例子。
在一个便携手机漫游时，它的位置可以从一个基站的覆盖区域改变到另一个基站的覆盖区域。基站号码的更新由当前覆盖这个便携手机的基站16提供给主SCP 16，使得对于这个便携手机的入局呼叫可以传送给这个基站。此外，对于另一个便携手机的出局呼叫可以通过对这个受话便携手机的位置登记的主SCP进行查询开始。在SCP 26a和26b之间周期性地和/或在有要求时执行一个数据库同步过程，用这个暂态数据更新SCP的各自拷贝。
图1c例示了各种装置与多个各标为SCP1、SCP2和SCPn的SCP对26连接的方框图。每一对都与SMS 30、VMS 32和BS 16(通过STP24)连接。装置SMS 30、VMS 32和STP 24每个都含有一个由NCC 28更新的全局标题表(GTT)。GTT按照给定号码将关联的装置指向适当的SCP对26。因此，例如，如果VMS 32具有与号码050-888-7777关联的语音邮件数据。它就参照它的内部GTT，确定这些SCP对26中哪对维护050-888-7777所属数据库。然后，VMS 32根据它的GTT内的信息开始与适当的SCP对26进行通信对话。如下面要详细说明的那样，在多个SCP对之间分配SCP数据库的能力保证了可灵活地配置电话系统的容量。例如，如果每个SCP对具有处理500万个用户的容量，当电话系统10的容量达到500万个用户时，就可以如下面将要说明的那样增添一个附加的SCP对26。可以按需要来增添附加的SCP对。
图2给出了按本发明构成的一个与它的对偶SCP 26a连接的SCP26b的较为详细的方框图。每个SCP包括一个在用平台管理器(PM)34和一个备用平台管理器36，通过总线、局域网(LAN)或局域网集线器50与个数预定的应用处理器组(APG1-APGm)38-42连接。为了提供较大的网络整体性和容错性，可以用双重LAN或集线器来连接这些PM和APG，以提供冗余。APG 38-42每个都包括多个智能处理器单元(IPU1-IPUn)44-48。可以将一个或多个IPU配置成备用IPU，在其他IPU出现故障时可以挂到线路上。主机51接在各STP 24和这个SCP的IPU之间。一个在下面将要说明的路由表将查询指向正确的IPU。路由表由PM管理，分配给宿主51，和分配给各IPU。通过将路由表分配给宿主51和IPU，来自STP的查询就能迅速地传给正确的IPU。
如图3可见，平台管理器34和36每个都包括一个PM数据库管理器过程52和每个APG一个的APG数据库管理器过程54。IPU1-n60-64每个也都有一个IPU数据库管理器过程66-70和驻留在其中的共享存储器72-76。共享存储器72-76可以用包括随机存取存储器(RAM)在内的任何高速存储装置实现，可接受所有驻留在IPU内的过程访问。一对镜像存储器存储设备80和82与各个IPU 60-64连接，可以同时接收IPU 60-64的所有访问。同时文件存取可以通过用多端口媒体实现存储器存储设备80和82或通过对每个存储设备80和82以多启动器模拟运行IPU 60-64来实现。存储器存储设备80和82可以用固态磁盘或其他适当的存储媒体实现。在多启动器模式，存储器存储设备80和82可以各通过一个独立的总线或小计算机系统接口(SCSI)与IPU 60-64连接。以这种方式结构和配置，IPU 60-64中任何一个IPU都可访问这两个存储器存储设备80和82。
存储器存储设备80和82可以划分为一些预定的部分或文件系统，其中的X个用来存储用户文件。便携手机用户数据库包括数量固定的文件，存储在SCP 30的APG 38-42的镜像磁盘上，每个APG有一对镜像磁盘。每个用户文件列入整个用户数据库中的一个用户记录子集。每个用户文件指定存储在SCP的一对专用镜像磁盘内，使得每个APG分管用户数据库的一个互异子集。如图3所示，可以存储在一对磁盘上的文件的数量为Y。磁盘对互为镜像，因此在这两个磁盘都工作时其中的内容始终相同。
为了访问给定磁盘对上的一个具体文件，含有这个文件的文件系统必需装到APG中一个IPU上的目录内，一个文件系统一次只能装到一个IPU上。在一个文件系统装到一个IPU上时，它的文件就映射入这个IPU的共享存储器。在典型的操作期间，每个文件系统指配给一个特定的IPU，安装和映射入这个IPU的共享存储器，使得其中所含的数据很容易由在这个IPU中运行的所有过程访问。含有用户位置信息等的暂态数据更新只对IPU的共享存储器进行，而诸如用户的增添、删除或业务的修改之类的静态数据更新立即写到磁盘以及在共享存储器内加以更新。根据进行情况，映射到一个IPU的共享存储器中的文件(包括暂态数据更新)的容量可配置段同时写到镜像磁盘，更新其中所含的拷贝。这种进行性写入操作的结果是每隔一段可配置的时间不断通过所映射的共享存储器周转文件，使得更新磁盘拷贝不需要过分的输入/输出操作或CPU操作高峰。因此，通过不断将文件的小段写到磁盘，避免了可能出现的间歇性服务延迟。
图3A示出了APG内各IPU的文件分配和再分配的示范方框图。如果磁盘80和82各有六个部分或文件系统FS1-FS6，例如，每个文件系统可以有文件F1-F14构成的集合中的两个或三个文件。在这些文件的初始分配中，IPU160可以装FS1和将文件F1-F3映射到它的共享存储器；IPU262可以装FS2和将文件F4-F6映射到它的共享存储器；IPU363可以装FS3和FS4和将文件F7-F10映射到它的共享存储器；以及IPU464可以装FS5和FS6和将文件F11-F14映射到它的共享存储器。每个IPU于是只可以访问它装的文件系统中的文件内的用户记录。作为一个整体，APG为分配给它的所有文件内的所有用户服务。以后，如果IPU363不能工作，文件系统FS3和FS4中的文件F7-F10就重新分配给其余IPU中的一个或几个IPU。在图3A所示的例子中，FS3和FS4中的文件重新分配给IPU160和IPU262，从而使得为信息存储在文件系统FS3和FS4内的那些用户的服务可以连续而不致中断。因此，在有IPU投入或退出服务时，文件分配就重新配置。
作为另一些例子，对于两个APG、每个APG的每个磁盘用六个文件系统、共有32个用户文件的配置可以具有如下方式的一种典型文件分配方案
表I
可见，32个用户信息文件均匀地分配给这两个APG，各负责一半的负荷，即16个文件，分别驻留在各自的镜像磁盘上。如果每个APG各有三个在用IPU，那么每个IPU可以各分管两个文件系统，安装和映射入各自的共享存储器。如果每个APG有四个IPU，那么其中的两个可以各分管两个文件系统，而其余两个可以各分管一个文件系统。在每个APG内也可以包括一个或多个备用IPU，保持在备用状态，直至有IPU发生故障时。
个人用户号码(PSN)或呼叫号码用来确定存储有关这个帐户的信息的文件的文件序号。例如，在以上的例子中，数据库划分成32个文件，对个人用户号码所选数字进行模(MOD)32操作，得出用户文件附标。对于大多数应用来说，在MOD操作中可以用个人用户号码的最后四位或五位数字来得出文件附标。
例如，为了支持300-400万用户，用户信息数据库可以分为128个文件。如果用五个APG支持系统，一种示范性的文件分配情况如下表II
在以上数据库分为128个文库的例子中，可以对个人用户号码的最后四位或五位数字执行模128操作来得出这个呼叫号码的用户信息所在文件的文件附标。因此，可以很快确定有关一个特定用户的信息在数据库内的位置。
应注意的是缺省或初始文件分配以后可以根据负荷和业务量情况加以修改。每个IPU维护有关它接受查询的次数的统计资料，并且报告这统计资料。于是文件分配可以依此加以修改，使得任何IPU不致过分工作。为达到更为均匀分配的负荷平衡的情况将在以下说明。
因此，PM数据库管理器52主要负责SCP 30内各IPU的数据库负荷平衡，而APG数据库管理器54主要负责对加到各自APG内的各IPU的数据库负荷的管理。IPU具有至少三个服务状态IN_SERVICE、OS_MIN和OUT_OF_SERVICE。PM数据库管理器52、APG数据库管理器54和IPU数据库管理器60-70协同从OS_MIN和OUT_OF_SERVICE的IPU卸下文件系统，将这些文件系统重新分配给其余IN_SERVICE的IPU。也可以在文件系统之间移动文件，以使每个IPU和APG承受的负荷分配更加均匀。有关这些过程的工作状态的情况可参见共同未决美国专利申请No.08/526,953“多站分配的对象管理环境的系统和方法”(“System and Method for Multi-SiteDistributed Object Management Environment”)，该申请在此列为引用参考。
参见图4，PM数据库管理器52可以包括一个数据库配置表90和一个IPU表92，用来处理数据库配置。数据库配置表90保存着整个数据库内每个文件系统的信息，包括1.文件系统名称2.缺省IPU名称3.当前IPU名称4.APG ID5.文件系统内的文件数6.文件系统内的文件映象缺省IPU是文件系统最初所分配给的那个IPU；当前IPU是由于数据库重新配置和/或负荷平衡的作用文件系统当前所装到的那个IPU。IPU表92保存着系统内每个IPU的信息，可以包括1.IPU名称2.APG ID3.IPU上当前文件数4.IPU上当前文件系统数第三个表，路由表94，也由PM数据库管理器过程52维护。路由表94含有数据库内每个文件的信息。它用来为与PM连接的宿主(见图2)，如一个消息传送网(MTN)，提供路由选择信息，使得宿主可以根据每个IPU的数据库负荷将查询指向适当的IPU。路由表可以包括1.用户文件附标2.文件当前所在的IPU的名称3.IPU ID所有这三个表都是持久和有拷贝的，如本技术领域内所知。所有的这些表的更新和拷贝都由在此不作详细说明的另一个子系统处理。
PM数据库管理器过程52包括若干个实现数据库管理任务的对象。下面是这些对象功能的简短说明，而详细情况将结合图7-16讨论。如图4所示，PM数据库处理器96执行各IPU之间的负荷平衡，以及处理来自宿主的征集路由选择信息的请求。路由表访问程序100和数据库配置表访问程序102是驻留在PM数据库管理器52内的对象，分别控制对路由表94和数据库配置表90的访问。负荷平衡处理器104是一个含有对文件和文件系统进行负荷平衡的处理方法的对象。共享存储器数组106是一个由在共享存储器72-76(图3)内的一些布尔值构成的数组，用来同步PM数据库管理器52和APG数据库管理器54之间的负荷平衡和重新配置。
图5示出了APG数据库管理器54的一种典型组成，它可以包括为APG数据库管理器54提供一个与IPU数据库管理器66-70的接口和其他过程的APG数据库处理器110，还提供一些在IPU撤除和恢复时调用的方法。数据库路由控制程序112含有重新分配文件系统的各种处理方法，用来处理IPU恢复、撤除和审核的不同情况。它还含有有关APG本身的信息。IPU信息表114是一个保存着专用于APG内的IPU的信息的表，包括当前IPU服务状态。与PM数据库管理器52类似，APG数据库管理器54也包括数据库配置表90、数据库配置表访问程序116、路由表访问程序116、路由表94和共享存储器数组120，以控制对各表内数据的访问。
参见图6，IPU数据库管理器66可以包括若干个对象，诸如提供一个与APG数据库管理器的接口和在IPU节点60-64(图3)上执行的应用过程的IPU数据处理器130。IPU数据库管理器66间接也负责在IPU上装、卸文件系统以及将数据库文件映射到共享存储器72(图3)和从共享存储器72对数据文件解映射。过程66的对象130还将新的数据库负荷信息通知节点上的应用过程。
组文件处理器132是一个负责周期性地使在共享存储器72(图3)内的数据库文件同步到镜象磁盘80和82(图3)的对象。IPU磁盘管理器对象134由IPU数据库处理器130例示，负责文件系统的装、卸。数据库文件映射器对象136负责将文件映射到共享存储器和从共享存储器对文件解映射。在IPU节点上每个文件有一个数据库文件映射器。用户数据库访问对象138负责提供在远程节点访问由本IPU处理的部分数据库的过程。远程节点包括例如在对偶SCP 26a(图2)上驻留的节点。
分布冗余数据库的工作情况下面将结合图7-19的流程图和方框图详细说明。在讨论到一些专用结构时，如果必要的话可以参考图2-6。
APG数据库管理器52首先例示对于SCP内每个APG的一个APG数据库管理器54。图7为在方框160开始的APG数据库管理器初始化的示范过程流程。首先，例示一个APG数据库处理器对象110，如方框162中所示。在方框164，APG数据库处理器110例示数据库路由控制程序112、数据库配置表访问程序116和IPU信息表114。然后，数据库路由控制对象112例示和初始化在APG数据库管理器52内所有的表90-94，如方框166和168所示。如果PM在用，如方框170所确定的那样，则在方框172由APG数据库处理器96执行对处于IN_SERVICE状态的IPU的审核。这个审核得出受审IPU的数据库负荷，用来更新这些表，如方框174中所示。接着在方框176和178，APG数据库管理器54向PM节点过程登记后，初始化过程结束。登记这个行动向其他过程揭示这个对象的情况，使得其他过程可以与之通信。
图8例示了IPU数据库管理器初始化190的示范过程流程。在方框192，例示IPU数据库处理器130、组文件处理器132和用户数据库访问138这些对象的实例。在方框194，初始化一个用于共享存储器对磁盘更新的同步定时器。然后，IPU数据库处理器130向APG数据库处理器110请求它的数据库负荷份额，如方框196中所示。在响应中，APG数据库管理器54从数据库配置表和IPU表查找出有关文件系统和提出请求的IPU的信息，利用这信息根据处在IN_SERVICE状态的IPU数和业务量情况确定处在IN_SERVICE状态的IPU的数据库负荷，如方框198和200中所示。在方框202，为提出请求的IPU分配数据库负荷。然后，IPU数据库管理器66向PM节点过程登记，如方框204中所示。在方框206，IPU数据库管理器接受分配的负荷。于是，属于数据库中分配给这个IPU的部分的文件系统就加给或装到这个IPU，如方框208中所示。初始化过程随即在方框210结束。
图9示出了在一个平台管理器34从备用模式转移到在用模式时在APG数据库管理器中的过程流程，该流程在方框230开始。所有影响这个平台管理器的APG数据库管理器54都对它们的IPU数据库负荷进行审核，如方框232中所示。然后，每个APG的数据库路由控制程序112初始化所有的表，包括数据库配置表90、路由表94和IPU表92。于是，APG数据库处理器110得到一个列有它的APG的处于IN_SERVICE状态的IPU的表，向每个处于IN_SERVICE状态的IPU查询它的数据库负荷，如方框236和238中所示。这些表用处于IN_SERVICE状态的IPU所提供的信息进行重构和更新，如方框240中所示。还根据这审核信息将未分配的文件系统分配给那些负荷轻的处在IN_SERVICE状态的IPU，而为没有分配到负荷的IPU分配它们的缺省数据库负荷，如方框242和244中所示。新的数据库负荷分配在路由表94内产生新的路由选择信息，由APG数据库处理器110提供给宿主。备用到在用的转移过程在方框248。
IPU故障由图10所示在方框250开始的过程流程处理。在方框252，APG数据库管理器54从PM节点过程接收到一个IPU有故障的通知。为每个有故障的IPU设置一个定时器，如方框254中所示。如果APG数据库管理器54在定时器计满所定时间前接收到一个IPUIN_SERVICE(IPU处于服务状态)通知，如方框256中所确定的那样，那么不需要进行任何处理。然而，如果没有接收到这样的通知，并且如果接收到一个IPU退出通知或如果定时器计满所定时间，如方框258中所示，就将由有故障的IPU承担的负荷重新分配和发送给其余处在IN_SERVICE状态的IPU，如方框260和262中所示。如果现在又有任何处在IN_SERVICE状态的IPU发生故障，如方框264中所确定的那样，过程就转至方框260，再次将数据库负荷重新分配给其余处在IN_SERVICE状态的IPU。如果没有其他IPU发生故障，如方框264中所确定的那样，数据库路由控制程序112就从路由表94中提取更新的路由选择信息，然后由APG数据库处理器将这信息提供给宿主，如方框266和268中所示。过程在方框270结束。
为了将文件系统加给一个IPU，可以利用图11所示在方框280开始的示范过程流程。IPU磁盘管理器134安装需加给适当IPU的文件系统，如方框282中所示。所装文件系统内的文件由组文件处理器132映射至共享存储器，如方框284中所示。然后，用户数据库访问程序138接至共享存储器文件，如方框286中所示。由于这些文件中的记录在本优选实施例中是由一个红-黑树(Red-Black Tree)数据结构中的访问指针组织和可搜索的，因此如果必要的话可校正或重建这个红-黑树。红-黑树是一种有利于快速搜索的平衡树数据结构，通过搜索红-黑树的节点可以确定一个文件内的所有记录的位置。模操作得出文件附标，再通过搜索适当的红-黑树共享存储器文件，就可以访问具体的记录。需指出的是，也可以采用其他数据结构，这并不背离本发明的精神。此后，用户数据库访问程序138将有关新IPU文件装载的消息发送给所有有关应用程序，如方框290中所示。过程于是在方框292结束。
文件系统的撤消也由IPU数据库处理器130处理，如图12所示，在方框300开始。用户数据库访问程序138首先从共享存储器卸下文件，再从共享存储器卸下应用程序，如方框302和304中所示。然后，组文件处理器132解除原分配的共享存储器段，IPU磁盘管理器134卸下所述文件系统，如方框306和308中所示。文件系统撤消过程在方框310结束。
前面已指出，数据库负荷可以在一个APG内的各IPU之间加以平衡，从而使查询业务量分配均匀。此外，由于IPU可能发生故障或进入一个不工作状态(OS_MIN或OUT_OF_SERVICE)，数据库负荷可能需要重新配置或重新分配给其余处在IN_SERVICE的IPU为了在PM数据库管理器52和APG数据库管理器54之间同步负荷平衡和数据库重新配置，例示共享存储器数组120的实例，一个是重新配置数组，为一个在共享存储器内的布尔数据，另一个是负荷平衡标志，为一个也是保存在共享存储器内的布尔标志。如果数据库在一个具体APG内由于一个或多个IPU退出或重新进入服务而正要重新配置，适当的APG数据库管理器54就将重新配置数组内它的相应标志置位。一旦数据库重新配置完成，APG数据库管理器54就使重新配置数组内它的标志复位。类似，在要执行负荷平衡时，由PM数据库管理器52将负荷平衡标志置位。
图13-15为说明同步负荷平衡和数据库重新配置的过程的流程图。在图13中，示出了一个示范的负荷平衡请求过程320。负荷平衡可以由职业人员通过职业屏幕界面、PM数据库管理器52或APG管理器54提出请求。首先检查重新配置数组，确定对于有关APG的重新配置标志是否置位，如方框322中所示。如果重新配置标志置位，就在方框324直接放弃负荷平衡，可以稍后再试。由于负荷平衡并不是一个紧迫的操作，因此并不要求负荷平衡等待重新配置结束，虽然也可以形成这样的机制。如果重新配置标志没有置位，就将负荷平衡标志置位，如方框326所示，执行负荷平衡，如方框328所示。
图14示范性地示出了在方框340开始的负荷平衡的流程图。在方框342，接收到一个将一个或几个指定的文件系统移动到一个或几个指定的IPU的请求。这请求可以是由一个职业人员、PM或APG管理器审视当前负荷分布和业务量情况时产生的。在方框344，数据库路由控制器112对表作必要的改变，反映经平衡的负荷分布。新的数据库负荷由PM数据库处理器96提供给源IPU和目的IPU双方，如方框346中所示。如果此时检测到源IPU和/或目的IPU有故障，如方框348中所示，就在方框354直接终止负荷平衡。否则，数据库路由控制器98从路由表94提取新的路由选择信息送至宿主，如方框350和352所示。
图15示出了开始数据库重新配置的过程流程，在方框360开始。如果需要重新配置数据库，就将对于这个APG的重新配置标志置位，如方框362中所示。接着，将一个再试计数器或定时器(RETRY_CNT)复位为零，如方框364所示。然后，执行进入一个循环，重新配置过程等待负荷平衡完成，如果它在进行的话。首先检查再试计数器，确定它是否已达到预定上限，例如180，如方框368所示。如果已达到上限，确定PM节点是否已发生故障和它的状态是否降为OS_MIN状态。如果再试计数值还没有达到预定上限，就检查负荷平衡标志，看它是否已置位，如方框370中所示。如果它没有置位，就继续执行数据库重新配置。否则，将再试计数器加1，允许过了一段预定时间，例如1秒钟，再返回循环开始的方框366。
在分布冗余数据库10内有几个数据同步过程发生。存储在每个IPU共享存储器内的数据对两个镜像磁盘同步，而在每个SCP的数据库内的所有经修改的暂态数据提供给它的对偶SCP。
图16为将IPU的共享存储器72-76(图3)内的数据对镜象磁盘80和82(图3)同步的示范过程流程380。在方框382，检查同步时钟，确定它是否已计满所定时间。注意，这个定时器是在IPU数据管理器初始化期间初始化(见图8的方框194)的。如果同步定时器还没有计满所定时间，可以过一段预定时间再检查，直至同步定时间计满所定时间。同步定时器计满所定时间指示这时候是将共享存储器内的一个文件的一部分或一块拷贝给镜像磁盘的时间，如方框384中所示。然后使同步定时器复位，如方框386中所示，再返回执行方框382。在下次同步定时器计满所定时间时，将这文件的下一部分拷贝给磁盘。在一个文件整个都拷贝完时，将下个文件拷贝给磁盘。用这种方式将每个IPU的共享存储器内的所有文件都拷贝给磁盘。由于每个IPU分配到的是一个不同的文件系统集合，因此这些IPU可以用多启动模式并行地对磁盘“同步”，各个操作不会相互干扰。要注意的是，这种对磁盘的数据“同步”过程主要是用诸如用户当前位置之类的暂态数据更新磁盘。诸如增添或删除新用户、服务选项更新和用户优先权数据之类的静态数据通常在写入共享存储器的同时立即写入镜像磁盘。
图17例示了使一对SCP对26的SCP 26a和SCP 26b含有相同信息的SCP数据库之间的同步的简化方框图。作为例子，假设SCP 26a和26b各包括三个APG(如图2所示)，这三个APG每个有四个IPU，因此每个SCP总共有12个IPU。与一个SCP对26关联的用户数据库分为128个单独的文件，所以每个APG负责42或43个文件。每个APG内的四个IPU分别负责7-43个文件，取决于有多少IPU在用和各IPU之间的文件分配情况(见图3和3A)。每个IPU可以有多个CPU处理器，以提高性能。
在工作中，文件F1-F128各由独立的一些同步过程处理。对于每个文件，有一个IPUsync过程用来确定哪些记录具有已改变的暂态信息和/或语音邮件，并将这些已改变的记录存入一个同步缓存器。对于每个记录都有两个标志，分别用来标明从IPUsync过程上次检查这个记录以后暂态信息和语音邮件信息是否有了改变。在同步缓存器充满或这个文件搜索完时，IPUsync将同步缓存器转给它的对偶SCP(SCP 26a是SCP 26b的对偶SCP，SCP 26b是SCP 26a的对偶SCP)的相应IPU。此外，对于每个文件，有一个IPUupd过程从它的对偶SCP的相应IPU接过同步缓存器。从对偶SCP接过了同步缓存器后，IPUupd过程更新它的关联文件内的记录。
在每个IPU中，有两个过程，IPUsyncMain和IPUupdMain，负责激活和管理与这个IPU关联的各文件的IPUsync和IPUupd过程。
在另一个实施例中，对于每个文件执行四个独立的过程IPUsyncV(对文件进行搜索，确定语音邮件已改变的记录，并将这些已改变的记录存入一个语音邮件同步缓存器)，IPUsyncT(对文件进行搜索，确定暂态信息已改变的记录，并将这些已改变的记录存入一个暂态信息同步缓存器)，IPUupdV(根据语音邮件同步缓存器内的记录更新对偶SCP内的记录)，以及IPUupdT(根据暂态信息同步缓存器内的记录更新对偶SCP内的记录)。
图18为说明IPUsync过程情况的流程图，假设IPUsync过程对暂态信息或语音邮件信息已改变的记录进行搜索。在方框420开始，首先是关联文件的第一个记录。每个记录在判决方框422受到检查，确定其中的暂态信息或语音邮件信息是否已改变。如果信息已改变，就在方框424将这个记录写入同步缓存器。如果这个记录内的信息没有改变，过程就在判决方框426确定是否已到达文件的结束处或者在判决方框428确定缓存器是否充满。如果这两个条件有一个满足，就将缓存器转给对偶SCP的IPUupd过程。如果没有一个条件满足，就在方框432检查下一个记录。
在对每个文件的暂态信息和语音邮件信息分别执行IPUsync过程的另一个实施例中，图18的基本流程仍然可用，只是在判决方框422对于IPUsyncT过程是只确定暂态数据是否有改变，而对于IPUsyncV过程是只确定语音邮件数据是否有改变。
图19例示了说明IPUupd过程情况的流程图。在方框442，从对偶SCP的IPUsync过程接过同步缓存器。在方框444、446、448和450用同步缓存器中的每个记录对关联文件进行更新。
如在图18的情况下，在对每个文件的暂态信息和语音邮件信息分别执行IPUupd的另一个实施例中，图19的基本流程仍可使用，只是在方框442对于IPUupdT过程接过的是暂态同步缓存器，而对于IPUupdV过程接过的是语音邮件同步缓存器。
图20例示了集中全局标题解释(CGTT)表34。CGTT表34将各个PSN范围与负责支持相应范围内的用户的SCP对26联系起来。CTGG表34内的信息用来支持AIN系统22内需要这样的信息的子系统，即各个SCP 26、各个STP 24、SMS 30和VMS 32。SMS需要用这信息来确定在增添、删除和修改用户帐户信息时应将信息发送给哪个或哪些SCP对26。STP 24需要用CGTT表34内的信息将查询送至适当的SCP对26。VMS 32需要用CGTT表34内的信息将语音信箱状态信息发送给适当的SCP对26。最后，SCP对26需要用CGTT表34内的信息确定与电话连接的另一方关联的SCP。
参见图20，CGTT表具有n个表目(或记录)36，其中n在典型实施情况下可以是1000(或无限制)。对于每个表目，有五字段。第一字段38标明对于在这个表目规定范围内PSN的数字的位数。这一字段用于电话系统不用固定长度的电话号码的地方，如日本和其他一些国家。第二字段标明这个范围内的开始PSN，而第三字段标明这个范围内的最后PSN。第四字段标明一个与由第二和第三字段规定的范围内的PSN关联的第一SCP对。第五字段标明一个与由第二和第三字段规定的范围内的PSN关联的第二SCP对26。第二SCP对26在数据在SCP对之间迁移期间将信息写入两个SCP对时使用，这将在下面详细说明。
在第四和第五字段内各有九个子字段。第一子字段规定解释类型。如果必要的话，这可以用来标明不同的网络类型。第二子字段标明编号方案的号码规划，这对于不同的提供方可以是不同的。第三子字段规定后备模式，可以是对于第一SCP的，第一和第二SCP之间的负荷共享，或者在第一SCP不工作时可以是对于第二SCP的。第四、第五和第六子字段分别标明STP是否为最终STP、主SCP的名称和主SCP内的目的应用。第七、第八和第九子字段分别标明对于后备路径的同样信息。
在工作中，CGTT表34可用来改变PSN在不同的SCP对之间的分配。重新分配可以在增添一个新的SCP对或者要将一些PSN从一个过荷SCP对重新分配给一个欠荷SCP对时进行。
将一些新的GTT分配给AIN内不同子系统可以用两种方法执行。首先，在NCC内为子系统准备一个新的表发送给子系统。在子系统接收到这个新的GTT时，用这个新的GTT代替老的GTT。
然而，在有些情况下这种直接文件替换可能不得不中断服务。在这种情况下，编辑GTT的现有编辑程序可以结合CGTT表34内的数据加以使用。首先，NCC接收子系统内的GTT的一个拷贝。然后，将这个拷贝与CGTT表34内的当前信息进行比较，得出GTT与CGTT之间的差别。用这些差别产生一些控制GTT的编辑程序的命令。这些命令作为一个批文件发送给子系统运行，模拟由一个用户输入的进行这些改变的命令，而不是发送新的表。然而，在优选实施例中，这些命令由NCC通过对两个数据库的比较自动产生，下载给子系统，稍加或不加人工干预执行。
图21和22为分别例示两种实现子系统内部GTT改变的方法的流程图。在图21中示出了说明数据库替换方法的流程图。在方框460，用来自CGTT 34的信息为子系统产生一个GTT数据库。在方框462，子系统的这个新GTT从NCC下载给子系统。在方框464，子系统当前正在使用的GTT用这个新的GTT代替。
图22例示了按照CGTT 34内的信息修改一个子系统内的当前GTT的批文件方法。在方框470，NCC上载子系统内当前使用的GTT。在方框472，来自当前GTT的信息与CGTT 34内的信息进行比较，确定需要对子系统当前GTT进行哪些改变(如有的话)以使信息与CGTT 34一致。在方框474，产生修改当前GTT的命令。典型的命令有ADD<record>、DELETE<record>和MODIFY<record>。在方框476，一个含有这些命令的批文件下载给为这个指定子系统执行GTT编辑程序的计算机。在方框478，批文件由计算机执行，实现对GTT的修改。
图23a-e例示了信息从一个SCP对(SCP1，始发SCP，包括SCP1A和1B)迁移到另一个SCP对(SCP2，终接SCP，包括SCP 2A和2B)的情况。信息从一个SCP对26迁移到另一个SCP对26涉及将与一个范围的PSN相应的记录从SCP 1传送给SCP 2。这个过程可以例如在系统增添一个新的SCP对26时或在移动一些记录以使SCP对26之间负荷均衡时执行。重要的是，信息迁移能动态地进行，而且不影响服务。
第一个迁移步骤结合图23a进行说明。首先，操作员禁止SMS为需从SCP 1转至SCP 2的规定范围内的号码服务(增添、删除和修改用户记录)。由于SMS的服务并不影响电话装置之间的连接，因此这个步骤不影响电话业务。在规定范围内的所有用户记录从SCP 1A拷贝给SCP 2A和拷贝给SCP 2B。始发SCP 1A和1B将使与规定范围内各记录关联的各个传送同步比特(指示相应要传送的记录已修改)复位。SCP2A和2B将使所接收的各记录内的传送同步比特和查询同步比特(如前面结合图17-19对在对偶SCP之间的数据同步所作的说明)复位。在执行记录信息传送的同时，始发SCP 1接收到查询(暂态数据)和语音邮件信息，将使受影响的记录的传送同步比特和查询同步比特置位。查询同步比特在SCP将暂态和语音邮件更新数据发送给它们的对偶(即SCP 1A的对偶是SCP 1B，SCP 1B的对偶是SCP 1A)后复位。
在记录传送完成后，在SCP 1A和2A之间以及SCP 1B和2B之间执行审查。如果有差异，就加以消除，或者重新启动这个过程。
图23b例示了在记录迁移中的下个步骤。在这个步骤中，发布传送同步命令。一旦发布了传送同步命令，SCP 1A就向SCP 2A发送更新信息，而SCP 1B向SCP 2B发送更新信息。发送了更新信息，始发SCP1A或1B将使它的更新记录的传送同步比特复位。允许SCP 2向SCP 1发送更新信息，但由于它不接收暂态或语音邮件查询，因此SCP 2将在此时不向SCP 1发送消息。对偶SCP 1A和1B之间的同步继续执行。也允许SCP 2A和2B之间进行同步。
传送同步命令置位后，在SMS和SCP内的全局GTT按照CGTT 34更新，以便将对在规定范围内的记录的更新发送给SCP 1和SCP 2。因此，来自SMS的任何改变都影响这两个SCP对。
在图23c中，对各STP的GTT进行修改，以将对在规定范围内的记录的所有查询都送至终接SCP对，即SCP 2。传送同步现在在两个方向都可以，因为对于暂态数据SCP 2将更新SCP 1，而对于语音邮件数据SCP 1将更新SCP 2。
在图23d中，对VMS的GTT进行修改，以将对在规定范围内的记录的所有语音邮件查询都送至终接SCP对，即SCP 2。虽然传送同步在两个方向都可以，但实际上始发SCP对，即SCP 1，不再接受任何暂态或语音邮件查询，因此没有更新消息要发送。在SCP 2向SCP 1发送更新信息时，它就将更新记录的传送同步比特复位。应当指出的是，VMS的GTT可以与STP的GTT同时加以修改，以便将语音邮件和暂态查询同时转至SCP 2。
此时，两个SCP对都完全可以对规定范围内的记录进行工作，虽然终接时要继续进行服务。可以对SCP 2对记录的处理情况进行监视，如果处理进行顺利，就可以不同执行传送同步。否则，操作员可以将与STP和VMS关联的各GTT改变成它们先前的设置倒回始发SCP对。
在图23e中，假设不倒回先前的设置，这样就可以按照CGTT 34改变SMS和SCP的GTT，从而指定终接SCP对负责规定范围内的记录。然后，从SCP 1中可以删除已传送的记录。
这里所说明的这种AIN系统与现有技术相比具有一些显著的优点。重要的有，多个SCP提供了对查询的快速响应。随着用户数据库的增大，可以为系统增添一些附加的SCP。记录可以从一个SCP对迁移到另一对，而不需要中断服务，也不会丢失暂态或语音邮件信息。一个集中的GTT提供了一个修改与AIN内各子系统分别关联的这些GTT的高效体制。这些将查询导向正确的SCP的GTT结合将来自宿主51的查询导向正确的IPU提供了一条高效的信号通路，迅速地将查询送至所希望的目的地。高速同步方法的最短的更新等待时间维护各个SCP对内的SCP之间的冗余。
虽然本发明的详细说明是针对一些示范实施例的，但对于熟悉本技术领域的人员来说，这些实施例的种种修改形式以及替换形式都是可设想的。因此，本发明函盖了所有在所附权利要求明确的本发明专利保护范围内的修改形式和替换形式。
权利要求
1.一种用于对冗余服务控制点子系统之间的数据库的存储进行同步的方法，每个服务控制点子系统具有多个处理器，所述方法包括步骤在每个所述服务控制点子系统上存储数据库的一个备份；在每个服务控制点子系统中，将每个所述数据库的备份中的数据组织成相应的文件，每个文件包括多个记录；在每个服务控制点子系统中，将相应的所述文件组分配给所述服务控制点子系统中的处理器；和对于每个服务控制点子系统中的每个文件，标识已改变的记录，并将信息送到其它服务控制点子系统中的相应处理器以更新改变的记录，这样每个文件记录的更新可与其它文件记录的更新分开进行和并行进行。
2.权利要求1的方法，进一步包括步骤对于每个服务控制点子系统中的每个文件从其它服务控制点子系统接收有关与所述文件相关的记录的更新信息，并响应该信息更新所述文件中的记录。
3.权利要求1的方法，其中所述标识已改变的记录的步骤包括用瞬时数据的变化标识记录的步骤。
4.权利要求1的方法，其中所述标记已改变的记录的步骤包括用语音信箱数据的变化标识记录的步骤。
5.权利要求1的方法，其中所述标识已改变的记录的步骤包括标识已改变的记录和在与每个处理器相关的一个或多个存储器的高速缓冲存储器中存储所述改变的记录的步骤。
6.权利要求5的方法，进一步包括步骤将所述改变的记录从一个或多个高速缓冲存储器送到其它服务控制点子系统中的相应处理器。
7.权利要求5的方法，其中所述一个或多个高速缓冲存储器包括一单个用于存储带有瞬时数据变化和语音信箱数据变化的记录的高速缓冲存储器。
8.权利要求5的方法，其中所述一个或多个高速缓冲存储器包括单独的用于存储带有瞬时数据变化的记录和用于存储带有语音信箱数据变化的记录的高速缓冲存储器。
9.一种用于维护数据库的电路系统，包括第一和第二冗余服务控制点子系统用于存储数据库的一个备份，每个服务控制点子系统具有多个处理器；其中，在每个服务控制点子系统中，将每个所述数据库的备份中的数据组织成相应的文件，每个文件包括多个记录；其中，在每个服务控制点子系统中，将所述文件组分配给所述服务控制点子系统中的相应处理器；和对于每个服务控制点子系统中的每个文件，标识已改变的记录，并将信息送到其它服务控制点子系统中的相应处理器以更新改变的记录的电路系统，这样每个文件记录的更新可与其它文件记录的更新分开进行和并行进行。
10.权利要求9的电路系统，进一步包括电路系统对于每个服务控制点子系统中的每个文件从其它服务控制点子系统接收有关与所述文件相关的记录的更新信息，并响应该信息更新所述文件中的记录。
12.权利要求9的电路系统，其中所述标识已改变的记录的电路系统包括用瞬时数据的变化标识记录的电路系统。
13.权利要求9的电路系统，其中所述标记已改变的记录的电路系统包括用语音信箱数据的变化标识记录的电路系统。
14.权利要求9的电路系统，其中所述标识已改变的记录的电路系统包括标识已改变的记录和在与每个处理器相关的一个或多个存储器的高速缓冲存储器中存储所述改变的记录的电路系统。
15.权利要求14的电路系统，进一步包括电路系统将所述改变的记录从一个或多个高速缓冲存储器送到其它服务控制点子系统中的相应处理器。
16.权利要求14的电路系统，其中所述一个或多个高速缓冲存储器包括一单个用于存储带有瞬时数据变化和语音信箱数据变化的记录的高速缓冲存储器。
17.权利要求5的电路系统，其中其中所述一个或多个高速缓冲存储器包括单独的用于存储带有瞬时数据变化的记录和用于存储带有语音信箱数据变化的记录的高速缓冲存储器。
全文摘要
AIN服务网包括多个能加以扩展来满足增长需求的SCP对。这种扩展可以在不中止服务的情况下在各SCP对之间迁移记录来实现,同时又维护了各对之间的冗余。一个集中的GTT用来维护一些在AIN系统内多个子系统之间分配的GTT。由于用户数据库分成多个文件,而每个文件具有一个独立的同步过程,因此每对的对偶SCP之间的同步非常迅速。
文档编号H04M7/06GK1264518SQ98806021
公开日2000年8月23日 申请日期1998年5月4日 优先权日1997年5月9日
发明者托马斯·W·雷基塔, 陈香梅, 扎克·S·古斯里尔 申请人:美国阿尔卡塔尔资源有限合伙公司