Y省B局点核心网GUTP传输通道配置问题导致无线掉线率升高讲解Word格式文档下载.docx
《Y省B局点核心网GUTP传输通道配置问题导致无线掉线率升高讲解Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《Y省B局点核心网GUTP传输通道配置问题导致无线掉线率升高讲解Word格式文档下载.docx（14页珍藏版）》请在冰豆网上搜索。
99.95
48530
01/29/2015
1238
3441
99.97
99.54
48570
01/30/2015
1241
3448
99.55
49528
01/31/2015
1242
3450
99.99
0.17
99.56
47963
02/01/2015
3451
50694
02/02/2015
1248
3462
0.18
99.57
52270
02/03/2015
0.19
99.45
52515
02/04/2015
0.23
0.22
99.43
53583
02/05/2015
0.24
99.93
54256
02/06/2015
3464
99.9
54597
02/07/2015
0.29
0.28
99.86
53668
02/08/2015
0.25
99.6
99.89
53019
表1：
网管KPI指标统计（1月28日-2月8日）
2告警信息
无
3原因分析
1.无线掉线率指标定义
无线掉线率=（eNodeB发起的S1RESET导致的UEContext释放次数+MME发起的S1RESET导致的UEContext释放次数+UEContext异常释放次数）/UEContext建立成功总次数*100%
UE上下文异常释放包括eNodeB主动发送UECONTEXTRELEASEREQUEST消息，原因为异常的释放以及eNodeB、MME发起的S1RESET导致的UE上下文释放。
eNodeB发起的UE上下文释放异常定义：
当eNodeB向MME发送UECONTEXTRELEASEREQUEST消息，会释放UE的所有E-RAB。
当释放原因不为“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“Timecriticalhandover”，“HandoverCancelled”时，测量指标L.UECNTX.AbnormRel加1。
当eNodeB向MME发送S1RESET消息时，根据包含的上下文个数，指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。
当MME向eNodeB发送S1RESET消息时，根据包含的上下文个数，指标L.UECNTX.Rel.S1Reset.MME进行累加。
eNodeB性能指标中定义的eNodeB发起的UE上下文释放原因只有5种，分别为无线问题、UserInactivity、UELOST、切换流程失败、上行弱覆盖，指标体系并不完善。
另外性能指标中对核心网发起的UE上下文释放原因并没有进一步定义。
小区eNodeB发起的UE上下文释放原因各指标名称及描述如下：
指标ID
指标名称
指标描述
所属网元
1526728857
L.UECNTX.Rel.eNodeB.Rnl
eNodeB发起的原因为无线层问题的UEContext释放次数
BTS3900,BTS3900LTE
1526728858
L.UECNTX.Rel.eNodeB.Userinact
eNodeB发起的原因为UserInactivity的UEContext释放次数
1526728859
L.UECNTX.Rel.eNodeB.UeLost
eNodeB发起的原因为UELOST的UEContext释放次数
1526728860
L.UECNTX.Rel.eNodeB.HOFailure
eNodeB发起的原因为切换失败的UEContext释放次数
1526730863
L.UECNTX.AbnormRel.UlWeak
eNodeB发起的原因为上行弱覆盖的UEContext异常释放次数
2.性能指标统计分析：
通过对话统中定义的UE上下文释放测量指标进行统计，得到2月2日-2月11日的数据原表，各指标的UEContext的释放次数如下，可以看到eNodeB发起的UEContext释放次数没有明显的变化，反之MME发起的UEContext释放次数呈现明显的增长；
eNodeB发起的原因为无线层问题的释放次数有所浮动，但不是异常释放总数升高的主因，而原因值为其他的MME发起的释放UEContext次有明显上升（MME释放总次数-原因为NormalRelease的MME释放次数），因此从整网指标的变化情况上看，UEContext异常释放次数增多与MME发起的释放原因有关：
表3：
UEContext释放原因值统计
图1：
UEContext释放各原因值比例变化情况
3.TOP问题小区分析
选择2月5日的TOP3（XX固东爱国-HLH-3、XX辛街大官市-HLH-1、XX永昌白塔-HLH-1）问题小区进行针对性分析，提取这三站点2月5日一键式日志，并通过工具进行解析，2月5日这三个站点无异常告警、事件以及网络操作，从内部释放原因表中可以看到三个小区的掉话次数主要原因为UEM_UECNT_REL_RECV_GTPU_RESET_BEAR_REQ，占总掉线次数的80%以上，从TOP用户分析表中看到每一个问题小区下的掉线次数集中在一个TIMSI下，结合TOP终端分布可以进一步确认是否由于某类终端异常导致，但是结合三张表可以看到XX固东爱国-HLH-3下TOP终端为Coolpad8720L，但是该类终端在XX辛街大官市-HLH-1下表现正常，并且XX辛街大官市-HLH-1下的TOP终端OPPOFind7X9077，但该小区下另外一部同类型终端正常，因此判断小区异常掉线升高不是某一款终端异常导致的，而是某些TOP用户导致的：
XX固东爱国-HLH-3
表5：
XX固东爱国-HLH-3掉线内部释放原因统计
TMSI
掉话次数
上行弱覆盖
上行干扰
信号陡降
其它
XX854C27
27819
6
27813
FFFFFFFF
174
36
138
XXA55E25
27
18
9
XX8DBE09
24
XX7F1414
XX354B1F
3
15
XX0FBA13
XX962605
XX98E923
12
XX28DD19
XX51A921
其他
1710
147
180
1383
表6：
XX固东爱国-HLH-3掉线TOP用户统计
表7：
XX固东爱国-HLH-3掉线TOP终端统计
XX辛街大官市-HLH-1
表8：
XX辛街大官市-HLH-1掉线内部释放原因统计
表9：
XX辛街大官市-HLH-1掉线TOP用户统计
表10：
XX辛街大官市-HLH-1掉线TOP终端统计
XX永昌白塔-HLH-1
表11：
XX永昌白塔-HLH-1掉线内部释放原因统计
XX1DE212
3412
42
XXA17229
7
4
XX6DCD12
XX7AEF15
XX83251F
XX84880C
XX648034
XX640C3D
XX91BB18
2
57
8
43
表12：
XX永昌白塔-HLH-1掉线TOP用户统计
表13：
XX永昌白塔-HLH-1掉线TOP终端统计
4.TOP用户分析
以XX固东爱国-HLH-3为例，TMSI为D48XXC27的TOP用户，导致掉话L.E-RAB.AbnormRel.TNL内部释放原因全为UEM_UECNT_REL_RECV_GTPU_RESET_BEAR_REQ，eNodeB中对统计L.E-RAB.AbnormRel.TNL的定义为“当判断相应承载有数传且释放原因为传输层错误时”。
GTPU为用户面隧道协议，在两个端点间建立专用隧道，传输用户数据，在S1-u接口实现隧道功能，满足多个用户共享少数传输通道的需求，在X2-u接口实现隧道功能，传递数据和某些信息（如PDCPSN），空口并不涉及GTP-U协议，下面为GTPU协议层在LTE/SAE网络的示意图：
图2：
GTPU协议层在LTE/SAE网络的示意图
选取2月5日01:
14:
53的异常掉线事件分析，在此后的时间里该用户平均3-5秒左右会发生一次掉线，查看SigInfoLst，发现在第15个信令消息的记录里，eNodeB向MME发起S1MsgType:
S1AP_UE_CONTEXT_REL_REQ（10），并且释放请求原因S1Cause:
Transp|TRANSPORT_RESOURCE_UNAVAILABLE（512），在第16条信令消息里面eNodeB收到MME下发的S1MsgType:
S1AP_UE_CONTEXT_REL_CMD（11）：
图3：
无线掉线内部释放原因
图4：
SigInfoLst内容
根据掉话性能优化X板斧的规定动作，下一步进行GTPU检测，如果是GTPU请求响应超时，则需要传输和核心网共同分析，如果是GTPUErrInd，联合核心网一期分析对方发送ErrInd的原因，eNB侧可以根据信令分析说明问题过程推动核心网投入分析，由于信令查询需要提前开启，并且XX固东爱国-HLH-3非持续掉线指标恶化小区，因此需要通过对其他具有相同掉线原因的高掉线小区进行信令分析。
4处理过程
1.XX辛街阿今中寨-HLH复现掉线问题：
提取2月14日传输层问题导致的E-RAB异常释放次数（无）无线掉线TOP小区，发现隆阳辛街阿今中寨-HLH-2连续两个15分钟出现大量L.E-RAB.AbnormRel.TNL原因值的掉话，因此对该小区分析S1标口、UU标口及传输GTPU信令：
表14：
2月14日传输层问题高掉线小区统计
2.XX辛街阿今中寨-HLH-2从11点开始无线掉线率开始突然升高，13点后无线掉线恢复正常，查询告警事件日志，在1月30日后该网元无异常告警，通过操作日志发现在该时间点附近同样无异常指令下发：
图5：
高掉线时间内告警、事件、操作日志查询
3.从掉线原因统计明细中看到，XX辛街阿今中寨-HLH-2无线掉线内部原因值统计为UEM_UECNT_REL_RECV_GTPU_RESET_BEAR_REQ的最早一条信令是在11:
38:
24：
图6：
隆阳辛街阿今中寨-HLH-2最早异常时间点
4.按照11:
24时间点查询DBG日志,NO.179860（11:
13）记录的消息为PathLink可用，在NO.179861中记录的消息为gtpuPeerMtSendErrorIndMsg2TRM:
BegintosenderrorindicationtoTRM，即为对端向收发机发送了错误的指示，基站在收到错误指示后对原有承载发起释放，而TMSI为XXXXF513的用户进行MODATA业务，因此一直处于上下文的建立释放状态，协议3GPP23.007的描述，对基站收到GTPerrorindication的处理定义如下，说明基站对相应流程的处理符合规范：
5.ulLocIP=0x64XXd6fa（100.XX.214.250）,与实际配置相符，ulTriggerIpAddr=0x64XXfb05（100.XX.251.5），100.XX.251.5是对端设备的IP地址，因此需要核心网配合核查这个IP地址归属的设备，确认发送错误指示的原因：
图7：
异常事件时间点DBG日志查询
图8：
XX辛街阿今中寨-HLHDEVIP配置
6.从S1口信令消息进一步验证该问题，筛选S1AP_UE_CONTEXT_REL_REQ消息，发现连续不断的异常释放原因值均为cause=transport-resource-unavailable，并且出现异常的TMSI均为XXXXF513
7.MME发送给eNB的S1AP_INITIAL_CONTEXT_SETUP_REQ带了传输链路的信息transportLayerAddress:
01100100010101011111101100000101（6455FB05），gTP-TEID:
5D0A0F8E，与DBG消息中解出来的一致：
图9：
初始上下文建立请求中的地址信息
8.另外通过eNB侧的GTPU信令查询同样可以实现问题定位，在无线掉线异常的小区开启GTPU查询，然后查看查询结果，XX辛街阿今中寨-HLH的信令查询结果中存在大量的ErrorIndication消息，蓝框中为接收到错误指示的信息，截图如下：
9.在eNB向核心网发起上下文建立请求后，核心网侧指示了错误的传输通道，导致EPS承载一直无法建立，在反复的建立过程中不断释放连接，最终导致掉话异常升高
10.已通过信令分析及协议查询，确定产生该问题的原因不在无线侧，属于核心网侧的问题，需要核心网侧检查transportLayerAddress:
01100100010101011111101100000101（6455FB05）的设备归属，确认出现GTPU指示异常的原因。
5学习心得
本案例中出现的问题分别涉及无线侧和核心网侧，对于问题的定位依据一定要充分，便于下一步推动解决问题。
这整个问题的分析过程中得益于X板斧的思路，若在日常优化工作中遇到问题建议优先按照X板斧的checklist进行排查梳理。
升级会员 