WCDMA-DT测试中未接通归类及处理指导手册20100127v1

未接通归类及分析

目 录

1 未接通概况 ......................................................................................................................................................... 2 2 未接通分析 ......................................................................................................................................................... 2 2.1 位置更新导致的未接通 ....................................................................................................................................... 2 2.1.1 主叫位置更新导致的未接通 ....................................................................................................................... 2 2.1.2 被叫位置更新导致的未接通 ....................................................................................................................... 4 2.2 SDCCH拥塞导致的未接通 .................................................................................................................................... 5 2.3 SDCCH掉话导致的未接通 .................................................................................................................................... 7 2.4 TCH分配失败导致的未接通 ................................................................................................................................ 8 2.4.1 无线原因导致的TCH分配失败 .................................................................................................................. 8 2.4.2 BSC原因导致的TCH分配失败 ............................................................................................................... 10 2.5 TCH拥塞导致的未接通 ...................................................................................................................................... 11 2.6 其他异常原因导致的未接通 ............................................................................................................................. 12 2.6.1 由于上行干扰导致的未接通 ..................................................................................................................... 12 2.6.2 Cause: No user responding ................................................................................................................. 15 2.6.3 Cause: User Busy .................................................................................................................................... 16 2.6.4 呼叫重建导致的未接通 ............................................................................................................................. 18 2.6.5 交换机异常导致的未接通 ......................................................................................................................... 19 2.6.6 BSC与MSC间CR,CC丢失造成未接通 ................................................................................................ 21

1 未接通概况

? 未接通概述：

根据CMCC规范 以主叫Channel request来确定试呼开始，接着出现了Connect，Connect Acknowledge消息中的任何一条就计数为一次接通，否则就计为一次未接通。

CMCC测试标准中规定：在城市忙时进行自动拨打测试，每次通话时长120秒，呼叫间隔20秒；出现未接通情况，应间隔20秒进行下一次试呼。 接通率定义：接通率＝接通总次数/试呼总次数×100％； 说明：

? 接通次数：当一次试呼开始后出现了Connect，Connect Acknowledge消息中的任

何一条就计数为一次接通。

? 接通率＝总Connect（Connect Acknowledge）数/总Channel Request数×100％ ? 接通率取主叫双频测试手机的统计结果。

2 未接通分析

2.1 位置更新导致的未接通

2.1.1

主叫位置更新导致的未接通

在GSM DT正常测试中，主叫手机在idle状态下有时会发生小区重选现象，小区重选后主叫手机会有两种情况下的位置更新。一种为在idle时间内主叫手机位置更新顺利完成，另一种为手机小区重选后还未来得及进行位置更新或位置更新未完成，主叫手机就发起起呼命令（channel request），此种情况会导致未接通，网络下发CM Service Reject（Cause＝4，IMSI unknown in VLR）。 ? 案例描述：

如图中红圈处所示，主叫测试手机行驶过程中占用林庄1小区，手机接收电平为－53dbm左右，发起呼叫，但未接通。

主叫手机占用小区情况图

? 案例分析：

回放测试数据知，主叫手机由国税局3（LAC:20854）重选到林庄1（LAC:20857），未来得及做位置更新就发起呼叫，导致未接通。信令显示为CM Service Reject，Reject Cause Value：IMSI Unknown in VLR。

信令CM Service Reject消息示意图

信令CM Service Reject详细内容示

? 解决方案：

根据C1、C2算法，调整CRO\\CRH等相关重选参数。

2.1.2 被叫位置更新导致的未接通

在GSMDT测试中中是一种常见的现象，具体情况为主叫起呼后，被叫正在进行位置更新，无法正常响应主叫的寻呼命令，最后主叫网络下发Disconnect（Cause Number＝18，No User responding）。主叫正常起呼后，TCH分配完成，被叫正在做位置更新，最后主叫网络下发Disconnect，导致未接通，cause一般为：NetWork Out Of Order。附被叫位置更新案例如下：

? 案例描述：

17:16:54主叫占用西安路_1出现未接通现象。

? 案例分析：

由信令图可以看出，主叫完成起呼（assignment complete） 后2－3秒，被叫正处于位置更新流程中，导致未接通发生。如图所示：

主叫起呼信令图

? 解决方案：

被叫位置更新信令图

合理规划LAC区域，减少位置更新时长。

2.2 SDCCH拥塞导致的未接通

由于SDCCH拥塞导致的未接通，需要结合A接口，Abis接口信令跟踪及OMC统计分析。具体情况为主叫手机起呼Channel Request后，网络无法对其进行正常的立即

指配命令。见网络连续对主叫进行立即指配命令，但均未成功，最后导致未接通，通过分析发现该小区存在SDCCH拥塞现象。附SDCCH拥塞案例如下：

? 案例描述：

16：49：13主叫占用移动公司_1出现未接通。

? 案例分析：

