HC_UE连续发多次测量报告问题分析报告

目    录

1.      问题现象描述... 3

2.      数据呈现及数据附件... 4

3.      分析推理过程... 5

4.      问题结论、优化措施、优化前后效果对比... 10

5.      总结该类问题一般分析优化思路... 10

1.        问题现象描述

某日测试中，UE2在RNC390的申泉-3（CPI97，UARFCN10120）上起呼，做CS长保业务，呼叫号码为12121，UEID=17306，行驶方向如图中红色箭头所示。UE在切换到雅典-1（CPI61，UARFCN10088）后，由于信号强度的变化，上报了7条2A Measurement Report，但是一直没有收到网络侧的重配命令，38秒后收到 disconnect，随后释放RRC连接。

图表 1 Analysis窗口

图表 2 信令窗口

2.        分析推理过程

空口没有看到切换命令，那么RNC是否发出了切换命令呢？

这就需要借助call trace看网络侧有没有下发切换命令。

查看RNC390在16时的trace（按照UEID过滤，UEID=17306）：

图表 3 call trace截图

从上图可以知：UE在成功切换到雅典-1（CELLID=401）之后，网络侧下发测量控制后到收到CN的DIRECT TRANSFER(DISCONNECT)之间的2分2秒内没有任何信令过程。

网络侧看不到测量报告，有没有可能是空口有问题导致测量报告没有发上去呢？

从空口信令（图表2）和网络侧的trace数据（图表3）看不到失步和层二的错误，所以可以排除空口的问题。

既然不可能是空口的问题，那么问题出在哪里呢？这就需要看测量报告消息是如何发送的。

我们来分析一下一条测量报告消息是如何发送到RNC的：

测量报告消息是RRC层的消息，UE的RRC层把这个消息发送给底层，经过底层的多次分段/组装和处理后经过空口发给网络侧，网络侧对接收到的数据进行组装/分段和处理后发给高层，这些数据发到RRC层后就是可以通过信令解析工具（LDT）解析为测量报告消息。

RRC层下面就是RLC层，RLC层的功能实体分为UM RLC 实体、TM RLC实体和AM RLC实体，分别对应RLC-UM、RLC-TM和RLC-AM模式的数据。

Measurement Report消息是RLC-AM模式消息。

RLC-AM模式的发送机制为：发送端在发送一个数据以后会等待接收端返回的确认，发端通过这个确认来判断先前发送的数据是否在对端已经完整的接收从而决定是否进行重传：如果完整并正确接收就从发端的重传buffer中删除对应的数据；如果对端没有完整并正确的接收，就需要重传对应的数据。如果达到重传的最大次数，某一个数据还是没有得到对端的确认的话，RLC层就不再重传数据包，而是启动一个reset过程：启动reset重传定时器；向对端发送一个reset消息，等待对端对reset的确认。收到确认就认为链路恢复了，重新开始数据的传输。如果reset定时器超时没有收到确认会根据设定的reset最大次数进行下一次的reset（同时重启reset重传定时器）。考虑最差的情形：reset的次数达到最大值且reset重传定时器超时仍没有得到接收端的确认，发送端RLC控制实体就会认为链路不能再恢复，从而向RRC层上报不可恢复错误（UE检测到这个错误指示就会进行小区重搜，触发RLC不可恢复错误原因的小区更新。RNC检测到这个错误指示就会触发RNC向CN发Iu release request。）。RLC层通过这样的机制就可以保证RLC-AM模式的数据在两个对等的RLC层之间可靠的传输。

以Measurement Report为例，典型的RLC-AM模式消息其传输数据流如下图所示：

图表 4 RLC-AM消息传输模式

本案例中由于在收到DISCONNECT消息之前UE和RNC都没有物理层失步和RLC不可恢复错误的相关消息出现，因此可以认为UE底层与RNC底层之间的传输是可靠的。也就是说测量报告消息不可能在UE的RLC层到RNC的RLC层之间丢失。

