EVDO掉话信令快速定位分析 - 图文

1 EVDO掉线信令特征

EVDO空口掉话可分为前向掉话和反向掉话两类。前向掉话是指前向链路首先丢失，主要包括以下两种触发条件： 1、开销消息监控失败

包括QuickConfig，SectorParameters，或者是同步控制信道包监控失败，其特征信令是测试log中出现QucikConfig Supervision Timer Expired，SectorParameters Supervision Timer Expired或者Control Channel Supervision Timer Expired； 2、DRC监控失败

特征信令是在连续TFTCMPRestartTx内DRC均为0后又未有NFTCMPRestartTx个时隙连续的非零DRC，其特征是测试log中出现RTCMAC_DRC_Tx_STOPPED且未出现RTCMAC_DRC_TX_RESTARTED。

由于目前TFTCMPRestartTx是12个控制信道周期，和开销消息的监控时长相同，所以大多数情况中在DRC监控失败之前开销信道消息监控失败已经触发掉话，故DRC监控失败的较为少见。

反向掉话是指反向链路首先丢失，其特征信令是后台网管中出现A9-AL-disconnected消息且同时未伴有A16_Session _Transfer（即不是A16口切换），同时AN在前向信道发送ConnectionClose后没有收到AT应答的ConnectionClose，则可判断为反向掉话。

跨AN切换失败的特征信令是出现“A16 Session Transfer Abort”，AN重新建立空口，则可判断为切换失败导致掉话。

若在信令中出现以上特征信令之一，均判定为掉话。

2 信令分析流程

分析流程：在排除覆盖原因后首先检查有无邻区漏配的情况，而后再观察是否存在开销消息监控失败的问题，随后检查是否存在扇区参数配置不一致，最后分析跨AN切换失败的情况。

2.1 邻区漏配导致空口掉线

特征信令：邻区漏配的特征是Rx良好，Ec/Io和SINR很差，AT上报大量的RouteUpdate消息，掉话后AT再次接入的扇区PN不在掉话前最后一次下发的邻区列表中。

1

图 13 邻区漏配导致空口掉话现象

图13是因邻区漏配引起空口掉话的典型现象：AT反向连续发送4条RouteUpdate消息，最后一条RouteUpdate消息中，AT上报了两个信号较强的PN，分别是PN423和PN462，要求进行切换；但AN一直未下发TCA消息，经查，最后一次下发的邻区列表消息中不含PN423和PN462，到此可确定是邻区漏配导致的DO空口掉话。

2.2 检查开销消息是否丢失

特征信令1：测试log中出现QucikConfig Supervision Timer Expired，SectorParameters Supervision Timer Expired（图14）或者Control Channel Supervision Timer Expired（图15），则判定为开销消息丢失导致掉话。

图 14 AT监控SP和QC失败后进入空闲状态

2

图 15 AT监控控制信道失败后的LOG特征

在定时器超时后，AT关闭了发射机，如图16所示。

图 16 AT关闭发射机的LOG特征

特征信令2：如果发现在first_packet=1的包后缺少last_packet=1的MAC包，也表明同步控制信道消息丢失，特征信令如下图所示。

图 17 同步控制信道MAC包丢失的特征信令

如果出现以上特征，均可认定为因控制信道消息丢弃导致AT掉话。

2.3 检查相邻扇区配置是否一致

特征信令：若看到AT在经历切换、重新建立空口后出现“ConfigurationStart”信令并进行简短的会话协商（比AT初次建立HRPD会话时的过程要简短得多）可判定为扇区配置不一致导致AT和AN间频繁参数协商，如下图所示。

3

图 18 AT和AN进行会话重协商的过程

在相邻载频的协商参数设置不一致情况下，处于连接态的AT在这些扇区移动时会保持原先协商参数不变并继续使用；但若AT从空闲态进入激活态，网络发现AT接入的载频相关协商参数与该AT的原会话不一致，会发起会话重协商机制、修改相关属性。