在主叫完成起呼（assignment complete ）后2秒左右，此时被叫发起信道请求channel request report,由于SDCCH拥塞溢出，被叫手机无法获得SDCCH，重复2次发送信道请求后仍然无法获得SDCCH信道消息的回复，导致未接通的发生。如图所示：

流程图

? 解决方案：

主叫信令流程图 被叫信令

增加SDCCH信道

2.3 SDCCH掉话导致的未接通

在SDCCH正常指配过程中，无线链路有时候会变得很差，最后会引起SDCCH掉

话，从而导致未接通。主叫起呼，立即指配顺利完成后，话音质量变得很差，最后SDCCH掉话引起未接通。（该情况较多是由于重选不及时、背向起呼、无线环境差等原因引起，低电平起呼后来不及切换，无线信道恶化导致，可以从小区选择、小区重选等方面来着手处理该问题）附SDCCH掉话案例如下：

? 案例描述及分析：

测试车辆沿青松路由东向西行驶，MS占用XA731_1在20：05：09发起CHANNEL REQUEST,SDCCH分配成功，手机上发classmark change后，下行质量较差，手机一直上发测量报告，直至转为空隙模式，SDCCH掉话发生未接通。

? 解决方案：

调整XA731_1方位角增强该路段主控覆盖。

2.4 TCH分配失败导致的未接通

2.4.1

无线原因导致的TCH分配失败

在GSMDT测试中常有发生，具体情况为无线链路很差或者其它软硬件原因导致TCH分配失败，从而引起未接通。TCH分配失败的现象，网络下发Assignment Command后，移动台由于下行电平和下行质量均很差，导致移动台分配失败（Assignment Failure），从而导致无法接通。

? 案例描述：

14：29：42 主叫占用西安路_2信号发起呼叫(channel request report)，在14：29：44完成呼叫（assignment complete）,被叫未接通。

? 案例分析：

在主叫呼叫完成后2－3秒后，被叫开始信道请求，在完成assignment complete 后2秒左右出现assignment failure（TCH分配失败）,导致未接通发生。如图所示：

主叫起呼流程图

被叫TCH分配失败信令图

? 解决方案：

优化问题区域的无线环境，排除弱覆盖、频点干扰、基站硬件故障。

2.4.2

BSC原因导致的TCH分配失败

? 案例描述及分析

（1）主叫手机在call proceeding后1秒左右收到原因为normal call clearing的DISC，在A接口,主叫手机在发送call proceeding后,MSC向BSC发送assignment request消息,而BSC回应assignment failure(cause: protocol error between BSC and MSC),MSC向手机发送DISC(normal call clearing)释放链路.

（2）被手机在call confirm后1秒左右收到原因为normal call clearing的DISC,主叫手机在TCH分配成功后收到网络下发的原因为normal call clearing的DISC.在A接口,被叫手机在发送call confirm后,MSC向BSC发送assignment request消息,而BSC回应assignment failure(cause: protocol error between BSC and MSC),MSC同时向主,被叫手机发送DISC(normal call clearing)释放链路。

? 解决方案：

配合OMC-R组解决BSC性能指标

2.5 TCH拥塞导致的未接通

TCH拥塞引起的未接通，需要结合A接口，Abis接口信令跟踪及OMC统计来进行具体分析。主叫手机起呼后，无线链路正常建立，电平正常，主叫信令call proceeding后，网络无Assignment command命令，最后网络下发Channel Release，导致未接通。

? 案例描述：

拥塞造成的未接通主被叫手机均有可能发生，从信令流程上来看主叫手机在Call proceeding ( 被叫手机在 Call confirmed )后，系统没能下发Assignment command 消息，察看Disconnect 的Cause 为No radio resource。

? 案例分析：

结合话务报告分析该小区的占用情况是否存在拥塞。

主叫流程 被叫流程

? 解决方案：

扩容高话务小区。

2.6 其他异常原因导致的未接通

2.6.1

由于上行干扰导致的未接通

? 问题描述：

在10:49:50分测试车辆桃园基站方向行使，主被叫手机占用桦树岭3（17235_2113）小区时，主被叫手机的接收电平都在-60db左右，语音质量为0；在收到下行的Immediate Assignment命令，分配SDCCH信道后，在SDCCH上信令突然中断转为IDLE模式，导致一次未接通的发生，而被叫手机一直处于IDLE状态。

问题区域话音质量和小区分布图

? 问题分析：

主被叫手机占用桦树岭3（17235_2113）小区时，在距离农行2.8公里处，发生一次未接通，电平为-70db左右，现场测试环境良好，MS在收到下行的Immediate Assignment命令，分配SDCCH信道后，在SDCCH上信令突然中断转为IDLE模式，查看话务报告发现桦树岭3小区的上行干扰较严重，导致桦树岭3小区的上行质量切换较多，占总比例的49.85%，由于上行干扰导致桦树岭3小区的TCH分配失败率也较高（10.80%）。

桦树岭3小区上行质量切换分析图

