GSM语音DT测试分析未接通.docx

资源描述

GSM语音DT测试分析未接通.docx

《GSM语音DT测试分析未接通.docx》由会员分享，可在线阅读，更多相关《GSM语音DT测试分析未接通.docx（35页珍藏版）》请在冰豆网上搜索。

GSM语音DT测试分析未接通.docx

GSM语音DT测试分析未接通

未接通原因分析

1概述3

1.1系统消息类型3

1.2呼叫建立流程3

1.2.1主叫建立过程：

1.2.2被叫建立过程3

1.3信令流程3

1.3.1主叫呼叫信令3

1.3.2被叫呼叫信令3

1.4未接通定义3

1.5未接通分析流程3

2具体分析3

2.1TCH拥塞造成的未接通的分析3

2.2TCH分配失败导致未接通3

2.3SDCCH拥塞导致未接通3

2.4SDCCH掉话引起未接通3

2.5SDC分配失败3

2.6位置更新导致未接通3

2.7跨LAC位置更新未接通优化3

2.8被叫小区重选造成未接通3

2.9硬件问题,SUM板和载频问题.降级告警.3

2.10上行链路问题的未接通问题3

2.11连续未接通现象3

2.12传输中继造成未接通3

2.13TCSR补丁引起连续未接通事件分析3

2.14被叫用户忙的未接通3

2.15被叫用户已关机或未应答的未接通3

2.16测试手机原因造成未接通3

2.17测试软件原因3

2.18主被叫手机欠费，系统播放录音通知.3

3总结3

1概述

在进行讲解之前先对系统消息和信令部分进行一下说明.

1.1系统消息类型

系统消息在两种逻辑信道中传送，BCCH和SACCH信道：

1）在空闲模式下，网络通过BCCH信道传送系统消息1－4及7、8；

2）在通信模式下，网络通过SACCH信道传送系统消息5和6。

各种系统消息分别包含的主要内容如下：

（1）系统消息类型1：

小区信道描述＋RACH控制参数。

（2）系统消息类型2：

邻小区BCCH频点描述＋RACH控制消息＋允许的PLMN。

（3）系统消息类型2bis：

扩展邻小区BCCH频点描述＋RACH控制消息。

（4）系统消息类型2ter：

扩展邻小区BCCH频点描述2。

（5）系统消息类型3：

小区识别（CELLID）＋位置区识别（LAI）＋控制信道描述＋小区选择＋小区选择参数＋RACH控制参数。

（6）系统消息类型4：

位置区识别（LAI）＋小区选择参数＋RACH控制参数＋CBCH信道描述＋CBCH移动配置。

（7）系统消息类型5：

邻近小区BCCH频点描述。

（8）系统消息类型5bis：

扩展邻小区BCCH频点描述。

（9）系统消息类型5ter：

扩展邻小区BCCH频点描述。

（10）系统消息类型6：

小区识别（CELLID）＋位置区识别（LAI）＋小区选择。

（11）系统消息类型7：

小区重选参数。

（12）系统消息类型8：

小区重选参数。

（13）系统消息类型13：

描述有关PBCCH信道的信息及其他GPRS消息。

各种信息单元包含的主要内容如下：

1）小区信道描述中含有该小区所使用到所有频点，包括BCCH频点和跳频频点。

2）RACH控制消息中含有参数MAXRETRANS（最大重传数）、TXINTEGER（传输的时隙数）、CELLBARACCESS（小区是否被禁止接入）、RE（呼叫重建允许比特）、EC（紧急呼叫允许比特）、AC（被限制接入的用户级别）。

3）邻小区BCCH频点描述包括其邻小区所使用的BCCH频点。

4）允许的PLMN用来提供小区内BCCH载波上移动台监测所允许的NCC。

5）控制信道描述中包括：

ATT（移动台附着分离允许指示）、BSAGBLKSRES（留做接入允许AGCH的块数）、CCCHCONF（公共控制信道结构）、BAAGMFRMS（传输寻呼消息留给同一寻呼组的51TDMA复帧数）、T3212（用着周期性位置更新的时间）。

