10次），则总的掉话次数=主叫掉话次数+被叫掉话次数-同时掉话的次数。
在本例中，总掉话次数= 10+26-10=26，则掉话率= 26/239=10.88%。
6 平均呼叫建立时延
定义：平均呼叫建立时延＝（呼叫建立时延总和/接通总次数） 说明：
1) 呼叫建立时延：主叫手机发出第一条AC Origination Message到被叫手机接收
到Alert with information的时间差。
2) 取所有测试样本中除了呼叫失败情况外的平均时长。
软件提供统计呼叫时延的功能，但是不符合上面的定义。需要手工计算。方法： 1) 在消息窗口点击鼠标右键，选择Message Flow，导出一个TXT文件。 2) 用Excle打开，把被叫文件的Alert with Information Message消息和时间COPY
到新的Excle表中，同样把主叫消息Origination Message合并到该表中，两者的时间差即位呼叫时延。
注1：在导出信令时，不要合并测试数据。
注2：如果时间差较大（如超过15s），说明本次呼叫失败，应把Origination Message删除。
7 存在信令丢失时的修正
7.1 被叫接通次数的修正
按Alert with Information 统计的接通率明显偏低（小于85%），说明信令丢失严重，则修改统计点：只要出现Service Connect Message、Service Connect Completion Message、Alert with Information之一，即为被叫接通。 必须注意的是：替换前后的统计方法需要保持一致！
以Service Connect Message、Service Connect Completion Message、Alert with Information之一作为被叫接通标志的设置步骤是：
a) 1）～3）同第4章；
b) 在添加了Alert with Information消息后，同样的方法把Service Connect Message、
Service Connect Completion Message都添加到Page Response Message下。最后左边窗口显示如下：
修正后的统计结果如下：
按照新方法统计到的被叫接通次数由原先的239次，增加到290次。 接通率变成：290/334=86.82%。
7.2 掉话次数的修正
按照CallSuccess的定义，在手机接通后（Service Connect Completion Message），如果没有释放消息，就转为空闲状态，就统计成一次掉话。如果丢失了释放消息，则本次掉话就成了“虚假”的了。
正常情况下，手机在预设的通话时间（90s）后才会转为空闲状态，也就是说，虚假的掉话，Sync Message消息与Service Connect Completion Message消息的时间间隔，应在90s左右。实际统计是89s，如下：
可以根据这个特点对虚假的掉话进行过滤。步骤如下：
1) 对Call Success事件进行编辑，在左边窗口选择SC Sync Message，再点击
Advance。
2) 在Use Diagnose一栏打勾，再在左上角第一个空格里填上85000ms，打勾。
通过以上设置后，对不超过85ms的掉话（真正的掉话）进行诊断。
对被叫测试文件的诊断结果如下。右上角的数据表示符合条件的事件为7次（即真实掉话次数）。注意Table It的结果不受影响，仍是26次。
这样被叫掉话次数就由原先的26次降低到7次！利用诊断功能还可以对掉话事件进行分析，如上图显示，有5次掉话是Ec/Io覆盖差，有1次FFER也很大。
8 总结
由于测试软件或测试手机的原因，空口信令消息经常丢失，导致统计结果失真。在此情况下需要进行修正。
一般可按常规方法（第3、4章）进行统计，如果统计到的接通率很低（如在85%以下），或掉话率很高（如在1%以上），则需要按第6章的方法对被叫接通次数和主被叫掉话次数进行修正。