《原始话单分析在运行维护中的应用》由会员分享，可在线阅读，更多相关《原始话单分析在运行维护中的应用（4页珍藏版）》请在金锄头文库上搜索。
1、原始话单分析在运行维护中的应用 刘晖 钱秀琴 1 概述 产生详细话单的交换机（如移动交换机）能够真实、详细地记录用户每一次的呼叫过程。这里说的呼叫具有广义上的涵义，它指用户通过通信终端利用网络资源进行的一系列活动，如用户的一次话音、数据、传真主叫被叫；附加业务的查询激活去活；短消息的主叫被叫等过程。无论用户完成何种呼叫，产生详细话单的交换机上都会产生一条（ ）记录，即通常所说的原始话单。计费后台数据处理中心首先要在所有原始话单中过滤有效的原始话单，然后再根据原始话单中提供的信息，按照一定的计费原则产生客户账单，即通常所说的用户详细话单。 那么记录中都包含哪些信息呢？按照交换设备技术规范对交换机
2、计费的要求，不同交换机的记录中都应该包括以下一些信息 （1）记录类型（单次计费记录或中间计费的记录）； （2）呼叫处理类型（标识用户是主叫、被叫等）； （3）主叫方及主叫设备号（主叫用户在交换机中的标识及主叫使用的设备标识号）； （4）被叫方及被叫设备号（被叫用户在交换机中的标识及被叫使用的设备标识号）； （5）拨叫数字（用户实际所拨打的号码，或更准确地说是交换机接收到的数字，因此也可以称为入局号码）； （6）被叫号码（交换机接收到的数字经过交换机处理之后即交换机翻译之后的结果，因此也可以称为出局号码）； （7）计费日期、时间； （8）通话时长； （9）通信业务类别（指示本次通信的业务类别是话
3、音、数据、传真等）； （10）通信结果和终止原因； （11）其他一些信息，如占用中继群代码中继线编号、流水号等。 2 实例分析 在实际情况中，的格式会因交换机的不同而不相同，具体到每一项，各个厂家的叫法也不同，而且上述的一项在实际中可能由几项组成。因此在本文中我们不介绍某种机型具体的格式，而是介绍在处理一些实际问题时，通过对的分析是如何解决问题的，目的是提供一种分析和解决问题的思路与方法。下面以北电数字式移动交换机型为例，用几个实例来说明。 实例 1：信令配合的失误导致客户账单（用户详细话单）中无记录 在一次常规的长途拨打测试中，拨通某市某固定电话后，并未发现主叫手机的客户账单（用户详细话单）
4、记录，经过多次拨测验证结果均一致。当时部分技术人员认为是交换机上未产生，因此也就不可能产生客户账单（用户详细话单）。那么找到测试时的将是解决问题的惟一办法，以下是当时找到的（由于篇幅所限，只列出中相关部分内容）： 2011018613608529595 00100102787857167 000 06108 602787857167 010 0000001 0000012 03016 006 011 000905155624000 既然有记录，为什么没有生成客户账单（用户详细话单）呢？ 分析上述记录，可以发现主叫用户（ 8613608529595）在拨打被叫（ 02787857167）后，实际
5、的被叫号码（出局号码）正确（ 02787857167），主叫通信业务类别为基本话音业务（ 006 011），通信时间为 12，（ 0000012），满足计费时长的最低要求，终止原因（ 000正常释放、03016后向挂机）也正常，惟一有疑问的是呼叫标识（ 0000001表示 ）指示不计费。计费后台处理程序“照章办事”未对该做处理，从而也就不可能产生客户账单。因此这个问题的出现肯定与计费后台无关。 这样我们把工作重点定位在呼叫标识上。原因只有交换机在产生时出错或外围原因导致的。我们知道7 信令的层消息中有一些与计费有关的消息，会不会是信令配合不当引起的呢？这时挂上7 信令仪表测试发现，拨打这一号码
6、时，对方局总是回送（应答，不计费）消息，这不符合长途局信令配合的程序，因此本端交换机根据对方指示使中的呼叫指示为不计费。在通知对方局更改消息流程后，此问题得以解决。 实例 2：计费后台程序“漏判”导致客户账单（用户详细话单）中无记录 的数据通信业务开通后，在做测试的过程中发现，用手机直接拨打 169、172 等号码可以计费，但是当利用手机上互联网或进行流览后，在客户账单（用户详细话单）中未发现相应记录。同样的道理，我们从的存在与否开始检查。在进行了一次测试后，发现一条记录为： 2011018613809450001 001001172 000 06601 6172 010 0000002 00
7、00112 00016 002 002 000517002629700 分析上述记录，可以发现主叫用户（ 8613809450001）拨打被叫（ 172），出局号码正确（ 172），通信业务类别为承载业务（002 002），通信时间为 112（ 0000112）满足计费时长的最低要求，终止原因（ 000正常释放、00016主叫释放）也正常，呼叫标识（ 0000002表示）指示计费，应该说这张记录得非常完整，根据这张话单应该可以正常计费。 但是手机进行流览时没有计费，那为何直接拨打 169、172 可以计费呢？直接拨打号码时，手机上会申明呼叫为话音呼叫，而进行业务流览时手机却申明通信业务类别为承
8、载数据通信，那么会不会和通信业务类别有关呢？在计费部门检查相关过滤程序后发现，由于过滤时只识别基本话音业务有效，而未考虑承载业务的，也就没有对这类话单进行处理。修改计费程序后，该问题得以解决。 从现象上看实例 1 与实例 2 好像一样，但是其真正原因却大不相同。这类故障的发生所引起的用户申告可能并不多见，其结果往往给运营商造成话费费用流失，因此对运营商来说，建立健全的维护测试制度，可以及时发现某些问题，但是要从根本上找到问题的原因，分析上相关域是最基础的工作了。 实例 3：交换机中数字翻译结果与实际情况不一致 中国移动的智能网结构为（叠加网结构），它可通过特殊号段来触发智能网业务，例如“神州行
9、”预付费卡即是在此网络中实现的智能网业务。具体的实现方法是：只要交换机判断主叫或被叫有一方为预付费用户时，交换机就会在出局号码前加上本地前缀（贵州地区贵阳为 40）后，将呼叫接续至，然后由来控制其余的工作。 由于业务发展的需要，“神州行”用户也能使用电话业务。为了方便用户拨号，中国移动以前曾采用“”来表示中国移动的电话接入码“17951”，即用户在拨打长途电话时，可以使用“”方式来代替“17951”拨号。 我公司交换机端局的一次常规补丁完成后，在测试过程中发现，“神州行”用户采用“17951”拨号方式时，扣减费用正常；当“神州行”用户采用“”拨号方式时，“神州行”用户的卡上并未扣减费用。检查翻
10、译表对“”的预翻译为“17951”正确，交换机上显示的最终数字翻译结果也正常。例如以方式拨打广州 114 时，采用“17951020114”拨号方式时，扣减费用正常；而采用“020114”时，理论上结果（出局号码）应该为“4017951020114”并送到处理，这时交换机上显示的翻译结果也为“4017951020114”并送到，但是实际测试时却没有扣减费用。从现象上看，“”拨号方式时，好像并没有触发智能网业务，问题可能出在端局上，这时我们在端局上收集了相应的“神州行”用户的，发现： 00100017951020114 000 08095 6020114 010 0000002 00000013
11、 00016 中用户的通话时长正常（ 00000013），满足计费最短时间要求，呼叫指示为计费（ 0000002，应答计费），终止原因（ 000正常释放、00016主叫释放）也正常。但是中，用户实际所拨打的号码为 020114，在北电交换机中“”代表拨的“”号；而数字翻译结果的被叫号码（出局号码） 17951020114却为“17951020114”而并非期望的“4017951020114”，也就是并未在出局号码加上前缀。由于出局号码没有前缀，呼叫就不可能接续到，智能网业务也就不可能被触发，因此也就无法扣减用户费用。为了验证上记录的情况是否属实，挂上7 信令仪表后拨测，发现出局号码确实没有加前缀且呼叫也未接续到，与的记录完全吻合。在判断是补丁导致的故障后，取消补丁后交换机恢复正常。 通过该实例可以看到，在分析一些与出、入局号码相关的呼叫处理事件中，查找可能是最快捷的办法。因为挂信令仪表要首先找到所有的信令链路，再到现场配置仪表、插线等，费时费事。从解决问题的效果上看，分析简单、直观，能有效地说明问题。 3 结束语 综上所述，能熟练地对进行分析是解决工作中许多实际问题的有效方法之一，然而正如文中开始所讲的，本文只是提供一种思路、一种方法，要想真正做到利用分析解决问题，还得去理解掌握具体机型的格式。
