东莞割接MME后无线掉话率恶化问题分析V2.0.docxVIP

文档名称文档密级  TIME \@ yyyy-M-d 2017-4-29华为保密信息,未经授权禁止扩散第PAGE22页, 共 NUMPAGES \* Arabic \* MERGEFORMAT 22页 东莞TAC割接后掉话恶化分析 问题描述 5.15日凌晨将TAC10250和TAC9822割接到新建的MME Pool后，无线掉话率恶化，不能恢复； 5月26日对TAC9982和TAC9243进行割接，无线掉话率也恶化，不能恢复，MME为华为设备。 前期初步分析 第一批割接的10250和9822前期分析，TOP小区均是在POOL边界；掉话主因是UE LOST。 深入详细分析 由于第一批割接伴核心网DNS数据映射错误的切换问题，本报告重点以第二批割接TAC9982/9243掉话抬升为例进行分析。 掉话原因 第二批于5月26日凌晨割接，即5月29日核心网整改DNS（解决MME间TAU更新成功率问题）后进一步恶化。主因是 UE LOST增加。 掉话TOP站分布 经过分析，掉话增多并非整个TAC所有站均有所增多，掉话TOP站分布有一定关系，目前来看属于POOL边界： 挑选新增掉话TOP站 挑选条件： 割接前每天掉话次数少于100次； 割接后新增掉话次数排序，挑选TOP，确保目前跟到的掉话信令基本都是属于新增的掉话。 掉话信令 经过跟踪典型TOP站分析发现，新增的掉话信令具有明显的共性特征：均是S1切换到目标侧后在几百毫秒内掉话。 典型信令如下： 统计切换入的eNodeBID发现均是其他POOL的TAC切换入本TAC。 信令深入分析： 用户首先从东莞大新围站点Attach接入。 通过wireshark解析分析发现给该用户分配的M-TMSI为:D71A1421 切换到目标侧手机立马掉话，eNodeB 10秒不活动定时器超时释放 UE LOST。 其实该UE切换到国龙工业区后立马掉话后，又立马重新在大新围站点Attach接入。 从其携带的M-TMSI信息可以确认是同一个用户。 但是UE切换到目标侧国龙工业区后，又立马掉话，原因为UE LOST。 POOL边界：整个流程如下： 该问题与已知问题相同 掉话率恶化点出现TAC边界区，目前怀疑掉话是因为个别终端被核心网用#15 no suitable cells in tracking area拒绝，终端将该TAC记录在forbidden tracking areas for roaming列表中，导致终端后续连接态切换到forbidden TAC区域内的小区后UE自动???话。 针对该怀疑点的理论分析及协议原理摘录如下： （1）终端在发起Initial NAS流程（TAU/Attach/Service request）时，MME可能因为网络侧异常（如：宜昌出现的DRA改造异常，导致MME与HSS间diameter消息交互异常；或者核心网改造恢复过程中时序配合问题等）这里就不要了吧 ，而发送携带#15原因值的TAU reject/Attach reject/Service reject，此时UE会将当前TAI记入forbidden TA列表: 24.301： （2）TA forbidden列表会在UE关机/USIM卡移除/UE内部维护的周期定时器（12~24小时间）超时后，才会清除掉 24.301： （3）而后处于该forbidden TA边界区的UE可能接入到相邻的TAC小区中进行业务，但forbidden TAC的邻区信号在满足条件后，UE会在连接态切换到forbidden TAC的邻区，切换到目标邻区（UE在目标小区发送切换完成消息RRCConnectionReconfigurationComplete）后，搜索目标小区的SIB（含TAI信息）后，才发现该小区属于forbidden TA小区，所以，UE自行掉网离开了目标小区，导致目标小区掉话。 协议规定UE是在切换完成后，才发起SIB消息捕获： 36.331： 5.3.5.4? Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover) TAI信息是在SIB1消息中发送的： 实验室验证被#15号原因值拒绝终端表现 实验室构造模拟复现场景： 源站：PCI=159，TAC=1 目标站：PCI=158，TAC=5（TAC=5被构造成TAU失败以15号原因拒绝） 成功复现出，终端被拒绝后的表现： 只有158的信号时，被拒绝后终端被释放RRC连接后，无法入网，终端侧显示不停地在搜信号，最后显示无服务。 从159切换入158时，网侧必现掉话，概率100%。 禁止TAI列表 终端被网