电信运营商收入保障系统设计与实现 第9页
当出现超过阈值的波动时，自动提醒监控人员。监控人员需要分析、确认产生波动的原因，如果设备原因影响了数据采集，就对设备进行维护。
在统一的采集模型、指标和业务流程的基础上，我们建立了统一集中的采集完整性监控平台。监控软件包括采集、计算、图示、统计查询、自动告警、日志、权限管理等模块，运行在统一的硬件平台上。对应新业务和新设备的监控，一般可以通过配置完成，特殊情况下，也只需要扩展计算模块。由于采用统一界面，在一个界面上可以观察所有业务、所有设备的数据采集完整率曲线[24]。
4.1.4断点续传功能
由于网络的原因，数据采集进程经常会中断，造成话单采集不完全的情况发生，从而导致话单的丢失，所以数据采集处理应支持断点续传功能。
进行文件传输时，在服务器端，对打开的文件设置了一个偏移量，每次传输文件的一部分，就将偏移量设置成当前传输的块的偏移量。如果传输成功，则取下一块的偏移量，如果失败，则保存该偏移量。这个偏移量是断点续传的关键之一。
在客户端，在传输失败的时候保留该未完成的文件，这个文件的大小是断点续传的另一个关键。
有了上述两个关键点，系统便可以实现断点续传了。
当客户端发送续传命令时，与命令一起发送的还有续传点，也就是文件应该从哪里开始添加数据。这个续传点可以通过取未完成的文件的大小来得到。当服务端接收到续传命令，取得续传点，将其与服务器上保存的偏移量进行比较，若一致则打开一个数据连接，从该偏移量开始传输。而在客户端，只需要将文件位移置于末尾，便可以从数据连接接收续传的数据，将其添加到未完成的文件的末尾[12]。
4.2预处理收入保障
4.2.1话单检重
日常我们有时会发现有些话单重复而造成重复收费的情况，话单重复会导致用户投诉，运营商不但要对用户进行高额的赔偿外还要受到名誉的影响，这也是造成运营商收入流失的一个问题。那么我们可以在预处理的同时也完成话单的检重工作。
重单类型包括：
 话单主叫、被叫相同，通话开始时间重复或在指定的误差范围内；
 话单主叫、被叫相同，通话时间重叠或在指定的误差范围内；
预处理提供灵活的检重处理和重单规则配置，支持参数配置选择需相互捡重的业务和捡重条件。
系统将通过如下的方式来进行检重处理：话单预处理完成后，需要提取话单中的某几个字段（以普通电话语音话单为例），起始主叫号码，起始主叫时间，被叫号码，采用HASH算法，将这三个字段的值进行进一步的计算得到一个该话单对应的唯一性标志码，对于当天的话单形成的唯一性ID是放在内存数据库中，对于历史的唯一性ID放在文件系统中，按照一天一个（或多个）ID号文件的方式进行存放，根据发送来的新的话单的发生日期，进行排重，如果是当天的话单，则在内存数据库中进行排重，如果是迟到话单，则根据实际发生的日期找到相应的唯一性ID号文件进行排重。下一条话单计费完后，同样进行这个HASH算法，如果得到的唯一性标志码与已有的标志码相重复，则表示该话单是重单，将该话单入库到重单数据库进行分析，查询。采用HASH算法来实现重单的检验，比用数据库的唯一性索引来检查重单，极大的提高了话单的入库速度，主要体现在两个方面：采用HASH算法，对于检验话单的重复提高了速度[23]。
4.2.2包容单检查
若两条清单中的几个关键域完全相同且下一条清单的起始时刻和结束时刻分别小于上一条清单的起始时刻和结束时刻的情况视为包容单。我们在话单检重的时，一般对包容话单经常采取选择时长最大清单进行计费而另一条清单不计费的原则，但现在我们不能完全遵循这一原则，因为对于N-ISDN业务和主被叫都为PBX用户出现话单包容情况是业务发展的结果，所以需要对其不进行包容单检查，如果按照以前丢掉其中任意一条清单都会对运营商造成收入损失[26]。
4.2.3交叉单检查
若两条清单中的几个关键域完全相同，且下一条清单的起始时刻或结束时刻介于上一条清单的起始时刻和结束时刻之间情况视为交叉单。我们在话单检重的时，一般对交叉话单经常采取选择起始时间最早的清单进行计费而另一条清单不计费的原则，但现在我们不能完全遵循这一原则，因为对于N-ISDN业务和主被叫都为PBX用户出现话单交叉的情况是业务发展的结果，所以需要对其不进行交叉单检查，如果按照以前丢掉其中任意一条清单都会对运营商造成收入损失[19]。
4.2.4话单纠错
对话单预处理时候，会因为话单字段格式错误或者其它原因，我们把其作为错误话单进行单独存放，错误话单是不能进行下一步计费操作的，这就意味着运营商不能向用户收取这些话费，导致运营商的收入损失。
为了减少损失，在不影响费用计算的前提下，对话单进行适度的修改。具体包括下述可以纠正的错误：
 如果对端号码记录错误，删除对端号码中的非法字符；
 如果是与计费无关的字段出现错误，我们可以忽略这种错误的出现；
 可以将用户指定模式的错误处理情况在预处理时自动纠正，以便能够进行计费处理[26]。
4.3计费处理收入保障
4.3.1参数及时回调
在进行计费处理过程中，我们将计费参数一次性全部调入共享内存区，各个批价进程从共享内存区获取计费参数，进行批价处理。
 由于系统维护的参数永久存储在数据库中，因而需要将用户更改过的计费参数及时更新到内存中以便批价系统可以按照新的规则进行批价，如果没有及时更新，会导致批价结果错误，造成损失。
我们可以在系统中设计了专门的进程参数守护进程，实时检测系统中参数是否变化。对于已经变化的参数，系统及时阻塞批价进程，进行内存参数更新，这样就使得系统参数的变化及时反映到实时批价系统中。再加上批价系统的参数化驱动机制，于是在资费标准、计费规则等改变时，系统不必事先停止所有进程，而仅仅根据需要进行参数更改，系统则会自动将新的政策完好地体现在系统中。
在所有的参数表中,我们需要定义参数生效起始时间、参数生效终止时间。因此，在系统中政策变更、资费调整时，只需要在系统中更改旧参数的生效终止时间，另外增加新的参数即可。

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>