|
移动电话综合业务管理系统的关键技术研究(3)
3.2重复话单检查技术
重复话单剔除是计费和账务系统中一个重要处理内容。目前大致有利用数据库唯一索引进
行剔重和利用重单检查文件剔重两种方法。
（1）数据库唯一索引剔重技术
重单检查是根据被服务方号码、呼叫起始日期和呼叫起始时间三个字段进行的。利用数据
库唯一索引技术进行剔重的具体方法是，在详细话单表中对上述三个字段建立唯一索引，在详
细话单进行入库操作时，唯一索引机制对每一条插入的话单记录进行检查，从而保证重单不会
入库。在表中的话单记录较少时，该方法的入库效率还可以。但是，当表中记录数较多时（如
在每个出账周期的后几天），入库速度将严重下降以致于该方法失去了实用意义。
通常的解决方法之一是将详细话单表进行物理分割。例如，在全省集中计费模式下，按照
移动业务区建立详细话单表，减少每张表中的记录数。对某些移动用户数较多的中心城市，还
可以按照MSISDN号码段建立详细话单表。这种方法可在一定程度上提高入库速度，但还是存在
每个出账周期中入库速度越来越慢的现象。这成为严重制约系统处理速度的一个瓶颈。进一步
地，如果对每一个移动业务区每天建立一张详细话单表，这可以彻底解决入库速度问题，但这
又会造成对数据统计和查询等操作的极大不便。
目前，某些数据库系统带有“表分割”选件，该功能可以有效地用于解决上述问题。所谓
“表分割”即是按照某种规则，将物理上的一张“大”表划分为若干张逻辑上的“小”表。数
据库操作可以选择对某个小表进行，也可以选择对整张大表进行。如果计费结算系统的数据库
系统支持“表分割”功能，将大大地简化重单检查工作的复杂性，并能够保证计费系统的处理
性能不受入库速度的影响。具体地说，就是在按照移动业务区或MSISDN号码段建立若干张详细
活单表的基础上，再利用“表分割”选件对每张话单表按照通话日期进行逻辑上的分割。在入
库重单检查时，入库操作是对每天一张的逻辑小表进行的，由于每天的话单数较少，不会出现
入库速度逐渐下降的现象。而数据的查询和统计可在大表上进行，不会额外增加处理的复杂度。
（2）利用重单检查文件进行剔重
如果计费结算系统的数据库系统不支持“表分割”功能，我们建议采用建立重单检查文件
的方式，在话单入库之前进行重单剔除。该方法的具体实现思想如下。
在话单预处理过程中，每天建立一个重单检查比较文件。对每条经过预处理后生成的标准
话单，取出被服务方号码、呼叫起始日期和呼叫起始时间三个字段（字符串），根据呼叫起始
日期打开相应的重单检查文件，利用HASH算法和匹配函数在重单检查文件中进行快速查找，如
果匹配成功，该话单属于重单，则进行相应的重单处理。如果匹配不成功，该活单不是重单，
该话单中上述三个字符率添加到呼叫发生当天的重单检查文件中，用于对后续话单的重单检查。
为了减少HASH算法的匹配查找的时间，重单检查文件也应该越小越好，重单检查文件也应
按照移动业务区或MSISDN号码段建立。此外，为提高处理速度，在内存资源允许的情况下，应
尽可能地将重单检查文件放在内存中运行。实践表明，该方法不依赖数据库所提供的功能，处
理速度快，但是重单检查文件数量较多，除了要占用一部分硬盘存储资源以外，还需要系统有
较大的内存资源。
4电子工单系统的实现技术
（1）业务驱动思想与开放式的电子工单系统
在业务管理系统中，实时开停机和实时用户业务功能更新是其中一个重要组成部分。我们
设计并实现了一种开放式的电子工单系统，在湖北襄樊局的运行结果表明，该系统具有操作时
延短、可靠性高、全自动运行等特点，并且与具体的交换机（HLR）型号以及MML语言无关，取
得了良好的使用效果。
由于交换网的复杂性。交换机制式的多样性等原因，熟悉移动业务管理的人员未必了解交
换机的操作指令，也未必了解哪个号码段的移动用户所属的HLR是哪一个，如果仍然采用参数
驱动方式将会遇到业务管理人员不知如何定义参数表中的参数等问题。我们采用了“业务驱动”
和参数驱动结合的方式设计电子工单系统。所谓业务驱动就是预先为每一种业务定义一种代码，
如新装用户开通操作的业务工单代码定义为“GA”，当业务管理系统中完成“新装用户”受理
后，只要向业务工单表发送代码为“GA”的业务工单及相应信息，如MSISDN号和申请开通的业
务功能种类代码等即可，其余的事均由电子工单系统处理。业务管理人员不必关心交换机可执
行工单的具体格式，也不必知道某一具体业务操作究竟是如何实现的。
电子工单系统须将每条业务工单分解为若干条交换机／HLR可执行的基本工单（分单）。
分解处理是由建立在业务工单表上的触发器完成的。例如，业务管理系统受理了某一用户“功
能变更”业务，内容包括限制国际长权、不可及呼叫转移和来电显示，受理完毕将向业务工单
表发送一条代码为“GG”的业务工单，以及 MSISDN号和业务功能种类代码等。业务工单表中
的插入操作使触发器触发运行，对该业务工单进行分析，并生成三条分单分别存入“分单表”
中。
考虑到移动交换机／ HLR制式较多，各交换机的 MML语言也存在很大的差别。为了能够使
电子工单系统与具体的交换机／ HLR制式无关，实现对交换机／ HLR的开放性，我们设计了基
于“交换机指令表”的参数化交换机指令翻译系统，在程序和分单表中不牵涉到任何交换机的
指令。系统中外建立存放具体交换机指令格式的“交换机指令表”，其内容（交换机指令）是
由专业的交换机维护人员事先输入的。交换机指令表中的参数部分以变量代替，在被调用执行
时再以实际的参数代人。
例如，需要对MSIMSI号后10位为7279000001的用户执行限制呼出呼人操作，对于西门子公
司的D900系列GSM交换机，其交换机操作指令的格式为：MODMSUB：MSIN=727000001，BAOC=OC，
BAIC=IC。存放在交换机指令表中的指令为：MODMSUB：MSIN=＠msin＠，BAOC=OC，BAIC=IC。
运行时，再以分单中的“7279000001”来替换上述指令中的变量部分＠msin＠即可。
（2）电子工单的执行策略
电子工单的执行需要有优先级处理策略。例如，当有多条工单等待向交换机发送时，缴
费复话的工单执行应优先于停话和来电显示等工单的执行，这就要求电子工单系统提供优先
级处理功能。我们在指令表中为每一种交换机指令定义一个优先级别，当多条工单同时等待
处理时，处理程序先执行优先级高的工单。
工单的执行采用优先级划分以后，又会带来一个新的问题。例如，对某一客户已发送了
停话工单，该工单正在等待执行，但此时该客户恰好缴费，系统又发送一条该客户的缴费夏
话工单。如果该客户的停话工单还未来得及执行，由于复话工单优先级高于停话工单，复话
工单先被执行，接着又执行了停话操作，后果是该客户虽然已缴费还是被停话，这显然是不
允许的。解决这一问题有两种方法：
·在触发器中检查
当触发器向执行工单表发送工单时，先判断该客户有无未执行的工单，若有，做相应处
理，如删除停话工单且不发复话工单。
·在执行程序中检查
在执行电子工单时，若某一客户有多于一条以上工单时，按工单申请时间顺序进行处理，
而不是按优先级高低来处理。
（3）MSISDN号与MSIMSI号的匹配问题
业务管理系统中的大多业务都是根据用户手机号（MSISDN）来受理的，而交换机的大
多数指令是根据MSIMSI号区分的。两者可以通过业务管理系统中存放的MSISDN号与MSIMSI
号对照表进行映射。但是，如果上述对照表中的数据不完整或有错误（如在一个新系统刚
刚开通运行初期），将导致交换机无法执行对某些用户的操作指令。对这一问题我们采用
以下方式予以解决。
当出现交换机指令执行失败时，系统对交换机输出的错误消息进行分析，如果执行失
败的原因是由于没有找到MSIMSI号，则根据用户的MSISDN号直接对HLR内部的用户数据库进
行查询，找出其所对应的MSIMSI号，并根据正确的MSIMSI号完成该指令的执行。同时，电
子工单系统对业务管理系统中的两个号码的对照表进行数据重新操作。
摘自《电信科学》
|