道路测试中出现呼叫建立失败的原因分析

1、道路测试中出现呼叫建立失败的原因分析目 录第一章前言1第二章测试系统简介3一.TOM测试系统3二.TEMS测试系统3三.测试系统主要功能4查找网络故障4网络优化手段4下行干扰测试4第三章道路测试中呼叫建立失败原因分析6一.道路测试中成功的呼叫建立消息历程61)手机做主叫的消息历程6手机做被叫的消息历程8被叫用户没有接通的消息历程10被叫用户忙的消息历程11被叫用户已关机或未应答的消息历程12二.道路测试中呼叫建立失败的消息历程132)SD 拥塞的消息历程133)TCH 拥塞的消息历程144)下行质量差造成TCH接入失败的消息历程155)SDCCH掉话的消息历程176)上行链路问题的消息历程18

2、7)无效的呼叫20三.道路测试中呼叫建立失败的主要原因21第四章结束语23第一章 前言道路测试是为了对网络进行全面的了解，使用测试工具对移动通信网络进行测试、测量工作。道路测试主要分成两种，一种是网络运行质量调查测试，另一种是网络优化测试。网络运行质量调查测试主要是网络运营商为了了解自己网络运行的情况，对自己的网络进行的大规模的摸底测试，因为单从统计上看网络的性能指标如：掉话率、接通率等是不全面的，一个网络运行的好与坏只有从用户的角度进行了解才是最客观准确的，网络运行质量调查测试便是很好的方法，它可以使用一部与普通用户几乎一样的测试手机，进行数以百计的拨叫测试，对测试结果进行量化分析，从而得出

3、当前网络的运行状况，为运营商下一步发展提供依据。再有，如果网络进行了重大调整如：软件升级、网络改频等，要等到从统计上观察出调整不成功，用户不能正常使用，就耽误了时间，最快最有效的方法也是进行网络测试。网络优化测试是当网络出现了一些问题时，从OMC测试不能判断故障原因所在，由网络测试人员使用专用的测试设备对有问题的地区进行测试，再将测试结果进行分析，就可以发现故障原因，为优化工作提出建议，改进网络运行质量。总之，道路测试是提高网络运行质量的有效方法。在道路测试中，根据优化目的不同，有着对网络覆盖、掉话、呼叫建立等不同的分析过程。这里我们就测试过程中的呼叫建立失败的各种情况加以分析，希望借此提供一

4、些查找测试过程中出现的呼叫建立失败原因的思路，以供大家参考。第二章 测试系统简介由不同厂商提供的测试工具，在上报和处理网络消息时有着不同的格式。目前我们就使用最广泛的TOM和TEMS测试系统进行介绍。一. TOM测试系统 TOM是由芬兰NEMO公司开发的无线网络测试设备，该设备硬件主要包括如下几个部分：² 数据采集前端，主要负责对空中传播的无线电信号进行接收，在与网络联系中进行信令传输与交换，并且将信息发送给计算机和接收计算机发送的控制指令。² 连接电缆，将手机与计算机连接起来，实现两者通信的设备，一端连接计算机串口，另一端接手机数据口。不同系列的测试手机因为数据接口不同，

5、所以连接电缆也有所不同。² 计算机，是测试设备的核心部分，主要作用是运行测试软件，对测试手机进行控制和操作，并且将测试手机采集的数据完整地记录下来，通过软件将测试数据显示出来，为优化人员判断故障提供依据。² GPS，全球定位系统接收机，将收到的位置信息（经纬度）发送给计算机，以便把测试数据在数字化地图当中显示出来，便于分析。² MMAC扩展架，该设备可以通过扩展手机插槽和相应电路使计算机同时控制1至4部手机，便于进行网络评估测试（BENCHMARKING）。二. TEMS测试系统TEMS是由瑞典ERICSSON公司生产的无线网络测试设备，它的主要组成部分基本与TO

6、M测试系统的设备一样,具体硬件设备如下：² 数据采集前端² 连接电缆² 计算机² GPS全球定位系统三. 测试系统主要功能道路测试系统在进行测试的过程中，可以完整地记录下测试手机与网络进行的信令信息，以与当时网络手机所在服务小区，邻区等无线环境，如果使用GPS定位系统，还可以同时记录位置信息（经纬度），通过这些信息可以发现网络的一些问题。具体功能如下：查找网络故障在日常测试过测试文件分析也可以发现网络中小到一个TRX，大到MSC、HLR的故障，并且根据相关信息对故障原因进行判断。网络优化手段在日常运行时，尽管硬件设备没有问题，但是由于无线环境的变化（如建

