路测中接通不成功的原因分析 作为路测(DRIVE TEST) 当中考察的一项重要 ...

1、 路测中接通不成功的原因分析作为路测(drive test) 当中考察的一项重要指标, 接通率一直是优化中要应对的一个重要工作.在日常的测试当中, 我们经常遇到各种各样的未接通情况。原因也是多种多样。为此，我们在最近针对未接通的原因，与统计，交换一起配合。进行了多次测试。希望在反复的测试中找到一些我们未知和忽略的东西，并且我们根据长沙现网的问题，对屡次测试未接通的点进行了定点测试。希望找到未接通的真正原因。从测试中主叫与被叫的信令流程分析，要完成一个完整的接续过程，一共有以下几步的信令流程： 主叫的信令流程接口信令方向信令过程空中接口ms- bts channel request空中接口bts

2、 - msimmediate assignment abss - msccr(coml3inf (cm service request)abss - mscclassmark changedvlr - hlrudt(send parameters or send identification in mapv2)amsc - bsscc(authentication request)dhlr - vlrudt(send parameters or send identification in mapv2)abss - mscdt1(authentication response)amsc - b

3、ssdt1(cipher mode command)abss - mscdt1(cipher mode complete)amsc - bssdt1(identity request)abss - mscdt1(identity response)amsc - bssdt1(tmsi reallocation command)abss - mscdt1(setup)amsc - bssdt1(call proceeding)amsc - bssdt1(assignment request)abss - mscdt1(tmsi reallocation complete)abss - mscdt

4、1(assignment complete)amsc - bssdt1(alerting)amsc - bssdt1(connect)abss - mscdt1(connect acknowledge)相比主叫，被叫在交换机一侧多了以下几步流程，在无线上多了paging 这个流程：e|gmsc - hlr udt(beg(inv(send routing info)d|hlr - vlr udt(beg(inv(provide roaming number)d|vlr - hlr udt(end(res-l(provide roaming number) roaming numbere|hlr

5、 - gmsc udt(end(res-l(send routing info) roaming numbera|msc - bss udt(paging)我们将结合长沙现网的实际情况，根据信令流程，一步一步对未接通的原因进行分析。1， channel request 拒绝： 没有出现过，但是在小区被bar 的情况下，会出现手机channel request 发送不出的现象。如下图，在l3 的信息里面不会出现channel request 的信息。路测中间，如果主叫手机在一个启动了流量控制的小区发起呼叫，可能不会出现channel request 消息。根据最新的测试规范，只有channel

6、request和 cm service request 同时出现时，才计算一次试呼，所以，主叫没有channel request 不会影响接通率。如果是被叫，则会在小区里收到paging 消息，但是建立不了呼叫，造成一次未接通。值得注意的是在路测过程中，有时会出现连发 多次channel request 的情况（连发的次数由小区参数max_retran 决定， 长沙的max_retran 3， 表示可以连发7次）。如果是由于sdcch 本身时隙的问题或者手机在弱覆盖地带收不到sdcch，在信令上不会出现immediate assignment，如果是sdcch 拥塞，结果如下。2， sdcch

7、 拥塞：对于主被叫，sdcch拥塞的一个重要标志是信令上出现immediate assignment 和immediate assignment reject 两条信息，如下图：如果是主叫sdcch 拥塞，用户的感受是电话拨出以后马上退回，没有任何的提示音。如果是被叫sdcch 拥塞，主叫一方听到的是“暂时无法接通”的录音通知。主叫disconet 的cause value 是16。分析长沙现网的数据，sdcch 拥塞率大于1 的小区约在2025个左右，应 该通过修改sdcch 数目来减少sd 拥塞，实际路测当中，碰上的sd 拥塞很少。3， tch 拥塞：对于主叫，tch 拥塞的是在setup

8、 以后直接discoonect的消息，cause value 是34，显示没有信道资源，用户的感受时在电话拨出以后 45秒内，听到连续的嘟嘟嘟嘟音。如果是被叫tch拥塞，主叫一方听到的是“暂时无法接通”的录音通知。主叫disconet 的cause value 是16，被叫的release 的原因也是cause value 34. 应该说，tch 拥塞是长沙现网路测中发现的主要原因。4， sdcch 掉话，sdcch 掉话是在sdcch 分配以后，到tch分配之前的掉话，长沙现网的sdcch 总掉话次数与sdcch 总的分配次数之间的比约为0.04。 有约100 个小区的sd 掉话率在1 以上

9、。sdcch 与无线环境和覆盖有很大的关系。上面的100个小区主要分布是：覆盖居民区的小区，沿江的小区。覆盖高速的小区sdcch 掉话引起的disconet 的cause value 是 temp failure。5，paging: 在测试过程中，我们多次发现，有的未接通是由于没有paging 消息而造成的（主要根据被叫手机接收到的imsi 和tmsi 号进行查找， 被叫手机只要不做tmsi relocation，它的tmsi号与上一次呼叫 一致，而imsi号是固定的）。 paging消息的发送流程如下： e|gmsc - hlr udt(beg(inv(send routing info)

10、d|hlr - vlr udt(beg(inv(provide roaming number) d|vlr - hlr udt(end(res-l(provide roaming number) roaming number e|hlr - gmsc udt(end(res-l(send routing info) roaming number a|msc - bss udt(paging) paging 消息由交换机产生以后，通过msc 送到被叫小区的lac区所在的 bsc, 在由bsc 所在的bts 通过pch 进行paging. paging 消息丢失在什么地方了，有以下几种可能：1，

11、空中接口，由于pch 配置不合理造成paging 信息的丢失，但是，长沙的统计数据表明：所有小区的pch_page_q_discrd 的数目都为 0，这表示，在空中接口的paging 能力是足够的。2， msc 到 bsc 到 bts， 从没个小区的统计项 page_request_from_msc 来看相同lac下面的每一个小区的page_request_from_msc 数目基本相同，差异仅仅为 万分之一或者十万分之一。因此，在bsc到bts 这一段丢失paging 的可能性很小。msc 到bsc这一段由于受到bsc处理能力的影响，有可能造成paging溢出，一般来说，在paging 溢出

12、的小区，在基站的mcuf的swfm 里面有以下的告警：(如何看告警：在bsc内进入3级状态，3stooges 4beatles，set_mmi exec_mon,rlogin 2(站号) 1015h，swmf l a,swmf r a ) full mailbox: this and all subsequent messages will be discarded 5d until the mailbox is no longer full. no further notices will be5d given for discarded messages or the full condi

13、tion. full mailbox的告警消息与基站本身的话务没有关系，基站本身的话务不足以使它的mailbox 满掉，它主要和收到的paging信息有关系。现在长沙网络的规划合理，paging 溢出的bsc 没有，检查paging信息量最大的lac区下的bsc和bts 的mailbox , 均没有出现溢出的现象。3， msc 没有下发paging 消息： 需要msc 配合 进行几项统计的对比： 要求msc下发paging 的数目：包括短消息中心，bsc，pstn 等 不同路由的paging 要求。实际下发的paging 消息数目和bsc一侧 收到的paging 消息数目。4月16日，我们在河

14、西m9进行的测试，发现有3次未接通和paging 丢失有关系，我们同时检查的k1205 捕捉到的a 接口数据，发现以下的问题。1， 路测当时小区无拥塞，没有tch 分配不成功的情况2， 路测数据里没有发现含tmsi 和imsi的paging 消息。3， 没有paging discard ，小区收到的paging 数目和同lac下的小区相同。4， k1205 里没有发现被叫的 cc 和cr等数据。4:18:51 pm,920,210 1:h (rx):16 mtp-l2 msu sccp rlc 4:18:51 pm,920,210 1:h (rx):16 text = 4:18:51 pm,9

15、20,210 1:h (rx):16 text = sccp connection released: 4:18:51 pm,920,210 1:h (rx):16 text = opc = 09-0-05-5 dpc = 09-0-03-64:18:51 pm,920,210 1:h (rx):16 text = 4:19:50 pm,751,411 1:e (rx):16 mtp-l2 msu sccp cr 4:19:50 pm,852,624 1:g (rx):16 mtp-l2 msu sccp cc 4:19:51 pm,210,235 1:e (rx):16 mtp-l2 msu

16、 sccp dt1 4:19:51 pm,455,032 1:e (rx):16 mtp-l2 msu sccp dt1 4:19:51 pm,520,637 1:g (rx):16 mtp-l2 msu sccp dt1 下面的数据是被叫数据，在4:18 到4：19之间有一次呼叫，但k1205数据里没有发现：我们怀疑paging 数据没发下来的原因是由于交换一侧没有下发paging 消息建议检查交换的统计，进行跟踪。6，号码错误：在路测中，我们一共发现了六次号码错误引起的未接通，release 的cause value 为28 ，invalid number format出现号码错误时，主叫

17、的感受是听到许许多多的杂音，然后听到多来米的声音，并且直接收到下行的release 消息。没有disconnect 消息。六次号码错误4次出现在河西，一次在绕城高速的望城县境内，一次出现在铁路测试的望城境内。原来以为是由于测试卡为vpn 短号码卡的原因，但最近的一次测试发现使用普通号码也会出现号码错误的提示。值得注意的是，所有六次号码错误都出现在长沙msc9 下面。由于号码的判断和识别属于交换机一侧的功能，建议对交换数据进行检查。7， 呼叫无应答：路测当中，有五次出现呼叫无应答的现象，地点出现无规律性。cause value 18: alerting,but no answer. 我们认为这些

18、情况应该从未接通中间扣除，原因是被叫用户可能在进行通话。建议在测试中使用专用测试卡 以避免被叫接听主叫号码以外的电话。8， 协议错误: 测试当中，可以看到主叫有时会出现协议错误的diconnect 的 消息，一般出现的几率较小，一次全网路测中有1次到2次，cause value = 111， protocol error 。我们认为可能与msc 到 bsc 之间的电路复位有关(reset circuit)，另外，可能与msc 分配的时隙是一个已经被 blocked 的时隙有关，在bsc的swfm 里面，会出现以下的告警： swfm log entry 60 1cf nonfatal swfm

19、error routine: cp_messages.c 1cf area: 0x00008000 error: 0x0000000b pc: 0xc0002c0e pid: 0x40 (sm bsc) 1cf bss release: 1.6.2.7.0 obj version: 1.6.2.7.4 exec version: 1.6.2.7.9 1cf 05-apr-2004 14:34:24.455 subsystem: 0x01 cpu: 0x0115 board: gproc2 ram 1cf 1cf sm error 0xb: old cic was not active 1cf detected in file cp_transf.c at line:287 1cf _old_circuit_id = 0x64 1cf _old_cic_node-operational_state = 0x0 1cf sm error: cp transfer failed. 在