异常信令导致未接通.docx
《异常信令导致未接通.docx》由会员分享，可在线阅读，更多相关《异常信令导致未接通.docx（14页珍藏版）》请在冰豆网上搜索。
异常信令导致未接通
异常未接通专项分析报告
1概述
上海移动测试组在2010年1月至2010年5月的无线测试中发现大量MS异常信令未接通事件从而导致了无线网络接通率较低。
由于该现象出现比较频繁而且出现的原因也比较的复杂，要弄清具体的原因需要通过UM,ABIS,A口的联合信令分析，由于我们资源有限无法进行端到端的分析，因此我们只能对UM和A口进行联合分析。
2信令异常问题分析计划
针对本次上海移动出现的多次异常未接通情况，设计院优化小组在优化期内重点收集了无线测试中发现异常未接通的事件，截止到11月设计院共发现异常未接通数量为12个，占了所有未接通比例的22.7%。
我们将结合A口数据分析原因所在。
3GSM接口简介
接口概述
BSS对外的接口都是标准接口，包括MS与BSS之间的Um接口、BSS与MSC之间的A接口，这些接口协议和规程都在ETSI协议中有严格和完备的规定。
BSS的各个网元（BTS、BSC）之间的接口以及BSS与OMC的接口都是内部接口，与设备供应商的实现有关。
其中ETSI对BTS与BSC之间的Abis接口也做了许多规定，但不够完备。
下图是GSM系统信令模型，每个接口总体介绍如下：
MS：
移动台
BTS：
基站收发信台
BSC：
基站控制器
MSC：
移动交换中心
CM：
接续管理
MM：
移动性管理
RR：
无线资源管理
MTP：
消息传递部分
SCCP：
信令连接控制部分
LAPD：
D信道上链路接入规程
LAPDm：
Dm信道上链路接入规程
BSSMAP：
基站子系统应用管理部分
BTSM：
BTS管理
3.1.1A接口
A接口定义为网路子系统（NSS）与基站子系统（BSS）间的通信接口，就是移动业务交换中心（MSC）与基站控制器（BSC）之间的接口，物理链路采用标准的2.048Mb/s的数字传输链路实现。
此接口传递的信息包括移动台管理、基站管理、移动性管理、接续管理等。
3.1.2Abis接口
Abis接口定义了基站子系统（BSS）中基站控制器（BSC）和基站收发信台（BTS）之间的通信标准，用于远端互连方式。
它们之间采用标准的2.048Mb/sPCM数字链路来实现。
此接口支持所有向用户提供的服务，并支持对BTS无线设备的控制和无线频率的分配。
3.1.3Um接口
Um接口（空中接口）定义为移动台与基站收发信台（BTS）之间的通信接口，用于移动台与GSM系统的固定部分之间的互通，物理链路是无线链路。
此接口传递的信息主要包括无线资源管理、移动性管理和接续管理等。
4无线接通率的统计、定义和基本处理流程
未接通主要是在手机向系统发送呼叫请求，但是在呼叫过程中由于某种原因，主叫或被叫手机没有分配到TCH信道，导致未接通。
路测（DRIVETEST）当中考察的一项重要指标,接通率一直是优化中要应对的一个重要工作.在日常的测试当中,我们经常遇到各种各样的未接通情况。
原因也是多种多样。
导致未接通的常见的原因主要有：
被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH掉话、呼叫号码错误、CIC分配错误、寻呼失败。
无线接通率的定义
根据集团公司测试的规范和要求，无线接通率公式如下：
无线接通率=接通总次数/试呼总次数×100％
从信令点上分析是以channelrequest和CMservicerequest同时出现来确定试呼开始；当一次试呼开始后出现了Connect，ConnectAcknowledge消息中的任何一条就计数为一次接通；具体情况如下图所示：
基本处理流程
在路测过程中，L3接续流程和故障判断流程：
附表：
各种未接通时间的原因，原因值，用户感受
DISCONNECT原因（CAUSEVALUE）
用户感受
被叫TCH拥塞
34:
Nocircurt/channelavailable
录音通知,暂时无法接通
主叫TCH拥塞
34:
Nocircurt/channelavailable
连续的嘟嘟嘟嘟
有寻呼消息,但没有PAGING_RESPONSE
16:
normalclearing
录音通知,暂时无法接通
被叫SDCCH拥塞
16:
normalclearing
录音通知,暂时无法接通
主叫SDCCH拥塞
没有DISCONNECT消息
没有任何提示音,直接返回
SDCCH掉话
41：
temporaryfailure
录音通知,暂时无法接通
错误号码
28：
Invalidnumberformat
主叫在听到一阵杂音后，多来米
呼叫无应答
18:
alerting,butnoanswer
录音通知,用户无人接听
CIC复位
111：
protocolerror
主叫听见多来米
被叫位置更新
41：
tempfailure
录音通知,暂时无法接通
连接超时
102
主叫听见多来米，被叫无寻呼信息
无线侧异常未接通统计
4.1.1局方数据统计
我们针对优化中心给出的异常信令事件进行了详细的统计，具体结果如下：
2010年1月～5月优化中心评估型测试结果，未接通进行分类（测试设备OT260）：
月份
信令异常未接通
1月
7
2月
6
3月
7
4月
6
5月
6
总计
32
XX文库-让每个人平等地提升自我占所有未接通比例
51.61%
XX文库-让每个人平等地提升自我具体分类如下：
2010年8月～10月优化中心评估型测试结果，未接通进行分类（测试设备OT260）：
月份
信令异常未接通
8月
2
9月
0
10月
1
总计
3
占所有未接通比例
37.5%
具体分类如下：
异常信令类型
次数
CMservicereject（cause:
messagenotcompatiblewiththeProtocolstate
1
CMSERVICEREJECT：
IMSIunknowninVLR
1
Disconnect（Normal,unspecified）
1
4.1.2设计院数据统计
我们对优化区域内的异常信令事件进行了详细的统计，具体结果如下：
2010年6月～10月设计院测试结果，未接通进行分类（测试设备TI9.1）：
月份
信令异常未接通
6月
5
7月
1
8月
5
9月
0
10月
1
总计
12
占所有未接通比例
22.7%
具体分类如下：
4.1.3小结
从上述数据对比中我们可以看出2010年6月至10月的内，异常信令导致未接通的事件已经出现下降，但该现象依然还是存在。
因此针对该情况我们选取了BSC64-9进行了A口挂表分析。
5核心网侧问题现象和分析
由于无线测试中发现的异常信令无法分析出问题的具体原因，因此我们在9月份选取了BSC64-9进行了A口挂表分析。
从A口挂表数据结合路测LOG进行进一步的分析。
MSC发起CMServiceReject
我们统计了所有CMSERVICEREJECTCAUSE值，我们发现Messagenotcompatiblewiththeprotocolstate占所有CAUSE值的18.11%，排在所有CAUSE的第2位，具体情况如下图所示：
从上图可以看出异常CAUSE：
Messagenotcompatiblewiththeprotocolstate对网络影响还是较大的，因此我们对该现象进行了进一步的分析。
Ø消息定义：
根据规范0408所定义的情况来看该消息类型属于未知或不可预见的消息类型，规范上的解释为：
Ifthemobilestationreceivesamessagenotcompatiblewiththeprotocolstate,themobilestationshallignorethemessageexceptforthefactthat,ifanRRconnectionexists,itreturnsastatusmessage（STATUS,RRSTATUSorMMSTATUSdependingontheprotocoldiscriminator）withcause#98"Messagetypenotcompatiblewithprotocolstate".WhenthemessagewasaGMMmessagetheGMM-STATUSmessagewithcause#98“Messagetypenotcompatiblewithprotocolstate”shallbereturned.WhenthemessagewasaSMmessagetheSM-STATUSmessagewithcause#98“Messagetypenotcompatiblewithprotocolstate”shallbereturned.
Ifthenetworkreceivesamessagenotcompatiblewiththeprotocolstate,thenetworkactionsareimplementationdependent.
Ø消息说明：
也就是只有在RR状态和MM状态不匹配的时候才会触发该消息，然而具体触发的原因还要根据网络真实情况而定。
Ø案例分析：
用户向网络发出接入网络的请求，差不多同时0.1S内被网络拒绝了，拒绝的原因为Messagenotcompatiblewiththeprotocolstate。
该情况如果大量发生还需厂家配合查明原因。
MS发起ASSIGNMENTFALIURE
我们统计了所有RR层错误消息我们发现Protocolerrorunspecified占所有CAUSE值的0.3%，排在所有CAUSE第2位，具体情况如下图所示：
从上图可以看出异常CAUSE：
Protocolerrorunspecified虽然排名第2但占的比重相对较小，对网络影响也是微乎其微。
以下我们对该现象进行了分析。
Ø消息定义：
根据规范0408里的解释下发Protocolerrorunspecified的原因如下：
Onthemobilestationside,ifalowerlayerfailurehappensonthenewchannelbeforetheASSIGNMENTCOMPLETEmessagehasbeensent,themobilestationdeactivatesthenewchannels,reactivatestheoldchannels,reconnectstheTCHsifanyandtriggerstheestablishmentofthemainsignallinglink.ItthensendsaASSIGNMENTFAILUREmessage,cause"protocolerrorunspecified"onthemainDCCHandresumesthenormaloperation,asifnoassignmentattempthadoccurred.Theoperationalparameters（e.g.cipheringmode）whenreturningontheoldchannelarethoseappliedbeforetheprocedure.
Ø消息说明：
在新信道发送ASSIGNMENTCOMPLETE之前，底层交换发生错误，MS从分配业务信道返回信令信道就会发送该消息"protocolerrorunspecified"。
Ø案例分析
从上面的流程我们可以看出MS在Assignmentrequest后差不多2S内没有收到COMPLETE，导致等待T3107超时MS上发AssignmentFailure。
该现象发生的原因可能是无线环境差或核心网丢包，由于我们没有ABIS数据我们无法判断在ABIS口有没有收到该条消息，具体情况还需进行端到端的优化分析。
Ø计时器T3107定义
作用：
MS层3连接建立时间（指配流程）启动：
收到BTS发来的EST_IND消息
停止：
收到MS发来的ASS_CMP消息收到MS发来的ASS_FAIL消息
超时：
定时器超时后，BSC释放已分配的资源
取值：
范围〈1-25s〉缺省值〈6〉
MSC发起的Disconnect（Normal,unspecified）
我们统计了所有DTAP层错误消息我们发现Disconnect（Normal,unspecified）占所有CAUSE值的4.44%，排在所有CAUSE第2位，具体情况如下图所示：
从上图可以看出异常Disconnect（Normal,unspecified）排名第2为4.44%，对网络有一定的影响，以下我们针对该现象进行了分析。
Ø消息定义：
根据规范0408里的解释下发normal,unspecified的原因如下：
IfthenetworkhasreceivedanALERTINGmessage,butdoesnotreceiveaCONNECTorDISCONNECTmessagepriortotheexpiryoftimerT301（oracorrespondinginternalalertingsupervisiontimingfunction）,thenthenetworkshall:
initiateclearingprocedurestowardsthecallinguserwithcause#19"useralerting,noanswer";andinitiateclearingprocedurestowardsthecalledmobilestationinaccordancewithsection5.4.4,usingcause#102"recoveryontimerexpiry"orusingcause#31"normal,unspecified".
Ø消息说明：
该现象主要是因为网络发出ALERTING后没有收到CONNECT和DISCONNECT消息导致计数器T301超时。
网络自动下发DISCONNECT消息。
Ø案例分析
从上面的流程我们可以看出ALERTING消息发出后0.8S后网络在没有收到任何的CONNECT和DISCONNECT后自动下发DISCONNECT。
导致该现象的可能原因有主叫无线环境较差或T301设置过短和核心网丢包，具体情况还需进行端到端的优化分析。
Ø计时器T301定义
作用：
用户摘机定时器（监控呼叫建立后用户摘机的时间；如果网络侧已经使用了内部呼叫监视功能（即组合呼叫时），此时T301不起作用）
启动：
MSC收到ALERTING消息
停止：
MSC收到CONNECT消息MSC收到DISCONNECT消息
超时：
定时器超时后，MSC以原因值#19“useralerting,noanswer”向主叫方清除本次呼叫；同时MSC以原因值#102“recoveryontimerexpiry”或#31"normal,unspecified"向被叫方清除本次呼叫（发送DISCONNECT消息）
取值：
最小180s（协议定义）；
MSC发起的Disconnect（Temporaryfailure）
我们统计了所有DTAP层错误消息我们发现Disconnect（Temporaryfailure）占所有CAUSE值的0.31%，排在所有CAUSE第5位，具体情况如下图所示：
从上图可以看出异常CAUSE：
Disconnect（Temporaryfailure）占的比重相对较小，对网络影响也是微乎其微。
以下我们对该现象进行了分析。
Ø消息定义
根据规范0408里的解释下发Disconnect（Temporaryfailure）的原因如下：
IftimerT322expires,theSTATUSENQUIRYmessagemayberetransmittedmaximallyonce.IfT322expiresaftertheSTATUSENQUIRYhasbeentransmittedthemaximumnumberoftimes,clearingofthecallshallbeinitiatedwithcausevalue#41,"temporaryfailure",inthefirstcallclearingmessage.
Ø消息说明：
该现象出现主要是因为计时器T322到期，导致MSC下发Disconnect（Temporaryfailure）消息。
Ø案例分析
从上面的流程我们可以看出MS在SETUP后差不多12S内没有收到connect消息，导致T322超时MSC下发Disconnect。
该现象发生的原因可能是无线环境差或核心网丢包。
具体情况还需进行端到端的优化分析。
Ø计时器T322定义
作用：
呼叫状态查询定时器
启动：
MSC第一次发送STATUSENQUIRY消息，
停止：
MSC收到STATUS消息
超时：
当STATUS消息发送了最大次数后，若定时器超时，MSC清除本次呼叫，原因值为#41“temporaryfailure”
取值：
一般取值30S
小结
异常信令是网络优化中较难优化的一部分，要确诊现象的发生需要进行端到端的挂表分析以及厂商的大力配合，由于我们此次采集到的数据有限，因此只能做一个初步的判定。
升级会员 