一种移动通信网的联机计费装置及方法

1一种移动通信网的联机计费装置，包括：移动交换中心(MSC)的业务 主处理机和计费服务器(1)和计费服务器(2)，以及路由器，其特征在于：
所述计费服务器(1)和计费服务器(2)通过基于TCP/IP协议的局域网(LAN) 与业务主处理机连接；
所述计费服务器(1)和计费服务器(2)之间通过心跳线相互连接，并且计 费服务器(1)和计费服务器(2)各自分别与磁盘阵列连接；
移动交换中心(MSC)的业务主处理机包括受控于主控制单元(CP)的计 费话单采集部件(BIAS)，所述计费话单采集部件(BIAS)的输出通过基于TCP/IP 协议的局域网(LAN)分别与两计费服务器相连；
所述计费服务器(1)包括依次相连的计费话单存储部件(BFSS)、计费话 单数据接收部件(CDRR)、计费话单数据编码部件(CDRC)和文件传输访问管 理部件(FTAM)，所述文件传输访问管理部件(FTAM)的输出，通过局域网 (LAN)，由所述路由器送往计费中心，所述计费服务器(2)与计费服务器(1) 结构相同。
2如权利要求1所述移动通信网的联机计费装置，其特征在于：还包括与 计费话单采集部件(BIAS)相连的冗余容错文件部件(RFTFS)。
3如权利要求2所述移动通信网的联机计费装置，其特征在于：还包括直 接与局域网(LAN)相连的告警服务器。
4一种移动通信网的联机计费方法，包括处理步骤如下：
(1)移动交换中心(MSC)业务主处理机的计费话单采集部件(BIAS) 采集原始计费话单数据；
(2)移动交换中心(MSC)业务主处理机的计费话单采集部件(BIAS) 和计费服务器的计费话单数据接收部件(CDRR)之间采用消息方式传送计费话 单数据，并采用带CRC校验的停等应答机制来保证网络传送不丢失、不重复、 不错码；
(3)计费服务器的计费话单数据接收部件(CDRR)接收来自计费话单采 集部件(BIAS)的计费话单数据，完成对计费话单数据的分拣、有效性验证； 然后将此数据送至计费话单数据编码部件(CDRC)，计费话单数据编码部件 (CDRC)将计费话单数据(CDR)按照既定的编码规则生成二进制码流送至 BFSS；
(4)计费服务器通过DDN专线或PSPDN线路将计费话单处理部件 (BFSS)的计费话单数据编码文件上报计费中心。
5如权利要求4所述移动通信网的联机计费方法，其特征在于：计费话单数 据的处理步骤(2)中，当计费话单采集部件(BIAS)与计费话单数据接收部件 (CDRR)之间消息传送发生障碍时，计费话单采集部件(BIAS)便把计费话单 数据写入冗余容错文件部件(RFTFS)，待计费话单采集部件(BIAS)与计费话 单数据接收部件(CDRR)之间消息传送恢复正常时，再由业务主处理机将冗余 容错文件部件(RFTFS)中存放的计费话单数据读出，传送给计费话单数据接收 部件(CDRR)。
6如权利要求4所述移动通信网的联机计费方法，其特征在于：还包括管 理所有计费服务器上运行的计费应用进程的监控步骤：
计费服务器正常启动后，首先通过配置文件读取应用进程的名字和其它属 性，然后逐一启动这些进程，启动完成后，进入运行状态；
定时向各个应用发握手消息，如果等待一定时间仍未收到应答，就认为该 应用进程已陷入死锁状态，向其发送关闭消息令其关闭，关闭成功后再将其调 起，若应用程序内部发生异常，则通过应用程序自身截获该异常，将该进程重启， 以防止出现更进一步的异常。