因HRPD的会话协商需要建立连接，协商完成后又必须再次关闭原连接、重建新连接以使新配置生效，这个过程占用了过多的时间，用户不能很快地从Dormant状态下激活，导致用户申告掉线。

2.4 检查跨AN的切换是否成功

特征信令：在信令中出现“A16-Session Transfer Abort”则说明AT在经历跨AN切换失败，形成掉话，下图是AT跨AN切换失败的特征信令。

图 19 AT跨AN切换失败时的特征信令

4

AT在业务态跨AN切换时，由于需要经历A16的信令交互、以及Session Transfer过程，耗时较长、信令交互过程较为复杂，导致AT出现空口掉话的概率增加。AT在跨AN掉话后，需要重新捕获网络、重新获取UATI、完成HRPD的协商、甚至是A12口的重新鉴权，会导致长达10秒钟的速率为零的等待，用户抱怨强烈。

3 网速慢问题的原因定位

造成网速慢的原因比较复杂，对于此类用户申告，除覆盖外，还先应排查是否存在资源不足或设备故障的情况：Abis口传输资源受限或丢包（重传率高）、单扇区下用户过多、反向RSSI过高等。对于以上问题可按照集团无线网优中心下发的相关白皮书逐一排查。

3.1申告原因速查表

在相对较为简单的原因已经被排除后，需要分两类讨论网速慢的可能原因：第一类是检查AT是否在使用1X网络，这种情况下用户会申告长时间网速很慢；第二类是检查HRPD的会话协商属性，这类问题对整个AN下的用户均可能造成影响，用户感知的速率远低于空口所能向用户提供的带宽，下表是网速慢申告的原因速查表。 频繁掉线原因分类 特征信令或事件 问题原因 A12口信令出现“A12_Access_Reject”； AN-AAA鉴权失败 用户使用1X网络 AT上报原因值为3的ConnectionClose， AT切入1X网络 并在1X网络上起呼后建立SCH信道； HRPD会话协商属性参数配置错误 用户使用EVDO网络 HRPD会话协商属性与默认值不符； 表 1 网速慢申告原因速查表

3.2信令分析流程

? 检查AT否能通过AN-AAA鉴权

如果AT无法通过A12口鉴权，将只能使用1X网络上网，从而导致用户感知速率很低。 正常信令流程：AN首次接入网络时会产生的A12口信令，若在 A12_Access_Request后出现A12_Access_Accept消息，并在该消息中返回IMSI，则说明通过A12口鉴权，信令如图20所示。

5

图 10 AT通过A12口成功通过AA-AAA鉴权的信令

从PPP层信令看，AN-AAA会给AT发送“Success”消息，如下图所示。

图 21 AT成功通过A12口鉴权的特征信令

特征信令：本步骤需使用设备网管的信令跟踪工具跟踪A12口信令。在清除Session后观察A12口信令，如果在A12_Access_Request后出现A12_Access_Reject则表明鉴权失败，特征信令如下图所示。

图 22 A12鉴权失败

? 检查AT是否切换入CDMA 1X网络

特征信令：图23是AT从EVDO网络切换到CDMA 1X的特征信令，其特点是AT主动发出ConnectionClose，且其携带原因值为3，之后AT在CDMA 1X网络上起呼并出现补充业务信道指配消息。

6

图 23 AT从EVDO网络切入CDMA 1X网络的特征信令

如果看到以上信令，则可确定因AT从EVDO网络切入1X网络，导致用户感知上网速率慢。

? 检查HRPD会话协商属性参数

在HRPD中可能影响用户数据速率的属性参数有很多，为方便随时查询相关的属性参数，我们已经在附件4中列出了所有消息及其所属协议，以帮助优化人员在处理用户申告时快速检查可能出错的参数。

分析流程：逐一检查在AT和AN间的HRPD间的会话协商中，FTCMAC、RTCMAC等关键协议的属性参数是否为默认值，如果有非默认值的参数，则需要逐一排查。