现在的情况是：我们通过Outum /Analysis在UE的RRC层看到了Measurement Report消息，但是从call trace看在RNC的RRC层没有收到。如下图所示：

图表 5 测量报告传输

由上图可以看出，只要是UE的RRC到RLC出现问题或者RNC的RLC到RRC之间出现问题都有可能导致我们看到的这个现象的发生，因此根据现有的数据无法深入定位RNC有没有收到测量报告消息。

回到空口的消息窗口，看到disconnect之后的释放过程比较异常：

本次空口的释放过程：

图表 6 本次释放信令过程

正常的网络侧释放过程：

图表 7 网络侧释放的正常流程

对上述过程说明如下：

a、    CN下发disconnect消息，同时启动NAS层定时器T305；

b、    UE收到RNC转发的disconnect消息后：停止所有正在运行的呼叫控制定时器；向网络回release消息；启动NAS层定时器T308；

c、    CN在T305超时之前收到UE的release消息：停止T305及其它正在运行的呼叫控制定时器；下发release complete消息；释放MM连接；进入空闲态。

d、    UE在T308超时之前收到CN的release complete消息，停止T308和其它正在运行的呼叫控制定时器；释放MM连接；进入空闲态。

网络侧释放过程中定时器超时的处理：

a、    CN侧T305超时，下发release消息，同时启动T308；

b、    UE侧T308超时，重传release消息，同时重启T308，T308第二次超时，释放MM连接，UE进入空闲态。

相关定时器的设置：

T305（网络侧）：30s协议规定值；

T308（网络侧）：10s运营商设置值；

T308（UE侧）： 30s协议规定值；

本案例中的网络侧的释放过程：  

图表 8本次网络侧释放过程

对照空口和网络侧信令（图6和图8），本次释放的信令流程如下：

a、  CN下发disconnect，同时启动等待定时器NAS层的T305，等待UE的release消息；

b、  UE收到disconnect，向网络侧回release消息，同时启动NAS层定时器T308，等待网络侧的release complete消息；

c、  CN的T305 30s超时没有收到UE的release，下发DIRCET TRANSFER（release），同时启动NAS定时器T308，给计数器置1；

d、  UE T308 30s超时未收到release消息，释放MM链接，启动一个10s定时器，定时器超时上发Signalling Connection Release Indication消息；

e、  CN的T308定时器超时，下发一条DL DIRCET TRANSFER（release）消息，计数器加1；

f、   UE收到release消息，上发RRC status消息指示UE没有与CN的CS连接；

g、  CN的T308再次超时，计数器为2，发Iu release command消息释放Iu信令连接；

h、  RNC释放RRC连接（未能收到UE发的RRC Connection Release Complete消息）；

i、   UE收到RRC Connection Release消息，向网络回RRC Connection Release Complete消息。

根据协议，disconnect、release、RRC Connection Release (DL-DCCH)、Signalling Connection Release Indication和RRC status都采用RLC-AM传送。

由此可以看出释放过程中UE发送的RLC-AM消息（release、Signalling Connection Release Indication）在RNC的RRC层没有收到，导致了CN侧对应的定时器超时。

综合前述测量报告消息RNC的RRC层收不到和上述异常释放过程两个情况，我们可以得出一个规律：从UE的RRC层发出的RLC-AM消息都到不了RNC的RRC层。我们可以定位问题是发生在UE的RRC层到RLC层和/或RNC的RLC的到RRC的这两个地方。

由于不能解析UE层二的消息和RNC的层二的消息，无法进行深层次的定位。

3.        问题结论、优化措施、优化前后效果对比

问题结论：

本案例中从Uu口看到手机多次上报测量报告，没有收到网络侧的响应，最后网络侧释放。通过对测量报告消息的发送机制以及后面释放过程中的异常现象的分析可以 定位到UE的RRC层到RLC层和/或RNC的RLC层到RRC层的传递可能有问题。