TCH分配失败分析图

? 解决方案：

对问题小区进行扫频测试，查找干扰源。

2.6.2 Cause: No user responding

当主叫手机Disconnect Cause为No user responding，一般具体原因都为被叫未发出Channel Request Report响应寻呼或者被叫发出Channel Request Report后无后续信令，导致未接通发生。

? 问题描述：

如图中红圈处所示，主叫手机行驶过程中占用仪征城南3，接收电平为－66dbm，通话质量等级为0，发起呼叫，但未接通。

主叫手机占用仪征城南3未接通示意图

主叫手机占用仪征城南3情况图

? 问题分析：

通过数据回放，发现主叫手机占用仪征城南3，发出Assignment Complete后9秒，收到Disconnect消息，原因为No user responding 。被叫发出Channel Request Report后无后续信令，导致未接通发生。

主叫信令Disconnect详细内容示意图

2.6.3

Cause: User Busy

? 案例描述：

主叫手机在14：35：00完成起呼后1秒左右拆链，出现未接通现象，拆链（disconnect）原因为用户忙（cause value: user busy）。在随后4分钟时间内连续出现连续未接通现象。

? 案例分析：

查看被叫信令后发现，被叫在未接通出现前的一次呼叫中，在被叫收到connect acknowledge消息后一直处于系统消息5和系统消息6状态，没有收到后续上行的disconnect消息，也就是一直未出现信道拆链和释放，导致此后4分钟左右的时间内出现手机吊死的情况，直到14：39：40秒才出现下行的disconnect消息，而主叫在被叫未拆链和信道释放的情况下进行的连续的呼叫就出连续未接通情况，未接通的原因都是用户忙（cause value: user busy）。在被叫完成拆链后呼叫恢复正常状态。 在如图所示：

主叫未接通信令图

主叫未接通时被叫信令图

被叫上一次连接确认信令图 被叫出现拆链消息信令图

（注：14：34：06在被叫收到connect acknowledge消息后一直处于系统消息5和系统消息6之中，直到14:39:40才出现被叫拆链和信道释放消息）

? 解决方案：

此问题一般为手机原因导致，因此通过复测应该可以避免再次出现未接通。

2.6.4

呼叫重建导致的未接通

? 案例描述:

西潼高速测试手机占用小区LAC：37318 CI：18478（临潼斜口），MS在15：40：11上发CHANNNEL REQUEST,SDCCH分配成功后收到交换机下发的CM SERVICE REJECT，3s后收到系统下发的CHANNEL RELEASE，发生未接通。

? 案例分析：

查看主叫MS层三信令后发现MS在15：40：06时发生一次无线链路超时掉话，随后MS在15：40：11发起呼叫重建（CM RE ESRABLISHMENT REQUEST），查交换侧及BSC侧计数器及参数后发现，该小区所属交换没有开启呼叫重建功能，而该小区所属的ALCATEL BSC该功能开启，手机在15：40：11发起CHANNEL REQUEST，随即收到下发的CM SERVICE REJECT，引起未接通。

? 解决方案：

建议同时关闭交换侧及BSC侧呼叫重建的功能。

2.6.5

交换机异常导致的未接通

? 问题描述：

主叫MS assignment complete后收到系统下发的Disconnect信令，CAUSE：temporary failure（正常流程为assignment complete后收到alerting，然后收到connect信令），查看被叫上发alerting后，收到系统下发的Disconnect信令，CAUSE：temporary failure。

主叫信令

被叫信令

? 问题分析：

主叫未收到系统下发的alerting信令，当时无线环境良好，查看小区指标正常，被叫MS上发alerting，但交换侧未给主叫描述MS下发alerting，且交换机对主被叫手机同时拆链，由此判断该小区(XAD813_0)所属的交换机存在一定未知故障，建议交换侧跟信令，查看具体原因。

? 解决方案：

交换侧跟踪信令解决该问题。

2.6.6

BSC与MSC间CR,CC丢失造成未接通

? 案例描述及分析：

被叫手机在发送paging response后31秒,收到网络下发的原因为normal event的channel release消息,主叫手机在TCH分配成功后收到网络下发的DISC(no user responding)

主叫手机在TCH分配成功后8秒中,收到网络下发的DISC消息cause为NO USER RESPONDING..被叫手机在上发paging response消息后28秒,收到网络下发的channel release(cause: normal event).

我们同时跟踪了A口和Abis口信令,

发现在被叫手机A口流程中,存在网络下发的setup, identification request , disc等消息,而这些消息在Abis和空中接口上都不存在(A口上明确已下发),BSC由于某种原因丢弃了这些信令,造成未接通. ? 空口信令流程 被叫流程

主叫流程

? A接口信令流程

主叫流程

被叫流程

? Abis 信令流程

被叫流程

? 解决方案：

检查BSC侧或交换机侧信令模块或信令链路是否存在故障。

本文来源：https://www.bwwdw.com/article/mi2.html