6）小区选择中包括：

PWRC（功率控制指示）、DTX（不连续发射指示）、RADIOLINKTIMEOUT（无线链路超时值）。

7）小区选择参数包括：

小区重选滞后值、MSTXPWRMAXCCH（移动台接入小区应使用的最大TX功率电平）、RXLEVACCESSMIN（允许接入系统的移动台的最小接入电平）。

8）CBCH的信道描述包括：

信道类别和TDMA偏差（哪种专用信道的组合）、TN（时隙号）、TSC（训练序列码）、H（跳频信道指示）、MAIO（移动配置指数偏移量）、HSN（跳频序列号）、ARFCN（绝对频点号）。

9）CBCH移动配置中包括参与跳频的频道顺序与小区信道描述的关系。

10）小区重选参数包括PI（小区重选指示）、CBQ（小区禁止限制）、CRO（小区重选偏置量）、TO（临时偏置量）、PT（惩罚时间）。

1.2呼叫建立流程

1.2.1主叫建立过程：

1）MS在RACH信道上发送CHANNELREQUEST消息；

2）BTS接收解码后BSS在AGCH信道上发送IMMEDIEATEASSIGNMENT消息给手机，安排MS进入SDCCH；

3）MS收到IMMEDIEATEASSIGNMENT消息，转换到指定的SDCCH；

4）MS发送SABM（CMSERVICEREQUEST）；

5）网络对SABM以发送UA作为响应以建立L2无线链路，BSS处理该请求然后通过A接口上的信令链路向MSC报送；

6）通过鉴权加密过程后，MS在SDCCH发送setup消息；

7）MSC收到并处理setup消息，发起ASSIGNMENTREQUEST消息；

8）BTS然后在SDCCH上为手机分配TCH信道，通过ASSIGNMENTCOMMAND消息安排MS到指定的空闲TCH；

9）MS转到指定的TCH，在FACCH上发送ASSIGNMENTCOMMPLETE消息，并通过BSS上传到MSC；

10）MSC向MS发送ALERTING消息，告知MS对方铃已响，要求发送回铃音；

11）被叫摘机，CONNECT消息通过BSS发给MS，该信息在FACCH上发送；

12）MS收到该信息，打开音频通路，并通过FACCH向MSC发送响应（CONNECTACKNOWLEDGE），通话正式开始。

1.2.2被叫建立过程：

1）MSC向同一LAC内的所有小区发送寻呼命令，由各小区在PCH上发出PAGINGREQUEST消息。

2）MS根据系统分配的TMSI或IMSI值，从所有收到的PAGINGREQUEST消息中解出属于自己寻呼消息，并在RACH上发送CHANNELREQUEST消息；

3）BTS接收解码后BSS在AGCH信道上发送IMMEDIEATEASSIGNMENT消息给手机，安排MS进入SDCCH；

4）MS收到IMMEDIEATEASSIGNMENT消息，转换到指定的SDCCH；

5）MS发送SABM（PAGINGRESPONSE）；

6）其它后续消息与主叫完全一样。

1.3信令流程

1.3.1主叫呼叫信令

一次完整主叫通话的信令流程

MobileStation

Systeminformationtype1

ChannelRequest

ImmediateAssignment

CMServiceRequest

ClassmarkChange

CMServiceAccept

AuthenticationRequest

AuthenticationResponse

CipheringModeCommand

CipheringModeComplete

Setup

CallProceeding

AssignmentCommand

AssignmentComplete

Alerting

Connect

Connectacknowledge

Disconnect

Release

ReleaseComplete

ChannelRelease

需要注意的几点信令:

1）在被叫时的PagingRequest与Idle时的PagingRequest的区别在于前者在寻呼时包含有TMSI，如果为主叫起呼，则从信令开始计算ChannelRequest。

2）CipheringMode为加密模式

3）在Setup之后若手机为主叫则是CallProceeding,手机为被叫则是CallConfirm

