标签：协议 余额 计费 消息 业务 模式 参考 sof 开始
在准实时计费和实时计费之间，实际还存在一种折中的解决方案，那就是分话单计费，所谓分话单计费，就是产生话单的交换机，对可能会产生高额费用的话单进行分割，比如用户在使用语音业务，在打了30分钟电话后，交换机先出一张话单出来给计费，计费完成后判断是否余额足够，如果不足就发出停机，网络侧在收到停机单后，中止用户通信（这一点存有疑问，问过一些熟悉的人士，有些说可以中止，有些说不能中止，期待解答），避免造成高额的欠费。
然而对于计费，如果不对分话单进行单独处理，可能会造成计费的错误。比如一条2分钟的话单，被切割成61秒和59秒，就会计算为3分钟（不足一分钟按一分钟计算，前面算2分，后面算1分），这样用户肯定会投诉。所以，分话单业务需要在计费时有单独的处理步骤。一般的做法是，在计费时，如果是分话单，计费完成后，做一个记录，同次通信的下一条话单过来后，再将这条记录合并，并根据合并后的话单的费用，减去计算上次话单的费用，得到这一条话单的费用。
这里面存在的最大问题是给用户查询的问题。用户查询时，需要查询到的是一条话单，后面交给经营分析和统计的数据，也需要是一条话单。计费最终输出的，应该是一条话单。所以，这条话单在没有完成全部计费前，不能交给入库和合帐处理。如果不交给合帐处理，就参考不到前面分话单的费用做信控处理。就失去了分话单的本意。所以，要么是查询模块做出修改，查询时考虑分话单的逻辑，要么就是信控模块做出修改，信控时参考分话单”预留”的费用。要说根本解决问题，自然是信控模块修改好些。
有一个终极的解决方案，分话单的流程与在线计费的流程非常相似。分话单的首单，更新单，尾单可以映射为在线计费的初始包，更新包和结束包。将分话单的业务转成消息处理就可以解决上面的所有问题。它是怎么解决的呢？分话单转消息用OCS的流程，余额就会被预留，自然就解决了这个问题。
话单计费还是消息计费，从表面上看是文件接口还是消息接口的问题，实际上，文件接口或者消息接口，仅仅是协议层面，定义好了相关的文件格式或者消息格式，流程上不会因此产生差异。真正产生差异的，是目前文件计费(OFCS)和消息计费(OCS)在余额流程上的差别。长期以来，由于系统的惯性，我们把系统分为了计费和帐务两块，计费管计算费用，余额管扣减费用。所以OFCS在计费时，并没有把余额真正的扣除，而只是做了累加，信控的时候参考”可用余额”和累计的费用的大小，而OCS计费时，余额会被扣除，信控的时候，仅仅参考余额。文件计费转消息计费，流程最大的不同就是，余额是不是被扣除（或者预扣），信控流程是参考累积费用+余额还是仅参考余额。文件消息转到消息计费，抛开效率的问题不谈，实际上仅仅是两者流程的统一。
当然，还有个大杀器，语音业务按秒计费，数据业务按字节计费，大家以为然否？
标签：协议 余额 计费 消息 业务 模式 参考 sof 开始
原文地址：http://www.cnblogs.com/smokefire/p/6209344.html