7、筑物变化、周边基站增加等），会使基站覆盖、主控区等发生变化；随着一些地区的发展，某些地区的用户数急剧增加，这些可以导致网络部分基站、BSC发生高掉话、高拥塞等指标降质现象，严重时可以导致网络瘫痪。在测试过程中，根据测试文档和统计等信息，可以发现上述问题，依据情况提出优化方案。下行干扰测试通过道路测试系统的SCAN与DECODE BSIC功能，可以确定小区中的某一个频率受到其他小区中相邻频率的干扰，从而与时对局部网络的频率规划的加以修正。第三章 道路测试中呼叫建立失败原因分析呼叫建立分析是移动通信网络优化的畴之一。这里我们主要分析道路测试中测试系统采集的无线接口消息。呼叫建立阶段包括移动台发起呼

8、叫MOC和移动台被呼叫MTC。以下展现的就是呼叫建立的一些典型情况。对于不同的测试系统，其无线消息采集处理上有着些许的差异，但总体上都依据GSM规制定。下面通过针对测试系统收集处理的信令消息分析，进而查找呼叫建立失败的原因。从道路测试的角度分析呼叫建立的过程，我们不仅要关注统计意义上的TCH分配过程；更重要还要从用户感知上考虑，从RACH接入、SDCCH分配、TCH分配一直到用户真正开始通话为止。从而完整的分析用户呼叫直至通话的全过程。一. 道路测试中成功的呼叫建立消息历程道路测试中正常的呼叫建立过程，通过信令消息:Assignment Complete体现了TCH信道的正常分配。而对于广义上

9、的呼叫建立，即有户所感知而言，信令消息则对应为：Connect Acknowledge体现了用户通话的开始。1) 手机做主叫的消息历程 TOM测试系统TEMS测试系统手机做被叫的消息历程 TOM测试系统 TEMS测试系统由以上不同路测系统的层3消息分析，其呼叫流程信息以与信令消息解码都基本一样。因此接下来我们就以TEMS测试消息为例进行分析。在成功的呼叫建立过程中，有一些呼叫对于用户而言不能发生通话。我们以移动台发起呼叫为例，在被叫用户（固定网）不能接通、被叫移动用户未开机、被叫用户没有接听、被叫用户正在通话等许多情况下，都不会发生用户间的通话。但是，对于无线网络而言，他们都属于正常的呼叫信令

10、接续。被叫用户没有接通的消息历程从上面的层3消息中，我们可以看到TCH信道的正常分配。之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。分析Disconnect消息中的Cause Value可以大致得出原因：MSC未能建立对外的连接，有可能是由于没有可用的资源。被叫用户忙的消息历程从上面的层3消息中，我们可以看到TCH信道的正常分配。之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。分析Disconnect消息中的Cause Value可以得出明确的原因：被叫用户忙。被叫用户已关机或未应答的消息历程从上面的层3消息中，我们可以

11、看到TCH信道的正常分配。之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。分析Disconnect消息中的Cause Value可以得出明确的原因：被叫用户没有应答。二. 道路测试中呼叫建立失败的消息历程对于道路测试中的呼叫建立失败，不仅是针对TCH分配过程中的失败，还涵盖了包括RACH接入、SDCCH分配过程以与无效的呼叫等多种情况。而对于广义上的呼叫建立，还包括了在TCH分配完成后，在移动台发送Connect Acknowledge消息之前，所发生的TCH掉话。下面我们从网络中可能出现的一些引发呼叫建立失败的原因入手，分析移动台处于各种情况下，其信令消息

12、的接续历程。2) SD 拥塞的消息历程从上面的层3消息中，我们可以看到SDCCH拥塞时，系统会向移动台发送Immediate Assignment Reject消息。比较Layer3消息中的Random reference，从而可以确定多个信道请求消息中，那一条由于SDCCH拥塞而被拒绝。3) TCH 拥塞的消息历程从上面的层3消息中，我们可以看到TCH拥塞时，下行发出Call Proceeding消息后，当没有TCH可用信道时，手机在排队打开的情况下，在SDCCH上排队等待，直到排队时长终止。下行即发出Channel Release消息。4) 下行质量差造成TCH接入失败的消息历程从上面的层

13、3消息中，我们可以看到当TCH拥塞和TCH分配失败时，经常可以看到移动台回到SDCCH上发送Assignment Failure消息，其描述多为：没有无线资源、无线接口失败以与协议错误。对于无线接口失败，导致其发生的原因有多种。其中多数是由于硬件故障、干扰、信号阻挡等因素造成的。当处理这类问题时，需要根据测试现场的周边环境；小区相关性能统计；结合测试文件综合加以考虑。硬件问题案例：由于单个载频故障或收、发信通路上的硬件发生故障，造成射频通路上的衰耗突然增大，通信质量下降，致使射频丢失。从上面的层3消息中，我们可以看到Assignment Failure消息，分析分配失败的原因Cause Val

14、ue: 111,只是属于没有具体的原因协议错误。结合测试情况分析统计项MA_FAIL_FROM_MS（MA_FAIL_FROM_MS表示系统已为移动台分配了TCH信道，但在规定的时间，没有在TCH上建立连接，则认为此次分配失败，MS跳回原SDCCH信道发送失败消息）。发现该小区中有两个载频的MA_FAIL_FROM_MS的数目很多，观察指配失败消息前的MR可以看到RXQUAL=7。同时，在测试中周边小区不存在同、邻频现象。因此我们怀疑该小区存在硬件问题。通过对基站射频通路检测，发现该小区的合路器CBF故障，更换后其呼叫建立成功率恢复到正常水平。5) SDCCH掉话的消息历程RF_LOSSES_

