网优培训交流案例大唐Word文档下载推荐.docx
《网优培训交流案例大唐Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《网优培训交流案例大唐Word文档下载推荐.docx（74页珍藏版）》请在冰豆网上搜索。
3.2案例2：
核心网问题导致未接通33
4掉话案例34
4.1案例1：
弱覆盖导致掉话34
4.2案例2：
干扰导致掉话案例分析36
5性能统计分析案例40
5.1案例1：
呼叫易失败问题定位处理40
5.2案例2：
切换掉话问题处理41
6干扰掉话44
6.1案例1：
微波通信导致干扰44
7特殊场景案例47
7.1案例1：
周围非铁路覆盖小区过覆盖问题47
7.2案例2：
新共灯基站弱覆盖问题49
8HSDPA案例51
8.1案例1：
HSDPA_PS64k业务无法分配H资源问题分析51
8.2案例2：
不同商用终端测试速率差别较大分析55
92G/3G互操作案例59
9.1案例1：
棠东东路弱覆盖问题59
9.2案例2：
棠下大片路CS域系统间切换优化60
9.3案例3：
广州东郊科技园CELL3CS切换失败问题62
1覆盖案例
邻区缺失引起的弱覆盖
1、问题描述：
在上海新翔路测试中，UE驻留在年丰-1（频点：
10088码字：
81），RSCP-95dbm左右，问题路段出现弱覆盖直至UE脱网。
2、问题分析：
分析扫频数据，发现较强信号翔方-3（频点：
10120码字：
40），检查数据库中年丰-1的邻区关系，发现年丰-1未配置翔方-3之间的邻区关系。
3、解决措施：
添加年丰-1与翔方-3之间的邻区关系。
4、处理效果：
添加邻区后由于能够顺利进行小区重选，弱覆盖问题得到较好解决。
参数设置不合理引起的弱覆盖-功率参数设置不合理
在上海祁连山路测试中，覆盖较弱，此时UE驻留在全新-1（CPI：
120，频点：
10054），在该问题路段信号很弱，PCCPCH_RSCP在-95dBm以下。
该路段距离全新基站较近，应为全新-1主覆盖。
核查数据库，发现全新-1小区功率参数设置不合理，DwPCH、PCCPCH功率设置偏小（254，即25.4dbm），主要是由于该路段的无线环境与规划仿真时的情况不同导致规划数据出现偏差。
提升全新-1的DwPCH与PCCPCH的功率以提高覆盖。
提升全新-1的功率后问题路段覆盖得到明显提升。
参数设置不合理引起的弱覆盖-切换参数设置不合理
在上海大名路测试中，覆盖较弱，此时UE占用较近的圆明园-1（频点：
10054码字：
120），但随着UE的移动，PCCPCHRSCP逐渐衰减到－95dBm以下，仍未触发切换。
核查数据库切换参数，发现圆明园-1小区异频切换门限参数中本小区绝对导频门限强度参数设置不合理（30，即-86dbm），建议调整该门限参数。
将上述参数由30->
70（即从-86dBm调整到-46dBm）。
修改切换门限参数后切换顺畅，弱覆盖问题得到很好解决。
缺少基站引起的弱覆盖
在对上海浦东大道的扫频测试中，位于罗山路、居家桥路之间路段弱覆盖，UE脱网，PCCPCH_RSCP、PCCPCH_C/I都很差，严重影响覆盖以及网络商用之后的用户感受。
测试情况如下：
注：
图中出现的部分路段没有测试数据是因为UE异常与软件失去连接所致，不影响问题分析定位。
从上图中可以看出，问题区域距离周围基站都比较远，加上建筑物等的遮挡没有小区能在该区域形成良好覆盖，从大唐移动NPS规划工具的PCCPCH_RSCP覆盖的仿真图中可以清楚的看到这一点：
在上海移动TD-SCDMA网络规划中本有栖山基站（栖山路1128号西山中学）对该区域进行覆盖，但是由于种种原因没有开通。
与业主进行协调或者在附近区域另选站点以增强该路段覆盖。
相信相关基站开通后弱覆盖问题将得到很好解决。
越区覆盖
在对上海延安路高架测试中，当测试车辆从西到东行驶到延安高架位于乌鲁木齐路、华山路之间路段时，由于延镇-2（频点：
10104码字：
63）越区与愚园-2（频点：
34）形成干扰造成虽然PCCPCH_RSCP良好但是PCCPCH_C/I很差。
由于实际无线环境比较复杂，扩频码不能完全正交，导致虽然上述两个小区的码字相关性不大，仍出现比较强的干扰。
将延镇-2的机械下倾角6°
->
9°
。
调整延镇-2天线后复测，原来干扰问题得到较好解决。
背向覆盖
上海测试中，车辆由天目西路入口进入高架，UE占用中投-3（频点：
10070码字：
108）通话，此时下行PCCPCHRSCP较好，但C/I却达到－5db以下，通话质量较差，最后出现主叫掉话。
分析测试数据，在该处梅丰-3（频点：
49）对中投-3扇区形成干扰，导致C/I较差，最终出现掉话。
实际勘察梅丰-3天线状况，发现其正对一玻璃幕墙建筑，导致该小区反向覆盖较严重，因此建议调整其天线方位角规避该问题。
梅丰-3覆盖情况如下：
将梅丰-3（频点：
49）方位角由240°
210°
对原掉话区域进行复测，测试过程中未出现掉话，原问题段的C/I值一直正常。
且在该路段，梅丰-3（频点：
49）覆盖已经较弱。
天馈实际安装与规划不一致引起的覆盖问题-下倾角安装不合适
上海测试中，在交通路由西向东测试，当行驶到交通西路路口附近时，UE占用中骊3扇区（CPI：
68，UARFCN：
10070）通话，PCCPCHRSCP在－95dBm以下。
分析测试数据结合实际覆盖情况，建议调整闸中-3（频点：
90）的机械下倾角：
5°
2°
将闸中-3（频点：
调整后，对交通路交通西路路口附近进行了复测，测试数据显示，调整后该路段覆盖得到加强，PCCPCHRSCP接收电平在－95dBm以上，能够满足正常通话。
天馈实际安装与规划不一致引起的覆盖问题-天馈接反
上海测试中，在对中打基站进行单站测试过程时，用大唐移动spananalysist工具的单小区覆盖分析功能分析中打-2、中打-3的PCCPCH_RSCP覆盖情况，发现中打-2、中打-3两个小区覆盖范围与规划不符（规划中中打3个小区的方位角依次为0，120，240）：
中打-2整改前PCCPCH_RSCP覆盖图
中打-3整改前PCCPCH_RSCP覆盖图
从上面的单小区覆盖图中可以明显看出，中打-2、中打-3小区的实际覆盖范围与规划不符：
规划中由中打-2覆盖的区域现在由中打-3覆盖，规划中由中打-3覆盖的区域现在由中打-2覆盖。
在这种情况下，必然导致按照规划配置的邻区关系存在错误以及与周围基站形成严重的干扰，影响网络性能。
按照规划调整中打-2、中打-3的方位角。
对上述小区天馈进行整改后，覆盖达到预期效果。
中打-2整改后PCCPCHRSCP覆盖图
中打-3整改后PCCPCHRSCP覆盖图
基站GPS故障引起的弱覆盖
在上海逸仙路高架测试过程中，当测试车辆行驶到长逸基站附近时，扫频仪收到长逸-2、长逸-3（频点：
119；
频点：
81）信号很强但是UE显示邻区列表中这两个小区信号很弱，在-110dbm左右；
当经过小区初搜驻留在该站小区信号后，解码其它基站邻区信号强度均在-110dbm以下。
这与与相关小区实际信号强度偏差很差。
驻留在其它基站小区后显示长逸基站小区信号弱
驻留在长逸基站小区后显示其它基站小区信号弱
仔细分析上述测试中出现的现象，发现如下规律：
驻留在长逸基站小区则UE邻区中其它基站小区信号显示与实际情况差别很大；
驻留在其它基站小区后则UE列表中长逸基站小区信号显示与实际情况差别很大，这表明长逸基站与其它基站不能良好同步，造成UE在测量时出现偏差，怀疑长逸基站GPS相关模块存在故障，经RNC机房核实长逸基站GPS果然存在告警，处于holdover状态。
更换相关故障模块。
故障模块更换后该基站小区与其它基站小区顺利重选、切换，由于该基站失步引起的UE测量失真问题得到很好解决。
UE顺利的按照淞南-2->
长逸-3->
长逸-2->
长逸-1->
东运-2进行切换、重选
UE顺利按照东运-3->
淞南-2进行切换、重选
2切换案例
切换参数设置问题
在广州RNC17进行簇集成优化测试中，从光明北路往桥兴大道的路上发生了一次掉话，从span软件测试log分析掉话时候UERSCP值非常差。
如下图所示：
从路测log数据上分析，在掉话前UE从繁华路进入光明北路，从路测图中回放反映出，UE由华海大厦1小区切换到电子公司1小区。
下图所示：
切换前服务小区切换后服务小区
当UE切换到电子公司1小区后继续往前移动，在距离电子公司基站670米、离汀沙基站160米、离富华花园基站230米处，已经满足切换条件，但UE依旧占用电子公司1小区。
如下图，电子公司1小区RSCP比较差了，但是仍然不和强邻小区切换。
UE由光明北路进入到桥兴大道后，UE依旧占用电子公司1小区，且此时电子公司1小区信号非常差了。
从下图可以看出明显没有切换：
从信令上来分析，UE一直没有发起handover－star，只是发出测量报告一直持续到drop－call。
掉话前信令如下图所示：
从前面几个服务小区和邻小区信息表，以及从RNC中查看电子公司、富华花园、汀沙等基站的邻小区列表数据，电子公司、富华花园、汀沙等基站的相邻关系并没有漏配。
而电子公司1小区邻区是完整的。
而从RNC中查看电子公司、富华花园、汀沙等基站的小区算法配置，发现HC算法参数中电子公司1的“TDD系统内切换的算法开关”属性值为“关闭”。
而一般该属性值应为“打开”。
3、解决措施
修改TDD系统内切换参数开关，由关闭改为打开设置。
4、处理效果
完成参数修改后，效果明显，切换顺利进行，如下图所示：
漏配邻区导致不切换
1.问题现象描述
11月14日下午，测试车辆沿图1-1所示方向行驶（虹梅路由南向北行驶至虹桥路后，左转沿虹桥路由东向西继续行进），此前主叫UE1经过切换过程如下：
云山1小区（RNCID：
406，CellID：
257）南国1小区（RNCID：
8209）云山3小区（RNCID：
259），UE1最终切换至云山3小区后，UE1上发Disconnect，结束了1次呼叫，回到空闲。
在间隔了约10s后，UE1占用云山3小区（RNCID：
259）启呼，RSCP在-79dBm左右。
在启呼过程中，随着测试车辆的西行，UE1在完成RAB建立，并成功收到网络侧下发的Progress消息后，由于服务小区覆盖质量的下降（RSCP衰耗至-83dBm左右），而邻区表中南国1小区（RNCID：
8209）的RSCP增强至-65dBm左右，UE1在12：
10：
49时发起2a测量报告，选择向南国1小区触发切换；
在12：
50时成功收到网络侧下发的PhysicalChannelReconfiguration消息；
随后经过约12秒的时间，UE1回到空闲状态进行系统消息的接收（期间没有触发小区更新流程），由于接续过程还没有完成（主叫正常接续流程需要在UE1上发ConnectAcknowledge后才算完成），故发生未接通1次。
图21Outum测试情况示意图
2.分析推理过程
表象分析过程
从Outum测试数据回放情况来看，正如上述的现象描述中所陈述的，问题发生在UE1从云山3小区（RNCID：
259）启呼后，在12：
49时发起2a测量报告，UE1上报的测量报告内容如图3-1所示：
图22UE1上报的测量报告内容示意图
测量报告内容显示，UE1选择向异频的南国1小区（RNCID：
8209）触发切换；
UE1在发送测量报告后，相隔1秒，在12：
随后经过约12秒的时间，UE1回到空闲状态进行系统消息的接收。
正常的切换流程如图3-2所示：
图23正常切换流程示意图
与问题流程对比，UE1在收到PhysicalChannelReconfiguration消息后，就回到了空闲模式；
显然，UE1的切换过程并没有完成，而是在切换过程中回到了空闲模式。
至此，首先需要确认的问题是UE1在收到PhysicalChannelReconfiguration消息后，为何没有回PhysicalChannelReconfigurationComplete消息？
即使UE1向目标小区的切换不成功，又为何没有回到切换源小区恢复无线链路，并向网络侧回PhysicalChannelReconfigurationFailure消息？
由于Outum软件所能看到的信令情况局限于Uu口，因此需要配合CDL进行进一步的问题定位工作。
3.深入分析过程
根据UE1在云山3小区启呼时的RRCConnectionSetup消息中包含的IE内容来定位对应的RNCID和UEID等关键性信息，RRCConnectionSetup消息IE内容如图3-3所示：
图24RRCConnectionSetup消息内容示意图
由上述查询可知，UE1的服务小区云山3小区属于RNC406、网络侧给UE1分配的本次启呼的UEID为31756；
另一方面，问题发生在下午12点-13点的时间段内，故查询11月14日RNC406下文件名为CDL12的CDL文件。
经核查，发生未接通时间段的CDL记录情况如图3-4所示：
图25发生未接通时间段CDL记录内容示意图
从CDL记录情况分析，RNC在收到UE1上发的MeasurementReport后，立即下发了PhysicalChannelReconfiguration消息；
UE1收到该消息后，与切换目标小区南国1小区完成上行同步，NodeB向RNC上发了RadioLinkRestoreIndication消息，随后大约8s后发生上行失步，并且UE1与切换源小区云山3小区也发生了上行失步；
而后，RNC收到UE上发的PhysicalChannelReconfigurationFailure消息，并立即向CN发送了IuReleaseRequest，释放了资源，最终导致未接通的发生。
分析以上过程，主要存在两个问题点：
其一，是在UE1从云山3小区向南国1小区切换过程中，UE1首先与切换目标小区南国1小区完成上行同步，但在大约8s后发生上行失步，并且UE1与切换源小区云山3小区也发生了上行失步，UE1是由于什么原因与目标小区和源小区均发生了失步？
（问题点1）
其二，是RNC在发送了PhysicalChannelReconfiguration消息后，间隔10秒左右，收到了UE1上发的PhysicalChannelReconfigurationFailure消息，而这条消息UE并没有在Uu口发出（Outum测试软件中没有记录），那这条消息是如何产生的？
（问题点2）
针对问题点2的分析过程
针对上述提出的两个问题，问题点2的原因定位相对较为容易，可以直接通过查询PhysicalChannelReconfigurationFailure消息中IE所携带的原因值得知，本次物理信道重配置失败的原因是Timeout，即超时。
PhysicalChannelReconfigurationFailure消息IE携带的原因值如图3-5所示。
图26关键消息携带的原因值示意图
物理信道重配置的计时是由本地资源配置定时器制约的，现网RNC406的该定时器配置情况如图3-6所示：
图27现网RNC406本地资源配置定时器设置示意图
目前现网RNC406中设置的本地资源配置定时器为10秒，即在RNC向UE发送了PhysicalChannelReconfiguration消息后，如果10秒内没有收到PhysicalChannelReconfigurationComplete消息，则RNC会自动模拟发送一条PhysicalChannelReconfigurationFailure消息，这与CDL实际记录的过程相符。
由此，先前问题点2产生的疑问迎刃而解，PhysicalChannelReconfigurationFailure消息并不是由UE发送的，而是由于本地资源配置定时器超时，导致了RNC模拟了PhysicalChannelReconfigurationFailure消息（IE携带超时原因），并且随后RNC触发了IuReleaseRequest消息IE中携带了“物理信道重配置超时”的原因值。
针对问题点1的分析过程
在解决了问题点2的疑问后，下一步需要分析的就是问题点1的疑问：
为何UE1在切换过程中，与切换目标小区和源小区均会发生上行失步？
一般对于失步问题的分析可以从覆盖和干扰两方面着手分析。
覆盖分析
首先，从覆盖强度来看，UE1发送MeasurementReport消息后，到UE1回到空闲模式前的无线环境情况分析（参照Outum测试情况），当时UE1服务小区云山3小区的RSCP维持在-84dBm左右，而邻区中南国1小区RSCP达到-65dBm，整体覆盖强度较好，不存在弱覆盖情况。
具体测试情况如图3-7所示：
图28Outum测试覆盖强度情况示意图
其次，从合理覆盖角度分析，问题区域周边基站分布情况如图3-8所示：
图29周边基站分布情况示意图
图3-8中清晰显示，UE1服务小区云山3小区距离问题区域大约440米左右，切换目标小区南国1小区距离问题区域在620米左右，而距离问题区域最近的并非上述的两个小区所属的基站，而是new濮家桥局基站，其距离问题区域仅137米左右。
结合Outum实际测试情况来看，在云山3小区邻区表中没有测到new濮家桥局基站各个小区的信号。
有两种可能会导致上述情况发生，第一种可能，new濮家桥局基站存在硬件故障或没有激活导致UE1测不到其各个小区的信号；
第二种可能，UE1的服务小区云山3小区与new濮家桥局基站的各个小区间没有做邻区关系，导致UE1不对new濮家桥局基站的各个小区信号进行测量。
首先，对new濮家桥局基站的工作状态进行核查，与机房核实，该基站工作情况正常；
并且，从11月14日当日KPI指标统计情况（参照表3-1）来看，new濮家桥局基站存在少量话务，虽然话务较少，但完全可以排除该基站处于未激活状态或存在硬件故障的可能性。
小区名称
Cs12.2k会话业务话务量
Cs64k话务量
Ps业务流量
new濮家桥局1小区
0.00
251.43
new濮家桥局2小区
0.01
102407.48
new濮家桥局3小区
0.72
82662.36
表2111月14日new濮家桥局基站各个小区KPI统计情况
至此，new濮家桥局基站存在硬件故障或未激活导致UE1测不到其各个小区的信道的假设不成立，该基站各个小区工作状态正常。
其次，对第二种假设进行分析，即对云山3小区与new濮家桥局基站各个小区间的邻区关系进行核查。
（由于new濮家桥基站已经割接入RNC396，故将其各个小区的基本参数列举在表3-2中。
）
RNCID
CELLID
主频点号
CPI
396
8721
10088
62
8722
10104
34
8723
10120
84
表22new濮家桥局各个小区的基本参数
核查结果如图3-9所示：
图210云山3小区邻区核查结果示意图
从核查结果来看，云山3小区与new濮家桥局基站的3个小区均不存在邻区切换关系，由此可以判定，由于UE1的服务小区与new濮家桥局基站的各个小区间没有做邻区关系，导致UE1不对new濮家桥局基站的各个小区信号进行测量的假设是成立的。
由于问题区域位于new濮家桥1小区、new濮家桥2小区主瓣交叠覆盖区域，故有必要对这两个小区对于问题区域的覆盖强度予以关注。
参照当时Outum测试的扫频情况，可以发现，扫频结果显示new濮家桥1小区的RSCP强度排在扫频最强小区列表的第一位、new濮家桥1小区和云山3小区的RSCP强度分列在第二位和第三位。
扫频结果如图3-10所示：
图211扫频测试结果示意图
以覆盖分析为基础的干扰分析
另一方面，实际Outum测试过程中，UE1切换目标小区南国1小区（ARFCN：
10088、CPI：
10）并没有出现在扫频测试的最强前6个邻区中，而南国1小区的频点与new濮家桥局1小区的频点恰好同为10088，而切换源小区云山3小区与new濮家桥局1小区间没有邻区关系。
由此，新的疑问产生了，是否由于new濮家桥局1小区与南国1小区同频，导致UE1在进行邻区测量时，受到new濮家桥1小区信号较强的干扰，将对问题区域覆盖很弱的南国1小区的RSCP测得比较强呢？
为了进一步验证上述假设，需要对南国1小区进行一个简单的覆盖评估。
通过基站数据库查询可得，南国1小区天馈挂高27M，方位角为0°
，下倾角为9°
（机械倾角+电子倾角）；
结合问题路段周边无线环境（如图3-11）观察，南国1小区与问题区域间由南向北依次有酒店、延安路高架和一片住宅区建筑群对其进行阻挡，并且南国1小区的下倾角达到9°
，由此判断UE1在问题区域测得南国1小区RSCP可达到-60dBm是一个假象，南国1小区对于问题区域的实际覆盖情况与扫频结果（可参见图3-1
升级会员 