1.3.2被叫呼叫信令

一次完整被叫通话的信令流程

MobileStation

PagingRequest

ChannelRequest

ImmediateAssignment

PageResponse

ClassmarkChange

AuthenticationRequest

AuthenticationResponse

CipheringModeCommand

CipheringModeComplete

Setup

CallConfirmed

AssignmentCommand

AssignmentComplete

Alerting

Connect

Connectacknowledge

Disconnect

Release

ReleaseComplete

ChannelRelease

需要注意的几点信令:

1）在被叫时的PagingRequest与Idle时的PagingRequest的区别在于前者在寻呼时包含有TMSI。

2）CipheringMode为加密模式

3）在Setup之后若手机为主叫则是CallProceeding,手机为被叫则是CallConfirm

1.4未接通定义

“一次接通”从主叫手机Channelrequest开始，一直到被叫手机的TCH分配完成、Alerting、Connect。

在此过程中，任何的信令中断都是“未接通”。

未接通信令分析

正常信令如下:

由主叫起呼信令流程图可以看出，主叫首先发出channelrequestreport---CMservicerequest---setup---callproceeding---assignmentcommand---assignmentcomplete---alerting---connect---connectacknowledge完成一次起呼。

在主叫Assignmentcomplete完成后2－3秒左右被叫开始信道请求流程Channel上requestreport---pagingresponse---setup---callconfirmed---assignmentcommand---assignmentcomplete---alerting---connect---connectacknowledge完成一次被叫接入。

主叫起呼信令流程图被叫接入信令流程图

1.5未接通分析流程

2具体分析

在DT测试过程中造成未接通的原因有许多,下面我对其进行了一下总结:

2.1TCH拥塞造成的未接通的分析

在GSMDT测试中，发现很多未接通事件的原因是小区拥塞、无TCH资源可用,为了提高无线接通率，就必须解决因小区拥塞导致的未接通事件。

而当小区TCH拥塞时,从信令流程上来看主叫手机在Callproceeding（被叫手机在Callconfirmed）后，系统没能下发Assignmentcommand消息，而是下发Disconnect命令.当主叫没有Assignmentcommand消息时为主叫TCH拥塞,当被叫没有Assignmentcommand消息时为被叫TCH拥塞.

图1主叫未接通流程图

图2被叫未接通流程图

TCH拥塞案例:

贵阳开磷百花小区_D3（主叫）

图3

图4

图5

【路测文件】:

2009-7-23-08

【问题描述】:

车辆在贵阳开磷百花小区附近上行驶,主叫MS发生未接通.

【问题分析】:

主叫MS占用到贵阳开磷百花小区_D3（CI:

31655BCCH:

718BSCI:

16）的信号,主叫MS的接收电平在-77DB左右,话音质量在0级,主叫MS信令CMSERVICEREQUEST→SETUP→CALLPROCEEDING→DISCONNECT,时间间隔为11s,被叫MS占用微波局_D1（CI:

11551BCCH:

723BSCI:

03）的信号,被叫MS的接收电平在-55DB左右,被叫MS信令一直为PAGINGREQUESTTYPE1,没有呼到被叫,主叫TCH拥塞.

【解决建议】:

继续观察贵阳开磷百花小区_D3指标,如长时间有拥塞情况,扩容.

2.2TCH分配失败导致未接通

【描述】：

14：

29：

42主叫占用西安路_2信号发起呼叫（channelrequestreport），在14：

29：

44完成呼叫（assignmentcomplete）,被叫未接通。

【分析】：

在主叫呼叫完成后2－3秒后，被叫开始信道请求，在完成assignmentcomplete后2秒左右出现assignmentfailure（TCH分配失败）,导致未接通发生。

如图所示：

主叫起呼流程图被叫TCH分配失败信令图

图六

【解决方案】：

解决小区TCH分配失败问题。

2.3SDCCH拥塞导致未接通

【描述】

16：

49：

13被叫占用移动公司_5出现未接通。

【分析】：

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

如图所示：

主叫信令流程图被叫信令流程图