本发明涉及一种通讯领域的计费方法，特别涉及移动通信系统的计费方法。\n在移动通信网计费体制中，通常可以分为两种计费方式：脱机计费方式和联 机计费方式。\n脱机计费方式是指计费中心与MSC的计费信息交换通过磁带、光盘等脱机设 备实现。移动通信网建设初期一般都采用该方式。但其缺点是从MSC产生的计费 话单数据(即原始计费话单数据)到计费中心处理该数据的时间间隔比较长，造 成计费结算时间延迟也比较长。因为计费中心是收到MSC的原始话单数据后再集 中处理，导致处理负荷不平衡，具有阶段性。\n联机计费方式是指由计费中心负责从所辖地区的所有MSC中采集计费话单 数据，并通过DDN专线进行数据传输，对MSC的采集周期一般不大于15分钟， 大大提高了处理计费话单的实时效果。\n因此，就发展趋势来看，联机计费方式将逐步取代脱机计费方式。\n现有联机计费装置一般将计费功能由前端业务处理机承担，与计费中心的接 口通常要有一块专门的插板，置于MSC的机架上，脱机设备(如磁带机、DVD- RAM、CDR/W、MO等)也被安装在MSC的机架里面。如爱立信公司的MSC是采用 专用计费接口板在机架上提供计费输出端口，只支持X.25协议，采用MTP进行 文件传输。由于MTP是非标准协议，导致计费中心必须添加附加设备(如爱立信 的Billing Gateway)来专门处理。再加上计费接口板与业务处理系统藕合度较 大，改动困难，因此该公司迟迟未将文件传输协议更换为标准的FTAM方式。\n计费装置采用这种处理方式增加了前端业务处理机的负担，也不利于计费功 能扩充，如扩充热计费，过滤本地话单、转换话单格式等功能就比较困难，配置 的灵活性受到很大限制；为降低成本，配置中冗余措施少，稳定性不高。采集、 传送、处理原始话单数据直接关系到网络运营商的利益，因此计费装置的稳定性 是运营商十分关注的技术指标。\n本发明的目的是为了克服现有联机计费装置存在的缺陷，把计费装置的大部 分功能从MSC中分离出来，由计费服务器来完成，以减轻前端MSC业务主处理机 的负担，增强计费功能的可扩充性、系统配置的灵活性，提高联机计费装置的稳 定性，\n本发明所述联机计费装置的结构采用硬件与软件相结合的方式，把计费功能 从MSC业务主处理机分离出来，由相对于MSC业务主处理机而言独立的计费服务 器来完成。\n所述联机计费装置包括：移动交换中心(MSC)的业务主处理机和计费服 务器1和计费服务器2，以及路由器；\n所述计费服务器1和计费服务器2通过基于TCP/IP协议的局域网(LAN) 与业务主处理机连接；\n所述计费服务器1和计费服务器2之间通过心跳线相互连接，并且计费服务 器1和计费服务器2各自分别与磁盘阵列连接；\n移动交换中心(MSC)的业务主处理机包括受控于主控制单元(CP)的计 费话单采集部件(BIAS)，所述计费话单采集部件(BIAS)的输出通过基于TCP/IP 协议的局域网(LAN)分别与两计费服务器相连；\n所述计费服务器1包括依次相连的计费话单存储部件(BFSS)、计费话单数 据接收部件(CDRR)、计费话单数据编码部件(CDRC)和文件传输访问管理部 件(FTAM)，所述文件传输访问管理部件(FTAM)的输出，通过局域网(LAN)， 由所述路由器送往计费中心，所述计费服务器2与计费服务器1结构相同。\n如上所述移动通信网的联机计费装置，还包括与计费话单采集部件(BIAS) 相连的冗余容错文件部件(RFTFS)。\n如上所述移动通信网的联机计费装置，还包括直接与局域网(LAN)相连的 告警服务器。\n一种使用本发明所述移动通信网的联机计费装置的方法，其处理步骤如下：\n(1)移动交换中心(MSC)业务主处理机的计费话单采集部件(BIAS) 采集原始计费话单数据；\n(2)移动交换中心(MSC)业务主处理机的计费话单采集部件(BIAS) 和联机计费服务器(PC-SEVER)的计费话单数据接收部件(CDRR)之间采用 消息方式传送计费话单数据，并采用带CRC校验的停等应答机制来保证网络传 送不丢失、不重复、不错码；\n(3)联机计费服务器(PC-SEVER)的计费话单数据接收部件(CDRR) 接收来自BIAS的计费话单数据，完成对计费话单数据的分拣、有效性验证；然 后将此数据送至计费话单数据编码部件(CDRC)，计费话单数据编码部件 (CDRC)将计费话单数据(CDR)按照既定的编码规则生成二进制码流送至 BFSS；\n(4)联机计费服务器(PC-SEVER)通过DDN专线或PSPDN线路将计 费话单处理部件(BFSS)的计费话单数据编码文件上报计费中心。\n所述联机计费方法在话单数据的处理步骤(2)中，当BIAS与CDRR之间 消息传送发生障碍时，BIAS便把计费话单数据写入冗余容错文件部件(RFTFS)， 待BIAS与BFSS之间消息传送恢复正常时，再由业务主处理机将RFTFS中存放 的计费话单数据读出，传送给CDRR。\n联机计费服务器还包括管理所有计费服务器上运行的计费应用进程的监控 步骤：\n计费服务器正常启动后，首先通过配置文件读取应用进程的名字和其它属 性，然后逐一启动这些进程，启动完成后，进入运行状态；\n定时向各个应用发握手消息，如果等待一定时间仍未收到应答，就认为该 应用进程已陷入死锁状态，向其发送WM_CLOSE消息令其关闭，关闭成功后再将 其调起，若应用程序内部发生异常，则通过应用程序自身截获该异常，将该进程 重启，以防止出现更进一步的异常。\n本发明所述移动通信网的联机计费装置及方法，采用硬件与软件相结合的 方式，克服了现有技术的缺陷，把计费功能从MSC业务主处理机分离出来，由相 对于MSC业务主处理机而言独立的计算机服务器来完成，减轻了MSC业务主处理 机的负担，可以方便地在计算机服务器上实现计费功能的扩充，增强了系统配置 的灵活性；计费装置在业务主处理机上的BIAS部件和计费服务器上的CDRC部 件之间的原始计费话单数据采取消息方式传送，采用带CRC校验的停等应答机 制来保证网络消息传送不丢失、不重复、不错码。而计费服务器的硬件结构采用 了廉价磁盘冗余阵列(RAID)技术和集群(CLUSTER)技术，采取双机在线守候 的工作方式，大大提高了计费装置的稳定性。\n图1：移动通信网联机计费装置MSC侧结构图；\n图2：移动通信网联机计费装置计费服务器侧结构图\n图3：监控程序流程图；\n图4：移动通信网联机计费装置结构图。\n下面结合附图，通过具体的实施例对所述联机计费装置作进一步详细描述。\n一种采用所述装置及方法的移动通信网的联机计费系统如图4所示，它是一 个省级移动通信网的联机计费系统结构图。MSC产生的计费话单数据通过局域网 传送至计费服务器，传送采用基于TCP/IP协议的消息停等应答机制。在MSC中， 配置一定容量的磁盘以提供RFTFS的物理介质，如2.1G。通过将Disk Array配 置为RAID5，提高磁盘系统的容错性。计费服务器上运行双机软件和计费应用进 程以及进程监控程序SerApp Manager，通过它们来实现服务器系统的容错性。 告警服务器能够监控计费双机的运行状况，对发生异常而引起的倒换立即告警， 对磁盘空间不足时立即告警，还可以通过人机接口发出倒换命令，同时通过Q3 接口和上一级网管中心(OMC)连接。\n下面对各部分的功能分别加以描述：\n图1是移动通信网联机计费装置MSC侧结构图。省级计费中心负责从全省所 有MSC中采集计费话单数据，采集协议使用标准的文件传输访问管理协议 (FTAM)，对MSC的采集周期≤15分钟。省计费中心与MSC之间的通信链路一般 采用DDN专线。MSC所完成的计费功能是如下两点：\n(1)产生计费话单数据，并在本地以文件方式存储；\n(2)提供FTAM接口用于传送计费信息。\n在呼叫处理部件所在的主处理机模块上，主要进行业务处理，将系统相对复 杂、特别是存储需求庞大的BFSS独立成为另一个处理模块——计费服务器，从 而减轻了主处理机的负担。而BIAS部件由于其与呼叫处理联系紧密，故将其归 置于主处理机模块；这样BIAS在设计上可做到尽量简化，它只完成信息采集、 转发和必要的容错功能。\n另外还采用了冗余容错文件部件(RFTFS)，它用于提供一种后备话单文件存 储部件。当业务主处理机与计费服务器间的传输链路发生中断时，BIAS部件采 集的计费信息被送至RFTFS暂时存储，待链路恢复，由BIAS将存储的文件再发 往计费服务器。\n计费服务器上的计费话单数据接收部件(CDRR)是与BIAS的接口部件，主 要完成对计费信息记录的分拣、有效性验证。它的输出被送至计费话单数据编码 部件(CDRC)，CDRC将CDR按照一定的编码规则生成二进制码流，输出至BFSS。 这种编码规则比较规范，符合ASN.1(抽象语法描述)的基本编码规则(BER)。 BFSS是计费装置稳定性的核心，存储MSC侧计费装置的最终结果，通过FTAM部 件的访问与计费中心进行文件数据交换，实现计费信息的上报。计费服务器的硬 件一般采用PC SERVER级平台，操作系统可以采用UNIX或WINDOWS NT。\n因为业务主处理机和计费服务器采用基于LAN的TCP/IP协议，就不能不考 虑网络传输带来的传送阻断、拥塞和差错。如果对其不加以特别处理，就会导致 话单丢失、话单错漏，严重的还可能导致业务主处理机系统崩溃。对此，采取如 下措施：\n(1)主处理机上的RFTFS被设计用来提供后援存储空间，当BIAS部件 检测到发送缓冲区已满(可能是由于网络阻断或传输流量过大造成的拥塞)而 CP部件仍有原始计费话单数据产生时，BIAS会调用RFTFS的访问接口，将这 些原始计费话单数据保存到RFTFS中，当网络恢复正常时(当BIAS检测到发 送缓冲区为空)，BIAS会向RFTFS查询有无呼叫记录存储，如有，则将其读出 到发送缓冲区中等待发送。这即解决了由于传输链路不畅造成的话单数据丢失， 又不会使话单长期驻留在RFTFS而延误计费。如果网络长时间阻断，造成RFTFS 占用超过80％(可设置)，业务主处理机会产生告警信号提醒用户(局方)及时 检查通信链路情况。\n(2)业务主处理机上的BIAS部件和计费服务器上的CDRC部件之间的计 费话单数据传送采取消息方式传送，采用带CRC校验的停等应答机制来保证网 络消息传送不丢失、不重复、不错码。\n上述停等应答机制的工作过程如下(在以下描述中，将BIAS称做发端，CDRC 称做收端)：\n(1)发端保留一发送流水号，在将计费话单数据包发出时，该流水号附加于 数据包中用以标明发送数据包。\n(2)收端相应于每个发端(如果MSC有多个业务主处理机，属于多发端，单 收端的情形)保留三种流水号：\nExpSeq[]      期待流水号\nPrevSeq[]     最近一次收到的数据包流水号\nUnExpSeq[]    意外收到的流水号\n收到数据包后，依次进行下列处理：\na)将数据包中发送流水号与收端程序中保存的PrevSeq[Module]相比较。若 相等，则认为该数据包是重发包，收端程序已收到过该包，只发应答消息，不再 接收此包；若不相等，则继续检查。\nb)将数据包中发送流水号与收端程序中保存的ExpSeq[Module]相比较。若 相等，则认为该数据包是正确的，于是接收该包，并更新ExpSeq[Module]、 PrevSeq[Module]，发应答消息；若不相等，则进一步处理。\nc)将数据包中意外发送流水号赋给收端程序中的UnExpSeq[Module]。收端 于是向发端发送一个带UnExpSeq[Module]的要求确认意外包是否是正在发送的 数据包的消息。发端收到要求确认的消息后，再向收端发送确认意外包正确与否 的消息，收端若收到确认为正确的消息后则接收该包，并更新ExpSeq[Module]、 PrevSeq[Module]，发应答消息；反之，不更新ExpSeq[Module]、PrevSeq[Module]， 直接发应答消息(应答流水号为UnExpSeq[Module])。\n(3)发端收到应答消息后，将应答消息中所带流水号与本程序中所保存的发 送流水号相比较。若相等，则认为该包已为收端接收到，可以继续发送下一数据 包，于是更新发送流水号，即循环累加流水号(0～32767)；若不相等，则认为收 端未接收该数据包(有可能是因为CRC错，序号错等原因)，需要重发。发端对所 有的重发包，都打上重发标记。\n(4)下面讨论几种异常情况：\na)若数据包在到达收端之前丢失，收端未接收到数据包，将不会发出确认 消息，则发端将超时重发此话单数据包，流水号不变。重发成功后，收端将根据 流水号接收该包。\nb)若收端已收到数据包，并发出确认消息，但确认消息在途中丢失，则发 端将超时重发此数据包，收端将根据流水号判别该重发包，只发应答消息，并不 再次接收该包.\nc)发端重启(指重新启动)时，在内存中尚未向收端发送的数据将无法恢 复。此时，它向收端发送的第一个数据包肯定是收端从未接收过的。因此，发端 重启时把流水号初始化为-1。收端收到流水号为-1的数据包总是接收，并更新 ExpSeq[Module]、PrevSeq[Module]，发应答消息。\nd)收端重启前，可能发端未向收端发新数据包(不重发)、也可能发端已经 向收端发了数据包但收端没有收到(重发)、也可能收端已经收到了但还没有发 送应答消息(重发)、也可能发了应答消息但丢失了使发端收不到到应答消息(重 发)，因此收端重启后，收到的第一个数据包如果是重发包，则是可疑的。对于 收端重启的可疑话单数据包，分两种情况来处理：\n(i)重启前为正常退出(如发现停电、UPS告警等紧急情况时，维护人员及 时退出应用程序、退出操作系统)，此时，收端把重启前的流水号保存在文件里。 重启后读出，与前台的发送话单比较，根据带流水号的停等应答机制，决定是否 接收话单；\n(ii)重启前为非正常退出(如未退出程序和操作系统就突然关机)，这时， 由于操作系统(UNIX，WINDOWS NT)采用缓冲区存文件，正在存储的一些话 单必然会丢失，对重启后的可疑话单文件(重发包)采取直接丢弃的处理方式。 这样做，主要考虑了处理器处理速度问题，即流水号只在程序开始和结束时分别 读写一次。而对于后台突然掉电丢话单，用户应该能理解。\ne)发端主备倒换后，原主机的数据包将通过新机转发到收端。原主机将尚 未发送的计费话单数据发给新主机。新主机收到原主机的数据包后，不拆包，保 持模块号、重发标记等信息不变，直接转发到收端。收端收到原主机发来的数据 包后，回应答消息也通过新主机向原主机转发。即新主机收到应答消息后，必须 先判别该应答消息是发给自己还是发给原主机的，若是后者，则转发给原主机。 这样，不管各发端如何主备倒换，对停等应答机制来说都可按单发端单收端的情 况来处理。\n图2是计费服务器的硬件结构图，采用了廉价磁盘冗余阵列(RAID)技术 和集群(CLUSTER)技术。\n磁盘阵列配置3块9G硬盘，支持热插拔，做成RAID5，实际数据空间为3 ×9×2/3＝18G，用作话单文件的存储池。每台计费服务器上有各自的系统磁盘， 系统软件安装在各自的主机上。\n这项技术实现了在标准计算机系统上组建双机容错系统，从而大大降低系 统数据丢失和停机的概率，提高系统运行的稳定性。\n双机系统采用在线守候方式工作，工作状态下一台机器上运行计费服务器 所有的应用，包括CDRR、CDRC、FTAM等部件，控制BFSS，称作主机。另一台机 器则处于等待状态，没有任何计费应用在运行，只保持和主机必要的状态信息联 络，称作备机。主备机上均运行双机监控软件，通过心跳线(如RS232口)负责 双机状态监测与互通以及必要时的倒换控制。当下列情况发生时，双机监控软件 会触发主备机系统倒换(Switch)：\n(1)系统软件或应用软件造成服务器系统宕机\n(2)SCSI卡损坏，造成服务器对磁盘阵列无法存取资料\n(3)服务器内硬件损坏，造成服务器宕机\n(4)服务器不正常关机\n(5)以太网卡损坏或网线断路造成网络通信异常 倒换后，由原备机接管原主机的所有应用，而成为主机。原主机变为备机。\n这样，通过RAID技术，提高了磁盘的容错能力，一旦某块硬盘发生损坏， 数据不会丢失，由于RAID5硬盘均支持热插拔，可以实现在线更换；通过CLUSTER 集群技术，提高了计算机系统的容错能力，无论是软件系统还是硬件系统发生故 障，均可以通过主备倒换来实现不停机运行。\nRAID5只有在二块以上硬盘同时损坏时才会导致数据丢失，而统计测试表 明，现在一般硬盘的MTBF均达到180000小时以上，由此可以看出，RAID+CLUSTER 集群技术的计费双机系统其稳定性是相当高的。\n另外，在CLUSTER集群系统自身应用程序中存在死锁问题，例如，在计费 服务器上存在的应用中，当计费话单接收程序出现死锁时(注意，此时服务器不 一定宕机，CLUSTER软件也就无法感知)，CLUSTER系统无法发起倒换。这样，业 务主处理机上的BIAS不断产生原始话单数据，而服务器端的CDRC无法接收处理， 也就容易造成话单数据不能及时传递到上级计费中心，极端情况当RFTFS系统空 间耗尽时，还会出现丢失话单的严重局面。\n为解决这一问题，专门设计了计费服务器监控程序SerApp Manager，其处 理流程图如图3所示。\n该程序管理所有计费服务器上运行的计费应用进程，当发现这些应用进程 无法响应消息或出现进程内部异常时，SerApp Manager会发消息让应用进程重 启。这样就解决了由于应用程序死锁而造成的系统隐患。\n以WINDOWS NT系统举例如下：计费服务器正常启动后，SerApp Manager 首先通过配置文件读取由它监控的应用进程的名字和其它属性，然后逐一启动这 些进程，启动完成后，进入运行状态，SerApp Manager每隔一定时间(如3秒) 向各个应用发握手消息，如果等待一定时间(如15秒)仍未收到应答的话，监 控程序认为该应用进程已陷入死锁状态，会向其发送WM_CLOSE消息令其关闭(若 关闭不成功则直接发Application Terminate消息)，关闭成功后再将其调起。 若应用程序内部发生异常，则通过应用程序自身截获该异常，将发生异常的信息 在与SerApp Manager的握手消息应答中通知SerApp Manager，SerApp Manager 也会将该进程重启，以防止出现更进一步的异常。\n为了提高联机计费装置的稳定性，对整个联机计费装置还采用了监控技术。 由MSC本地操作维护的告警系统监控，一旦发生故障，立即发出各种可视、可闻 的声光信号。告警级别分为通知、一级告警、二级告警、三级告警、四级告警。\n(1)当BFFS出现空间不足时，产生告警信号。根据所剩空间的大小(200M， 100M，50M，可以设置)，产生不同级别的告警信号。例如当空间＜50M时(可以 设置)，产生一级告警，通过专用告警设备(告警箱)发出持续告警音。\n(2)一旦业务主处理机与计费服务器之间通信链路发生中断，立即告警。\n(3)通过操作维护台，可以由操作员发起命令，控制CLUSTER的倒换。其最 大好处在于操作员或工程人员在更换计费服务器软件版本或检测设备时，实现系 统不停机。\n(4)当计费服务器由于种种异常原因而倒换时，会通知告警模块，告警模 块也会产生告警信号，提示用户某台服务器可能出现故障。\n在计费传输上采用双网技术。由计费服务器通过FTAM协议向计费中心实 时传送话单。计费服务器与计费中心链路采用双备份，其一是通过DDN传输； 其二是当DDN链路发生故障时，启动PSPDN传输。当然，也可以根据用户的 要求全部采用DDN传输或者PSPDN传输。\n由此可见，整个系统结构从软件到硬件都考虑了容错机制，从而最终保证 计费装置的高可靠性、高稳定性要求。由于业务主处理机和计费服务器的分离， 保证系统具有良好的可扩充性，满足运营商一些特殊计费要求，例如增加支持热 计费(Hot Billing)的CMIP协议等等只需在计费服务器上增加一个CMIP软件 模块即可，而业务主处理机无需作任何修改。 英文缩略语注释： BER：           基本编码规则 BIAS：          计费话单采集部件 BFSS：          计费话单存储部件 CMIP：          公共管理信息协议 CDRR：          由计费话单数据接收部件 CDRC：          计费话单数据编码部件 FTAM：          文件传输访问管理协议 RFTFS：         冗余容错文件部件 MSC：           移动交换中心 OMC：           网管中心 PC-SERVER：     联机计费服务器 RAID：          廉价磁盘冗余阵列 RFTFS：         冗余容错文件部件