异常信令导致未接通

异常未接通专项分析报告 1 概述 上海移动测试组在2010年1月至2010年5月的无线测试中发现大量MS异常信令未接通事件从而导致了无线网络接通率较低。由于该现象出现比较频繁而且出现的原因也比较的复杂，要弄清具体的原因需要通过UM,ABIS,A口的联合信令分析，由于我们资源有限无法进行端到端的分析，因此我们只能对UM和A口进行联合分析。 2 信令异常问题分析计划 针对本次上海移动出现的多次异常未接通情况，院优化小组在优化期内重点收集了无线测试中发现异常未接通的事件，截止到11月设计院共发现异常未接通数量为12个，占了所有未接通比例的22.7%。我们将结合A口数据分析原因所在。 3 GSM接口简介 接口概述 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.1 A接口 A接口定义为网路子系统(NSS)与基站子系统(BSS)间的通信接口，就是移动业务交换中心(MSC)与基站控制器(BSC)之间的接口，物理链路采用标准的2.048Mb/s的数字传输链路实现。此接口传递的信息包括移动台管理、基站管理、移动性管理、接续管理等。 3.1.2 Abis接口 Abis接口定义了基站子系统(BSS)中基站控制器(BSC)和基站收发信台(BTS)之间的通信标准，用于远端互连方式。它们之间采用标准的2.048Mb/sPCM数字链路来实现。此接口支持所有向用户提供的服务，并支持对BTS无线设备的控制和无线频率的分配。 3.1.3 Um接口 Um接口(空中接口)定义为移动台与基站收发信台(BTS)之间的通信接口，用于移动台与GSM系统的固定部分之间的互通，物理链路是无线链路。此接口传递的信息主要包括无线资源管理、移动性管理和接续管理等。 4 无线接通率的统计、定义和基本处理流程 未接通主要是在手机向系统发送呼叫请求，但是在呼叫过程中由于某种原因，主叫或被叫手机没有分配到TCH信道，导致未接通。路测(DRIVE TEST) 当中考察的一项重要指标, 接通率一直是优化中要应对的一个重要工作.在日常的测试当中, 我们经常遇到各种各样的未接通情况。原因也是多种多样。 导致未接通的常见的原因主要有：被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。 无线接通率的定义 根据集团公司测试的规范和要求，无线接通率公式如下： 无线接通率=接通总次数/试呼总次数×100％ 从信令点上分析是以channel request和CM service request同时出现来确定试呼开始；当一次试呼开始后出现了Connect，Connect Acknowledge消息中的任何一条就计数为一次接通；具体情况如下图所示： 基本处理流程 在路测过程中，L3接续流程和故障判断流程： 附表：各种未接通时间的原因，原因值，用户感受 　 DISCONNECT 原因(CAUSE VALUE) 用户感受 被叫TCH拥塞 34: No circurt/channel available 录音通知,暂时无法接通 主叫TCH拥塞 34: No circurt/channel available 连续的嘟嘟嘟嘟 有寻呼消息,但没有PAGING_RESPONSE 16: normal clearing 录音通知,暂时无法接通 被叫SDCCH拥塞 16: normal clearing 录音通知,暂时无法接通 主叫SDCCH拥塞 没有DISCONNECT 消息 没有任何提示音,直接返回 SDCCH 掉话 41：temporary failure 录音通知,暂时无法接通 错误号码 28：Invalid number format 主叫在听到一阵杂音后，多来米 呼叫无应答 18: alerting,but no answer 录音通知,用户无人接听 CIC 复位 111：protocol error 主叫听见多来米 被叫位置更新 41：temp failure 录音通知,暂时无法接通 连接超时 102 主叫听见多来米，被叫无寻呼信息 无线侧异常未接通统计 4.1.1 局方数据统计 我们针对优化中心给出的异常信令事件进行了详细的统计，具体结果如下： 2010年1月～5月优化中心评估型测试结果，未接通进行分类（测试设备OT260）： 月份 信令异常未接通 1月 7 2月 6 3月 7 4月 6 5月 6 总计 32 占所有未接通比例 51.61% 具体分类如下： 2010年8月～10月优化中心评估型测试结果，未接通进行分类（测试设备OT260）： 月份 信令异常未接通 8月 2 9月 0 10月 1 总计 3 占所有未接通比例 37.5% 具体分类如下： 异常信令类型 次数 CM service reject（cause:message not compatible with the Protocol state 1 CM SERVICE REJECT：IMSI unknown in VLR 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发起CM Service Reject 我们统计了所有CM SERVICE REJECT CAUSE值，我们发现Message not compatible with the protocol state占所有CAUSE值的18.11%，排在所有CAUSE的第 2位，具体情况如下图所示： 从上图可以看出异常CAUSE：Message not compatible with the protocol state对网络影响还是较大的，因此我们对该现象进行了进一步的分析。 ( 消息定义： 根据规范0408所定义的情况来看该消息类型属于未知或不可预见的消息类型，规范上的解释为： If the mobile station receives a message not compatible with the protocol state, the mobile station shall ignore the message except for the fact that, if an RR connection exists, it returns a status message (STATUS, RR STATUS or MM STATUS depending on the protocol discriminator) with cause #98 "Message type not compatible with protocol state". When the message was a GMM message the GMM-STATUS message with cause #98 “Message type not compatible with protocol state” shall be returned. When the message was a SM message the SM-STATUS message with cause #98 “Message type not compatible with protocol state” shall be returned. If the network receives a message not compatible with the protocol state, the network actions are implementation dependent. ( 消息说明： 也就是只有在RR状态和MM状态不匹配的时候才会触发该消息，然而具体触发的原因还要根据网络真实情况而定。 ( 分析： 用户向网络发出接入网络的请求，差不多同时0.1S内被网络拒绝了，拒绝的原因为Message not compatible with the protocol state。该情况如果大量发生还需厂家配合查明原因。 MS发起 ASSIGNMENT FALIURE 我们统计了所有RR层错误消息我们发现Protocol error unspecified占所有CAUSE值的0.3%，排在所有CAUSE第2位，具体情况如下图所示： 从上图可以看出异常CAUSE：Protocol error unspecified虽然排名第2但占的比重相对较小，对网络影响也是微乎其微。以下我们对该现象进行了分析。 ( 消息定义： 根据规范0408里的解释下发Protocol error unspecified的原因如下： On the mobile station side, if a lower layer failure happens on the new channel before the ASSIGNMENT COMPLETE message has been sent, the mobile station deactivates the new channels, reactivates the old channels, reconnects the TCHs if any and triggers the establishment of the main signalling link. It then sends a ASSIGNMENT FAILURE message, cause "protocol error unspecified" on the main DCCH and resumes the normal operation, as if no assignment attempt had occurred. The operational parameters (e.g. ciphering mode) when returning on the old channel are those applied before the procedure. ( 消息说明： 在新信道发送ASSIGNMENT COMPLETE之前，底层交换发生错误，MS从分配业务信道返回信令信道就会发送该消息"protocol error unspecified"。 ( 案例分析 从上面的流程我们可以看出MS在Assignment request后差不多2S内没有收到COMPLETE，导致等待T3107超时MS上发Assignment Failure。该现象发生的原因可能是无线环境差或核心网丢包，由于我们没有ABIS数据我们无法判断在ABIS口有没有收到该条消息，具体情况还需进行端到端的优化分析。 ( 计时器T3107定义 作用：MS层3连接建立时间（指配流程）启动：收到BTS发来的EST_IND消息 停止：收到MS发来的ASS_CMP消息收到MS发来的ASS_FAIL消息 超时：定时器超时后，BSC释放已分配的资源 取值：范围〈1-25 s〉缺省值〈6 〉 MSC发起的Disconnect（Normal, unspecified） 我们统计了所有DTAP层错误消息我们发现Disconnect（Normal, unspecified）占所有CAUSE值的4.44%，排在所有CAUSE第2位，具体情况如下图所示： 从上图可以看出异常Disconnect（Normal, unspecified）排名第2为4.44%，对网络有一定的影响，以下我们针对该现象进行了分析。 ( 消息定义： 根据规范0408里的解释下发normal, unspecified的原因如下： If the network has received an ALERTING message, but does not receive a CONNECT or DISCONNECT message prior to the expiry of timer T301 (or a corresponding internal alerting supervision timing function), then the network shall: initiate clearing procedures towards the calling user with cause #19 "user alerting, no answer"; and initiate clearing procedures towards the called mobile station in accordance with section 5.4.4, using cause #102 "recovery on timer expiry" or using cause #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 “user alerting, no answer”向主叫方清除本次呼叫；同时MSC以原因值#102 “recovery on timer expiry”或#31 "normal, unspecified"向被叫方清除本次呼叫（发送DISCONNECT消息） 取值：最小180s（协议定义）； MSC发起的Disconnect（Temporary failure） 我们统计了所有DTAP层错误消息我们发现Disconnect（Temporary failure）占所有CAUSE值的0.31%，排在所有CAUSE第5位，具体情况如下图所示： 从上图可以看出异常CAUSE：Disconnect（Temporary failure）占的比重相对较小，对网络影响也是微乎其微。以下我们对该现象进行了分析。 ( 消息定义 根据规范0408里的解释下发Disconnect（Temporary failure）的原因如下： If timer T322 expires, the STATUS ENQUIRY message may be retransmitted maximally once. If T322 expires after the STATUS ENQUIRY has been transmitted the maximum number of times, clearing of the call shall be initiated with cause value #41, "temporary failure", in the first call clearing message. ( 消息说明： 该现象出现主要是因为计时器T322到期，导致MSC下发Disconnect（Temporary failure）消息。 ( 案例分析 从上面的流程我们可以看出MS在SETUP后差不多12S内没有收到connect消息，导致T322超时MSC下发Disconnect。该现象发生的原因可能是无线环境差或核心网丢包。具体情况还需进行端到端的优化分析。 ( 计时器T322定义 作用：呼叫状态查询定时器 启动：MSC第一次发送STATUS ENQUIRY消息， 停止：MSC收到STATUS消息 超时：当STATUS消息发送了最大次数后，若定时器超时，MSC清除本次呼叫，原因值为#41“temporary failure” 取值： 一般取值30S 小结 异常信令是网络优化中较难优化的一部分，要确诊现象的发生需要进行端到端的挂表分析以及厂商的大力配合，由于我们此次采集到的数据有限，因此只能做一个初步的判定。