图六

【解决方案】：

增加SDCCH信道

2.4SDCCH掉话引起未接通

【描述】：

15：

20：

47主叫手机占用沈场_2发起呼叫后出现未接通现象。

【分析】：

由信令图可以看出主叫起呼,在立即指配（immediateassignment）后紧接着就出现信道释放（channelrelease）,也就是在SDCCH分配后就出现信道释放命令，即SDCCH掉话产生此次呼叫未接通。

如图所示：

主叫信令图

【解决方案】：

未知原因掉话，可以通过信令跟踪进一步确认情况

2.5SDC分配失败

【分析】：

由信令流程可以看出,MS在channelrequestreport后下发IMMEDIATEASSIGNMENT,然后有IMMEDIATEASSIGNMENTFAILURE转为IDLE,导致未接通

建议：

排除无线方面原因后，应从交换侧寻找问题原因

2.6位置更新导致未接通

【描述】：

17:

16:

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

【分析】：

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

如图所示：

主叫起呼信令图被叫位置更新信令图

【解决方案】：

调整位置更新参数设置。

2.7跨LAC位置更新未接通优化

某城东城区大部分区域都属于LAC20857,城区西部有部分地区属于LAC20854。

城区LAC分布图

由于城区西部边缘地区与市中心不属于同一个LAC，而城西又是测试必测区域，几乎每次测试时在两个LAC交界处都会遇到跨LAC位置更新。

由于位置更新的信令流程较长，持续时间大概在5秒左右，而在被叫手机发起位置更新至完成位置更新流程中，不会响应寻呼消息，故会发生被叫手机无法接通的情况。

且由于市区的这两个LAC不属于同一个VLR，故若主叫跨LAC未及时发起位置更新，也会造成cause=IMSIunknowninVLR的未接通。

针对这一问题，我们认为最好的解决方法为进行LAC规划。

方案是将部分属于LAC20854的测试范围内的小区割接至LAC20857，保证测试范围内只有一个LAC，从根本上避免由于主被叫手机位置更新造成未接通的情况。

但是，在查询了LAC20857寻呼量以及BSC容量后，综合考虑后认为由于Paging容量限制和BSC容量限制，该方案无法实施。

之后，我们采用第二种方案，即调整LAC边界区域的CRH参数值，影响相关区域的小区重选速度，来尽量减少位置更新的概率。

移动台进行小区重选时，若原小区和目标小区属不同的位置区，则移动台在小区重选后必须启动一次位置更新过程。

由于无线信道的衰落特性，通常在相邻小区的交界处测量得到的两个小区的C2值会有较大的波动，从而使移动台频繁地进行小区重选。

尽管移动台两次小区重选的间隔时间不会小于15秒，但对位置更新而言15秒的时间是极其短暂的。

它不但使网络的信令流量大大增加、无线资源得不到充分利用，并且由于移动台在位置更新的过程中无法响应寻呼，因而使系统的接通率降低。

该参数的作用是要求邻区（位置区与本区不同）C2值必须比本区C2值大，且其差值必须大于CRH规定的值，移动台才启动小区重选.

2.8被叫小区重选造成未接通

和位置更新造成未接通相类似，小区重选造成的未接通也发生在被叫侧手机。

主叫侧在上行发送Setup消息后，网络侧开始寻呼被叫，被叫在小区重选完成后才能监听Paging消息，其间可能造成未接通。

从信令流程上来看，主叫侧正常分配完成，被叫侧一直处于空闲模式，重放路测数据，被叫手机在主叫上行发送Setup后，网络Paging被叫时，被叫手机曾进行小区重选。

主叫流程被叫流程

小区重选造成未接通流程图

【解决方案】:

检查小区重选参数设置是否合理

2.9硬件问题,SUM板和载频问题.降级告警.

由于载频隐性故障导致的未接通

在10:

31:

