1.1.1 地形环境导致弱覆盖
【问题现象】路测表现为：主被叫手机当前小区和所有邻区RSRP均小于-110dbm，无主服务小区导致SINR<-3dbm,无线环境恶化，导致掉线、切换失败、接入失败等异常事件频发。
【问题分析】结合现场环境和基站拓扑图，对周边所有基站进行逐个勘察和验证覆盖，对于地形原因导致无法彻底解决的区段，提交后续工程建设方案。
【解决方案】：
1：核查局方站点规划方案，如果有规划站点，提高建设开通优先级，如果无建设规划，提交建站方案；
2：测试2G网络陵磨锋覆盖情况，对于2覆盖良好情况下，开启SRVCC功能；同时确保2G侧FR功能开启，确保及时回落4G。
3：对于有测试考核要求的情况下，采取规避路线，减少异常事件发生概率；
1.1.2 邻区漏配导致弱覆盖
【问题现象】
DT测试中，此类问题主要表象为如下几种情况：
1. 频发A3事件而无法切换；
2. 通常伴随主被叫占用小区不同，RSRP相差较大；
3. 切换链紊乱；
4. 容易引发掉线、重建立、切换失败等事件
如下图：
【问题分析】
1：前台测试分析，核对A3事件上报小区信息是否包含在RRCConnectionReconfiguration。如未包含，则确定为漏配邻区。核对基站拓扑图，判断是否需要添加该邻区，排除过覆盖、针状覆盖小区（室分泄露小区、非道路覆盖小区等）尤其需要慎重添加，防止切换后无法及时切出问题发生。
如下图所示，两个基站相距200m，并且为相邻基站，所以建议补充邻区关系
2：后台IMSI跟踪信令分析，可以通过UDA工具筛选UnknowPciNotify，对于持续上报未定义PCI的现象要重点结合基站拓扑图来进一步确定是否添加邻区。
如下图，后台信令分析同样发现上报多个测量报告切换候补邻区为486，结合拓扑图，最终建议添加邻区关系
【解决方案】：
1：近距离相邻基站通常采用添加遗漏邻区方案；
2：过覆盖小区优先控制覆盖；
3：针状覆盖场景不建议添加，此问题一般影响较短路面，优先控制覆盖；
1.1.2.1实例1
【问题现象】
主被叫占用新开基站983529133（PCI149)后无邻区关系导致无线环境恶化；
【问题分析】
下图为主被叫占用该小区后，RSRP由强到弱，无线环境逐步恶化，A3事件频繁上报但是未发起切换，查看邻区配置发现该站仅仅配置自身2个小区为邻区关系，通过了解，此站点为新建尺晌基站，未实施单验和入网优化工作，因此在此路游卖段频繁导致掉话、重建立等事件发生
【解决方案】
1：及时开展单站优化和邻区关系补充，确保单站业务性能通过验收；
2：开通站点第一时间通知优化团队进行参数核查、邻区核查、性能测试，确保入网后正常投入网络运行。
1.1.3 站点故障导致弱覆盖
【问题现象】
测试中，此问题表现为：无法占用附近基站，会伴随邻区漏配、过覆盖情况发生，易导致未接通、掉线、切换链紊乱等现象；
如下图，基站462682位于麓枫路和咸嘉湖西路十字口，为该两条主干道主服务小区，测试到该路段后始终未占用该基站，RSRP下降到-110dbm以下，切换链紊乱，导致掉线。
【问题分析】
站点“长沙阳明山庄23栋(地华梅溪湖拉远)ZL-B8300462682PT”因纠纷暂时下网，导致周边无主覆盖小区；
【解决方案】：
需尽快恢复“长沙阳明山庄23栋(地华梅溪湖拉远)ZL-B8300462682PT”；对周边小区开启SRVCC切换。
1.1.4 越区覆盖导致无法切换
【问题现象】
过覆盖问题主要表象为：
未占用过覆盖小区情况下，当前小区可能会发生SINR恶化，伴随上报测量报告包含周边未知PCI。
占用过覆盖小区情况下，RSRP变化较大，伴随上行信号异常，邻区漏配现象，易导致掉线、接入失败、切换失败等异常事件。
如下图，手机占用PCI=121小区，enodeid=471089，无法向周边PCI=110切换，最终导致掉话；
【问题分析】
此类问题需要结合周边道路测试分析和基站拓扑关系来判断问题小区为周边哪个区域的主覆盖小区，进而采取优化手段进行调整；
如下图描述，问题点区域最近4次切换链为1、2、3、4次切换，其中2、3、4切换和PCI=121有关，同时分析周边道路主服务小区并无PCI=121,查看拓扑图发现该站位于周边较远区域，同时前往PCI=121测试发现，经纬度正确，主要原因是地势较高导致；
【解决方案】：
针对周边过覆盖小区，采用调整俯仰角、天线挂高、基站分布等手段；
对于特殊场景建设的基站，比如此案例中该站实际主要覆盖附近风景区，但是地势原因导致信号无法彻底控制，可以采取单向删除过远基站邻区，避免孤岛效应。
1.1.4.1实例1 岳华路长房和园附近长沙观沙岭消防队2小区越区覆盖
【问题描述】
UE从4625062到4620931切换不及时导致重建
【问题分析】
1、增强4625333、4620931在此处的覆盖；
2、压低4625062下倾角2-3°。
已调整4625333、4620931小区方位角及下倾角至该路口覆盖，但覆盖方向存在部分阻挡，已达最大优化调整，调整后测试效果不明显，后调整新开站点长沙岳麓大道与岳华路交叉口-3小区覆盖至该片区域，调整后覆盖得到一定增强，如需彻底解决该片区域覆盖问题，需开通该区域规划站址长沙绿洲小区景观塔。
【解决方案和复测结果】
通过上述调整，该站点及时切换到983474，越区覆盖小区此处信号减弱。
1.1.5 切换参数设置错误导致无法切换
【问题现象】
车辆由东向西行驶在茶子山，当于基站462514退服后不能及时向附近小区切换，使得该路段RSRP差，最终导致掉话。如下图
对比前期测试该路段正常，如下图：
【问题分析】
从路测占用小区来看，即使该站断站，如果可以向462576-2（PCI=259中心频点1895Mhz）切换，信号可以保持在-105dbm，不会发生掉话现象。查看未切换到462576-2原因，从路测信令来看，A2事件上报后，重配消息中没有携带该异频邻区，首先认为没有配置该邻区关系。但是后台核查邻区列表后发现已经添加该邻区，进一步排查为什么重配消息中未携带该邻区关系，发现【EUtranCellMeasurementTDD】表中的“eutranMeasParas_interCarriFreq”异频载频里面没有配置1895导致，补充添加后可以正常切换。
【解决方案】
1：主因是由于基站462514退服导致跨站切换不顺畅，因此优先解决故障站点
2：从该事件发现，如果测量参数【EUtranCellMeasurementTDD】中漏配异频频点，也会导致无法下发该异频频点邻区，即使配置了邻区关系也是无效，所以需要日常优化中定期核查【EUtranCellMeasurementTDD】表中的“eutranMeasParas_interCarriFreq”是否包含邻区定义的频点。
1.1.6 异频重定向
【问题现象】
终端上报A3测量事件后，基站直接发送重定向的RRCrelease消息，导致掉话
【问题分析】
图中可以看到，终端上发A3事件后，系统直接发送了重定向到37900的RRC release消息，导致此次掉话。
【解决方案】：
1、 通过后台参数，打开邻区切换功能，解决配置了邻区但没打开切换功能的重定向。
1.2 干扰类问题
【问题现象】
测试中一般表现为RSRP良好但SINR偏差，干扰严重区域容易导致掉线、切换失败等各类异常事件发生。
【问题分析方法】
干扰类问题涉及方面较多，有系统内干扰和系统外干扰，详细排查方法可以参考排查指导文档，这里仅仅对现场发现的案例进行描述。
1.2.1 实例1：PCI规划不合理导致
下图中，测试区域发现信号RSRP良好同时伴随SINR较差，优先排查PCI规划问题，发现近距离有同PCI基站，如下图：
1.2.2 实例2：重叠覆盖引发干扰
网格17内西二环路段存在同频基站分布密集，存在200-300米路段SINR差，此段路段发生重建概率较高，是掉话隐患点，23日测试发生1起主叫掉话。
下图圈中区域来自4个站点信号均在-95dbm~-100dbm，当切换到PCI=66/67后，SINR容易恶化，地势较为平坦，周边间距均在300-400m。
【解决方案】：
针对PCI规划不合理问题，建议重新规划和修改PCI。
针对重叠覆盖引发干扰问题，首先通过RF优化控制覆盖，减少重叠覆盖，其次采用异频组网方案解决。比如此西二环路段，PCI=66/67/68三个小区可以不用覆盖该路段，其他三个小区可以良好覆盖不同区段，引入PCI=66/67/68后易发生摸3干扰。
1.2.3 实例3：重叠覆盖引发干扰
主叫在清水路段462326附近收到近距离100m处小区4742163（PCI254)干扰，导致无法切换发起重建立，该路段基站覆盖过密集。
【解决方案】：
针对PCI规划不合理问题，建议重新规划和修改PCI。
针对重叠覆盖引发干扰问题，首先通过RF优化控制覆盖，减少重叠覆盖，其次采用异频组网方案解决。比如此西二环路段，PCI=66/67/68三个小区可以不用覆盖该路段，其他三个小区可以良好覆盖不同区段，引入PCI=66/67/68后易发生摸3干扰。
1.2.4 实例4：岳麓大道与岳华路交叉口东侧SINR值较差切换失败
【问题描述】
岳麓大道与岳华路交叉口东侧，UE占用4623813的SINR值较差，导致切换失败。
【问题分析】
1、添加4623813与983474133、4625261的邻区关系。
2、控制4623813在岳麓大道上的越区覆盖；
3、核查新开站983474133（170）背向覆盖与4750223（83）形成强模三干扰。
4、调整4623813下倾角2°至4°，方位角300°至290°，983474133下倾角2°至0°。
【复测结果】
通过控制覆盖、邻区关系优化，该路段干扰现象消失
1.3 基站版本问题
1.3.1 TM3\8切换后掉话
【问题现象】
从前台信令看掉话流程，终端的模式为TM3，然后上发A2测量，然后终端收到异频测量控制的重配消息，发送完成后下行链路失步，之后发起重建后掉话。此过程中，无线环境在RSRP -100，SINR 3左右。从后台信令分析，基站侧收到终端上发的A2，然后下发测量重配消息，紧接着发送TM8模式切换的重配消息，出现TM8的重配无法下发，用户面上报SRB1的RLC的ERRORIND导致释放而掉话
【问题分析】
12:09:14秒的重配置为TM3模式
12:09:14秒上发的是A2测量重配，然后广播消息，在12:09:26秒收到重建请求后被拒。
12:09:26秒终端上发BYE掉话。
基站侧12:09:18收到A2测量
12:09:18秒TM8模式转换的重配。
12:09:25秒出现错误的标示，该重配未下发，达到最大重传次数。
12:09:25秒文本释放。
【解决方案】：
此问题为已知版本问题，现场已升级至R5p版本，该问题验证通过；
1.4 核心网相关问题
1.4.1 QCI=5未建立
【问题现象】
主叫发起会话请求，无响应，导致未接通；
【问题描述】
主叫12:27:57发起invite，12:28:13 无响应之后未接通，检查DRB承载，发现优先级为9的承载有两条，如下图所示：
【解决方案】
HSS删除多余APN签约，之后恢复正常，如下图所示；
1.4.2 TAU过程中Paging问题
【问题现象】
10:28:22，主叫起呼发起invite request 之后QCI=1建立，被叫未收到此次呼叫的Paging；
【问题分析】
被叫10:28:23移动过程中发生小区重选，TAC改变发起TAU更新，未收到此次呼叫Paging导致的未接通事件；
此次未收到Paging是流程冲突，在寻呼的时候，收到TAU消息，我们会当做Pagingresponse处理，如果TAURequest消息中没有携带activeflag，那么用户面隧道是无法建立的，消息也无法投递
【解决方案】
核心网在下一个补丁中修正，会在TAU过程中无论UE是否携带了active flag都去建立用户面隧道；
1.4.3 从2G/3G回到4G核心网未发Paging
【问题描述】
主叫在4G起呼，被叫3G回到4G，核心网未下发Paging
【问题分析】
主叫16:23:39发起inviterequest 被叫从3G回到4G 16:23:49 ims注册成功未收到此次Paging，当用户在3G下，HSS已经做了域选择，此时用户重选到4G，是没有办法逆转的。该场景没有规范支撑
【解决方案】
核心网答复，暂时无协议支撑
1.4.4 跨TAC之后 QCI=1被删除
【问题描述】
跨TAC后，在462696-2小区15:46:24呼叫建立之2s，核心网S1ap上收到两条ERAB释放(QCI=1/QCI=5)的指示后掉话
【问题分析】
SGW把会话误删了，导致eNB收到了error Indication，然后发起了释放。现网SGW确实有个已知的问题，在“MME改变，SGW没有改变的短时间内4切3再切4”过程中，SGW会删除上下文导致用户掉线
【解决方案】
需SGW升级版本解决
1.4.5 起呼过程中伴随切换，ACCEPT消息丢失导致的QCI=1释放；
【问题描述】
终端在起呼过程中伴随切换，终端透传给核心网的ACT消息超时没有被核心网接收到导致的释放；
【问题分析】
21:01:23，主叫UE发起寻呼，被叫UE收到后发起ERAB承载，建立完成；21:01:26，被叫UE收到RRC重配置消息中要求去激活QCI1的承载，随后被叫UE上报INVITE580（precondition failure），导致本次未接通。
【解决方案】
DT消息没有等到（丢了），核心网有没有保护机制，需核心网解决；
1.5 终端异常
1.5.1 终端异常主动挂机导致未接通事件
【问题现象】
被叫向主叫发180振铃消息，主叫端也成功收到被叫180振铃消息，但在被叫发出180消息后，紧接着3秒后向主叫发406用户忙消息（见下图），核心网收到后给主叫放音，然后释放，相同的现象，两次呼叫未接通。
从信令上看，被叫发486用户忙消息，是终端主动拒绝的原因，和网络无关。至于被叫为什么在振铃3秒后发用户忙和拒绝消息，终端问题，需要终端解决。
1.5.2 终端不上报TAU请求
【问题现象】
主叫正常呼叫后从PCI=17,TAU=29580小区切换到PCI=64，TAU=29482小区后不主动发起TAU请求后RRC释放,重新接入到其它小区,3次重复这样过程后，终端主动发BYE，被叫终端TAU正常。由于对于不同TAU切换后手机终端需要上报TAU请求，此处终端始终未发起TAU，为终端原因
1.6 测试软件统计
1.6.1 异常统计掉话
【问题现象】
被叫在2G下人工释放，上报DISCONNECT，挂机流程结束，此时主叫在4G下收到IMS下发BYE，并去激活了QCI=1承载，并标记为normal call clearing，但仍会统计为dropped ，此时主叫继续正常释放流程，为软件统计问题。
1.7 eSRVCC切换问题分析
1.7.1 GSM邻区参数错误导致掉话
【问题现象】
手机在LTE覆盖弱场，收到B2测量的重配消息后，手机发起Measurementreport（B2事件）后收到网络下发的RRC Connection Release，重定向到2G后掉话。
【问题分析】
当UE上报A2测量报告后，eNB下发B2重配消息给UE，根据B2重配消息，UE测量满足B2-1和B2-2条件并上报B2事件，上报的B2事件包含准备切换的目标2G小区BCCH/NCC/BCC，见下图：
1.正常情况下，eNB收到该B2事件测量报告后下发mobilityFromEUTRACommand消息给UE，切换到该GSM邻区；
2.异常情况下网络下发RRC Connection Release消息使UE重定向到BCCH为512的GSM小区，如下图：
随后主叫重定向到GSM网络，在2G网络手机状态是空闲态，统计为掉话，如下图：
通过以上现象分析可知UEVoLTE业务eSRVCCC切换到BCCH 525(BSIC 12)的G网邻区失败，核查网管中该G网邻区参数配置，发现该邻区BSIC配置为7，与实际UE测量的BSIC 12不一致，修改网管中该G网邻区BSIC为12后，可正常切换到该小区，掉话解决
【解决方案】：
同步LTE-->GSM网络邻区定义和实际GSM网络规划数据，如上案例，LTE-->GSM邻区定义中BSCI配置为7，而实际UE测量的BSIC为12，将LTE定义GSM邻区中BSIC改为12后，正常eSRVCC。
1.7.2 切换准备失败
【问题现象】
UE空口表现为发起多次B2测量后无法进行eSRVCC，最终易导致重建立和掉话事件发生；
eNB侧表现为接收到手机上报B2测量并发起切换请求，但是收到来自核心网的切换准备失败消息；
【问题分析】
正常情况下，eNB收到该B2事件测量报告后下发mobilityFromEUTRACommand消息给UE，UE会收到mobilityFromEUTRACommand并实施切换；
异常情况下，UE发起多个B2事件而未收到mobilityFromEUTRACommand，此时可能涉及空口无线环境恶化导致B2事件测量报告未上报给eNB，需要结合eNB侧信令分析。如下图：
当eNB收到B2测报后向MME发送handoverrequire消息（为eSRVCC切换准备资源），但随后收到了切换准备失败的回复。见下图：
导致此类失败的原因通常是核心网没有对目标小区配置eSRVCC相关功能参数的原因，需要核心网检查目标网络小区相关参数是否生效或正确配置。
【解决方案】：
导致此类失败的原因通常是核心网未配置SRVCC功能、未配置目标MSC、未配置TAU等原因，需要同核心网及目标网络核查相关配置是否生效。
1.7.3 GSM邻区频点配置不全
【问题现象】
UE上报A2事件后，网络下发B2重配消息并成功上报网络后，手机RSRP满足B2-1判决门限却始终未上报B2事件测量报告，最终容易导致重定向、掉话事件发生
【问题分析】
实际网络中会存在由于无线环境的改变、G网参数优化后同步不及时或RF优化等原因，导致LTE小区的GSM邻区频点配置不够准确，对于A2重配里下发的GSM频点在终端测量后，不满足B2-2事件，导致无法触发eSRVCC。如下图：
其他可能原因：需要检查系统间邻区是否已经设置为“支持切换”，如下图
【解决方案】：
完善和及时更新LTE邻区定义中的GSM邻区关系和参数定义；
对于问题点，建议进行GSM网络扫频或者结合GSM测试数据分析，检查这些频点是否已包含在后台配置中
1.7.4 手机原因导致无法SRVCC切换
【问题现象】
主被叫手机在相同小区，主叫手机上报A2后重配消息包含B2门限和异系统频点信息，而被叫手机上报A2后重配消息未包含异系统配置信息，进而导致被叫没有进行SRVCC，主叫正常SRVCC。如下图
【问题分析】
由于一个小区下两种不同行为，首先需要排查手机上报能力，从UE附着请求消息或TAU(TrackingArea Updates)消息中发现被叫手机上报的UE能力不包含SRVCC能力消息，并描述不支持GSM频带。主叫包含，因此重点排查手机哪方面出现了异常，由于前期测试无此问题，怀疑测试期间手机误设置为锁定LTE导致，因此将手机设定为锁定LTE和支持2、3、4G模式对比验证。
下图是未锁定LTE情况下TrackingArea Updates信令描述，包含手机支持SRVCC能力指示
下图是被叫锁定LTE网络后，TrackingArea Updates信令，标示手机不支持E-GSMor R-GSM。没有支持SRVCC标示。
【解决方案】：
此类问题需要检查手机设置和实际支持能力，确保上报支持能力。
1.8 其他
1.8.1 参数配置问题导致异常返回GSM
【问题现象】
主叫手机占用462502基站发起INVITErequest和servicerequest后手机进入GSM网络发起后续接入流程。
【问题分析】
如下图所示，主被叫占用相同小区，无线环境良好，主叫无法驻留在LTE进行呼叫，被叫正常，占用其他基站无此问题，手机调换后对比测试问题依旧存在主叫流程异常，和手机关系不大。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）