以下举一例说明会话协商属性参数造成网速慢的现象。

信令特征：AT上报的DRC长时间为0，但该处SINR值很高，如图24所示。

7

图 24 DRCoffset14配置错误时的测试情况

检查后台网管配置中“增强前向业务信道MAC协议”、“Subtype3 RTCMAC流非QoS参数”、“Subtype3物理层协议”、“Multicarrier RTCMAC流非QoS配置参数”等发现DRCOffset14被配置为14（图25），非默认值，故怀疑该值配置错误。

图 25 DRCoffset14配置错误

依据协议，在计算DRCValue前，AT 首先根据激活集中最强导频所能支持的最大速率形成一个Tentative DRC value，然后再减去DRCTranslationOffset 属性中的对应的偏移

DRCOffsetN，得到最终发射的DRC value；DRCOffsetN是HRPD会话协商中前向业务信道MAC层协议的协商属性参数。由于此处DRC很好，但上报的DRC却是0，故应检查该BSC的DRCOffset。经查，该AN的DRCOffset14被配置为14，导致AT上报的DRC为0，将参数改为0后，上网卡在此处可以正常上网。

8

4 快速定位空口掉线

析EVDO信令时，着重分掉线前后析RU—TCA—TCC消息可达情况和Configuration Request协商消息参数、QuickConfig等开销信令辅助定位。根据大量的实测数据分析结果，总结了切换失败，控制信道消息监视失败，反向信号质量差等最常见的八种EVDO空口掉线分析模板，如表3所示，按该模板进行信令排查，即可快速定位常见问题。

表3 EVDO空口掉线快速判别与分析模板

4.1切换失败

根据RU-TCA-TCC消息可达情况，切换失败常见的原因有邻区漏配、设备原因未下发TCA、AT未能正确接收TCA和基站没有收到RU。

? 邻区漏配

第一步：网管信令跟踪是否可以看到多次RU上报消息和切换上报的PN。 第二步：检查前向信道下发的邻区列表是否包括上报的PN。

典型邻区漏配信令流程如图20所示，16:31:48-16:31:55反向连续发送4条RouteUpdate消息，前向未发送TCA消息。最后一条RouteUpdate消息中，AT上报了两个信号较强的

9

PN，分别是PN423和PN462，要求进行切换。在网管信令跟踪可以看到RU上报消息，见图21。

图20 前台邻区漏配信令

10

图21 网管邻区漏配信令

RU请求切换的扇区PN：

图22 RU请求切换的扇区PN

邻区漏配分析第二步：

检查邻区列表是否包括上报的PN，查看前向信道下发的邻区列表没有上报的PN。如图23所示，邻区列表中没有PN423和PN46。

图23 邻区列表信息

11

AT发送了多次上报Route Update消息，但都没收到TCA消息。一般为系统准入控制机制和邻区漏配所致。但准入控制机制一般在高负荷扇区下起呼或者切换到高负荷扇区下，导致呼叫建立失败，主要需要检查网管数据配置。对BTS上每一个载频扇区设置一个最大用户门限OverloadControlUserThreshold，当载频扇区中连接用户数达到规定门限，认为发生了扇区的用户数过载。

? 设备原因导致无TCA下发

第一步：网管信令跟踪是否可以看到多次RU上报消息和切换上报的PN。 第二步：检查前向信道下发的邻区列表是否包括上报的PN。 第三步：TCA消息没有下发

典型的设备问题导致无TCA下发如图24所示，PN78上报RU请求加PN132、PN207，系统未下发TCA消息允许切换，邻区配置无误。此时基站不对AT上报的RU消息进行处理，导致掉线。因此，属于设备不对RU消息进行处理的原因。

图24 设备原因导致无TCA下发

? 基站下发TCA，AT未收到

AT占用PN342，信号质量逐渐变差，后搜索到强导频PN294，上报RU消息，从后台信令看基站下发TCA消息，但由于前向信道质量差，AT未能正确解调，最终AT关闭发射

