路测呼叫建立不成功的原因分析及解决.docx
《路测呼叫建立不成功的原因分析及解决.docx》由会员分享，可在线阅读，更多相关《路测呼叫建立不成功的原因分析及解决.docx（22页珍藏版）》请在冰点文库上搜索。
路测呼叫建立不成功的原因分析及解决
道路测试中出现呼叫建立失败的原因分析
目录
第一章前言1
第二章测试系统简介3
一.TOM测试系统3
二.TEMS测试系统3
三.测试系统主要功能4
查找网络故障4
网络优化手段4
下行干扰测试4
第三章道路测试中呼叫建立失败原因分析6
一.道路测试中成功的呼叫建立消息历程6
1）手机做主叫的消息历程6
手机做被叫的消息历程8
被叫用户没有接通的消息历程10
被叫用户忙的消息历程11
被叫用户已关机或未应答的消息历程12
二.道路测试中呼叫建立失败的消息历程13
2）SD拥塞的消息历程13
3）TCH拥塞的消息历程14
4）下行质量差造成TCH接入失败的消息历程15
5）SDCCH掉话的消息历程17
6）上行链路问题的消息历程18
7）无效的呼叫20
三.道路测试中呼叫建立失败的主要原因21
第四章结束语23
第一章前言
道路测试是为了对网络进行全面的了解，使用测试工具对移动通信网络进行测试、测量工作。
道路测试主要分成两种，一种是网络运行质量调查测试，另一种是网络优化测试。
网络运行质量调查测试主要是网络运营商为了了解自己网络运行的情况，对自己的网络进行的大规模的摸底测试，因为单从统计上看网络的性能指标如：
掉话率、接通率等是不全面的，一个网络运行的好与坏只有从用户的角度进行了解才是最客观准确的，网络运行质量调查测试便是很好的方法，它可以使用一部与普通用户几乎相同的测试手机，进行数以百计的拨叫测试，对测试结果进行量化分析，从而得出当前网络的运行状况，为运营商下一步发展提供依据。
再有，如果网络进行了重大调整如：
软件升级、网络改频等，要等到从统计上观察出调整不成功，用户不能正常使用，就耽误了时间，最快最有效的方法也是进行网络测试。
网络优化测试是当网络出现了一些问题时，从OMC测试不能判断故障原因所在，由网络测试人员使用专用的测试设备对有问题的地区进行测试，再将测试结果进行分析，就可以发现故障原因，为优化工作提出建议，改进网络运行质量。
总之，道路测试是提高网络运行质量的有效方法。
在道路测试中，根据优化目的不同，有着对网络覆盖、掉话、呼叫建立等不同的分析过程。
这里我们就测试过程中的呼叫建立失败的各种情况加以分析，希望借此提供一些查找测试过程中出现的呼叫建立失败原因的思路，以供大家参考。
第二章测试系统简介
由不同厂商提供的测试工具，在上报和处理网络消息时有着不同的格式。
目前我们就使用最广泛的TOM和TEMS测试系统进行介绍。
一.TOM测试系统
TOM是由芬兰NEMO公司开发的无线网络测试设备，该设备硬件主要包括如下几个部分：
✧数据采集前端，主要负责对空中传播的无线电信号进行接收，在与网络联系中进行信令传输与交换，并且将信息发送给计算机和接收计算机发送的控制指令。
✧连接电缆，将手机与计算机连接起来，实现两者通信的设备，一端连接计算机串口，另一端接手机数据口。
不同系列的测试手机因为数据接口不同，所以连接电缆也有所不同。
✧计算机，是测试设备的核心部分，主要作用是运行测试软件，对测试手机进行控制和操作，并且将测试手机采集的数据完整地记录下来，通过软件将测试数据显示出来，为优化人员判断故障提供依据。
✧GPS，全球定位系统接收机，将收到的位置信息（经纬度）发送给计算机，以便把测试数据在数字化地图当中显示出来，便于分析。
✧MMAC扩展架，该设备可以通过扩展手机插槽和相应电路使计算机同时控制1至4部手机，便于进行网络评估测试（BENCHMARKING）。
二.TEMS测试系统
TEMS是由瑞典ERICSSON公司生产的无线网络测试设备，它的主要组成部分基本与TOM测试系统的设备相同,具体硬件设备如下：
✧数据采集前端
✧连接电缆
✧计算机
✧GPS全球定位系统
三.测试系统主要功能
道路测试系统在进行测试的过程中，可以完整地记录下测试手机与网络进行的信令信息，以及当时网络手机所在服务小区，邻区等无线环境，如果使用GPS定位系统，还可以同时记录位置信息（经纬度），通过这些信息可以发现网络的一些问题。
具体功能如下：
查找网络故障
在日常测试中通过测试文件分析也可以发现网络中小到一个TRX，大到MSC、HLR的故障，并且根据相关信息对故障原因进行判断。
网络优化手段
在日常运行时，尽管硬件设备没有问题，但是由于无线环境的变化（如建筑物变化、周边基站增加等），会使基站覆盖、主控区等发生变化；随着一些地区的发展，某些地区的用户数急剧增加，这些可以导致网络部分基站、BSC发生高掉话、高拥塞等指标降质现象，严重时可以导致网络瘫痪。
在测试过程中，根据测试文档和统计等信息，可以发现上述问题，依据情况提出优化方案。
下行干扰测试
通过道路测试系统的SCAN及DECODEBSIC功能，可以确定小区中的某一个频率受到其他小区中相邻频率的干扰，从而及时对局部网络的频率规划的加以修正。
第三章道路测试中呼叫建立失败原因分析
呼叫建立分析是移动通信网络优化的范畴之一。
这里我们主要分析道路测试中测试系统采集的无线接口消息。
呼叫建立阶段包括移动台发起呼叫MOC和移动台被呼叫MTC。
以下展现的就是呼叫建立的一些典型情况。
对于不同的测试系统，其无线消息采集处理上有着些许的差异，但总体上都依据GSM规范制定。
下面通过针对测试系统收集处理的信令消息分析，进而查找呼叫建立失败的原因。
从道路测试的角度分析呼叫建立的过程，我们不仅要关注统计意义上的TCH分配过程；更重要还要从用户感知上考虑，从RACH接入、SDCCH分配、TCH分配一直到用户真正开始通话为止。
从而完整的分析用户呼叫直至通话的全过程。
一.道路测试中成功的呼叫建立消息历程
道路测试中正常的呼叫建立过程，通过信令消息:
AssignmentComplete体现了TCH信道的正常分配。
而对于广义上的呼叫建立，即有户所感知而言，信令消息则对应为：
ConnectAcknowledge体现了用户通话的开始。
1）手机做主叫的消息历程
TOM测试系统
TEMS测试系统
手机做被叫的消息历程
TOM测试系统
TEMS测试系统
由以上不同路测系统的层3消息分析，其呼叫流程信息以及信令消息解码都基本相同。
因此接下来我们就以TEMS测试消息为例进行分析。
在成功的呼叫建立过程中，有一些呼叫对于用户而言不能发生通话。
我们以移动台发起呼叫为例，在被叫用户（固定网）不能接通、被叫移动用户未开机、被叫用户没有接听、被叫用户正在通话等许多情况下，都不会发生用户间的通话。
但是，对于无线网络而言，他们都属于正常的呼叫信令接续。
被叫用户没有接通的消息历程
从上面的层3消息中，我们可以看到TCH信道的正常分配。
之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。
分析Disconnect消息中的CauseValue可以大致得出原因：
MSC未能建立对外的连接，有可能是由于没有可用的资源。
被叫用户忙的消息历程
从上面的层3消息中，我们可以看到TCH信道的正常分配。
之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。
分析Disconnect消息中的CauseValue可以得出明确的原因：
被叫用户忙。
被叫用户已关机或未应答的消息历程
从上面的层3消息中，我们可以看到TCH信道的正常分配。
之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。
分析Disconnect消息中的CauseValue可以得出明确的原因：
被叫用户没有应答。
二.道路测试中呼叫建立失败的消息历程
对于道路测试中的呼叫建立失败，不仅是针对TCH分配过程中的失败，还涵盖了包括RACH接入、SDCCH分配过程以及无效的呼叫等多种情况。
而对于广义上的呼叫建立，还包括了在TCH分配完成后，在移动台发送ConnectAcknowledge消息之前，所发生的TCH掉话。
下面我们从网络中可能出现的一些引发呼叫建立失败的原因入手，分析移动台处于各种情况下，其信令消息的接续历程。
2）SD拥塞的消息历程
从上面的层3消息中，我们可以看到SDCCH拥塞时，系统会向移动台发送ImmediateAssignmentReject消息。
比较Layer3消息中的Randomreference号码，从而可以确定多个信道请求消息中，那一条由于SDCCH拥塞而被拒绝。
3）TCH拥塞的消息历程
从上面的层3消息中，我们可以看到TCH拥塞时，下行发出CallProceeding消息后，当没有TCH可用信道时，手机在排队打开的情况下，在SDCCH上排队等待，直到排队时长终止。
下行即发出ChannelRelease消息。
4）下行质量差造成TCH接入失败的消息历程
从上面的层3消息中，我们可以看到当TCH拥塞和TCH分配失败时，经常可以看到移动台回到SDCCH上发送AssignmentFailure消息，其描述多为：
没有无线资源、无线接口失败以及协议错误。
对于无线接口失败，导致其发生的原因有多种。
其中多数是由于硬件故障、干扰、信号阻挡等因素造成的。
当处理这类问题时，需要根据测试现场的周边环境；小区相关性能统计；结合测试文件综合加以考虑。
硬件问题案例：
由于单个载频故障或收、发信通路上的硬件发生故障，造成射频通路上的衰耗突然增大，通信质量下降，致使射频丢失。
从上面的层3消息中，我们可以看到AssignmentFailure消息，分析分配失败的原因CauseValue:
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_SD是在SDCCH上的射频掉话的数目。
引起原因可能是覆盖问题；同、邻频干扰问题；硬件问题等等，需要进行实际的测试后，根据具体情况进行分析。
从呼叫建立的信令消息历程上分析，我们可将SDCCH掉话分为:
AssignmentCommand消息之前的SD射频丢失和AssignmentCommand消息之后，TCH分配失败后移动台不能回到原SDCCH信道的掉话。
从上面的层3消息中，我们可以看到AssignmentCommand消息之前的SD射频丢失。
当时用户在室内起呼困难，现场测试发现在分配SDCCH后，在单个载频RTF-73上经常产生SD_RF_LOSS，观察MR可以看到RXQUAL=7，通过对基站射频通路检测，发现该小区载频RTF-73所连接的天线朝向上存在严重阻挡，造成通信质量下降，从而导致信令在其SDCCH信道的接续失败。
在调整天线位置后，室内用户可以正常的呼叫。
6）上行链路问题的消息历程
上行链路问题通常是由于硬件问题、上行干扰造成基站不能正常解调手机的上行消息。
从上面的层3消息中，我们可以看到移动台在没有收到下行指配消息时，会根据系统消息3中定义的max_retran的次数，在T3212定义的时长内，重新发送Channelrequest消息；发送间隔根据tx_integer的取值，在数个RACH时长的范围内，随机取得。
其中，取值定义如下：
M=max_retran；
取值范围:
0-3
0=最大1次重发
1=最大2次重发
2=最大4次重发
3=最大7次重发
T=tx_integer；
取值范围:
0to15对应的RACHslots
03RACH811RACH
14RACH912RACH
25RACH1014RACH
36RACH1116RACH
47RACH1220RACH
58RACH1325RACH
69RACH1432RACH
710RACH1550RACH
S=根据tx_integer与复帧的类型共同决定（如下表）：
TX-integer
noncombinedCCCH
combinedCCH/SDCCH
3,8,14,50
55
41
4,9,16
76
52
5,10,20
109
58
6,11,25
163
86
7,12,32
217
115
在Channelrequest消息发送M+1次后，MS会启动T3126计数器，当计数器超时后，呼叫将被取消。
以上的案例中，经过测试后对起呼小区的载频的统计分析，以及利用CTP工具进行呼叫跟踪发现。
该小区受到严重的上行干扰，导致基站无法正确解调出RACH信息。
7）无效的呼叫
在测试过程中，常能碰到一些由于人为因素造成的呼叫建立失败。
在这里我们将其统一归为无效呼叫。
下面列举一些常见的现象：
✧移动台呼叫建立过程中的出现突然断电。
✧移动台关机（IMSIdetach）
✧移动台呼叫建立过程中，在Setup消息之前，由于移动台挂机等原因导致移动台发送CMServiceAbort消息，取消呼叫。
✧移动台道路测试过程中，由于人为设定拨叫等待时长，造成呼叫建立的信令接续不能完成。
其中包括几种情况：
1.由于人为设定呼叫接续等待时长短于系统正常的呼叫建立时长，造成呼叫建立的信令接续不能完成。
2.在结束一次通话后，由于跨越LAC区导致移动台发起位置更新。
在位置更新过程未完成时，人为设定拨叫等待时长到时，需进行下一次呼叫，则会出现无法发起呼叫或被叫不再服务区的现象。
3.由于LAC区规划不合理，LAC交界处基站覆盖调整不当时，会导致移动台在结束一次通话后，接连跨越LAC区，连续进行位置更新。
从而使人为设定拨叫等待时长超时，出现无法发起呼叫或被叫不再服务区的现象。
4.测试设备软件原因。
使用TOM测试系统，在结束一次通话后，移动台进行小区重选时，有时会出现短暂的脱网现象。
从而导致人为设定拨叫等待时长超时，出现无法发起呼叫或被叫不在服务区的现象。
三.
道路测试中呼叫建立失败的主要原因
当呼叫建立失败时，基站通常送DISCONNECT消息到移动台，DISCONNECT消息简要的指示出呼叫建立失败的不同原因。
下面就是在道路测试期间经常出现一些呼叫建立失败的原因值详细描述。
CauseValue
描述
可能的原因
CauseValue31
“正常，未详细说明”
这原因通常报告一个正常的事件仅仅当在正常的类别没有另外的原因适用时。
BSS（TCH拥塞）或MSC问题
CauseValue34
“没有可用的电路/信道”
（在AssignmentCommand前）
这原因显示有目前得不到适当的电路/隧道处理呼叫。
TCH拥塞
CauseValue34
“没有可用的电路/信道”（在AssignmentCommand后）
这原因显示有目前得不到适当的电路/隧道处理呼叫。
MSC拥塞
CauseValue41
“暂时的失败”
（在AssignmentCommand前）
这原因显示网络运行异常,达到要求的情况不能持续一个长的时段，移动电台可以很快地尝试另一次的呼叫。
BSS问题，尤其是硬件问题
CauseValue41
“暂时的失败”
（在AssignmentCommand后）
这原因显示网络运行异常,达到要求的情况不能持续一个长的时段，移动电台可以很快地尝试另一次的呼叫。
MSC问题
CauseValue42
“交换设备拥塞”
这原因显示交换设备正处于高通信量的处理时期。
MSC拥塞
CauseValue44
“请求电路/信道不可用”
当电路或信道请求的实体不能被另一边接口提供时这原因被返还。
BSS问题，尤其是CIC拥塞
CauseValue111
“协议错误，未详细说明”
这原因通常报告一个协议差错事件，仅仅当在协议差错类别没有另外的原因适用时。
BSS或MSC问题
在道路测试过程中，我们会碰到各种由不同原因引起的呼叫建立失败。
主要原因可以归结如下：
✧TCH拥塞
✧SDCCH拥塞
✧上行链路问题
✧无效的呼叫
✧硬件问题
✧干扰问题
✧MSC问题
第四章结束语
本文通过对道路测试过程中测试系统所收集处理的信令消息的分析，研究了呼叫建立过程中出现的各种问题。
力求帮助优化人员通过网络优化测试中反映出的问题，找到导致呼叫失败的原因，进而提高网络质量。
同时，基于北京网络的现状，有一些问题在近期内很难加以整理。
我们将在今后继续补充完善。
升级会员 