优化措施：

由于网优日常的数据采集工具只能解析UE和RNC的RRC层以上信令，因此本案例的更进一步定位需要RNC研发和UE研发支持。

4.        总结该类问题一般分析优化思路

在这个案例中，我们从空口看到UE多次上报测量报告网络没有处理，最后网络侧释放。通过查看RNC的call trace发现RNC的RRC层没有收到测量报告，进一步对空口的LOG和网络侧的call trace消息进行对比，我们发现UE在切换到雅典-1后所有上行的AM信令都到不了RNC的RRC层，由于AM模式是一种需要对端对接收的消息进行确认的一种传输模式，结合底层没有失步以及重传定时器超时的情况，我们认为UE的RLC层到RNC的RLC层之间是没有问题的，问题有可能出现在UE的RRC层到RLC层和/或RNC的RLC层到RRC层，更进一步的定位需要终端和RNC的研发抓取底层的消息来分析。

本案例中问题发生在UE内部处理或者是在RNC内部的处理上，属于设备问题，日常的网优工作很少能遇到这样的情况，不作为日常优化问题定位要考虑的方面。但是考虑到TD目前的设备尚不成熟，因此建议现阶段在问题定位中对于所有可能的地方都要考虑到，尽可能的发现设备与终端存在的问题，促进设备与终端的日趋成熟。

从空口看到测量报告发出去后没有收到切换命令的问题，依据网络侧RRC层有没有收到可以分为两个方面：

A.     RNC的RRC层没有收到测量报告消息；

a)         UE的RRC层没有发给RLC层；

b)        物理层失步或者RLC层重传导致RNC侧没有收到；

c)         RNC的RLC层没有将消息发给RRC层；

B.      测量报告收到后处理问题；

a)         测量报告不符合切换门限；

b)        重定位过程中目标RNC侧重定位准备失败；

c)         在切换保护时间内收到测量报告RNC不予处理；

d)        在目标基站/小区分配资源失败；

e)         其它原因导致的RNC不下发切换命令

f)         网络侧下发切换命令UE没有收到；

g)        其它的情况；

总结此类问题定位的流程图如下图所示：

图表 9 测量报告无响应定位流程

第二篇：测量分析报告

测量分析报告

Xx技术有限公司 （内部保密文件 仅限内部使用）

文档密级：机密 受控类别：受控

文档状态：[ ] 草案 [√]正式发布 [ ]正在修订

目 录

第 1 章 引言 ......................................................................................................................... 1

1.1 目的 ......................................................................................................................... 1

1.2 读者 ......................................................................................................................... 1

1.3 参考文件 ................................................................................................................ 1 第 2 章 测量分析报告 ....................................................................................................... 1

2.1 测量目标与范围 ................................................................................................... 1

2.2 测量执行情况 ....................................................................................................... 2

2.3 测量结果分析 ....................................................................................................... 2

2.3.1 客户满意度 .................................................................................................... 2

2.3.1.1 产品满意度 ............................................................................................ 2

2.3.1.2 满意度客户分布情况 .......................................................................... 2

2.3.2 产品质量 ........................................................................................................ 2

2.3.3 客户服务质量 ............................................................................................... 3

2.3.3.1 客户需求受理 ....................................................................................... 3

2.3.3.2 故障处理 ................................................................................................ 3

2.3.4 过程质量 ........................................................................................................ 3

2.3.4.1 组织整体过程质量趋势 ..................................................................... 3

2.3.4.2 各类过程的质量趋势 .......................................................................... 3

2.3.4.3 各部门/项目的过程执行情况 ........................................................... 3

2.3.5 组织生产率 .................................................................................................... 3

2.3.6 项目管理 ........................................................................................................ 3

2.3.7 培训 ................................................................................................................. 4

2.3.8 其它 ................................................................................................................. 4

2.3.9 综合分析 ........................................................................................................ 4