15、SD是在SDCCH上的射频掉话的数目。引起原因可能是覆盖问题；同、邻频干扰问题；硬件问题等等，需要进行实际的测试后，根据具体情况进行分析。从呼叫建立的信令消息历程上分析，我们可将SDCCH掉话分为:Assignment Command消息之前的SD射频丢失和Assignment Command消息之后，TCH分配失败后移动台不能回到原SDCCH信道的掉话。从上面的层3消息中，我们可以看到Assignment Command消息之前的SD射频丢失。当时用户在室起呼困难，现场测试发现在分配SDCCH后，在单个载频RTF-73上经常产生SD_RF_LOSS，观察MR可以看到RXQUAL=7，通过对基

16、站射频通路检测，发现该小区载频RTF-73所连接的天线朝向上存在严重阻挡，造成通信质量下降，从而导致信令在其SDCCH信道的接续失败。在调整天线位置后，室用户可以正常的呼叫。 6) 上行链路问题的消息历程上行链路问题通常是由于硬件问题、上行干扰造成基站不能正常解调手机的上行消息。从上面的层3消息中，我们可以看到移动台在没有收到下行指配消息时，会根据系统消息3中定义的max_retran的次数，在T3212定义的时长，重新发送Channel request消息；发送间隔根据tx_integer的取值，在数个RACH时长的围，随机取得。其中，取值定义如下：M=max_retran；取值围: 0 -

17、 30 = 最大1次重发1 = 最大2次重发2 = 最大4次重发3 = 最大7次重发T=tx_integer；取值围: 0 to 15对应的RACH slots0 3 RACH 811 RACH14 RACH 912 RACH25 RACH 1014 RACH3 6 RACH 1116 RACH47 RACH 1220 RACH58 RACH 1325 RACH69 RACH 1432 RACH710 RACH 1550 RACHS=根据tx_integer与复帧的类型共同决定（如下表）：TX-integernon combined CCCHcombined CCH/SDCCH3,8,14,5

18、055414,9,1676525,10,20109586,11,25163867,12,32217115在Channel request消息发送M+1次后，MS会启动T3126计数器，当计数器超时后，呼叫将被取消。以上的案例中，经过测试后对起呼小区的载频的统计分析，以与利用CTP工具进行呼叫跟踪发现。该小区受到严重的上行干扰，导致基站无确解调出RACH信息。7) 无效的呼叫在测试过程中，常能碰到一些由于人为因素造成的呼叫建立失败。在这里我们将其统一归为无效呼叫。下面列举一些常见的现象：² 移动台呼叫建立过程中的出现突然断电。² 移动台关机（IMSI detach）²

19、; 移动台呼叫建立过程中，在Setup消息之前，由于移动台挂机等原因导致移动台发送CM Service Abort消息，取消呼叫。² 移动台道路测试过程中，由于人为设定拨叫等待时长，造成呼叫建立的信令接续不能完成。其中包括几种情况：1. 由于人为设定呼叫接续等待时长短于系统正常的呼叫建立时长，造成呼叫建立的信令接续不能完成。2. 在结束一次通话后，由于跨越LAC区导致移动台发起位置更新。在位置更新过程未完成时，人为设定拨叫等待时长到时，需进行下一次呼叫，则会出现无法发起呼叫或被叫不再服务区的现象。3. 由于LAC区规划不合理，LAC交界处基站覆盖调整不当时，会导致移动台在结束一次通话

20、后，接连跨越LAC区，连续进行位置更新。从而使人为设定拨叫等待时长超时，出现无法发起呼叫或被叫不再服务区的现象。4. 测试设备软件原因。使用TOM测试系统，在结束一次通话后，移动台进行小区重选时，有时会出现短暂的脱网现象。从而导致人为设定拨叫等待时长超时，出现无法发起呼叫或被叫不在服务区的现象。三. 道路测试中呼叫建立失败的主要原因当呼叫建立失败时，基站通常送DISCONNECT消息到移动台，DISCONNECT消息简要的指示出呼叫建立失败的不同原因。下面就是在道路测试期间经常出现一些呼叫建立失败的原因值详细描述。Cause Value描述可能的原因Cause Value 31“正常， 未详细说明”这原因通常报告一个正常的事件仅仅当在正常的类别没有另外的原因适用时。BSS（TCH拥塞）或MSC问题Cause Value 34“没有可用的电路/信道”(在Assignment Command前)这原因显示有目前得不到适当的电路/隧道处理呼叫。TCH拥塞Cause Value 34 “没有可用的电路/信道”(在Assignment Command后)这原因显示有目前得不