12

机，造成掉线。

图25 基站下发TCA AT未收到

? AT上报RU，基站未收到，导致TCA未下发

AT上报RU，基站未收到，在设定时间内，当终端没有收到RU等消息的应答响应消息时，将停止发送这些消息。

13

4.2反向信号质量差

? AIRLINK_LOST_TIMEOUT超时

网管信令跟踪出现A9-AL disconnected消息，并且没有A16-Session Transfer Reject消息，即不是发生在跨AN切换的时候，那么一定是反向信道问题而导致的掉线，即可确认出现反向掉线一次，如图26所示。

一般可能因为AN接收到的反向链路质量较差，此时AN侧可能因为AIRLINK_LOST_TIMEOUT定时器超时，释放连接导致掉线。当基站在给定时间里收到DRC信道的好帧数低于设定门限值时，基站会认为无线链路丢失并释放连接，从而导致掉线。这种情况常发生在突发大衰落情况，例如，移动到大楼背面，基站无法收到终端的发射信号；在设定时间内，终端无法正确解调前向链路，将停止发射。

图26 反向掉线信令判定

? TCC超时

第一步：网管信令出现A9-AL disconnected消息，且没有A16-Session Transfer Reject消息 第二步：测试发现，AT上报RU，收到TCA，AT发送TCC，AN没有收到TCC

初步判断前向存在干扰或控制信道负荷高导致TCA丢失，或者设备无TCA重发机制，AT没有正确捕获TCA，因此也不会回送TCC消息，AN等待TCC超时，释放连接，导致掉线。典型TCC超时过程如图27所示。从鼎利前台数据看，AT上报的RU消息中，预加入导频PN72。此时，参考导频PN396的导频强度为-11dB， PN393的导频强度为-7dB。基站收到AT上报的RU消息后，于15：38：13下发TCA消息，激活集导频为2个，分别为PN396和PN393。但是AT侧一直没有收到下发的TCA，也不会回TCC消息，15：38：13在控制信道上报了RU消息，同时，后台网管数据显示”A9-AL Discounected”，判断发生掉

14

线。

图27 TCC超时实例

实际网络中，常出现由于前向存在干扰，导致AT侧没有正确收到基站下发的TCA消息，最终TCC超时，导致掉线。对于此类问题，需要检查厂家建立TCA的重发机制，以保证信令传送的可靠性。此外，当存在前向强腿，反向弱腿，此时发生切换去，并且去掉的是反向强腿，则非常容易发生TCC超时的掉线。

4.3 前向信号质量差

第一步：网管信令观察，AT在业务信道，突然在接入信道上发送 Connection Request消息。 第二步：前台信令分析，前向开销信道四大类消息，QuickConfig、SectorParameter、Sync任何一条消息超过5.12S未接收。

因为后台网管跟踪不到QuickConfig开销消息，主要从前台分析。根据ping记录的掉线问题点，定位到Connection Request消息，观察掉线前的开销消息发送时间。若超过5.12S，即可定位为OM监视失败。如果发现终端没有持续上报DRC速率为0，但接收到QuickConfig、Sync消息或SectorParameter消息的间隔超过5.12s，则说明这是Overhead Message Supervision Failed管理机制生效而促使终端侧发起的掉线。此时重点检查导致前向数据信道质量瞬时深度衰落的原因。

OM监视失败典型实例如图28，从后台跟踪的信令来看，16:20:40 AT突然从业务信道

15

4.6设备未按协议规范

检查开销消息QuickConfig、Sectorparameter、Sync消息是否严格按控制信道周期发送。根据路测数据分析，有时设备未按协议发送消息，如图34所示，华为设备只间隔47毫秒便下发两条QuickConfig，AT立即关闭发射机，导致掉线。按协议规范两条QuickConfig消息之间应间隔1个控制信道周期（1个CC，426.7ms），导致AT认为协议错误，关闭发射机。

图34 QuickConfig消息发送间隔未按协议执行

21

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