20分测试车辆由农行北侧向南行使，主被叫手机占用汇丰酒店1（17235_1601）小区时，主被叫手机的接收电平都在-65db左右，语音质量为7；随着车辆继续向前行使，在农行1小区附近主叫手机切换到五中1（17235_1501）小区时，语音质量为0。

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

TCH分配失败分析图

分析：

主被叫手机占用汇丰酒店1（17235_1601）小区时，在距离农行0.9公里处，电平为-68db左右，而语音质量为7，通过话务报告发现，农行1小区的切入成功率较底，TCH分配失败率较高，可能是由于农行1小区硬件故障导致。

在查看话务报告的同时也发现农行1小区上行有干扰。

查看农行1小区的硬件发现有故障，在更换TRE后，第二天复测此路段语音质量正常，故障消失，没有发现未接通现象。

2.10上行链路问题的未接通问题

上行链路问题通常是由于硬件问题、上行干扰造成基站不能正常解调手机的上行消息。

从上面的层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

RACH

S=根据tx_integer与复帧的类型共同决定（如下表）：

TX-integer

noncombinedCCCH

combinedCCH/SDCCH

3,8,14,50

4,9,16

5,10,20

109

6,11,25

163

7,12,32

217

115

在Channelrequest消息发送M+1次后，MS会启动T3126计数器，当计数器超时后，呼叫将被取消。

以上的案例中，经过测试后对起呼小区的载频的统计分析，以及利用CTP工具进行呼叫跟踪发现。

该小区受到严重的上行干扰，导致基站无法正确解调出RACH信息。

2.11连续未接通现象

【描述】：

主叫手机在14：

35：

00完成起呼后1秒左右拆链，出现未接通现象，拆链（disconnect）原因为用户忙（causevalue:

userbusy）。

在随后4分钟时间内连续出现连续未接通现象。

【分析】：

查看被叫信令后发现，被叫在未接通出现前的一次呼叫中，在被叫收到connectacknowledge消息后一直处于系统消息5和系统消息6状态，没有收到后续上行的disconnect消息，也就是一直未出现信道拆链和释放，导致此后4分钟左右的时间内出现手机吊死的情况，直到14：

39：

40秒才出现下行的disconnect消息，而主叫在被叫未拆链和信道释放的情况下进行的连续的呼叫就出连续未接通情况，未接通的原因都是用户忙（causevalue:

userbusy）。

在被叫完成拆链后呼叫恢复正常状态。

在如图所示：

主叫未接通信令图

【解决方案】:

无

2.12传输中继造成未接通

传输中继造成的未接通从空中接口信令流程上来看，主要是网络侧没有下发Assignmentcommand消息，察看Disconnect的Cause为Resourceunavailable（这一点不同于拥塞造成的未接通）。

主叫流程被叫流程

传输中继造成未接通流程图

【解决办法】：

结合018报告，检查中继时隙状态。

2.13TCSR补丁引起连续未接通事件分析

在测试中，有时会发生连续未接通。

现象为被叫手机在发送PagingResponse后，发起一次ClassmarkChange，在下行收到ClassmarkEnquiry后上行再发一次ClassmarkChange，之后被叫手机一直处于接收系统消息5、系统消息6的状态，但一直没有收到下行的Setup消息，直到一分钟后下行收到ChannelRelease（RRcause=Normalevent）才释放。

而这段时间内，主叫手机连续3次未接通（按照规范，主叫接通后通话100秒，空闲状态20秒，产生未接通后隔20秒再次起呼，因为被叫手机在1分钟内都没有释放，所以主叫会连续产生三次未接通）。

经过一段时间的观察和分析后，该问题定位到交换侧TCSR补丁上，在TSCR开关关闭后，对城区连续进行两天的GSMDT评估测试，没再发生连续3次未接通的事件。

具体的现象和分析报告及处理建议如下:

2.14被叫用户忙的未接通

从上面的层3消息中，我们可以看到TCH信道的正常分配。

之后，MSC没有向移动台发送Connect消息，而是发送了Disconnect消息。

分析Disconnect消息中的CauseValue可以得出明确的原因：

被叫用户忙。

展开阅读全文