2.4 改进建议 ................................................................................................................ 4

第 1 章 引言

1.1 目的

{介绍测量分析的目的}

{括号的内容在正式文件中删除}

1.2 读者

{说明本文件的读者}

1.3 参考文件

?

《NKS_CMMI_ZC_0302_组织测量指标库》

第 2 章 测量分析报告

2.1 测量目标与范围

{介绍测量分析的目的，测量目标、相应的测量类别及测量项等，可直接参见组织测量计划《NKS_CMMI_ZC_0302_组织测量指标库》}

2.2 测量执行情况

{附表说明各部门提交的测量分析报告，

并简要描述测量执行情况，测量过程存在的问题，需改进事宜等。}

2.3 测量结果分析

{进行测量结果分析，反映组织当前状态，通过可能的均值比较、趋势分析、历史数据类比等，了解变化趋势，以找到改进机会。并将测量结果与组织指标值进行比较，判定是否达标，给出结论，对于偏差比较大的，进行或提示相关部门进行原因分析并进行必要的纠正。}

2.3.1 客户满意度

{说明调查背景：调查客户选样、调查方式、调查对象、调查指标等。调查结果说明，分析目标完成情况，并与历史数据对比，进行趋势分析。}

2.3.1.1 产品满意度

{按均值和各产品进行产品满意度目标及各调查指标实现情况说明，与历史数据对比，进行趋势分析，针对测量结果必要时进行原因分析}

2.3.1.2 满意度客户分布情况

{说明各客户类别的满意度分布情况，分析是否符合客户分级体系的配套措施要求}

2.3.2 产品质量

{对其它开发类（产品开发类、合同开发类）产品的缺陷密度均值进行趋势分析，与目标值进行对比，必要时进行原因分析}

2.3.3 客户服务质量

{从客户需求受理和故障处理时长两方面进行分析}

2.3.3.1 客户需求受理

{从需求受理总数、需求接受率、需求实现率、需求答复时间、需求实现时间等方面说明需求受理情况，进行趋势分析，并就需求答复时间、需求实现时间按需求受理类别和客户分类进行分析，必要时进行原因分析}

2.3.3.2 故障处理

{从故障处理数量、平均故障处理时长说明故障处理情况，就故障处理时长进行趋势分析，必要时进行原因分析。}

2.3.4 过程质量

{通过过程符合度说明组织整体过程质量趋势、按过程类别进行质量趋势分析，按项目/职能部门和进行平均符合度分析。必要时进行原因分析。}

2.3.4.1 组织整体过程质量趋势

2.3.4.2 各类过程的质量趋势

2.3.4.3 各部门/项目的过程执行情况

2.3.5 组织生产率

{按项目类别分析生产率状况、趋势变化。必要时进行原因分析。}

2.3.6 项目管理

{按项目类别从项目估算偏差、工作量分布、评审质量、评审效率、测试质量、需求变更等及其它方面分析项目管理的状况。}

{从几个方面分析其它开发项目的项目管理状况：

1. 其它开发项目进度、工作量、规模等估算偏差情况、及变化趋势；

2. 项目总工作量、软件工程活动工作量占比分布、占比变化趋势分析；

3.

4.

5.

6. 评估项目需求、设计、编码评审的有效性和效率及变化趋势。 做需求变化情况分析 做测试质量的分析 其它}

2.3.7 培训

{说明培训状况，对人均培训学时、人均培训费用、讲师合格率等做趋势分析，评估实际培训是否覆盖各部门提出的培训需求，是否满足公司现阶段的需求，培训费用是否控制在年度培训预算内，进行必要的原因分析。}

2.3.8 其它

｛做组织其它方面的数据测量分析，若无，删除本节｝

2.3.9 综合分析

{对所有指标进行可能的综合分析，说明内在关联、因果关系，寻找改进机会，如：产品质量与过程质量、产品满意度的关系，客户服务质量与服务满意度的关系等。}

2.4 改进建议